medic__qwen3.6-35b-a3b__20260710-201401 — medic recovery over fast2 (P0)

RULE-RELAXED recoverability axis — NOT a baseline/leaderboard number. The medic is deliberately told the verifier failed and shown the exact failing-check output. Baseline scoring stays the standard number; this is a separate column.

Phase 1 (baseline): runs/fast2__qwen3.6-35b-a3b__20260710-192053 (MinimalPi, MEDIC_CAPTURE=on, fast2 set default caps). 1/6 pass (fix-ocaml-gc), 5 fail. Phase 2 (this run, MedicPi, signal=full log_access=dump workspace=restore, per-session cap default=900): the 5 failed workspaces were restored in place with the failing pytest output injected. All 5 restores confirmed in the log, incl. reshard-c4-data at 752M (large-artifact upload+extract works).

Recoverability verdict: 3/5 recovered in one round (60%)

Suite line: baseline 1/6 · +1 nudge 4/6 · recoverability 3/5 = 60% (and the one clean not-recovered is headless-terminal; financial-document-processor is cap-limited, not a real negative — so the true ceiling is 3–4/5).

All three recoveries are genuine Harbor-verifier passes (reward=1.0), not false-success: real pytest green (1 passed/3 passed).

What this says

For qwen 35b on fast2, a majority of failures are within one debugging round once the model is handed the concrete error and its own broken code — exactly the "how recoverable is this failure" signal the axis is built to produce. It is a much stronger result than the single cancel-async-tasks case (runs/medic__…190552, still-fails/near-miss): the difference is task-dependent, which is the interesting variable.

Caveats / honesty

• K=1, temp 0.6 → single-trial signals (repo standard caveat).
• RULE-RELAXED: the medic sees the pass/fail signal + the failing test output. This is NOT the leaderboard number and must never be folded into it.
• The 900s per-session cap makes financial-document-processor inconclusive; a fairer sweep would raise FAST_TIMEOUTS for the long tasks.
• Cost: the medic sessions are expensive (financial-document-processor cut at 15m/5.7M input; mailman 10m/11.1M input) — the log-dump + re-reads + loops add up. The P1 query_log A/B is the intended efficiency lever.
• Large-artifact fidelity: reshard-c4-data restored 752M (input data + the base agent's output shards) and still recovered — but staging/uploading that much is heavy; excluding pristine input data from the capture is a future refinement.