test-first-implementationlisted

# Test-First Implementation ## Goal Drive implementation from observable behavior: write a failing test, make it pass with the smallest change, then refactor without changing behavior. ## When to use - The user asks for TDD, red-green-refactor, test-first implementation, or regression-first work. - A feature can be expressed as observable behavior, API output, UI state, CLI output, or integration behavior. - A bug fix should start with a failing regression test. ## When not to use - The repo has no runnable feedback loop and the user only needs a prototype. - The task is documentation-only or configuration-only. - The user explicitly asks for implementation without adding tests. ## Inputs to inspect - User story, acceptance criteria, bug reproduction, or expected behavior. - Existing tests, test helpers, fixtures, and package scripts. - `docs/agents/validation.md` when present. - Nearby production code only after selecting the behavior boundary. ## Workflow 1. Identify the smallest vertical behavior slice. 2. Choose the most stable observable test boundary; avoid testing private implementation details. 3. Write or update a test that fails for the right reason. 4. Run the focused test and capture the red result. 5. Implement the minimum production change. 6. Run the focused test again and capture the green result. 7. Refactor only if it improves clarity without broadening scope. 8. Run the smallest relevant validation suite. ## Safety rules - Do not test private he