SESSION-20 measured serial family-sweep gating as "roughly an 8-16x throughput loss on a 32-thread
box" and BUILT tools/sweep_parallel.py for it — but only reachable via a manual `--stage-only`
two-step, so this path stayed serial and three sweeps in SESSION-22 (133 + 273 + 137 members) ran
serially for no reason. §101, the stale-default class.
SHAPE OF THE CHANGE — deliberately minimal after two failed attempts earlier today. A parallel
PRE-PASS (phase 2a) runs only the per-group `harvest_verify` subprocess; phase 2b then consumes the
results IN THE ORIGINAL SERIAL ORDER, so every line of post-processing (the MISMATCH backstop, the
zero-bank restore, the counters, the prints) is untouched and output stays deterministic. No closure
restructuring — that is exactly what broke it twice before.
SAFETY, not a new claim: the Makefile already builds binaries concurrently (check-all/extract-all use
`xargs -P$(JOBS)`, JOBS=16) and bulk_harvest's farm does the same with a per-binary lock. The §28
hazard is two makes racing on the SAME artifacts, prevented by the per-overlay lock (two splits of
one overlay build the same binary and therefore serialise).
NEGATIVE-CONTROLLED BOTH WAYS: `--stage-only` stages identically under -j1 and -j12 (4 groups each);
a full gate returns IDENTICAL tallies (0 banked / 4 failed) parallel vs serial; tree clean after both.
HONEST MEASUREMENT: on the only sample available (4 groups, and they fail FAST on a compile error
rather than running full builds) parallel was 4s vs serial 6s — ~1.5x, NOT the 8-16x. That figure
needs a large family (137 groups of full builds) to show, and every such family was already banked
today. The wiring is proven correct here; the throughput claim remains SESSION-20's measurement, not
mine. `-j 1` restores the old behaviour.
Drew T
55cd894024