4a212e25b4
Mars::RNG::Chance at 0x00887c8a, in the BODY of ServerSpyManager::vslot13 (tail phase 23 call 9), measured at 1 call / 1 word / no_draw_calls=0 / strategic=true on VM144 at probes=8, with OnAllCombatDone_Tail going 363 -> 364 against 0 on every turn any lane has measured. The entry probe on SpyManager::Slot13RngCallee read 0 on the same turn -- that zero was never about the subtree. Predicate, decoded to save fields: spy.deat != 0 && spy.sdet == -1 && sys(deat).ARes2 > 0 && (sys(deat).TerrFl & 1). Corpus count 0 of 22; the failed conjunct is deat != 0, not the belt -- all 22 corpus saves already had one. Also: ServerSystem::AddSpy 0x007514c0 writes deat and pushes the spy id into ServerSystem+0x1cc in the same two instructions, so spies2 is the per-system DEPLOYED-spy vector; measured non-empty for the first time in the corpus. And 0x0078c97f, a strategic NextFloat in the SHIPACTION_DEPLOYSPY handler, is in no existing inventory -- decoded, not measured. |
||
|---|---|---|
| .. | ||
| ag.json | ||
| as.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.