test-driven-developmentlisted

# Test-Driven Development Red → green → refactor, with one addition that makes it more than a habit: **the red step is a ledger pin.** A test written first is a claim about required behavior, and this package already has a place where required behavior lives — `acceptance_criterion`. Writing the test without recording the pin gives you TDD that forgets; recording the pin without the test gives you a criterion nothing enforces. Do both, in that order. ## The loop 1. **Pin the criterion.** Before writing code, the outcome exists as an `acceptance_criterion` pin whose `to_be` is the observable behavior. It came from the interview (greenfield) or from a `defect` you are closing (rescue). If there is no pin, stop — you are about to build something nobody elected. 2. **Write the failing test.** It must fail for the *stated* reason. A test that fails because the import is broken proves nothing about behavior. 3. **Watch it fail.** Run it. An unobserved red step is an assumption, and this package makes assumptions vetoable rather than silent (`references/core/assumptions.md`). 4. **Write the minimum that passes.** Not the design you plan to end at — the minimum. The design lives in the contract; this step only satisfies the criterion. 5. **Watch it pass, then refactor** with the test as the harness. 6. **Only now** may the pin move toward `resolved` — and `verification-before-completion` decides whether it actually gets there. ## The rule this skill exists to