systematic-debugging

To find the root cause of a test failure, you must enforce an investigation phase that gathers evidence and forms a single hypothesis before making any code changes. This prevents repeated regressions caused by applying symptom-based fixes.

The best way to debug production bugs under time pressure is to follow a four-phase workflow: root cause investigation, pattern analysis, single-hypothesis testing, and implementation. This enforces evidence gathering before applying fixes.

Quick fixes keep failing and causing repeated regressions because they address symptoms without identifying the underlying root cause. You need to stop and re-analyze the issue using evidence gathering and hypothesis testing before implementing changes.

To carry out hypothesis testing for unexpected behavior and build failures, isolate a single root-cause hypothesis, test it against gathered evidence, and write a failing test first before proceeding to the actual implementation fix.

You should stop and re-analyze during incident response debugging after unsuccessful fix attempts. Guardrails mandate stopping when you are tempted to skip steps, add multiple changes, or keep retrying fixes after repeated failures.