slipway-tddlisted

# Test-Driven Development ``` IRON LAW: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST ``` ## Purpose Apply a strict RED → GREEN → REFACTOR loop so implementation never gets ahead of verification. This is a technique skill used by execution hosts; it does not replace governance gates such as `slipway-tdd-governance`. It is not a suggestion for code changes. ## Workflow Outline 1. RED: write one failing test and make the failure clean. 2. GREEN: make the smallest implementation change that turns RED into GREEN. 3. REFACTOR: improve structure only while the full relevant test set stays green. 4. Repeat one behavior slice at a time. ## Detailed Process ### Phase 1: RED — Write One Failing Test 1. Identify the smallest behavior slice to implement next. 2. Write ONE test that asserts the expected behavior. 3. Run the test. It MUST fail. 4. If it passes: either the behavior already exists (verify) or the test is wrong (fix the test). 5. If it errors (compile/syntax): fix the error until you get a clean FAIL (assertion failure, not crash). **The test defines the contract.** Once written, the test is the specification. Do not modify it during GREEN phase. ### Phase 2: GREEN — Smallest Possible Change 1. Write the MINIMUM code to make the failing test pass. 2. Do not write "clean" code. Do not write "complete" code. Write the smallest change. 3. Run the specific test. It must pass. 4. Run nearby regression tests. They must still pass. 5. If regressions appear, fix them while k