self-correction-looplisted

# Self-Correction Loop > Status: v0.1 baseline draft — derived from the case catalog and axis definitions; awaiting trace evidence from Fable 5.1 case runs. ## When to apply - A test, build, benchmark, or runtime check just failed after a change you made. - You are about to re-run the same command after a fix and are not sure the fix addresses the *cause*, only the *message*. - You notice you have edited the same file or function more than twice for the same failing check. - Output is wrong but there is no error at all (silent bug: wrong numbers, flaky pass, loss not decreasing). - A fix made one check pass but broke a different one — the failure moved instead of dying. - You are inside an autonomous loop (CI bot, harness runner) and need explicit termination and escalation rules. ## Core loop 1. **Capture the signal verbatim before touching code.** Copy the exact error text, failing assertion, expected-vs-actual diff, or metric delta into working notes. Never work from a paraphrase of the failure — the paraphrase deletes the clue. 2. **Classify the failure into one of three tiers:** | Tier | Name | Definition | Typical evidence | |------|------|------------|------------------| | T1 | Mechanical | Typo, missing import, wrong arg order, off-by-one in a line you just wrote | Cause visible in the error text itself | | T2 | Wrong approach | Code does what you intended, but the intention can't solve the problem | Correct-looking code, structurally wrong result (