systematic-debugging

To find the root cause of production incidents and flaky tests, you must enforce a strict investigation phase that traces data flow backward from the error until the original trigger is identified, preventing premature fixes.

The best way to debug deep stack-call errors is applying a four-phase process: investigation, pattern analysis, single-hypothesis testing, and root-cause implementation, ensuring you stop and re-analyze after any failed hypothesis.

Repeated fixes fail to resolve CI/build failures and integration issues because applying random patches without finding the root cause introduces regressions, requiring you to question the architecture after three or more failed hypothesis tests.

Systematically debug performance problems and unexpected behavior by following the Iron Law: read errors carefully, reproduce the issue consistently, and complete pattern analysis before proposing any implementation changes.

You should question software architecture during root cause investigation when you experience three or more failed hypothesis tests, triggering a mandatory stop condition to re-analyze the structural design instead of applying more fixes.