keel-debuglisted

# keel-debug — Diagnosis Loop ``` INPUT an observable symptom (error, wrong output, flake, slowness) and an environment the code can be run in OUTPUT a one-line root-cause statement, a regression test that went red before the fix and green after, and zero leftover instrumentation ``` Missing INPUT → `BLOCKED: 缺 <symptom | runnable environment> → 退回 <the stage or person that owes it>`. A symptom nobody can reproduce and no environment to try it in are the two things this stage cannot substitute for. **Build/compile failures short-circuit the loop.** If the symptom is a compile, type, or build error rather than a runtime behavior, Phase 1 is already done — the build command *is* the loop. Dispatch `build-error-resolver` (by name, never `general-purpose`, no `model` override) and skip to Phase 6's checklist. The phases below are for behavior you have to hunt. Skip phases only when explicitly justified. Read `CONTEXT.md` (if it exists) before exploring, so you name modules the way the project does, and `docs/adr/` for the affected area — what looks like a bug is sometimes a recorded deliberate trade-off; don't "fix" an ADR. <IRON-LAW> NO HYPOTHESIS WITHOUT A RED LOOP. Until you can name ONE command — already run at least once, output in hand — that reproduces the user's exact symptom, you may not theorize about causes or read code "to build a theory". Fix nothing you cannot watch fail. </IRON-LAW> ## Phase 1 — Build the feedback loop This is the skill; e