systematic-debugging

Start by reading the full error message and stack trace, then reproduce the failure consistently with a specific test command. Check recent git changes, trace the data flow to the root cause, and only then form a hypothesis and test a minimal fix.

Root cause analysis means identifying why a bug occurs before attempting any fix, rather than patching symptoms. It involves reading errors carefully, reproducing the issue, checking recent changes, and tracing bad values upstream to their source.

Stop after three failed fix attempts. If each fix reveals new problems in different places or requires massive refactoring, the pattern indicates an architectural problem that needs discussion rather than another patch.

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

Add diagnostic instrumentation at each component boundary, logging what data enters and exits each layer. Run once to gather evidence showing where the flow breaks, then investigate that specific component rather than guessing across the whole system.