systematic-debugging

To find the root cause of test failures, you must reproduce the issue and gather evidence first. This approach enforces a four-phase workflow: root cause investigation, pattern analysis, hypothesis testing, and implementation with verification before completion.

Debugging complex multi-component failures under time pressure requires an evidence-first approach, adding instrumentation across component boundaries and tracing data flow backward through call stacks to identify the true root cause before proposing fixes.

Quick fixes fail because they bypass root cause investigation. You must enforce hypothesis testing with minimal testing for a single hypothesis, and if a fix fails, you need to re-analyze the issue rather than attempting another immediate patch.

To stop applying ineffective patches, follow a STOP-and-reanalyze rule after failed attempts. This workflow escalates to an architecture review after three or more failed fixes, forcing a systematic re-evaluation of the underlying problem.

Use systematic debugging whenever you encounter a bug, test failure, or unexpected behavior, even when quick fixes seem obvious. It provides pressure-resistant guardrails that prevent wasted time by mandating root cause investigation before any changes.