954f3cec63
Canonical pair turn2->turn3: the complete block set, the three heap payloads no previous capture could read (route [272], list-10 [1728], the 24-byte Population body), the three AI client seeds, and both output autosaves -- byte-identical to the published oracle AND to this lane's own hooks=off control, so the stream and the save come from the same run and the instrument did not change the turn it recorded. Creation turn turn1->turn2: three runs. Pinning the AI client seeds to the values an earlier run observed made a DIFFERENT process reproduce that run's block -- including the research pick that varies -- and its autosave byte for byte. The workload three lanes could not reproduce is reproducible given the seeds. Two corrections to lane L4's list-23 reading (no trailing int; the body is not turn-dependent) and one to my own list-5 record, the latter found by lane RB while consuming this capture. Format: JSON (raw words are ground truth, decoded is a typing) plus lane RB's own .tcb grammar with the heap payloads filled in, so RB's reader consumes it unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ARBgSooAfokKUy6wKUKEyZ
2.1 KiB
Lane CB's VM harness
Driving VM146 from WSL. Two lab facts these scripts exist to encode, both of which cost this lane a run before they were understood:
1. The vmwatch wall caches frames for 5 seconds, and a cached frame is indistinguishable from a
click that did nothing. Four clicks were diagnosed as "not registering" when every one of them
had worked and the screenshot was simply older than the click. Every screendump here goes through
vmshot.py --ssh, which bypasses the service and costs ~4 s.
2. The >60 s startup is real (five confirmations on the board now). cbmenu.py polls the
framebuffer for the main menu's red button column and refuses to return until it is up. Never
sleep-and-click.
A third, less certain: cbfull.sh chains the whole path with fixed gaps and lost the Load-dialog
OK on one run — the click helper is fired by schtasks /Run, which is asynchronous, so batches
issued back to back can overlap and one gets dropped. Driving the path one cbstep.sh call per
click, with a screendump between, did not fail once. Prefer cbstep.sh + cbdo.sh over cbfull.sh
until that is understood.
| script | what |
|---|---|
cbstep.ps1 (on the guest, C:\SOTS\cb\) |
one click-helper batch; lines joined with ;; so PowerShell argument splitting cannot break sleep 500 into two arguments — which it silently does |
cbstep.sh |
send one batch |
cbdo.sh |
send one batch, then a fresh screendump |
cbmenu.py |
poll until the main menu is up |
cbload.sh |
the Load-dialog steps |
cbfull.sh |
the whole path (see the caveat above) |
On the guest: cbdeploy.ps1 -Tag <cfg> (stop, install DLL + cfg, clear autosaves and logs, launch),
cbgrab.ps1 -Name <run> (collect autosaves + logs + cfg into C:\SOTS\cb\<run>\ and print sha256s).
Row geometry: cbdeploy.ps1 deletes the three autosaves, so the Load dialog always lists the same
six files at y = 262, 291, 320, 349, 378, 407. ref-turn2 is row 4 (y=349), turn1-state
is row 5 (y=378). Selecting a row expands a preview panel that moves every row below it, so
select from a collapsed list or re-read the geometry from a screendump.