systematic-debugging

Follow four phases: investigate the root cause by reading errors and reproducing the issue, analyze patterns against working code, form and test ranked hypotheses one variable at a time, then implement a single fix with a regression test. Never propose fixes before completing the investigation phase.

Raise the reproduction rate by running the trigger in a loop 100 times, parallelizing execution, adding stress, or narrowing timing windows. A 50% flake is debuggable while a 1% flake usually is not, so prioritize making the failure frequent and deterministic.

A tight feedback loop is a single fast, deterministic command that fails on the exact symptom and passes only when the bug is fixed. Examples include a failing unit test, a curl script against a dev server, or a headless browser assertion.

Stop after three failed fix attempts. If each fix reveals new coupling or creates symptoms elsewhere, the pattern indicates an architectural problem, so discuss refactoring the design with the user before attempting more fixes.

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