fix(debug): close the intake gate properly — and the contradiction it exposed

The GREEN run confirmed the gate works: given "builds are flaky again... what's
the fix?" with no run id and no log, it produced zero hypotheses and an ordered
list of artifacts, each justified by what it would discriminate. It also caught
that the retry already shipped in that pipeline is destroying the evidence
needed to diagnose it, which is a better finding than any hypothesis would have
been.

Then it found eight problems, and the first two are mine:

**The template contradicted the rule.** I banned high/medium/low labels in
Step 2 and left them in the Step 3 output template and all three worked-example
hypotheses. "Prose loses to a format block every time" — correct, and the
template is what gets imitated. Labels are gone from both; the slot is now WHY
FIRST, which asks for the evidence that sets the order rather than a restatement
of it.

**The description never mentioned the gate.** That is the text a harness shows
before an agent decides to load anything, and it read "Generate 3-5 ranked
hypotheses" — so an agent routing on the description alone does exactly the
thing this skill was rewritten to prevent. Both description and use_when now
lead with the refusal.

The rest:

- Intake vs the failed-fixes section pointed opposite ways for a report that
  fires both, and nothing stated precedence. Intake wins, and says so: you
  cannot aim hypotheses at a premise you have no evidence about either.
- "One run narrows the search to a single component" was overclaimed exactly
  where it gets used — CI flakiness. One run *that reproduces* narrows it; a
  passing run narrows nothing.
- session_log had no phase for a correct refusal, so an intake stop logged as a
  failed read-failure. A metric that penalises the skill's best behaviour trains
  the next model to guess. Added an `intake` phase.
- The Anti-Patterns table — the part people scan in a hurry — was missing the
  failure this whole rewrite is about: answering "what's the fix?" from a report
  with no artifact.
- brain_query told you to search on an error string you may have just refused to
  proceed without. Now: query symptom + component, which may itself name the
  artifact to ask for.
- condition-based-waiting was an unconditional load on any mention of a timeout,
  including during an intake stop, which is the wrong side of the gate.

Closes #36
Bump-Type: minor

SKILLS_INDEX.md

@@ -14,7 +14,7 @@ the SKILL.md, not the table.
 | `clean-code` | Clean code principles with Go adaptation | Code review, refactoring, new code | claude-code, library |
 | `code-review` | Code smell detection + Go-specific checklist | Pre-merge review | claude-code, library |
 | `cognitive-load` | Cognitive complexity analysis (CLI score) | Identifying hotspots, before refactoring | claude-code, library |
-| `debug` | Hypothesis-first debugging discipline | Any test failure or bug whose cause is not immediately obvious | claude-code, library |
+| `debug` | Hypothesis-first debugging discipline | Any test failure or bug whose cause is not immediately obvious — or a bug report with no failure text, which this skill refuses rather than guesses at | claude-code, library |
 | `discovery-framing` | Problem-before-solution discovery/framing method | Framing/validating a problem before any solution; opportunity sizing | claude-code, library |
 | `dream` | Reflective consolidation pass over an agent's memory directory | Pruning/merging memory files, rebuilding a memory index | claude-code, library, chat |
 | `experiment-spec` | Rigorous experiment spec — falsifiable hypothesis, quantitative acceptance, null-result protocol | Scoping a research/ML phase instead of a feature | claude-code, library |

skills/debug/SKILL.md

@@ -2,8 +2,8 @@
 name: debug
 surfaces: [claude-code, library]
 summary: "Hypothesis-first debugging discipline"
-use_when: "Any test failure or bug whose cause is not immediately obvious"
-description: Systematic hypothesis-first debugging. Generate 3-5 ranked hypotheses with verification steps before suggesting any fix. Use when encountering a bug, test failure, or unexpected behavior.
+use_when: "Any test failure or bug whose cause is not immediately obvious — or a bug report with no failure text, which this skill refuses rather than guesses at"
+description: Systematic hypothesis-first debugging. Requires the failure itself — error text, stack, run id or log — and names what it needs and stops if the report has none, rather than hypothesising into a vacuum. Given evidence, generates 3-5 ranked, falsifiable hypotheses with verification steps before suggesting any fix. Use when encountering a bug, test failure, or unexpected behavior.
 ---
 
 # Debug
@@ -57,8 +57,9 @@ comments and the job log *first*.
 A system with boundaries (CI → build → signing, API → service → database) hides the
 question "which component is wrong?" behind the question "why is the output wrong?".
 Specify, as a pre-step, what to log entering and leaving **each** boundary, plus
-whether config and environment actually propagated. One run of that narrows the search
-to a single component.
+whether config and environment actually propagated. One run *that reproduces the failure* narrows the search to a
+single component. On an intermittent fault a passing run narrows nothing, so leave the
+instrumentation in across several runs rather than concluding from one.
 
 This does not suspend Iron Law 2. Still emit 3-5 hypotheses — the boundary spec comes
 first in the output, and each hypothesis says which boundary observation would kill it.
@@ -74,6 +75,10 @@ than fixes that partially worked.) Each one has been narrowing a window rather t
 closing it, and a fourth guess buys another tenth of the rate plus a layer of
 interacting guards nobody can reason about.
 
+Intake still gates this section. A report of three failed fixes with no artifacts fires
+both rules at once, and intake wins: you cannot aim hypotheses at a premise you have no
+evidence about either. Ask for the log, then aim.
+
 Say that explicitly — the refusal is the finding, not a preamble to it. Then aim the
 hypotheses one level up: the premise those fixes share is itself the thing to falsify.
 This is not an exemption from the output format. It is the format, pointed at the
@@ -112,11 +117,13 @@ is a restatement of the order it sits next to.
 Use this format:
 
 ```
-HYPOTHESIS 1 (likelihood: high): <mechanism in one sentence>
-VERIFY: <exact command or file:line to inspect>
+HYPOTHESIS 1: <mechanism in one sentence>
+WHY FIRST: <what makes it likeliest — a matching symptom, a recent change, a brain entry>
+VERIFY: <exact command, or the bounded observation that discriminates>
 EXPECTED IF CORRECT: <specific output, value, or condition>
 
-HYPOTHESIS 2 (likelihood: medium): <mechanism>
+HYPOTHESIS 2: <mechanism>
+WHY FIRST: <or why it ranks here rather than first>
 VERIFY: <exact command>
 EXPECTED IF CORRECT: <specific output>
 
@@ -138,15 +145,15 @@ End with the recommendation, not a fix.
 **Output:**
 
 ```
-HYPOTHESIS 1 (likelihood: high): parser indexes into pages[0] before checking len(pages) > 0; empty PDFs produce a zero-page document
+HYPOTHESIS 1: parser indexes into pages[0] before checking len(pages) > 0; empty PDFs produce a zero-page document
 VERIFY: rg -n 'pages\[0\]' internal/parser/
 EXPECTED IF CORRECT: at least one site reads pages[0] without a preceding length check
 
-HYPOTHESIS 2 (likelihood: medium): the test fixture is a zero-byte file rather than a valid empty PDF; pdf library returns nil pages slice instead of empty
+HYPOTHESIS 2: the test fixture is a zero-byte file rather than a valid empty PDF; pdf library returns nil pages slice instead of empty
 VERIFY: ls -la testdata/empty.pdf && file testdata/empty.pdf
 EXPECTED IF CORRECT: file size 0 bytes or "data" rather than "PDF document"
 
-HYPOTHESIS 3 (likelihood: low): a recently changed dependency reordered the page-extraction API; pages[0] now refers to metadata, not content
+HYPOTHESIS 3: a recently changed dependency reordered the page-extraction API; pages[0] now refers to metadata, not content
 VERIFY: git log --oneline -10 -- go.sum | grep -i pdf
 EXPECTED IF CORRECT: a pdf-library bump in the last few commits
 
@@ -160,6 +167,7 @@ RECOMMENDED NEXT STEP: Run VERIFY for hypothesis 1 first.
 | "Maybe try restarting the service" | Not a mechanism. Not falsifiable. Teaches nothing if it works. |
 | "Could be a race condition" | Mechanism without specifics. Which two operations race? On what state? |
 | "Let me add some print statements and see" | Skips hypothesis generation. Generates noise, not understanding. |
+| Answering "what's the fix?" from a report with no artifact | Hypothesising into a vacuum. The output looks like analysis, which is what makes it worse than saying "I need the log". |
 | Single hypothesis presented as fact | If you are sure, write the regression test, do not run a debug skill. |
 | Mixing hypotheses with fix suggestions | The skill is diagnose-only. The fix is a TDD task on its hypothesis. |
 
@@ -168,7 +176,7 @@ RECOMMENDED NEXT STEP: Run VERIFY for hypothesis 1 first.
 The brain holds prior debug sessions across the project. Use it to skip rediscovering known failure modes.
 
 **At debug start:**
-- Run `brain_query` with the error message snippet + the package name. Past sessions may have logged identical or similar failures with their resolved hypotheses.
+- Run `brain_query` with the error message snippet + the package name. On an intake stop you have neither — query the symptom and the component instead ("signed artifact missing CI"), which is worth doing precisely because it may name the artifact to ask for. Past sessions may have logged identical or similar failures with their resolved hypotheses.
 - **A hit is evidence, so cite it inline in the hypothesis it informs** — `(brain: <entry-name>)` — rather than mentioning it once at the top. If a prior entry is why a hypothesis ranks first, the reader needs that at the hypothesis, not in a preamble. If a prior entry contradicts your ranking, say so and rank it anyway if the evidence here is better; the brain records what was true then.
 
 **After a hypothesis is confirmed:**
@@ -186,7 +194,12 @@ treats `pass` as success, `fail` as failure, `skip` as neither.
 **At end of each phase:**
 - `session_log` with `{session_id: "<this session's id>", skill: "debug", phase: "<phase-name>", final_status: "pass" | "fail" | "skip", message: "<one-line summary>", project_root: "<absolute path>"}`
 
-**Phases for this skill:** read-failure, generate-hypotheses, output
+**Phases for this skill:** intake, read-failure, generate-hypotheses, output
+
+`intake` exists so that refusing correctly is recordable. A run that stops for want of a
+run id has done the right thing and logs `intake` / `pass`; without that phase the
+refusal logs as a failed `read-failure`, and a metric that penalises the skill's best
+behaviour teaches the next model to hypothesise into the vacuum instead.
 
 **Status semantics:**
 - `pass` — the phase's intended outcome was reached.
@@ -209,7 +222,9 @@ Techniques kept in `debug/references/`, inherited from the deleted
 - `defense-in-depth.md` — load after a root cause is confirmed, to decide which layers
   should have caught it.
 - `condition-based-waiting.md` — load whenever a timeout appears anywhere in the report,
-  including as one of the fixes already tried. A bumped timeout is a symptom.
+  including as one of the fixes already tried. A bumped timeout is a symptom. Not during an
+  intake stop: if you are not analysing yet, a symptom-analysis reference is on the wrong
+  side of the gate.
 - `find-polluter.sh` — run when a test passes alone and fails in the suite, or when
   something in the tree appears that no test admits to creating.