tdd-looplisted

# TDD Loop For an agent, a failing test is the one spec that cannot be argued with. Code that "looks correct" is a hypothesis; a green test that was red five minutes ago is evidence. The loop exists to stop "looks done" from quietly replacing "is done". ## The loop 1. **Write the smallest failing test** that captures the next slice of the requirement. For a bug: write the test that reproduces it. One behavior per test. 2. **Run it and watch it fail for the right reason.** The failure must be the assertion you wrote, not an import error, a typo, or a missing fixture. If the test passes immediately, stop: either the behavior already exists or your test is not testing what you think it is. Both are worth knowing before you write code. 3. **Write the minimum code to make it pass.** Resist building the general solution for requirements that do not exist yet. Minimum code keeps the diff reviewable and the design honest. 4. **Run the test, then the surrounding suite.** Your new green means nothing if you turned three neighbors red. 5. **Refactor while everything is green,** then commit. Small green commits are your save points. 6. Repeat until the requirement is covered. ## Anti-cheating rules These are where agents most often go wrong, so hold the line: - Never weaken, delete, or comment out an assertion to get to green. If the assertion is wrong, say so explicitly and fix the test as its own visible step, not as a silent casualty of the implementation. - Never mock the unit