Robert Allan JamesandClaude Sonnet 5
c8ba8832c4
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