tdd-implementationlisted

# TDD implementation No production code without a failing test or failing check first when behavior changes. A test written after the code passes immediately and proves little: it never demonstrated that it can catch the missing behavior. ## The cycle 1. **RED**: write one minimal test or check for the next required behavior from the task record. 2. **Verify RED**: run it and confirm it fails for the expected reason. 3. **GREEN**: write the smallest production change that passes. 4. **Verify GREEN**: run the focused check, then the task's Required Checks. 5. **REFACTOR**: clean names and duplication while everything is green. Keep the RED output. The implementation summary needs it under [[verification-evidence]]. For bugfixes, RED is the reproduction of the bug. For review revisions, RED covers the gap identified by [[review-and-accept]]. If production code already exists before its test, temporarily disable or revert the behavior, watch the new test fail, then restore the behavior. Otherwise the test is unverified. ## Test through a public seam Use the highest useful public interface that exercises the behavior: - service or repository method, - API route, - CLI command, - rendered component, - user-facing workflow. Assert observable behavior, not private helper calls or internal fields. Prefer real collaborators over mocks where practical. ## Vertical slices Do not write a batch of imagined tests and then a batch of implementation. Run one behavior at a time: