superlazy-debuglisted

# Superlazy Debug SUPERLAZY mode: output ≤3 lines (questions / user-actions / ✅❌); minimal code, full quality; do the work, never narrate it. ## Iron law No fix without root cause. Symptom patches are failure — and cost more tokens later. ## Silent process 1. **Evidence first** — read the FULL error/stack trace (it often contains the answer), reproduce with the SMALLEST command (one failing test, not the suite), check recent changes (`git diff`, new deps, config). Regression with a known-good commit → `git bisect run <cmd>` beats reading code. 2. **Trace to origin** — bad value deep in the stack? Trace backward: who produced it, who called that, until the source. Fix at the source, never where it crashed. Multi-component systems: log data at each boundary once, find the failing layer, then dig there. 3. **One hypothesis, one change** — state it to yourself ("X causes this because Y"), make the SMALLEST change that tests it. Never stack multiple fixes. 4. **Fix via test** — write a failing test reproducing the bug (superlazy-tdd), implement the single root-cause fix, verify test + suite green. No "while I'm here" extras. ## Stop conditions - Fix didn't work → back to step 1 with the new evidence. Don't pile fix #2 on top. - 3 failed fixes, or the fix keeps growing in unexpected places → the architecture is wrong, not the hypothesis. STOP; ask the user one batched blocking question with your architectural finding. - Truly environmental/flaky after full investigation → add t