tdd-cyclelisted

# TDD Cycle Write the test first. Watch it fail. Write minimum code to pass. Then refactor. **Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing. **Violating the letter of the rules is violating the spirit of the rules.** ## When This Applies **Always:** - Sprint task implementation (`kind: feature`) - Bug fix and hotfix work - `/ship-quick` changes that touch production code - Refactors that change observable behavior **Hard exceptions** (still follow the spirit; check with the user before deviating): - `kind: research` tasks — no code commit; output is a findings doc - `kind: operational` tasks — deliverable is captured run output, not new test+code - Throwaway prototypes the user explicitly marked as such - Generated code (the generator should have its own tests) - Pure config files If you find yourself thinking "skip TDD just this once" for any other reason — stop. That is rationalization. Apply the cycle. ## The Iron Law ``` NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST ``` If you wrote code before the test: - **Delete it.** Start over from the test. - Don't keep it as "reference" — subconscious work-backwards from it is hard to avoid. - Don't "adapt" it while writing the test. - Don't peek at it. - Implement fresh from the test you just wrote. Period. ## The Cycle ``` RED → GREEN → REFACTOR → repeat ``` ### RED — Write a failing test 1. **Read the acceptance scenarios** in the task file's `## Acceptance Crit