systematic-debugging

Start by reading the full error message and stack trace, then build a tight reproduction loop such as running the single failing test with pytest. Trace the data flow to the root cause before writing any fix, and confirm the fix with a regression test.

Raise the reproduction rate instead of chasing a perfect repro: run the trigger 100 times, parallelize, add stress, or narrow timing windows. A 50% flake is debuggable, while a 1% flake usually needs more instrumentation first.

Complete root cause investigation first: read errors fully, reproduce the symptom with a deterministic command, review recent git changes, and gather evidence at component boundaries. Proposing fixes before understanding why the bug happens leads to symptom patches.

After three failed fix attempts, stop and question the architecture. Signals include each fix revealing new shared state elsewhere, fixes requiring massive refactoring, or each patch creating new symptoms in different places.

Yes. For systems spanning APIs, services, and databases, add diagnostic instrumentation at each component boundary first, logging what data enters and exits. Run once to gather evidence showing where the flow breaks, then investigate that specific component.