Two real bugs found and fixed while attempting to raise N-REPS from
3 (both harmless only by coincidence at N-REPS=3, since 3 happened
to equal the hardcoded/literal values):
- N-RUNS was `27 CONSTANT`, not derived -- now `N-ID N-REPS *
CONSTANT N-RUNS`.
- START-REP's run_id decode used a literal `3 *` where it meant
`N-REPS *` (confirmed against EXEC-STD79-DOE, the serialized
baseline, which correctly uses N-REPS for the same decode).
Re-verified at N-REPS=3 (amd64): byte-identical to the already-
verified baseline -- 193s, 0 faults, 99/99 tokens every identity,
K conserved on all 656 rows.
Raising N-REPS to 6 was then tested and found to cause real, silent
data loss at full 8-identity scale (rajames 0/198, 00 66/198, 01/02
99/198, 03-06 fully complete) -- same failure class as §XXI defect 2,
just past the budget again since doubling N-REPS roughly doubles
total MSG-SEND volume (24->48).
Measured the reservoir's replenishment directly rather than assume
from source: 40 sends drained it from 21735 to 1; 300s of pure idle
time (zero further sends) brought it back to 2049 -- real, but only
~6.8 units/s, meaning a full refill would take on the order of 53
minutes against a campaign's few-hundred-second runtime. Raising
N-REPS further needs a cheaper per-send cost or an explicit top-up,
not reliance on ambient decay.
Reverted N-REPS to 3 (fixes kept, they're correctness fixes
independent of the value) rather than commit a silently-lossy result.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo
