diagnosing-bugs

Raise the reproduction rate instead of chasing a clean repro: loop the trigger 100 times, parallelize, add stress, and narrow timing windows. A 50% flake is debuggable; keep increasing the rate until your feedback loop reliably goes red.

Build a red-capable feedback loop first, then generate 3-5 ranked falsifiable hypotheses and test them one variable at a time. Only write the fix once you can state the root cause and the evidence confirming it.

It is a single command (test, curl script, CLI invocation, or headless browser script) that drives the actual bug code path and asserts the user's exact symptom. It must be deterministic, fast, and runnable unattended so it goes red on the bug and green once fixed.

Write the regression test before the fix, but only if a correct seam exists where the test exercises the real bug pattern as it occurs at the call site. If no correct seam exists, document that finding as an architecture issue instead of writing a shallow test.

Do not use it for post-incident reviews; use an incident-postmortem process instead. It is designed for live root-cause diagnosis of reproducible bugs and performance regressions, not retrospective analysis.