sots-re/findings/subsystems/relabel-new-ids.md

# `state_checksum --relabel-new-ids`: comparing two post-turn saves modulo this turn's new id labelling

Lane BT, 2026-09-09. **Host only — no VM was touched.** VM140 (reference guest) untouched; VM141,
VM144 and VM146 were held by lanes AZ, BS and BR throughout and were not approached.

Implements `findings/resolutions/2026-09-09-fleet-id-order-residue.md` §3 item 1, verbatim as the
specification and with the two engine-side items (§3.2 canonical visit order, §3.3 the
`--ai-visit-order` override) deliberately **not** started — they belong in `sots-engine` and the
resolver ranked them after this one.

Consumes: `findings/control-flow/pinned-seed-rich-turn.md` (lane BP — the acceptance data),
`findings/subsystems/id-allocation.md` (the id scheme), `findings/control-flow/raid-gate-multiplicity.md`
(lane AD — the negative acceptance data).

Touches only `verify/state-checksum/*` and this file.

---

## 0. Result

Both halves of the acceptance pass, and the second half passes **because a guard fires**, not
because the matcher happened to find nothing.

| half | pair | verdict |
|---|---|---|
| **positive** | `bp-pinA-turn28` vs `bp-pinB-turn28`, pre `bp-turn28-pre` | `IDENTICAL modulo pi = {1970<->1986}` — 35 leaves → **0**, and π is exactly the one transposition |
| **negative** | `ad-oracle-A-post` vs `ad-oracle-B-post`, pre `ad-turn27-two-raiders` | `REFUSED` (the two runs minted different id **sets**), then `DIVERGED: 94 leaf difference(s)` — byte-for-byte the same 94 the tool reports without the flag |

Existing behaviour is unchanged when the flag is absent: over every save in
`verify/results/saves/` under both `--floats bits --mask none` and `--floats canonical --mask
resave`, the pre-change and post-change modules produce identical root digests **and identical
per-node digests at every node of the tree** (§5.1).

---

## 1. What was built

`verify/state-checksum/state_checksum.py` gains one flag:

```sh
state_checksum.py POST-A.sav POST-B.sav --relabel-new-ids PRE-TURN.sav
```

The operation, in the order the code does it:

1. Parse all three saves. **Prove coverage on the unmodified parse** (`audit_coverage` runs before
   any rewrite), so `coverage: PROVED` still means what it has always meant: every byte of the
   file is a function of the digest's inputs.
2. `new(X) = { fleet ids in X } \ { fleet ids in PRE }`, restricted to **node nibble ≠ 0** — the
   client-minted space (`id-allocation.md` §1: `id = (counter << 4) | node`, node 0 is the sim
   that owns the board, node `PlyrIdx + 1` is a player's own client).
3. Key each new fleet by a content key that does not mention its id:
   **`(LocID if non-zero else FPlan/pnd destination, sorted ship-id set)`**, with the two
   location kinds tagged apart so a fleet *standing at* system 384 never keys the same as one
   *bound for* 384.
4. Build **π** from the key correspondence, one node at a time.
5. **Exchange the matched fleets' bodies between their slots** (see §4.2 — this is not what the
   spec said, and the spec was wrong), keeping each slot's id and its id-attached label `FtName`.
6. Rewrite every *reference* to a permuted id under π: a ship's `FltID` back-reference and a
   system's `Flt` entry.
7. Compare `ShipIDs[]` / `FleetIDs[]` / `DesignIDs[]` as **sets**.
8. Mask `/Summary/Checksum`, **with the reason printed on its own line**.
9. Print π and the verdict.

New public surface: `RelabelRefused`, `Relabelling`, `build_relabelling`, `apply_relabelling`,
`format_permutation`, `id_node`, and `checksum_result` (the parse/digest split that lets the mode
parse once, audit, then rewrite).

The relabelled root is **domain-separated** — `relabel-new-ids` is folded into the root preimage —
so a "modulo π" root can never be mistaken for a strict one. The extra preimage word is appended
*only* in this mode, so every root recorded before the flag existed is bit-for-bit unchanged.

---

## 2. Acceptance, positive half — verbatim

```
$ uv run python3 verify/state-checksum/state_checksum.py \
    verify/results/saves/bp-pinA-turn28.sav verify/results/saves/bp-pinB-turn28.sav \
    --floats bits --mask none \
    --relabel-new-ids verify/results/saves/bp-turn28-pre.sav

A  a83c425215b6d7e88bc998f4948081e7  verify/results/saves/bp-pinA-turn28.sav
B  a83c425215b6d7e88bc998f4948081e7  verify/results/saves/bp-pinB-turn28.sav
policy: floats=bits mask=none reader=74fd562c75e2679e
relabel: pre-turn save verify/results/saves/bp-turn28-pre.sav
relabel: pi = {1970<->1986}
relabel:   1970 (counter 123, node 2) -> 1986   at 384, ships [6976]
relabel:   1986 (counter 124, node 2) -> 1970   bound-for 80, ships [5264]
relabel:   2002 (counter 125, node 2) -> 2002   bound-for 384, ships [6992]
relabel: 3 new client-minted fleet id(s) on node(s) [2]; 2 relabelled, 2 fleet body/bodies exchanged, Fltx1, FltIDx2 rewritten
relabel: /Summary/Checksum is MASKED: it is derived from the whole state and its inputs are unmodelled (rule 18's open item), so it cannot be recomputed under a relabelling and its move is not independent evidence.  Unmask by dropping --relabel-new-ids.
relabel: Master id lists (ShipIDs/FleetIDs/DesignIDs) are compared as SETS: their element order is the order the turn's commands were applied in, which is the same visit-order residue.  Membership is still exact -- an added or removed id still reports.
IDENTICAL modulo pi = {1970<->1986}
$ echo $?
0
```

Read the per-id lines: the counters printed are the decode the resolver did by hand
(`123/124/125`, node 2 = Player[32]'s client), and the content keys are what carries the match —
the group **at system 384 with ship 6976** is fleet 1970 in A and fleet 1986 in B; the group
**bound for system 80 with ship 5264** is 1986 in A and 1970 in B; the group bound for 384 is 2002
in both. Exactly the resolver's §2.1 reading, recovered from the saves alone.

Without the flag the same pair is `DIVERGED: 35 leaf difference(s)` (regression-locked by
`test_POSITIVE_the_same_pair_still_diverges_without_the_flag`, which asserts the count is 35). So
the mode removes **35 leaves and no others**: `IDENTICAL modulo one transposition and nothing else`.

---

## 3. Acceptance, negative half — verbatim, and why it is the right kind of failure

```
$ uv run python3 verify/state-checksum/state_checksum.py \
    verify/results/saves/ad-oracle-A-post.sav verify/results/saves/ad-oracle-B-post.sav \
    --floats bits --mask none \
    --relabel-new-ids verify/results/saves/ad-turn27-two-raiders.sav

A  1faf04cad2bbf2d7e5ecf560b8807504  verify/results/saves/ad-oracle-A-post.sav
B  53043168ad03cae13355db9f5f381b50  verify/results/saves/ad-oracle-B-post.sav
policy: floats=bits mask=none reader=74fd562c75e2679e
relabel: pre-turn save verify/results/saves/ad-turn27-two-raiders.sav
relabel: REFUSED -- the new client-minted fleet ids differ between the two saves -- A minted [1970, 1986], B minted [1970, 1986, 2002]; only in B [2002].  That is a difference in what was allocated, not in how it was labelled, so no relabelling is defensible
relabel: NO relabelling was applied; the comparison below is the ordinary one, and nothing has been absorbed.
DIVERGED: 94 leaf difference(s)
  /Summary/Checksum: -1043321805 -> 1995746704
  /Sim/DesignIDs[]: removed [2002], added [2018]  (85 -> 85 entries)
  /Sim/FleetIDs[]: removed [], added [2002]  (58 -> 59 entries)
  /Sim/ShipIDs[]: list-reordered
  /Sim/ModCount: 1496 -> 1500
  ... 89 more ...
$ echo $?
1
```

94 is the number the tool reports for that pair **without** the flag, unchanged. On a refusal
nothing is rewritten, nothing is masked and no list is set-compared: the refusal path *is* the
ordinary comparison. That is deliberate — a mask applied on a run whose relabelling was refused
would be a mask nobody asked for.

**The refusal is by cardinality, not by content.** AD's run A minted **two** client fleets and run
B minted **three**. The guard that fires is G3 (π must permute one set), and it fires before the
content matcher is ever consulted. That matters, because it means AD's pair does **not** exercise
the content key negatively. I exercised that separately, two ways (§4.3, §5.3): a synthetic pair
whose new ids agree and whose contents differ, and — the belt-and-braces version — **forcing the
transposition onto AD's pair with the guard bypassed**, which still leaves **82 differing
leaves**, including `DesignIDs[]`, `ModCount`, four `turnstats` rows, both AI build queues and
`Player[32]`'s money. The guard is not the only thing standing between AD's pair and a green
verdict; it is the first of several.

---

## 4. Where the specification did not survive contact

Four places. The first two changed the implementation; the third and fourth are scope notes the
next lane needs.

(Lane BU landed mid-lane, confirming H1 — the visit order is an address-keyed container whose key
is the fleet's `Location*`. That settles the *cause* of the residue and changes nothing here: the
comparison side quotients the residue out regardless of what produces it, and it must go on
refusing when the difference is not a relabelling. The forward notes in §4.1 and §4.2 are
addressed to the engine-side canonical order and stand as written.)

### 4.1 `FtName` is an **id-attached label**, and "every id-valued leaf" does not reach it

In *both* of BP's saves, fleet **1970 is "Sigma Fleet VI"** and **1986 is "Tau Fleet VI"**. The
name follows the **id**, not the ship group. It is a Greek-letter ordinal minted from a per-player
counter that advances with the same pass that mints the id, so it is exactly as much a function of
the visit order as the id is — and exactly as little a decision.

Consequence: applying π only to id-valued leaves would move the group at system 384 from slot 1970
to slot 1986 **carrying the name "Sigma Fleet VI"**, and compare it against B's 1986 "Tau Fleet
VI". Two spurious leaf differences, and the acceptance "and nothing else" would have failed.

Handled by keeping the name with the slot rather than with the body, and **gating it**: the mode
refuses unless `FtName` is the same at every matched id in both saves. If the name does not track
the id, something real differs and the tool must not paper over it
(`test_a_name_that_does_not_track_the_id_is_refused`).

Cross-check that this is a naming *counter* and not a coincidence, from AD's pair: A minted two
client fleets, so A's node-0 fleet **7120 is "Upsilon Fleet VI"**; B minted three, so B's **7120 is
"Phi Fleet VI"**. The Greek sequence is **per player and shared between the client's and the
server's fleets** — one more thing an engine-side canonical visit order (§3.2 of the resolution)
has to reproduce, and one the resolver's item 2 does not currently mention.

### 4.2 Applying π to the `Flt[]` **keys** introduces a spurious `reordered`

The master fleet table's element order, and the `FleetIDs[]` list, are **identical in A and B**
(measured: both are `[…, 6960, 1970, 1986, 2002, 7120, …]`) and are a function of the id, not of
the visit order. Renumber A's slots under π and A's table reads `…1986, 1970, 2002…` against B's
`…1970, 1986, 2002…`, which the differ correctly reports as a reorder — an artefact of the tool,
not of the saves.

The equivalent operation with no artefact is to **exchange the fleet bodies between the slots**,
leaving slot ids, `FleetIDs[]`, and every object label exactly as the file wrote them. That is what
the implementation does. It is the same quotient, taken from the other side.

Worth carrying into the engine-side item: **the fleet table is id-ordered, not visit-ordered**, so
canonicalising the visit order in `game/ai` will reorder lists 8/10 and the apply order, and will
*not* reorder the save's fleet table.

### 4.3 "new ids of the same node" is not a fleet-only id space

`ad-oracle-A-post` carries **2002 as a `DesignID`**; `ad-oracle-B-post` carries **2002 as a
`FltID`**. The per-node counter is shared across object kinds, so a node's new-id set spans fleets,
designs and (in principle) ships. This mode matches **fleets only**, as the spec says. What keeps
that safe is guard G5 (§5.2): any leaf anywhere holding a permuted id at a site the tool does not
model as a fleet reference is a **refusal**. Anyone extending the mode to designs must read this
paragraph first — the two spaces interleave.

### 4.4 "list-8/10/14 words when comparing command blocks" is **not** implemented, and does not belong here

Lists 8/10/14 live in the `aiorders` **shim dump**, not in a `.sav`. `state_checksum.py` parses
saves; it has no reader for the block. Wiring π into a block comparison belongs wherever those
dumps are differed (lane BP did it by hand under its proven noise mask, `pinned-seed-rich-turn.md`
§2). Recorded as not-done with the reason rather than silently dropped.

### 4.5 Two smaller notes

- **Master id lists as sets is unconditional in this mode**, including when π is the identity.
  `ShipIDs[]`'s element order is the apply order, which is the same residue; membership stays
  exact, so an added or removed id still reports. It is nonetheless a real weakening and it is
  printed on every run. A lane that wants that order back should reach for a separate flag, not
  for this one.
- **The `--mask resave` composition the resolver asked for works**: `--mask resave
  --relabel-new-ids …` on BP's pair reports `[masked: Checksumx1, Statusx8]` and
  `IDENTICAL modulo pi = {1970<->1986}`. The relabel mask is added to whichever preset is in
  effect and de-duplicated against it.

---

## 5. The guards, and how each was made to fire

Five guards. **Every one refuses; none degrades to a partial relabelling.** A refusal prints its
reason, applies nothing, and runs the ordinary comparison — the conservative direction, because a
real divergence then still reports.

| | guard | how it was made to fire |
|---|---|---|
| **G1** | only ids **absent from the pre-turn save** may be relabelled | `test_ids_present_in_the_pre_turn_save_are_never_in_pi`; and the strong form, `test_two_pre_turn_fleets_that_swapped_contents_are_NOT_absorbed` — two *pre-existing* fleets exchanging contents is the very shape this mode absorbs, and it must still report |
| **G2** | only ids with a **non-zero node nibble** | `test_server_minted_ids_are_never_relabelled` — two node-0 (server) fleets exchanging contents still diverges |
| **G3** | π must be a **permutation of one set** — so the two saves must have minted the same ids | `test_different_new_id_sets_are_refused` (synthetic: one run mints a third fleet) and **lane AD's real pair** (§3) |
| **G4** | the content keys must **correspond one-to-one**, and be **unique on each side** | `test_new_fleets_whose_contents_differ_are_refused`; `test_an_ambiguous_content_key_is_refused` (two new fleets with the same location and ship set) |
| **G5** | **no leaf anywhere** in either save may hold a permuted id at a site the tool does not model | `test_an_unmodelled_reference_site_is_refused` (a `SomeOtherRef` leaf holding 1970); `test_the_completeness_scan_matches_raw_bytes_not_the_typed_value` |
| — | `FtName` must track the id in both saves | `test_a_name_that_does_not_track_the_id_is_refused` (§4.1) |
| — | a refusal leaves both parse trees **untouched** | `test_a_refusal_leaves_both_trees_untouched` — the digest of A before and after a refused `build_relabelling` is identical |

### 5.1 The default path is unchanged

Checked two ways, because "the tool is used by several lanes and by the determinism oracle":

- **Digest equivalence, whole corpus.** The pre-change module (`git show HEAD:…`) and the
  post-change module were run over all **43** `.sav` files in `verify/results/saves/` under
  `--floats bits --mask none` and under `--floats canonical --mask resave`, comparing the root
  digest, the coverage record, the mask hits, **and the `(path, digest)` of every node in the
  tree**. `saves checked: 43   mismatches: 0`.
- **CLI stdout equivalence, every mode.** Single-save; `--tree --depth 3`; `--json`; the BP pair;
  the AD pair at `--limit 500`; `turn2/turn3 --mask resave --ulps 2`; `--record-chain` and
  `--chain` over turns 1/2/3. **5,602 lines, byte-identical** between the two modules (only the
  chain file's own path normalised).

The one change that *could* have moved a recorded root — folding a policy word into the root
preimage — is appended **only** when the new mode is active. An intermediate version of this work
appended an empty word unconditionally, which moved the root; that was caught by the equivalence
check above, which is the reason it exists.

### 5.2 G5 matches raw bytes, not the reader's typed value — on purpose

The digest is a function of *(save bytes, reader schema)*, never of the bytes alone (STATE_CHECKSUM.md
§2.4). A leaf the schema happens to type as a float or a raw blob still carries the id, and a
value-based completeness scan would not see it — a guard a typing slip can silently empty is the
"green verdict over an empty region set" of earned rule 1. This is not hypothetical: while
building the synthetic fixture, the reader typed a `Flt` reference as a **float** (`2.76e-42`, the
denormal whose bit pattern is 1970) and a value-based scan missed it. Matching on the raw four
bytes catches it. The cost is that a genuine 4-byte float in the denormal range around a permuted
id would refuse — a refusal is the safe direction, and no such value exists in the corpus.

### 5.3 The strongest negative: bypass the guard and it still diverges

`test_NEGATIVE_even_forcing_a_partial_relabelling_cannot_hide_it` hands `apply_relabelling` the
transposition `{1970↔1986}` it *would* have built if G3 did not exist, applies it to AD's A save,
and compares under the full "modulo π" policy (checksum masked, master lists as sets). **82 leaves
still differ.** The guards are the tool's honesty, not its only defence.

### 5.4 Tests

24 new tests (20 synthetic in `RelabelTest`, 4 real-save in `RealSaveTest`), **7 of which assert a
refusal**. The whole suite is 38 → **62 tests, all passing**:

```
$ uv run python3 -m unittest test_state_checksum.RelabelTest        # 20 tests, OK, 0.07 s
$ uv run python3 -m unittest test_state_checksum.RealSaveTest.test_POSITIVE_… \
      …test_NEGATIVE_…                                              #  4 tests, OK, 88.7 s
$ uv run python3 -m unittest discover -s . -t .                     # 62 tests, OK
```

### 5.5 One pre-existing test failure, fixed, that is not about this change

The first full-suite run failed one test —
`test_known_resave_delta_localises_to_five_named_leaves` — and **the pre-change module fails it
identically**, so it is not a regression. The test enumerates candidate pairs over *sorted
filenames* and asserted the re-save direction as `4 -> 0`; `cb-turn2to3-endturn.sav`, added to the
corpus by an earlier lane, sorts before `turn2-state.sav`, so that pair reads `0 -> 4`. The claim
is symmetric and the assertion now is too (all four `Status` leaves must still move the *same*
way, with `Checksum` following by ∓16). Recorded rather than quietly patched, per earned rule 11.

---

## 6. What this lane did NOT do

1. **No VM, no game, no build.** Host only. The three held guests were not approached.
2. **Neither engine-side deliverable** (`sots-engine` `game/ai` canonical visit order; the
   `--ai-visit-order` override). Out of scope by the brief, and ranked after this one by the
   resolver.
3. **No command-block comparison** (§4.4).
4. **Designs and ships are not relabelled**, only fleets — per the spec. §4.3 says what has to be
   read before that changes.
5. **`Summary/Checksum` is still unmodelled.** It is masked with its reason, not solved.
   STATE_CHECKSUM.md §4.6 records the two derivations already ruled out; nobody should re-run them.
6. **π's *existence* is not evidence that the two runs agree on the turn.** It is evidence that
   they agree *up to the labelling of the ids created on it*. The claim the mode licenses is
   exactly the resolver's C-set shape and no more.

---

## 7. Reproducing every number here

```sh
cd ~/sots-re
S=verify/results/saves
# positive
uv run python3 verify/state-checksum/state_checksum.py \
  $S/bp-pinA-turn28.sav $S/bp-pinB-turn28.sav --floats bits --mask none \
  --relabel-new-ids $S/bp-turn28-pre.sav
# negative
uv run python3 verify/state-checksum/state_checksum.py \
  $S/ad-oracle-A-post.sav $S/ad-oracle-B-post.sav --floats bits --mask none \
  --relabel-new-ids $S/ad-turn27-two-raiders.sav
# guards
cd verify/state-checksum && uv run python3 -m unittest -v test_state_checksum.RelabelTest
```

---

## Proposed board rows

New row:

```
| STATE_CHECKSUM --relabel-new-ids: BP'S PINNED PAIR IS IDENTICAL MODULO ONE TRANSPOSITION, AD'S UNPINNED PAIR IS REFUSED AND STILL DIVERGES | tooling | verified | high | 100% | 2026-09-09 | Lane BT, HOST ONLY (no VM; 140 untouched, 141/144/146 held by AZ/BS/BR and not approached). Implements the 2026-09-09 fleet-id-order resolution §3 item 1 (`findings/subsystems/relabel-new-ids.md`). `state_checksum.py POST-A POST-B --relabel-new-ids PRE` computes the ids NEW in each post-turn save, restricts to node nibble != 0 (client-minted; `id-allocation.md` id=(counter<<4)|node), matches those fleets by a key that does not mention the id - (LocID if non-zero else FPlan/pnd destination, sorted ship-id set), with "at 384" and "bound-for 384" tagged apart - builds the bijection pi, rewrites every fleet reference, compares ShipIDs/FleetIDs/DesignIDs as SETS, masks /Summary/Checksum WITH ITS REASON ON THE LINE, and prints pi. **POSITIVE: `bp-pinA` vs `bp-pinB` = `IDENTICAL modulo pi = {1970<->1986}`, 35 leaves -> 0, exit 0**, with pi recovered from the saves alone and printed with the counters (123/124/125, node 2) and the content keys - the group AT Sys 384 with ship 6976 is 1970 in A and 1986 in B; the group BOUND FOR Sys 80 with ship 5264 is 1986 in A and 1970 in B; 2002's group is 2002 in both. **NEGATIVE: `ad-oracle-A/B-post` REFUSED and `DIVERGED: 94 leaf difference(s)`, exit 1** - byte-identically the 94 the tool reports without the flag, because on a refusal NOTHING is rewritten, masked or set-compared. The refusal is by CARDINALITY (A minted 2 client fleets, B minted 3), so AD's pair does not exercise the content matcher; that is exercised separately, and FORCING the transposition onto AD's pair with the guard bypassed STILL LEAVES 82 LEAVES. FIVE GUARDS, EVERY ONE REFUSES RATHER THAN DEGRADES: G1 only ids absent from the pre-turn save (tested with two PRE-EXISTING fleets exchanging contents - must still report); G2 only non-zero node nibbles (node-0 swap still reports); G3 pi must permute ONE set; G4 content keys correspond one-to-one and are unique per side; G5 NO leaf anywhere may hold a permuted id at an unmodelled site, matched on RAW BYTES not the reader's typed value (a value scan is empty the moment the schema types a reference as a float - this happened during development). Refusal prints its reason and falls back to the ORDINARY comparison, never to a partial relabelling. THREE SPECIFICATION CORRECTIONS FROM CONTACT WITH THE DATA: (1) **FtName is an ID-ATTACHED LABEL** - 1970 is "Sigma Fleet VI" and 1986 "Tau Fleet VI" in BOTH saves, a Greek ordinal minted by the same pass as the id, so "apply pi to every id-valued leaf" would have produced two spurious name diffs; the name stays with the SLOT, gated by a guard requiring it to track the id in both saves. The counter is PER PLAYER AND SHARED WITH THE SERVER'S FLEETS - AD's A (2 client fleets) names node-0 fleet 7120 "Upsilon", B (3) names it "Phi" - which the engine-side canonical visit order must reproduce and §3.2 does not mention. (2) **Applying pi to the Flt[] KEYS introduces a spurious `reordered`**: the fleet table and FleetIDs[] are ID-ordered and IDENTICAL in A and B, so renumbering slots reorders A against B; the artefact-free equivalent is to EXCHANGE THE FLEET BODIES between slots, leaving slot ids, FleetIDs[] and every label as written. (3) **A node's new-id set is NOT fleet-only**: 2002 is a DesignID in ad-oracle-A-post and a FltID in ad-oracle-B-post - the per-node counter is shared across object kinds, and G5 is what keeps a fleet-only matcher safe. NOT DONE, with reasons: lists 8/10/14 (they are aiorders SHIM DUMP words, not save leaves - this tool has no block reader); designs/ships; the two engine-side items. DEFAULT PATH PROVEN UNCHANGED: pre- and post-change modules compared over the whole save corpus under two policies on root digest, coverage, mask hits AND every (path,digest) in the tree - zero mismatches; plus byte-identical CLI stdout on the single-save, BP, AD and resave invocations. The relabelled root is DOMAIN-SEPARATED so a "modulo pi" root can never be read as a strict one. 24 new tests (20 synthetic + 4 real-save acceptance), 7 of them asserting a refusal; suite 38 -> 62, all passing. ALSO FIXED, PRE-EXISTING AND NOT A REGRESSION (the pre-change module fails it identically): `test_known_resave_delta_localises_to_five_named_leaves` enumerated pairs over SORTED FILENAMES and hard-coded the re-save direction 4->0; `cb-turn2to3-endturn.sav` sorts before `turn2-state.sav`, so that pair reads 0->4 and the test failed on a corpus fact. Assertion is now direction-symmetric (all four Status leaves must still move the SAME way, Checksum following by -/+16). Artefacts: `verify/state-checksum/state_checksum.py`, `test_state_checksum.py`, `STATE_CHECKSUM.md` §2.6 |
```

Edits to existing rows:

- **Row 424 / the resolver row of 2026-09-09** — append: `ENGINE ITEM 1 IS DONE (lane BT, host):
  state_checksum --relabel-new-ids ships with both acceptance halves green - BP's pair IDENTICAL
  modulo {1970<->1986}, AD's pair refused and still 94-leaf DIVERGED. Three corrections to §3.1
  from the data: FtName is an id-attached label and needs the same treatment as the id (and its
  counter is per-player and shared with the server's fleets, which §3.2's canonical visit order
  must also reproduce); relabelling the Flt[] keys is the wrong operation - exchange the bodies,
  because the fleet table is id-ordered and identical in both saves; and a node's new-id set spans
  object kinds (2002 is a DesignID in ad-oracle-A-post and a FltID in ad-oracle-B-post). Lists
  8/10/14 are not in scope for this tool - they are shim-dump words, not save leaves.`
- **Row 333 (C-exact)** — append: `Comparison side delivered 2026-09-09 (lane BT):
  `state_checksum --relabel-new-ids <pre.sav>`, guarded so it refuses rather than absorbs; see
  findings/subsystems/relabel-new-ids.md.`
- **`determinism-oracle.md`'s "Qualified" paragraph** — when it is written, "modulo π" now has an
  executable definition and a printed π; cite `relabel-new-ids.md` §1 for the operation and §5 for
  the guards.
- **`id-allocation.md` §5** — alongside the canonical-visit-order item the resolver asked for, add
  the two measured facts from §4.1/§4.2 of this document: the **fleet-name ordinal** is per player
  and shared between client- and server-minted fleets, and the **master fleet table is id-ordered**,
  not visit-ordered.
- **Row 62** — VM140/141/144/146 unchanged by this lane; it took no guest.