systematic-debugginglisted

# Systematic Debugging Do root-cause investigation before proposing fixes. ## Iron Law **No fix without evidence for root cause.** This is non-negotiable. Every fix must trace back to a proven root cause. A fix applied without understanding why it works is not a fix — it is a mask. ## Four Phases ### Phase 0: Check Known Issues - If `known-issues.md` exists at the project root, search it for the error message, error code, or failing test name. - If a match is found, try the documented solution **first**. If it resolves the issue, stop — no further investigation needed. - If no match or the documented solution doesn't work, proceed to Phase 1. ### Phase 1: Investigate - Read the **full** error output — not just the last line. - Reproduce the bug reliably. If you cannot reproduce, you cannot fix. For tests that fail only in certain orderings (test pollution), run `find-polluter.sh` from this skill's directory to identify which test is corrupting shared state. - Check recent changes — what changed since it last worked? - If `context-snapshot.json` exists at the project root: read it. The `changed_files` and `recent_commits` fields answer this immediately without additional git commands. - Otherwise: run `git log --oneline -10` and `git diff HEAD~1..HEAD --name-only`. - Add instrumentation (logging, breakpoints) at component boundaries. - **Multi-component systems:** When the system has multiple components (CI → build → signing, API → service → database), add diagnosti