diagnoselisted

# Diagnose Debugging is hypothesis testing, not code staring. The loop below is sequential and rigid on purpose — the steps people skip (reproduce, minimise) are the ones that prevent fixing the wrong thing. ## Picking up the work Same worker contract as `/tdd`: a cited issue (`ISSUE_xxxx` or GitHub `#n`) is resolved through the configured backend — local via a fresh needs.json (the issue body usually carries the repro; `/qa` wrote it that way), github via `gh issue view`. Set it `in-progress` before starting (local: `:status:` edit + strict gate; github: label swap). ## The loop 1. **Reproduce.** Get the failure happening on demand — a command you can re-run, ideally as a failing test. No reliable repro → that IS the task; don't hypothesise about a failure you can't summon. If a repro is truly out of reach, say so and downgrade all conclusions accordingly. 2. **Minimise.** Shrink input, config, and code path until everything left is load-bearing. Every removed element is a hypothesis eliminated for free. For regressions: `git bisect` is minimisation over history — use it before reading code. 3. **Hypothesise.** State the suspected mechanism *before* looking deeper — written, falsifiable, one at a time, most-likely-first. "Something async" is not a hypothesis; "the cache returns the stale entry because invalidation runs before the write commits" is. 4. **Instrument.** Add the observation that would prove or disprove the current hypothesis