sots-re/findings/control-flow/tail-probes.md

# Five probes on the running game — and a harness defect the probes found in themselves

Lane H, 2026-09-08. Program `sots` / "Sword of the Stars.exe", ImageBase 0x00400000, all addresses VAs.
Engine worktree `wip/probes`, predictions in `sots-engine/docs/H-probes.md`, **committed before the build**
(method rule 2). VM140 held for the duration; released at the end.

**The headline, in order of what depends on what.**

1. **The determinism oracle reproduces exactly.** `bb4fd9ac…` and `978041ac…`, byte for byte, after
   everything this session changed. §1.
2. **A hook in this lane's own instrument changed the game's output**, and it was caught by comparing
   against a save lane Z had already produced. Bisected to **one address**. Every measurement below
   was then re-taken on a configuration proved byte-neutral against that save. §2.
3. The four tail callees that can draw are **entered on every single turn** and gated *inside*; the
   three inner functions that hold the draws are entered **zero** times. "Never observed firing" was
   about a gate, not about reachability. §3.
4. `CreateRaidEncounter` **is called** — twice on one measured turn — and **draws nothing**. The two
   hypotheses a word count could not separate are separated: the candidate list is empty. §4.
5. The Zuul prediction holds exactly: **7 calls and 7 words per site, 14 not 16.** The raid loop
   iterates the player vector. §5.
6. `EncounterDetect::AssignContacts` cannot fire on our corpus for a reason nobody had measured: its
   caller is never called, because `EncounterDetect_Run` receives an **empty** record vector. The
   2-word detection residual is somewhere else entirely, and §6 names the function it is in.

---

## 1. The oracle, regenerated — and it reproduces

Lane N's End Turns overwrote the three autosave *contents* on VM140 and said so. The file set was
never disturbed, `ref-turn2.sav` still hashed `ab4ac2d7e2977260…` (checked before the run), and all 11
curated saves were in the repo, so nothing was lost — but the reference pair had to be remade.

Load `ref-turn2.sav`, one End Turn, build `recap-7584bad-20260908T0615Z`, `hooks=trace`:

| file | size | sha256 | historical value |
|---|---|---|---|
| `(Autosave EndTurn).sav` | 66,732 | `bb4fd9ac89f41e3bc0db2af08b18ce83417521ac4bcee695fc9fa6ce16e30948` | **identical** |
| `(Autosave).sav` | 67,219 | `978041acd168b56ed8eb3f5e42e78d5e70eae6e6517d75e659a5eb7ca3d60921` | **identical** |

**Both reproduce.** The turn-2 state on screen (Imperial Savings 289,688) and the turn-3 state
(532,369) match `determinism-oracle.md` as well.

This is worth more than a repeat. The process the oracle now runs in is not the one it was measured
in: nineteen template hooks and seven entry-point detours installed instead of one asm stub, an x87
control-word module, eight save files where there were four, and a Zuul game played to turn 64 in the
same directory in between. **The oracle is revalidated across all of that**, which is what every
Phase-2 comparison downstream of it needed.

Files: `verify/results/shim/probes/oracle-restore/h-oracle-{endturn,autosave}.sav`.

**And the same two files were put back on the VM at the end**, so the three autosaves once again carry
the documented oracle bytes. That is a restore of bytes this lane produced by an actual run today, not
a substitution of an older snapshot — the distinction lane N was right to insist on.

---

## 2. The instrument perturbed the game. Bisected to one address.

This section is first among the probes because it invalidates a run and because nothing in this
campaign has ever tested it.

### 2.1 How it was caught

Three End Turns from `ref-turn2` under the full lane-H build gave per-turn word counts of
**19, 18, 19**. Lane Z's per-site table for the same three turns of the same save reads **19, 18, 20**.
One word apart on the third turn — the kind of difference that is easy to explain away as workload.

It was not explainable, because the **input was byte-identical**. The run's `(Autosave EndTurn).sav`
(the turn-4 pre-turn state) hashed `8648957fecf5041233f9add4c8173f78981f026f133ecdbecdb89ddd10917048`,
which is exactly lane Z's `z2-endturn.sav`. Same bytes in; different bytes out:

| | `(Autosave).sav` after the turn-4 → turn-5 End Turn | size |
|---|---|---|
| lane Z (`z2-autosave.sav`, and `z-t5-autosave.sav` from a second lane-Z run) | `b2124798470d85ea…` | 68,267 |
| lane H, full build | `058656787877cbee…` | 68,263 |

Both sides are reproducible: lane Z's value appears in two of its runs, and lane H's appeared in two
of its own (three consecutive End Turns, and a fresh load of `z2-endturn.sav` followed by one End
Turn). So this is not noise in either direction.

### 2.2 The bisect

`z2-endturn.sav` was pushed to the VM and the same single End Turn run five more times, changing one
thing each time. A `probes=` key was added to `shim.cfg` for exactly this purpose — an instrument that
can change what it measures has to be switchable, or the question cannot be asked at all.

| configuration | `(Autosave).sav` | verdict |
|---|---|---|
| `hooks=off` — the shim installs **nothing** | `b2124798…` | the un-instrumented game |
| all template hooks + 7 draw-site detours, `probes=0` | `b2124798…` | **neutral** |
| + probes 0–3 (the four phase-23/33 vtable callees) | `b2124798…` | neutral |
| + probes 4–7 (three inner callees, `CreateRaidEncounter`) | `b2124798…` | neutral |
| + probe 8 (`ServerTradeManager_GenerateTradeRaidEncounters` 0x00893290) | **`058656…`** | **perturbs** |

Two things fall out, and the first is the more important:

* **The un-instrumented game agrees with lane Z, not with lane H.** So lane Z's ledger — 7 draw-site
  detours and 6 nested template hooks — **is behaviour-neutral on this pair**, and its published
  numbers stand. This is the first time any lane has checked that, and it came out the right way.
* **Hooking `GenerateTradeRaidEncounters` at 0x00893290 with a MinHook detour changes the turn.**
  Specifically it *suppresses* the `ServerPlayer::RollResearchEvent` draw at 0x0088df4f: the clean run
  spends 20 words with that site firing once, the perturbed run spends 19 with it not firing at all.

### 2.3 What the mechanism is not

The obvious relocation hazard is **absent**. The bytes at 0x00893290 are

```
55              push ebp
8b ec           mov  ebp,esp
6a ff           push -1                 <- the 5-byte patch boundary falls exactly here
68 37 c3 99 00  push 0x99c337           ; SEH scope table
64 a1 00 00 00 00  mov eax,fs:[0]       ; ... standard MSVC __try + /GS prologue
```

so MinHook's five bytes land on a clean instruction boundary, the relocated prologue is three
position-independent instructions, and there is no branch target inside the patched range. A mangled
prologue is therefore **not** the explanation, which makes this more interesting rather than less.

**The mechanism is undetermined and is recorded as an open item, not guessed at.** What is odd, and is
the thing to chase: `RollResearchEvent` runs *earlier in the turn* than trade-raid generation, so
hooking 0x00893290 changed a decision taken before the hooked function was reached. The cheapest next
probe is a compare-mode hook on `RollResearchEvent` in both configurations, reading the threshold and
the progress value it tests, on the same input save.

### 2.4 What this costs, and what it does not

* Every number in §§3–6 was re-taken at `probes=8`, the largest configuration proved byte-identical
  to the un-instrumented game on this save. Nothing below rests on the perturbed run.
* The perturbed run's trace is kept — `verify/traces/h-probes-human-perturbed-t3-5.jsonl.gz`, report
  `verify/results/shim/probes/human-t3-5-perturbed.txt` — labelled as such, because it is the evidence
  for §2 and because its probe *entry counts* agree with the clean runs on every row.
* **The general lesson is a method rule waiting to be written.** A behavioural harness has to be
  checked against the oracle, not just against itself. It cost one save comparison to find this; it
  would have cost a published wrong number to find it later. The `probes=` key exists so the check is
  cheap to repeat: any lane adding detours should run one End Turn from `z2-endturn.sav` and confirm
  `b2124798470d85ea…` before trusting its own measurements.

---

## 3. The four tail callees — reached on every turn, gated inside

Lane V2 closed lane K's tier-4 blind spot: four of the eleven phase-23/33 vtable targets on
`StrategyServer+0x158`/`+0x15c` reach a draw on the strategic generator, at eight instructions. Lane Z
measured 0 tail words on eight turns. Between those two facts sat a question a word count cannot
answer — *not reached*, or *reached and gated*?

Register-transparent asm stubs (`pushfl; pushal; push idx; call; popal; popfl; jmp trampoline`) count
entries without assuming a calling convention. Two saves, three measured turns:

| address | what | Human t5 | Zuul t24 | Zuul t25 |
|---|---|---|---|---|
| 0x008877b0 | `ServerSpyManager` slot 13 | **1** | **1** | **1** |
| 0x0088db80 | `ServerSpyManager` slot 14 | **1** | **1** | **1** |
| 0x0088ef80 | `ServerTradeManagerImpl` slot 13 | **1** | **1** | **1** |
| 0x0082cca0 | `ServerTradeManagerImpl` slot 15 | **1** | **1** | **1** |
| 0x008408e0 | `SpyManager_Slot13RngCallee` | 0 | 0 | 0 |
| 0x00820ca0 | `TradeManager_Slot13RngCalleeA` | 0 | 0 | 0 |
| 0x0088b440 | `TradeManager_Slot13RngCalleeB` | 0 | 0 | 0 |

**P2a and P2c both hold.** The phase-23/33 dispatch block is unconditional, exactly as lane V2 read
it; and the gate that keeps the draws from firing is **inside each outer body, above the inner call**.
No draw-site row appeared at any of the eight return addresses on any turn, and the tail's bracket
cost stayed 0 — reproducing lane Z's number under an instrument that can now say *why*.

So the correct statement is no longer "the tail draws nothing" and not even "the tail draws nothing on
these turns". It is: **the tail's four draw-bearing callees run on every turn and return before
reaching their draws.** That is a much stronger negative, and it converts the open question from
"which turns reach these functions" to "what does the gate in each body test".

### 3.1 Three of the four gates are an empty container; the fourth is not, and it was wrong

Read from the bodies (each confirmed a real function start with exactly one caller):

| callee | the loop it drives | empty when |
|---|---|---|
| `ServerTradeManagerImpl` slot 15 | vector at `tradeManager+0x3c .. +0x40` | no trade routes |
| `ServerSpyManager` slot 14 | vector at `spyManager+0x10 .. +0x14` | no spy programs |
| `ServerSpyManager` slot 13 | 1,869 bytes, same manager, not fully read | — |
| **`ServerTradeManagerImpl` slot 13** | **`GetServer()+0x64 .. +0x68` — the FLEETS vector** | **no fleets** |

That last row produced a competing prediction, **P2b-alt**, committed after the bodies were read and
before any run: on a save with fleets, slot 13's loop body runs, `TradeManager_Slot13RngCalleeA`
fires, and the tail cost is non-zero.

**P2b-alt is falsified, and cleanly.** `zuul-turn23-fleet23.sav` is named for its 23 fleets; slot 13
was entered on both its turns and 0x00820ca0 was entered **zero** times. So the fleet loop is not the
gate — the per-fleet test chain that precedes the call at 0x0088f036 is, and it rejects every fleet on
a 23-fleet save. That is a narrower and more useful place to look than "the loop never runs", and it is
the kind of wrong prediction that pays for itself: had P2b been the only one written down, its
confirmation would have been read as "no trade routes, no spies" and the fleet loop would have gone
unexamined.

### 3.2 What is still a hypothesis (rule 6)

**Whether any of the eight draw sites ever fires** is still unexercised. The workload that would
settle it — a game with live trade routes and a live spy program — was **not built**, and it is worth
saying exactly why rather than vaguely:

* SotS 1 trade income requires trade-station construction and the tech behind it; from `ref-turn2`
  (turn 2, 1 colony, 0 techs) that is tens of End Turns at 30–60 s each plus a Build/Research click
  path per turn. The newest Zuul save in the corpus (turn 23) still has **no** trade routes: slot 15's
  loop body did not execute on it.
* The corresponding spy state is worse — no lane has yet identified which UI produces an entry in the
  `spyManager+0x10` vector, so there is no click path to write down, only a container to watch.
* What this lane did instead was cheaper and, for the map, better: it established that the containers
  are the gate for two of the four and that the fourth is gated per-fleet. A future lane that builds
  the workload now knows which two vectors to watch fill, and can confirm the workload took *before*
  spending a turn measuring.

---

## 4. `CreateRaidEncounter` — the two hypotheses, separated

A successful trade-raid roll calls `ServerTradeManagerImpl` slot 17, `CreateRaidEncounter` 0x008938a0,
which draws a `NextInt` at 0x008939ee to pick a target but returns at 0x0089391c **without drawing**
when the candidate vector is empty. It cost 0 words on all three of lane Z's turns, which lane Z read
as consistent with either "no roll succeeded" or "the candidate list is empty".

**A correction to the prior first (rule 11).** Lane Z wrote that no roll succeeding is "≈11% on the
defaults, so three quiet turns in a row is unremarkable". 11% is the probability of a quiet *turn*:
`0.8^8 × 0.95^8 = 0.1113`. Three consecutive is `0.00138`, about **1 in 720**. The two hypotheses were
never close to equally likely, and the expected number of successes per turn is `8 × 0.2 + 8 × 0.05 = 2.0`.

**Measured:**

| turn | `CreateRaidEncounter` entries | words drawn |
|---|---|---|
| Human t4 → t5 | 0 | 0 |
| Zuul t23 → t24 | **2** | **0** |
| Zuul t24 → t25 | **1** | **0** |
| Human t3/t4/t5, perturbed run | 0 / 1 / 0 | 0 |

**Settled: rolls succeed at about the predicted rate, and the candidate list is empty every time.**
Four successful rolls were observed across five measured turns and not one of them reached the
`NextInt` at 0x008939ee — no draw-site row at return address 0x008939f3 on any turn.

For the standalone this is the useful form: on a corpus like ours the cost of a successful raid roll
is **0 further words**, and the row lane Y flagged as "the one that will bite" does not bite yet. It
will bite the first turn a raid candidate exists, and the candidate list is built by 0x0083b110 — a
function no lane has read.

**One caveat this lane found and must state.** `CreateRaidEncounter` is slot 17 and is reached by
virtual dispatch, and `GenerateTradeRaidEncounters` is **not its only caller**: `0x007d5150`, the
other subtree of `DetectEncounters` (see §6), also dispatches slot 17 —
`(**(code **)(**(int **)(S + 0x158) + 0x44))(out, player, 1, records)` — on the branch where its own
per-player roll returns 0x12. So an entry count of 2 does not prove two *trade-raid* successes; it
proves two slot-17 calls from one of two known sites. Separating them needs the return address, which
an entry counter deliberately does not capture. `tail-rng-ledger.md` §11.1's "called from
`GenerateTradeRaidEncounters` at 0x0089345e / 0x00893548 / 0x00893603" is incomplete as a list of
callers.

---

## 5. The Zuul word count — 14, exactly as predicted

Lane Z's free prediction, restated by lane Y as a consequence of its `trade_raid.cpp` model: the two
`Chance` sites in `GenerateTradeRaidEncounters` cost one word per entry of `StrategyServer::Players`,
which holds 8 on the Human saves and 7 on the Zuul ones. Lane N ran a Zuul End Turn with the RNG hooks
off, so it could not answer.

`zuul-turn23-fleet23.sav`, two End Turns, `probes=8`:

| site | Human t5 | **Zuul t24** | **Zuul t25** |
|---|---|---|---|
| 0x00893426 `Chance` (`TRADE_RAID_ODDS_PLAYER`) | 8 calls / 8 words | **7 / 7** | **7 / 7** |
| 0x00893513 `Chance` (`TRADE_RAID_ODDS_NPC`) | 8 calls / 8 words | **7 / 7** | **7 / 7** |
| trade-raid block total | 16 | **14** | **14** |
| turn total (attributed = measured) | 20 | **18** | **18** |

**P5 holds in full**, and it is a prediction that survived a changed workload rather than a repeat of a
recording: 7 is a number no earlier run produced. The loop iterates the server's player vector and
nothing else — not the `TeamRecord` vector it is handed, not a species list, not a fixed NPC count.
Lane Y's `trade_raid.cpp`, which counts `NumPlrs`, is right.

The Zuul turn's remaining 4 words are 2 detection (§6) and **2 research** — both `ProcessResearch`
sites (0x00587888 and 0x005878bb) fired on both turns, which is the second research site's first
appearance in a site table.

---

## 6. `DetectEncounters` — the residual is not the `AssignContacts` family, and here is where it is

Lane Y's standalone leaves a 2-word residual per turn, attributed by lane Z to 0x0050329d
(`NextFloat`, depth 4) and 0x007929a4 (`NextInt`, depth 3), and refused to model it: *"fitting 2/turn
to three observations is not a model."* Lane I bounds the containing family at
`|contacts| × |detectors|` and showed `EncounterDetect_AssignContacts` draws one inlined `NextFloat`
per (contact, detector) trial. Lane Z found `AssignContacts` never ran.

`EncounterDetect_ProcessTeamRecord` 0x007ca640 — its only caller — was hooked, with lane I's gate
predicate, contact count and detector count recomputed from the record at hook entry.

**It never ran either. On any turn, on either save.** The hook installed (`MH_OK` for create and
enable, logged), was registered in the trace's meta line, and emitted **zero records** across five
End Turns, while the entry probe on `EncounterDetect_Run` recorded **one call per turn, every turn**.

`EncounterDetect_Run` calls `ProcessTeamRecord` once per 0x74-byte record. One call, zero records
means the vector it receives is **empty**. So:

* **`AssignContacts` cannot fire on our corpus, and the reason is one level higher than anyone
  thought.** It is not that the `+0xfc` gate fails on the records — there are no records. Lane I's
  `|contacts| × |detectors|` bound is correct and simply has nothing to bound yet.
* **P3b is falsified**, exactly as its falsification clause anticipated, and the depth reasoning that
  produced it was wrong about the *path*, not the depth.

### 6.1 Where the two words actually are

A call-graph walk from both residual sites upward lands in the same place, and it is not
`EncounterDetect_Run`:

```
StrategyServer::DetectEncounters 0x007d7f70          (the last phase of ProcessTurn)
 ├─ 0x007d8469  GenerateTradeRaidEncounters   [virtual]   16 words (14 on Zuul)   §5
 ├─ 0x007d8470  EncounterDetect_Run 0x007cb080           0 words -- empty record vector
 └─ 0x007d860b  0x007d5150                               ** the 2 words **
      ├─ 0x007d52b3  0x0078cc70 -> 0x0078ccb1  0x00503200 -> NextFloat 0x0050329d   1 word
      └─ 0x007d5311 / 0x007d5338  0x00792750  -> NextInt  0x007929a4                1 word
```

Every one of those edges is a direct `call` with a **single** incoming reference, so the attribution
is not a guess: 0x00503200 has exactly one caller (0x0078cc70), which has exactly one caller
(0x007d5150); 0x00792750 has two call sites, both inside 0x007d5150; and 0x007d5150 has exactly one
caller, `DetectEncounters` at 0x007d860b.

**The whole detection residual is inside one 744-byte function with one call site.** That is a far
better handle than a family bound over two counts nobody can observe, and it makes the residual a
tractable modelling target rather than a fitted constant. From its body:

* it first builds a bitmask over the same `records` vector (`entry[0]->+0xf9 == 0` sets bit
  `entry[0]->+0x28`) and returns immediately if the mask is 0;
* it then loops the **player vector** at `+0x54/+0x58`, skipping players whose mask bit is set or
  whose `+0xf9` is non-zero, builds a per-player candidate vector (0x00795870), and for each
  non-empty one calls 0x0078cc70 — **that is the `NextFloat`** — whose non-zero return leads on, and
  whose return value of **0x12 dispatches slot 17, `CreateRaidEncounter`** (§4's caveat);
* the measured cost is 1 call and 1 word per site per turn on 8-player and 7-player saves alike, so
  only one player reaches the draw per turn on both — the per-player gate, not the loop bound, is what
  sets the count.

That last observation is the one to hand lane Y: **the 2 words are not `2 × |players|` and not a
constant by luck — they are one per player that passes a gate, and on both corpus saves exactly one
player passes.** A model that assumes 2/turn will be right on our saves and wrong on a busier one, and
now there is a named function to read to find out when.

### 6.2 The hook that measured nothing, reported as loudly as the ones that did (rule 15)

`EncounterDetectProcessTeamRecordHook` compared nothing, because it never ran. Its coverage notes, its
gate predicate, its contact/detector classifier and its byte-vs-dword cross-check on `+0xfc` are all
**unexercised**. They are kept in the tree because the moment a save produces a non-empty record
vector they become the check that matters — but nothing in this report rests on them, and the
`fc_byte_vs_dword_disagreements` counter has never returned a value. Lane I's classification rules are
therefore still exactly as verified as they were: from the instruction stream, and from nowhere else.

---

## 7. Coverage — what these runs did not touch

* **Five End Turns on two saves.** Human `ref-turn2` turn 4 → 5 (once clean, three times in the
  perturbed run) and Zuul turn 23 → 25. That is a thin workload measured precisely.
* **No trade routes, no spy programs, no manufactured workload for either.** §3.2 says what it would
  take. Until then, every statement about the eight tail draw sites is "they are not reached on a game
  with none of either", and the four callees' gates are located but not read.
* **`ServerSpyManager` slot 13 (1,869 bytes) was not read.** Its loop and its gate are unexamined; it
  is grouped with slot 14 above only by manager, not by evidence.
* **The probe counters cannot say which caller.** They record entries, not return addresses — a
  deliberate cost of being calling-convention-agnostic — and §4 shows that costing something real.
* **The perturbation's mechanism is unknown**, and it is the largest open item this lane produced.
  A second, independent instance may already exist and be undetected in some other lane's build; the
  `z2-endturn.sav` → `b2124798470d85ea…` check is cheap enough that every future VM lane should run it.
* **No `Guard` region is declared by any hook in this family**, the same deliberate gap lane Z
  reported: these hooks measure the generator and claim nothing about game state. `undeclared = 0` in
  these traces is vacuous and must be read that way.
* **`probes=8` is proved neutral on one save and one turn.** It is not proved neutral in general, and
  the Zuul numbers in §3 and §5 inherit that limit — they were taken on a configuration validated
  against a Human turn, not a Zuul one.

## 8. Corrections to earlier findings

* `tail-rng-ledger.md` §11.1: the caller list for `CreateRaidEncounter` is incomplete — 0x007d5150
  dispatches slot 17 as well (§4).
* `tail-rng-ledger.md` §11.1: "three quiet turns in a row is unremarkable" — it is a 1-in-720 event,
  and the measurement shows the rolls do succeed (§4).
* `tail-rng-ledger.md` §11.3 and lane Y's residual table: the 2-word detection residual is **not** the
  `AssignContacts` family and is not blocked on the `+0xfc` gate; `EncounterDetect_Run` receives an
  empty vector, and the words are in 0x007d5150's subtree (§6).
* Lane V2's per-slot notes: "never observed firing" is confirmed for the draws and **wrong as a
  statement about the callees** — all four run on every turn (§3).
* `combat-done-tail.md` tier 4 / lane V2: the trade slot-13 loop is over the **fleets** vector, and a
  23-fleet save still reaches no draw (§3.1).

## 9. Files

* Predictions (pre-registered): `sots-engine/docs/H-probes.md`.
* Traces: `verify/traces/h-probes-human-t5.jsonl.gz`, `h-probes-zuul-t24-25.jsonl.gz`,
  `h-probes-human-perturbed-t3-5.jsonl.gz`.
* Reports: `verify/results/shim/probes/{human-t5,zuul-t24-25,human-t3-5-perturbed}.txt`;
  tool `tools/probe_report.py`.
* Oracle pair: `verify/results/shim/probes/oracle-restore/h-oracle-{endturn,autosave}.sav`.
* Addresses: `ghidra/addresses.d/lane-h.json` (3 entries, all `mapped`).
* Shim: `sots-engine/src/shim/hooks/probe_entry.{h,cpp}`, the `probes=` config key, and
  `EncounterDetectProcessTeamRecordHook` in `tail_rng.{h,cpp}`; configs `shim.cfg.hprobes*`,
  `shim.cfg.hp{0,4,8,9,10,11}`, `shim.cfg.hoff`.

---

## 10. Priority insert from lane AI1 — run before the VM was released

Lane AI1 asked for its P1–P3 on the same VM session. Results are written up where they belong, in
`findings/subsystems/ai-turn-logic.md` §8.1; in brief:

* **P2 held — and it is the roadmap-level one.** `ref-turn2.sav` loaded in **two separate process
  launches** (pids 3400 and 2028, killed and relaunched between), shim at `hooks=off` so nothing is
  installed, one End Turn each: both autosaves byte-identical to each other and to the 2026-09-07
  oracle. Byte-identity subsumes `ModCount` and `Summary.Checksum`. **The AI's turn is reproducible
  from a save alone**, so `backlog.md` §2's Rung B stays as written. Seven fresh processes across two
  saves agreed today in total, counting the `z2-endturn.sav` bisect runs of §2.
* **P1 could not be answered as specified.** `session.log` after a full load + End Turn of a game with
  an AI player is 22 lines and contains no `RunAI:`, no `random seed` and no `AI Process Turn` line;
  the game's stdout carries the same 22 and nothing more. The level-2 messages are not emitted by this
  build at its default log level, so the "one log read, no build" route does not exist. A suggestive
  counter-indication to the all-zero-seed prediction is recorded there as a hypothesis, with the
  decisive test named (record the `this` pointer beside the return address in `draw_sites.cpp`).
* **P3 not run** — no `ModCount` watchpoint was armed and no debugger session was held.

## 11. VM140 released

Left at the **main menu**, verified by screenshot, build `recap-7584bad-20260908T0615Z`,
`shim.cfg` = the recap trace config, `SavedGames\` back to the documented **8-file** set
(`ref-turn2` still at (400,436), `zuul-turn5` at (400,465)) with the three autosaves carrying the
oracle bytes `bb4fd9ac…` / `978041ac…` / `978041ac…`. Lane H left `C:\SOTS\shimdist-h` and
`C:\SOTS\ui\h{deploy,release}.ps1` in place, plus `C:\SOTS\ui\h-oracle-{endturn,autosave}.sav` and
`ai-run{1,2}.log`.

**One VM note worth carrying forward.** The board's advice to screenshot before clicking is right but
under-specified: the *intro* screens are bright white, so a brightness threshold fires on them and the
click batch lands nowhere. The reliable detector is **redness in the main menu's Exit button** —
crop `100x14+462+674`, require `mean.r > 0.2` and `mean.g < 0.15` (the menu reads 0.327 / 0.036; the
white intro reads 1.0 / 1.0; a black screen reads 0 / 0). With that, every one of this lane's ten
launches reached the menu on the first attempt, at t+48…54 s.