CB: record the third pinned run
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ARBgSooAfokKUy6wKUKEyZ
This commit is contained in:
parent
cd92076b39
commit
cd17280f01
1 changed files with 5 additions and 3 deletions
|
|
@ -42,9 +42,11 @@ of size k > 1: three lanes ran it with `hooks=off` and got three different files
|
|||
a 1/k coincidence — at lane L4's k = 6 that is a 17 % chance of a clean bill of health that means
|
||||
nothing. Pinning removes the only per-process input and makes a control possible.
|
||||
|
||||
It worked. A process whose natural seeds were `0x227235b9 / 0x762d125e / 0x9d77d4e6`, pinned to an
|
||||
earlier run's `0xe70a4703 / 0x0c63ca36 / 0x372be4df`, reproduced that run's **entire command block**
|
||||
— including the research pick that varies — and its autosave **byte for byte**.
|
||||
It worked, three times over. Three processes on that save, each drawing its own three natural seeds
|
||||
(nine distinct words in all), two of them pinned to the first's, produced **one** autosave
|
||||
(`d59bb9f2fd0eb535…`) with identical gates — including player 512's research target `282`, the value
|
||||
that varies — and identical element records. Two runs agreeing on a `k > 1` workload is a `1/k`
|
||||
coincidence; three is `1/k²`.
|
||||
|
||||
## 3. What a replayer needs from this, in one place
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue