systematic-debugging

Start by reading the full error message and stack trace, then reproduce the failure consistently with a verbose test run. Check recent git changes, trace the data flow to the source of the bad value, and only then form a hypothesis and write a regression test before fixing.

Root cause analysis identifies why a bug occurs rather than patching its symptoms. This process reads errors carefully, reproduces the issue, gathers evidence at component boundaries, and traces bad values upstream to their origin before any fix is attempted.

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 flawed and needs architectural discussion.

Yes, the process is designed especially for emergencies because guessing under pressure causes thrashing and rework. A structured investigation typically resolves issues in 15-30 minutes versus hours of random fix attempts.

Quick fixes address symptoms without understanding the root cause, so the underlying issue persists and the patch often introduces new defects. Bundling multiple changes at once also makes it impossible to isolate what actually worked.