CLAUDE: codify TDD-for-bug-fixes discipline
Bug fixes are red-then-green: write a failing test that pins the symptom, make the smallest change that turns it green, keep the test as a permanent regression. No fix without a test. Bug fixes do not need orchestrator permission — when a bug is unambiguous (build broken, fixture crashes, refcount underflow, observable wrong output), the fix is autonomous orchestrator work. The user directs features and priorities; bug fixes are mechanical work that ships when the bug is found.
This commit is contained in:
@@ -144,6 +144,33 @@ session.
|
|||||||
The default mode is autonomous. The notification is the
|
The default mode is autonomous. The notification is the
|
||||||
exception, not the rule.
|
exception, not the rule.
|
||||||
|
|
||||||
|
## Bug fixes — TDD, always
|
||||||
|
|
||||||
|
Every bug fix is test-driven. Concretely:
|
||||||
|
|
||||||
|
1. **Red first.** Before touching the fix, write a test that
|
||||||
|
demonstrates the bug — it must fail on the current code,
|
||||||
|
ideally with output that pins down the symptom (segfault,
|
||||||
|
wrong stdout, refcount underflow, panic). If a minimal
|
||||||
|
reproducer already exists (e.g. handed back by the bencher
|
||||||
|
or debugger), shape the test around that.
|
||||||
|
2. **Green second.** Make the smallest change that turns the
|
||||||
|
red test green. No surrounding cleanup, no opportunistic
|
||||||
|
refactor; the fix is the fix.
|
||||||
|
3. **Keep the test.** It stays as a regression — never delete
|
||||||
|
it after merging. Future iters that touch nearby code
|
||||||
|
exercise it automatically.
|
||||||
|
|
||||||
|
Bug fixes do NOT need orchestrator permission. When a bug is
|
||||||
|
unambiguous (build broken, fixture crashes, observable wrong
|
||||||
|
output, structured diagnostic from the bench / debugger), the
|
||||||
|
fix is autonomous orchestrator work. The user's role is to
|
||||||
|
direct *features*, not to gate *fixes*.
|
||||||
|
|
||||||
|
A bug fix without a regression test is a code change, not a
|
||||||
|
fix. The test is what makes the fix durable across future
|
||||||
|
edits.
|
||||||
|
|
||||||
## Iter cycle
|
## Iter cycle
|
||||||
|
|
||||||
Work is organised into **iters** — tightly scoped commits that
|
Work is organised into **iters** — tightly scoped commits that
|
||||||
|
|||||||
Reference in New Issue
Block a user