test-driven-development

1# Execute
2 
3→ False-positive entry on a native-direct-skill host? → **Exit immediately unless the user explicitly asked for TDD or the conversation already contains `TDD Route: strict`.**
4  In `off` mode, do not start RED / GREEN / REFACTOR from generic bugfix, contract, shared-module, or risky-code wording alone.
5  Hand control back to `using-aegis`, `systematic-debugging`, `writing-plans`, or the fast path with verification.
6→ Implementing a feature or bugfix under TDD Route `strict`? → **No production code without a failing test first.**
7  Gate: medium/high complexity? → route to brainstorming or writing-plans first.
8  Mode: default `off` disables automatic TDD, not completion verification; `auto` chooses strict/light/skipped by risk.
9  Change Necessity: before strict RED/GREEN enters production edits, confirm the slice really needs a code change.
10  Cycle: RED (write test → watch it fail) → GREEN (minimal code → watch it pass) → REFACTOR (clean up → keep green)
11  Regression: shared module → related tests. contract change → producer + consumer. core logic → old + new tests.
12  Ripple signal hit → cover producer+consumer or real user path before claiming green.
13  GREEN proves the currently expressed behavior slice only.
14  GREEN does not by itself prove parent-task acceptance, business-value completion, or final completion.
15…