diagnosing-bugs

Raise the reproduction rate instead of chasing a clean repro: loop the trigger 100 times, parallelise execution, add stress, and inject sleeps to narrow timing windows. A bug reproducible 50% of the time is debuggable; at 1% it is not, so keep increasing the rate first.

Build one command that goes red on the exact symptom: a failing test, a curl script against a dev server, a CLI invocation diffed against a snapshot, or a Playwright browser script. The loop must be deterministic, fast, and assert the user's specific failure, not just the absence of crashes.

Measure first, fix second: establish a baseline with a timing harness, performance.now(), a profiler, or a query plan, then bisect between known-good and known-bad states. Logging is usually the wrong tool for performance work because it cannot capture timing behaviour accurately.

Yes. Build a bisection harness that boots the system at a given state, runs the check, and exits with a status code, then pass it to git bisect run. This works when the bug appeared between two known commits, dataset versions, or configuration states.

Tagging every debug log with a unique prefix like [DEBUG-a4f2] makes cleanup a single grep operation after the fix. Untagged logs tend to survive in the codebase permanently, while tagged logs are guaranteed to be removed during the cleanup phase.

Skip the regression test when no correct seam exists, meaning no test location can exercise the real bug pattern as it occurs at the call site. A shallow test gives false confidence; instead document the missing seam as an architectural finding worth addressing separately.