d9b06ca447
The observed-design list is a MOVE-TO-BACK vector capped at 20 records per
DESIGN OWNER, and that is why lane CV's 55 odes leaves looked unrelated: a turn's
output is a permutation of its input, not an append.
rich turn ad-turn27 + BR's deep tcb vs bp-pinB-turn28 1092 -> 1058
36 closed / 2 regressed vs CV's run; 116 / 8 vs the 1166 baseline
canonical turn2-state + CB's tcb vs turn3-state 62 -> 61
1 closed / 0 regressed, set-differenced by leaf PATH
All five committed predictions held; P5 held in direction and was wrong in
magnitude (9 leaves, not 4 -- I predicted spurious records, not leaves).
CV's "no upstream dependency" is right for the design half and wrong for the
other 24 leaves of the 79, two separate ways, and both are named rather than
attempted: the otch/owep arms need three undecoded design->tech/weapon set
builders (the wire's own DOpts list covers 13 of the 18 tech names the turn
moves), and the design half is itself capped by SHIP CONSTRUCTION -- two designs
get their first ships that turn. Fed the true post-turn ship list the same code
leaves 1 leaf of 55 instead of 21, so the mechanism is not the residual.
Control, run: with the NPC-owner guard compiled out the canonical pair goes
61 -> 70 and the rich turn stays at 1058. The guard is load-bearing on one pair
and inert on the other, which is why both were run.
Coverage, stated as loudly as the divergence: 8 players swept, TWO produce any
record; the canonical pair offers 16 (player, ship) pairs of which the guard
drops 15, leaving one record call on one design. No foreign observation moves on
either pair, so the visibility gate -- a two-bit-per-player word at Ship+0x54
that is not on the wire, stood in for with ownership -- is entirely unexercised
and is labelled a hypothesis.
ghidra/addresses.d/dt.json: 10 entries (the sweep 0x007c2350, the recorder
0x007be340, RecordObservedWeapon, the vector helpers, sizeof(ObservedDesign) =
0x10, the vftable, and ServerPlayer +0x254 / +0xfb). gen_addresses.py merges it
clean at 1320 entries, no duplicate name or address.
|
||
|---|---|---|
| .. | ||
| ag.json | ||
| ap.json | ||
| ar.json | ||
| as.json | ||
| az.json | ||
| bu.json | ||
| cz.json | ||
| dn.json | ||
| dt.json | ||
| lane-a.json | ||
| lane-a2.json | ||
| lane-ac.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-id.json | ||
| lane-j.json | ||
| lane-k.json | ||
| lane-l1.json | ||
| lane-l3.json | ||
| lane-l4.json | ||
| lane-l5.json | ||
| lane-n.json | ||
| lane-o.json | ||
| lane-p2.json | ||
| lane-par.json | ||
| lane-pl.json | ||
| lane-q.json | ||
| lane-rb.json | ||
| lane-sd.json | ||
| lane-sv.json | ||
| lane-t.json | ||
| lane-t2.json | ||
| lane-u.json | ||
| lane-v2.json | ||
| lane-w.json | ||
| lane-w2.json | ||
| lane-w3.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.