board: lane B5 retreat pipeline; OID allocation closed; predicted original bug

campaign/board.md

@@ -194,3 +194,9 @@ Status flow: `backlog → in-progress → mapped → verified` (or `blocked`).
 | CORRECTION: the -0.15 divisor defect is much worse than noted | verify | verified | high | 100% | 2026-09-08 | The repo characterised the wrong bankruptcy divisor as roughly "one ulp on large empires". THAT UNDERSTATEMENT IS WRONG - and lane Y corrected its OWN prediction which had repeated it. `-0.15` and the real `-0.15000000596046448` differ for EVERY maxIncome DIVISIBLE BY 3, from m=3 (-20 vs -19), and the rate climbs: 33.3% below ~1.2M, 66.7% at ~1.4M, **100% above 3M**. SIX OF THE 25 CORPUS RECORDS would get a different BnkEl from the engine's current constant than the game wrote. One-line fix in economy.cpp wanting a test at maxIncome=3. Lane Y reported it and did NOT touch the file - it is lane N's |
 | re-ranked path to the byte-match | meta | mapped | high | 100% | 2026-09-08 | Lane Y's ranking, superseding lane S2's now that the RNG ledger is closed: (1) PER-SYSTEM MONEY OUTPUT - now has a per-save oracle - unblocks P01/P02/P05/P06/T31 and 5 of 11 record fields, ~82 of 204 leaves and 2 of the 4 missing words; (2) S04 alliance mask - 8 of the 17 leaves stopping T36; (3) encounter detection - the last non-research generator residual, HOOK-SHAPED; (4) ship-design catalogue (hull size + 0x400) - census, ship records, part of T24; (5) ModCount - ONE leaf, but it feeds Summary.Checksum, so NO BYTE-MATCH WITHOUT IT |
 | three hook-shaped questions for the VM holder | verify | backlog | — | 0% | 2026-09-08 | Lane Y raised these per rule 18: bracket DetectEncounters with contact/detector counts (settles the last non-research generator residual); hook CreateRaidEncounter to separate "no roll succeeded" from "candidate list empty" (a word count CANNOT); and run one ZUUL End Turn - THE STANDALONE PREDICTS 14 WORDS THERE, NOT 16, which tests what the raid loop actually iterates over. All three routed to lane N mid-flight |
+| CORRECTION: FUN_007d5a00 is RETREAT, not a combat pipeline | control-flow | verified | high | 95% | 2026-09-08 | Lane B5 corrects lane J's characterisation. It is the RETREAT pipeline - and THE LARGEST WRITER OF SAVED STATE ANYWHERE UNDER THE COMBAT RESOLVER. Lane J's "the resolver's own body writes nothing outside its stack context" STANDS; this is where a large part of "its callees write plenty" lives. Seven saved fields/containers move, ALL `verified` in struct-recovery.md so the autosave oracle sees all of them: StarShip.FltID (ships of a partly-retreating fleet re-parented); the StarFleet master list off S+0x64 (one fleet CREATED per partial group, every emptied fleet DESTROYED); **NMnx**, the object-id counter, `inc [ecx+eax*4+0x10]` at 0x008b8b16 once per created fleet; NShips/FtFlg (new fleet born with flag 0x400, retreaters flag 2); LocID/Pos/PrvPos/inline FlightPlan (gate retreat TELEPORTS, normal retreat installs a flight plan); ServerSystem VFlags/EFlags/AFlags/FFlags + NumFlts - AND RETREATING FROM AN UNEXPLORED SYSTEM MARKS IT EXPLORED FOR YOU; ServerPlayer.GTraf + per-system NVs/PlayerView debited and re-credited around every membership and plan change |
+| OID allocation CLOSED - R2's x16 is a shl 4 | objects | verified | high | 100% | 2026-09-08 | struct-recovery.md 7's long-open "OID allocation (R2's x16)" is answered. The allocator is IDMap::AllocateID 0x008b8ae0; the counter is PER NETWORK NODE at IDMap->+0x08 + node*0x14 + 0x10, pre-incremented, never issues 0; an id is `(counter << 4) | (node & 0xF)`. R2's x16 IS THE shl 4. Found ONLY by following E9 TAIL-CALL THUNKS - an 8-byte jmp thunk hid the whole chain from the first closure pass |
+| retreat destination rule + a predicted ORIGINAL BUG | control-flow | verified | high | 90% | 2026-09-08 | All six phases instruction-verified, dumped to the next function start. destinations -> group -> classify whole/partial -> split -> execute -> destroy. THE DESTINATION RULE: three INDEPENDENT nearest-system searches in ONE pass - nearest owned, nearest with no hostile presence, nearest at all - first non-null wins. The independence is LOAD-BEARING (each `best` store sits INSIDE its predicate arm); a single-loop version gives a different system. Squared distance, float32 deltas, strict `<` so exact ties go to the EARLIER system. New diplomacy rule: A SYSTEM CAPTURED ON THE CURRENT TURN LOSES ITS OWNER'S CEASEFIRE COVER. FALSIFIABLE PREDICTION WRITTEN BEFORE ANY RUN: on the first turn a battle produces a partial retreat, post-turn NMnx rises by exactly the number of groups with a split fleet - one per GROUP, not per ship or per fleet. PLUS A PREDICTED ORIGINAL BUG: the fleet is created BEFORE the ship loop, so a group flagged partial creates a fleet even when every ship turns out to belong to a wholly-retreating one - A ZERO-SHIP FLEET IN THE SAVE |
+| retreat pipeline: events and RNG | verify | verified | high | 100% | 2026-09-08 | EXACTLY TWO EVENT_* keys in the 327-function closure - EVENT_FLEET_RETREATED_VIA_TELEPORT (depth 1, and gate retreat is species 1 + mode 1 + a destination, the only path to it) and EVENT_FLEET_INTERCEPT_ABORTED (depth 3, posted to the INTERCEPTOR'S owner when a split empties a fleet). Both were already in lane J's 23 at the right depth; what is NEW is the condition for each and that these two are the ONLY ones this pipeline can post. DRAW-FREE CONFIRMED INDEPENDENTLY: zero RNG calls, zero inlined MT tempering immediates, including the fleet-name generator. The one 0x11c hit is a FALSE POSITIVE (FtMS = -1 in the fleet ctor) - no turn-results write here |
+| new failure mode: tail-call thunk in an argument list | meta | verified | high | 100% | 2026-09-08 | Lane B5 correcting ITSELF: it first read the fleet-creation call's arguments wrong, because a `ret`-N TAIL-CALL THUNK IN THE MIDDLE OF AN ARGUMENT LIST makes three pushes look like they belong to the wrong call. CHECKING `ret N` AGAINST THE PUSH COUNT CATCHES IT. Worth a rules line - and note the same thunks HID the OID allocation chain from a closure pass entirely |
+| duplicate-name check working as intended | meta | verified | high | 100% | 2026-09-08 | Two live demonstrations today. (1) Lane B5 found StarFleet_SetFlag ALREADY in addresses.json from lane B4, same address and same prototype DERIVED FROM A DIFFERENT PATH - entry dropped, agreement recorded as corroboration. (2) The generator HARD-ERRORED on my merge: `duplicate address entry 'StrategyServer_off_TradeManager': in lane-t.json and lane-v2.json`, catching an in-flight collision between a landed lane and a running one. Exactly the designed behaviour: two lanes disagreeing about an address surfaces instead of being silently last-wins |