systematic-debugging

Start by reading the full error message and stack trace, then reproduce the failure consistently. Check recent changes via git diff, form a single hypothesis about the root cause, and test it with the smallest possible change before implementing a fix.

Add diagnostic logging at each component boundary to capture what data enters and exits every layer. Run the system once to gather evidence showing which layer breaks, then investigate only that failing component instead of guessing.

Stop after three failed fix attempts. If each fix reveals a new problem in a different place or requires massive refactoring, the architecture itself is likely flawed and should be discussed before further patching.

Quick fixes address symptoms rather than root causes, so the underlying issue persists and resurfaces elsewhere. Bundling multiple changes at once also makes it impossible to isolate what worked, often introducing new defects.

No, simple bugs have root causes too, and the process is fast for simple issues. Skipping investigation under time pressure leads to thrashing, which is slower than systematic diagnosis.