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 before investigating.

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, rather than a generic check that the program does not crash.

Stop after three failed fix attempts. If each fix reveals new coupling in a different place or creates new symptoms elsewhere, the pattern indicates an architectural problem, and you should discuss refactoring with the user instead of attempting a fourth fix.

Yes. For systems spanning APIs, services, and databases, add diagnostic instrumentation at each component boundary to log data entering and exiting. Run once to gather evidence showing where the failure occurs, then investigate that specific component.