test-driven-development

# Execute → Implementing a feature or bugfix under TDD Route `strict`? → **No production code without a failing test first.** Gate: medium/high complexity? → route to brainstorming or writing-plans first. Mode: `auto` chooses strict/light/skipped by risk; `off` disables automatic TDD, not completion verification. Cycle: RED (write test → watch it fail) → GREEN (minimal code → watch it pass) → REFACTOR (clean up → keep green) Regression: shared module → related tests. contract change → producer + consumer. core logic → old + new tests. Ripple signal hit → cover producer+consumer or real user path before claiming green. → Done when: chosen TDD Route is recorded, strict-route tests pass, TDD preflight gate passed when applicable, pre-edit complexity risk was checked for non-trivial source edits, and `verification-before-completion` has fresh evidence. # Test-Driven Development (TDD) ## Overview Write the test first. Watch it fail. Write minimal code to pass. If you didn't watch the test fail, you don't know if it tests the right thing. TDD Mode has two values: `auto` and `off`. `auto` lets Aegis choose a `TDD Route`; `off` disables automatic TDD routing but never disables `verification-before-completion`. ## When to Use New features, bug fixes, refactoring, behavior/logic changes, interface/data contract changes, cross-module or shared module changes, core logic refactors. Exceptions (ask your human partner): throwaway prototypes, generated code, config files,...