MEASURED, not assumed. Baseline ~18s/sibling (92 siblings in 27:37). Profiling a realistic cold
cycle: `make extract` 3s + `make build` 2s = ~5s of the 16s, so MAKE IS NOT THE BOTTLENECK and -j
cannot be the 8-16x lever. Confirmed end-to-end on one sibling: 16s -> 14s.
Where the rest goes: the per-sibling loop tries up to FOUR stages (raw -> scoped -> recovered ->
reconciled) and EACH runs its own `make build`, plus jtbl_carve and remap/canon_sig_reconcile.
WHY THE REAL LEVER IS NOT DONE HERE. Cross-sibling parallelism is worth ~8-16x on this 32-core box
(each sibling is an independent binary, and the Makefile already proves per-binary parallel builds
safe: check-all/extract-all run `xargs -P$(JOBS)` at JOBS=16). It is blocked on a specific hazard,
not on effort: `revert()` restores config/ from git, and `config/overlays.mk` is SHARED, so a
concurrent revert would clobber peers' carve entries — the same "revert-from-HEAD eats another
worker's state" failure this tool's own precondition check warns about. Safe parallelisation needs
line-scoped + locked + atomic edits to overlays.mk and a revert that never wholesale-restores shared
paths. Designed, not built.
ALSO REVERTED THIS SESSION: an attempt to make parallel gating the default in family_sweep. The
adapter for it already exists (tools/sweep_parallel.py, built SESSION-20 after measuring the same
8-16x loss) but is only reachable via the manual `--stage-only` two-step, so the default path stayed
serial — and three sweeps today (133 + 273 + 137 members) ran serially for no reason. Wiring it is
right, but my patch broke the tool twice (missed import, then a closure-scope error) and family_sweep
banked 543 members today. Restructuring a proven tool with blind string replaces at the end of a long
session is how a working thing gets broken; reverted and left as a specified next-session task.
Drew T
445b149279