Paused at Drew's request for a Windows restart. Nothing running, tree lock free,
tree clean (R23 db churn aside). R22 run 19x this session, 140/140 every time.
THE ONE THING OWED: `.run/s37/*/func_*.c` — 16 wave-5 drafts, all claiming MATCH,
NONE gated. Force-added to git (.run/ is gitignored) because they cost ~2.7M
agent tokens and Workflow's resumeFromRunId cache is SAME-SESSION-ONLY, so it
does not survive the restart. Resume by GATING them, not by re-running the wave.
Also preserved: the wave scripts (.run/s36w.js, .run/s37w.js), manifests, the
hardened gate driver, and the four capture drivers.
MEASURED THIS SESSION (both answer questions Drew asked):
- The wave PROMPT is the lever. Bank rate 76% -> 77% -> 100% -> 100% on the same
models and the same gate, prompt the only variable. The jump was STEP 0 (a
magic-literal grep of src/, ahead of engine_core.h) — and that step came from a
wave-2 agent's index_gap report, i.e. the agents write the next prompt.
- The pipeline() fix, before/after: wave 4 parallel() 14 targets / 136 min /
2.5x parallelism; wave 5 pipeline() 16 targets / 82 min / 3.8x. 40% faster on
14% more targets. The two-batch design was a hard barrier with 46-min dead gaps
at each boundary; the harness already caps at 16 so the batching bought nothing.
Housekeeping: removed 3 stray cc1 intermediates (t.i, t.i.greg, t.s) that an
agent left at the repo ROOT — scratch belongs under .run/ (R12), same class as
the gccdump.lreg noted at the Phase-24 close.
Drew T