systematic-debugging

Follow four phases: investigate the root cause by reading errors and reproducing the issue, analyze patterns against working examples, form and test ranked hypotheses one variable at a time, then implement a single fix verified by a regression test.

Raise the reproduction rate by running the trigger repeatedly, parallelizing, adding stress, or narrowing timing windows. A 50% flake is debuggable while a 1% flake usually is not, so prioritize making the loop deterministic enough to go red reliably.

Stop after three failed fix attempts. If each fix reveals new shared state or coupling in a different place, requires massive refactoring, or creates new symptoms elsewhere, the pattern itself is likely wrong and needs architectural discussion.

Yes. Add diagnostic instrumentation at each component boundary, logging what data enters and exits, then run once to gather evidence showing where the failure occurs before investigating that specific component.

A failing test proves you understand the root cause and gives a tight feedback loop that goes green only when the bug is fixed. It also becomes a regression test preventing the bug from returning.