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
36 lines
2.1 KiB
Markdown
36 lines
2.1 KiB
Markdown
# 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.
|