test-driven-developmentlisted

# Test-driven development Use before implementation for any new feature, bug fix, refactor, or behaviour change. Exceptions require the user's explicit approval: throwaway prototypes, generated code, configuration files. ## The Iron Law **No production code without a failing test first.** If you find yourself writing implementation before a test, stop. Delete what you wrote. Start over with the test. ## The mandatory cycle ### 1. RED — write one minimal failing test Pick the smallest behaviour change that moves the feature forward. Write a test for it. One test, not five. The test asserts the behaviour you want; the minimum assertion that would be wrong if the behaviour were wrong. ### 2. Verify RED — actually run the test and see it fail Run the suite. Read the failure message. Confirm the test fails **for the right reason** — the assertion, not a syntax error, not a missing import, not a typo. A test that fails for the wrong reason isn't RED. It's a broken test dressed up as RED and will pass once you accidentally fix the typo. ### 3. GREEN — write the simplest code that passes The goal here is not elegance. The goal is to make the test pass with the minimum change. Hardcoded return values, stubs, and "obviously wrong but passes this test" implementations are allowed. The next test will drive out the generalisation. ### 4. Verify GREEN — the whole suite, no warnings Run every test. All pass. No new warnings. No skipped tests. If anything is off, that's a signa