systematic-debugging-playbooklisted

# Systematic debugging playbook The most expensive debugging mistake is skipping straight to a hypothesis and a fix. In any codebase with real history, most "new" bugs are re-encounters of something already root-caused, and most fixes that get re-reviewed introduce a second bug in the process of fixing the first. This playbook is the discipline against both. ## Step 0: look up ground truth before forming a hypothesis Before writing any code: 1. **Search prior art first.** Grep commit history for the symptom (`git log --all -i --grep="<keyword>"`), check any existing investigation/post-mortem archive your project keeps, and check file history for the specific file involved (`git log --follow -- <path>`). A surprising number of "new" bugs already have a full root-cause writeup sitting in history. 2. **If a prior investigation doc exists, check whether it was later corrected or resolved.** A doc that opens with a "RESOLVED" or correction banner should have that banner treated as overriding the body. Verify the recorded fix is actually still present in current code before concluding a fixed issue "recurred": it's easy to mistake "I'm looking at the pre-fix version" for "this regressed." 3. **Don't trust a finding's classification blindly, including your own project's tracker.** A finding marked resolved, retracted, or not-reproducible should be re-verified via the real path that would trigger it, not assumed correct because a doc says so. Post-mortems have real examples of a