ae47971316
Joins the emission side (lanes AI1-AI3) to the counting side (A2, W2). Three results. The cost of applying a command is a property of its list, and the boundary is sharp: lists 1-16 each advance ModCount once per element, lists 17-27 never do. Four of the six prologue gates bump, one is free, and the sixth has no applier anywhere in the application path -- its cost is unknown, not zero. The batch applies the twenty-seven lists in a fixed order that is neither list nor offset order, with the six gates split across three separate per-player loops at three different points, and four of the sixteen bumps inlined into the batch rather than living in a handler, which is why a call-graph sweep under-counts them. Lane W2's four unnamed handler EIPs are named, and so are its two inlined ones, and the ten measured command bumps then decompose with zero residual. Four of the ten are the research-rate gate, one per submitted block, and one of those four is the human's. Two are list 14, on a turn that moved exactly one fleet -- which confirms lane AI2's P1 (an AI fleet order deposits two fleet-task elements where the interface deposits one) from the counter side, at no VM cost. The reference game is not what the record says. ref-turn2.sav IS turn2-state.sav; there are THREE AI players, not one, and the two dormant ones do run -- all three set a research rate and picked a research target on turn 1; and the four monster-faction players submit no command block at all, which is the first direct evidence that they have no client rather than an empty task list. Prediction committed for turn1-state: the same 12, out of a different set of commands -- 4 rate gates, 3 research targets, and three orders from the one AI with an empire, which are predicted to be a new design, a build order and a system-rates command, with NO fleet order on turn 1. The trap multiset it predicts contains two EIPs W2 has never seen and omits three it did, so it is cheap to falsify: one save swap on W2's unchanged watchpoint module. Also: phase 2 of the AI's turn is Hiver-only (a fifth cross-check on the species reading, and the reason one prologue gate has never been observed set), phases 29-33 are dead because the submit latches the client before it builds the send buffer, and cl_SetResearchTarget is AI-only surface with exactly one caller. 14 addresses in ghidra/addresses.d/lane-ai4.json; validated to a scratch path, 1,138 -> 1,152, no duplicate names. |
||
|---|---|---|
| .. | ||
| lane-a.json | ||
| lane-a2.json | ||
| lane-ai1.json | ||
| lane-ai2.json | ||
| lane-ai3.json | ||
| lane-ai4.json | ||
| lane-b5.json | ||
| lane-b6.json | ||
| lane-c3.json | ||
| lane-d2.json | ||
| lane-e1.json | ||
| lane-e3.json | ||
| lane-ev.json | ||
| lane-g2.json | ||
| lane-g3.json | ||
| lane-h.json | ||
| lane-i.json | ||
| lane-j.json | ||
| lane-k.json | ||
| lane-n.json | ||
| lane-o.json | ||
| lane-p2.json | ||
| lane-q.json | ||
| lane-t.json | ||
| lane-t2.json | ||
| lane-u.json | ||
| lane-v2.json | ||
| lane-w.json | ||
| lane-w2.json | ||
| lane-z.json | ||
| README.md | ||
Per-lane address fragments
addresses.json is a single shared file. When several lanes run concurrently they edit the
same lines, and three times on 2026-09-08 one lane's git add swept another's in-flight
entries into the wrong commit. Nothing was lost, but authorship and atomicity were.
A lane may instead drop its own file here:
{ "entries": [ { "name": "...", "addr": "0x...", "convention": "...",
"prototype": "...", "status": "verified", "source": "findings/..." } ] }
Name it after the lane (lane-d.json). tools/gen_addresses.py merges every fragment in
sorted order after addresses.json. A duplicate name across files is a hard error, not
last-wins — two lanes disagreeing about an address is exactly the thing we must not paper over.
The integrator folds fragments back into addresses.json once the lane's work is merged.