Derived result: Bar B's "non-negotiable" cost row is unwinnable with speculation and comfortably winnable with batching — and no invariant forbids batching.
Law 3: cost per landed PR is governed by PRs-per-validation, not by speculation efficiency. Speculation validates one atom per candidate; a batch validates g. This also means M4 (cache) and M5 (affected targets) cannot help — they reduce cost per validation, which applies to the baseline equally, so they cannot move a ratio.
A batch of unrelated atoms replayed as one linear chain is structurally identical to a stack-as-atom: one candidate, one tree, one validation, one CAS, one commit per PR preserved. Invariant 1 satisfied identically. Invariant 2 untouched. The design already implements this — it is the THUNDERDOME cohort — but confines it to an emergency regime and sizes it ~5x wrong (max_atoms: 100 vs n* ~ 1/p ~ 20 at p=5%; at 100 and p=5% it lands 0.59 atoms/run, worse than serial).
The stated reason for rejecting batching (README:25, on Mergify) is factually wrong against Mergify's own documentation — they speculate via max_parallel_checks and bisect on batch failure.
Actions
Contested, do not quote yet: four lenses computed the multiple as 5x, 3.0x, 1.43x and ~1.0x because they modelled four different GitHub merge queues. The ordering (batching cheaper per landed PR) is robust; the multiple is not. E3/E5 settle it.
See docs/INVESTIGATION.md §2 Law 3, §6 Q2, §7 R2, §10.
Derived result: Bar B's "non-negotiable" cost row is unwinnable with speculation and comfortably winnable with batching — and no invariant forbids batching.
Law 3: cost per landed PR is governed by PRs-per-validation, not by speculation efficiency. Speculation validates one atom per candidate; a batch validates
g. This also means M4 (cache) and M5 (affected targets) cannot help — they reduce cost per validation, which applies to the baseline equally, so they cannot move a ratio.A batch of unrelated atoms replayed as one linear chain is structurally identical to a stack-as-atom: one candidate, one tree, one validation, one CAS, one commit per PR preserved. Invariant 1 satisfied identically. Invariant 2 untouched. The design already implements this — it is the THUNDERDOME cohort — but confines it to an emergency regime and sizes it ~5x wrong (
max_atoms: 100vsn* ~ 1/p ~ 20at p=5%; at 100 and p=5% it lands 0.59 atoms/run, worse than serial).The stated reason for rejecting batching (README:25, on Mergify) is factually wrong against Mergify's own documentation — they speculate via
max_parallel_checksand bisect on batch failure.Actions
p(n* ~ 1/psingle-shot,~1.4/pwith split recovery), bounded by the attribution probe budgetcohort.max_atoms: 100with that derived quantitygroup_size,build_concurrency, the only-merge-non-failing toggle, and the stack-depth mixContested, do not quote yet: four lenses computed the multiple as 5x, 3.0x, 1.43x and ~1.0x because they modelled four different GitHub merge queues. The ordering (batching cheaper per landed PR) is robust; the multiple is not. E3/E5 settle it.
See
docs/INVESTIGATION.md§2 Law 3, §6 Q2, §7 R2, §10.