systematic-debugging

Root-cause debugging requires completing a full investigation phase before proposing any fixes, tracing evidence to form a single hypothesis. This prevents symptom-whack-a-mole where quick patches introduce new bugs while leaving the true issue unresolved.

Systematic debugging provides a pressure-resistant, four-phase workflow: investigation, pattern analysis, hypothesis testing, then implementation with verification. It enforces anti-rationalization guardrails and a hard stop rule after repeated fix failures to prevent guesswork during incidents.

Repeated fix failures indicate you are treating symptoms rather than the root cause. The stop-and-reanalyze rule triggers when fixes fail repeatedly, requiring you to abandon patching, return to evidence tracing, and form a new single hypothesis before attempting another fix.

Form a single hypothesis from traced evidence during the investigation phase, then implement exactly one root-cause fix with verification. Testing one hypothesis at a time isolates variables and confirms the fix resolves the actual anomaly without introducing regressions.

Quick patches should be avoided whenever a test, build, integration, or production error appears, especially after prior fixes have failed. The iron rule prohibits proposing any changes until Phase 1 root-cause investigation is fully complete and evidence is traced.