rule 11 corrections: AD's 94 leaves decompose 59+35, list 10 is OnCommand_TransferShips, BP's income claim marked as inference

findings/control-flow/pinned-seed-rich-turn.md

@@ -178,7 +178,7 @@ is correct. But **four other AI players enter this turn with `ResTNm == ''`** (5
 **none of them contributed a leaf to AD's 94** — every one of the 94 is Player[32]'s or the global
 id counters'. All four have `NumOwn == 0`. So the predicate as written in rule 26 corollary (c) —
 "`ResTNm == ''` names a pick turn" — is **necessary and not sufficient**: a player with no colonies
-has no research income and does not reach the pick, whatever its `ResTNm` says. That is a
+has no research income and does not reach the pick, whatever its `ResTNm` says. That is a  **[INFERENCE, not measurement — flagged by the resolver 2026-09-09. The measured fact is only "no AI client". Whether a client with `NumOwn == 0` reaches the pick is UNTESTED: players 496 and 512 have `NumOwn == 0` and DO have clients, and they held research targets so the pick was not exercised either way.]**
 measurement on the input save, independent of how the runs come out, and it is offered as a
 refinement of the predicate rather than a correction of the resolution's Player[32] claim, which
 stands.

findings/control-flow/raid-gate-multiplicity.md

@@ -37,6 +37,16 @@
 > instrumented and not. §5 gives the digests. Every number in §3 is read off that reproducible
 > sub-tree; none of them is read off a leaf that moved.
 
+> **DECOMPOSED 2026-09-09 (lanes BP and the resolver, rule 11).** These 94 leaves are
+> **59 seed-driven + 35 visit-order**. With the three AI client seeds pinned, 59 of them go
+> away — `ModCount`, `NumFlts`, `DesignIDs[]`, `FleetIDs[]`, both build queues, every design
+> and ship record and all four turnstats rows become identical. The **35 that remain are a
+> single transposition**: two fleets exchange contents because the fleet-assignment pass
+> visited their ship groups in a different order. **The id counter is deterministic** — the
+> ids are minted in the same order in every process; what varies is which group each lands
+> on. So this lane's attribution to "the per-process AI seed" is right for the *substance*
+> of the variation and incomplete: a second, non-seed per-process input orders the visit.
+
 ---
 
 ## 1. Predictions, committed before the build (rule 2)

findings/subsystems/ai-order-emission.md

@@ -307,6 +307,14 @@ the other end).
    of turn 4 exists in the corpus, so that window's composition is assumed to match turn 2→3 on W2's own
    statement that the two windows agree.
 
+   > **NAMED 2026-09-09 (rule 11).** It is **`StrategyServer::OnCommand_TransferShips`**,
+   > `{systemId, fleetId, ships[]}` — lane W3 named the applier some time ago and these AI-side
+   > notes were never updated, so two documents disagreed with a third. The consequence is worth
+   > more than the name: **list 10 records the order in which the fleet-assignment pass visited
+   > each ship group**, so every captured command block carries its own visit order for free.
+   > That is what makes C-exact recoverable as `(save, seeds, visit order) -> byte match` rather
+   > than merely canonicalisable — see `findings/resolutions/2026-09-09-fleet-id-order-residue.md`.
+
 ---
 
 ## 5. Corrections to earlier findings

findings/subsystems/turn-command-replay.md

@@ -34,7 +34,7 @@ residual**:
 4   research-rate gates, one per submitting block (16, 32, 496, 512)
 1   list 5   system rates
 1   list 3   build order
-1   list 10  (unnamed)
+1   list 10  StrategyServer::OnCommand_TransferShips  [named by lane W3; was "(unnamed)" here]
 2   list 14  fleet task, modes 0 and 1 against ONE fleet
 1   list 8   fleet move
 0   list 23  population -- the 17..27 half is free