mirror of
https://github.com/Druthulu/BFM-decomp
synced 2026-09-27 22:45:39 -04:00
Drew T
3f51101ca9
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.