test-driven-developmentlisted

# Test-Driven Development The test is an executable statement of behavior, not a coverage decoration. ## Red-green-refactor 1. **Red:** name one behavior and write the smallest test at the highest seam that can fail for the missing behavior. 2. **Verify red:** run the focused command. Confirm it fails because the behavior is absent, not because of a typo, broken fixture, or setup error. 3. **Green:** implement the simplest production change that makes the test pass. Do not add speculative options or unrelated cleanup. 4. **Verify green:** run the focused test and relevant existing tests. 5. **Refactor:** improve names, duplication, and boundaries while keeping the suite green. Add the next behavior only after the current loop is stable. ## Honest tests - Assert user-visible or contract-visible behavior, not private call counts. - Prefer real collaborators; mock only an expensive, nondeterministic, or unavailable boundary and state why. - Make failures diagnostic: clear name, small fixture, one cause. - Include error, empty, boundary, retry, ordering, and permission cases when they are part of the contract. ## Exceptions For a prototype, generated output, or docs-only change, state why test-first is not useful and choose another observable check. “I will test later” is not an exception for production behavior. Use [test-design.md](references/test-design.md) when the test seam or fixture quality is unclear. Pair with `root-cause-debugging` for an existin