2e7ed8f288
TradeManager::Slot13RngCalleeA, entered 0 times in every measurement any lane had taken, is entered 1x/turn once a player fleet is parked on a trade-sector node, and OnAllCombatDone_Tail's RNG word delta goes 0 -> 1. Lane W3's open risk is realised, not retired: the RNG ledger and the standalone's generator model need extending by one draw site. The gate is neither freighters nor a deployed spy. It is a fleet whose LocID resolves to a node of kind 2 (TradeSector), positioned bit-equal to the sector, whose owner's bit is set in the sector's tscr mask -- which the CCC_ComRaid tech sets, taking tscr from 252 to 253 and setting ServerPlayer CnRad. Before the tech the game refuses in as many words: 'Alpha Fleet cannot raid trade sector.' Control: same guest, same build, same shim.cfg.l3probe, one End Turn on lane L3's turn-15 save -> all three inner callees 0, tail delta 0. Guest adoption: ref-turn2 hooks=off reproduces the published determinism oracle exactly. Corrects lane L3 §3.5 (the turn-15 save already had a freighter in service -- the AI's -- so 'freighters' was falsified before this lane started) and lane V2's 'trade slot 13 is draw-free'. The spy half is decoded but NOT reached: no AI system in that game has an asteroid belt, so a deploy was impossible, and spies2 is therefore still untested and stays a rule-6 hypothesis. Two new corpus saves; expect the coverage ratchet to break on CnRad, tscr=253, three rt records and a fleet whose LocID is a TradeSector. |
||
|---|---|---|
| .. | ||
| 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.