Two pieces of the parallel-cell-loop iteration (spec: parallel-cell-loop),
still sequential — behaviour-identical results, suite green unchanged:
- validate_campaign refuses a campaign document listing the same instrument
twice (DocFault::DuplicateInstrument + CLI prose). A duplicate enumerates
two identical cells and is the one input that could make two cells share a
registry family name; with distinct instruments the per-cell family name
(all four cell axes + stage ordinal) is unique by construction, so the
upcoming parallel appends can never race one name's run-index assignment.
- aura_campaign::execute flattens the 4-nested cell loop into a document-
order-indexed cell list, groups it by instrument ordinal, and walks
sequential chunks of K instrument groups; results land in index-addressed
slots and the ordered outputs (outcomes, realizations, nominee groups) are
rebuilt in document order. K arrives as a new NonZeroUsize parameter
(default DEFAULT_PARALLEL_INSTRUMENTS = 4), exposed as
--parallel-instruments on aura campaign run and threaded through the
run_campaign chain; the dissolved-verb sugar paths pass the default.
The chunk walk is the structural RAM bound for the parallel flip that
follows: no cell of an instrument outside the current chunk can be in
flight at all (chosen over a semaphore gate — blocking inside pool tasks
risks worker starvation; decision log on #277). Verified: workspace suite
green unchanged, clippy -D warnings clean, E2E fixtures pin the CLI prose
and the document-order persistence across K.
refs #277
claude
7fa3ef4e26