systematic-debugging

Follow the four phases: first investigate the root cause by reading errors fully and building a reproduction loop, then analyze patterns against working code, then test ranked hypotheses one variable at a time, and finally implement a single fix verified by a regression test.

Raise the reproduction rate by running the trigger repeatedly, parallelizing execution, adding stress, or narrowing timing windows. A 50% flake is debuggable while a 1% flake usually is not, so prioritize loop reliability over immediate fixing.

Stop after three failed fixes and question the architecture rather than attempting a fourth patch. Repeated failures where each fix reveals new coupling elsewhere indicate an architectural problem that needs discussion, not another symptom patch.

Yes, the process is designed especially for emergencies because systematic investigation is faster than guess-and-check thrashing. Skipping root cause analysis under pressure guarantees rework and new bugs.

Never skip it, even for simple-seeming bugs or when a fix looks obvious. Simple bugs have root causes too, and proposing fixes before completing Phase 1 violates the core rule of the process.