diagnosing-bugslisted

# Diagnosing Bugs A discipline for hard bugs. Skip phases only when explicitly justified. ## Phase 0 — Search past learnings and decisions When the loop config enables the solutions store, search `docs/solutions/` for learnings matching the symptom — the error message, the module, the failure mode. When it enables the ADR store, read the ADRs bearing on the area you are touching, so the fix you design does not re-litigate a decision already made. The loop config is `docs/agents/cantrips-loop.md`; when that doc is absent, both stores are off. A past solution may short-circuit the whole diagnosis: when one matches, verify its root cause applies here before building anything, and carry its gotchas into the phases below. ## Redact This skill has you show commands, outputs and captured artifacts. **Redact every secret first** — write `<REDACTED>` in its place. Build loops against env vars, so the credential stays in the environment rather than in what you show. Captured artifacts carry auth headers: quote only the lines that carry the signal. If the redacted output is not enough to diagnose the bug, say so and ask the user. ## Phase 1 — Build a feedback loop **This is the skill.** Everything else is mechanical. If you have a **tight** pass/fail signal for the bug — one that goes red on _this_ bug — you will find the cause; bisection, hypothesis-testing, and instrumentation all just consume it. If you don't have one, no amount of staring at code will save you. Spend dispro