systematic-debugging

To find the root cause of test failures, you must complete a full investigation phase analyzing error messages and behavior patterns before proposing any fixes. This prevents wasted time and new bugs caused by making quick fixes without understanding the underlying issue.

Debugging misleading multi-component failures requires forming a single hypothesis with a minimal test. If the first hypothesis fails, you must stop and re-analyze the root cause rather than adding more fixes on top of failed attempts.

Incident response debugging under time pressure still requires completing Phase 1 root cause investigation before proposing fixes. Anti-rationalization guardrails explicitly enforce finding the root cause first and stopping when a hypothesis fails to prevent compounding errors.

When your debugging hypothesis fails during a minimal test, you should stop and re-analyze the root cause. Do not add more fixes on top of the failed attempt, as this violates the systematic debugging process and introduces new bugs.

Systematic debugging for unexpected behavior involves four phases: Investigation to gather evidence, Pattern analysis to identify trends, Hypothesis and testing to validate a single root cause, and Implementation to apply the fix. You must complete them in order.

You should avoid quick fixes during local debugging whenever you do not fully understand the issue. Systematic debugging requires finding the root cause first, as making fixes without understanding the underlying behavior causes wasted time and new bugs.