re: the phase transitions -- and withdrawing yesterday's refutation

because the test probed the wrong state

Nine stores to the phase field this+132, control-gated on the 136 query
returning at least the 18 known ones. Attributed to the handler each
lives in, they give the phase graph: entry -> 2, then 2 -> 0 (splash),
2 -> 3, 3 -> 4, and 4 -> 2 on event 0.

That last edge is the problem with what I did last iteration. The event-0
block sets TWO fields one instruction apart -- stw r28,136(r30) for state
0 and stw r11,132(r30) with r11 = 2 for phase 2. So B from the menu lands
in PHASE 2, the same phase as the boot title, and the test I ran
believing it probed phase 4 state 0 probed nothing of the kind.

So the refutation is withdrawn. Worse for me and better for the idea: A
working on the B-returned title is exactly what the hypothesis predicts,
since phase 2 is the phase that references BUTTON. The hypothesis is back
to untested, now consistent with two observations rather than one, and
what it still needs is the attract-returned title's phase -- which no
test so far has read.

The measurement from that iteration stands, because it does not depend on
the phase: the B-returned title accepts A, so only the ATTRACT-returned
title is inert. I have said so explicitly in the page rather than letting
the withdrawal take the good half down with it.

METHOD gets the lesson: before testing "state X behaves like this", check
your route actually reaches state X. When a transition writes more than
one field, read the whole block and not just the store you were looking
for.

docs/port/HANDOFF.md

@@ -308,7 +308,7 @@ here until 2026-08-28 and is now settled.)
 | ❔ | **the other ~319 SE cues** (Q8) | located one at a time by triggering them; only the three the menu needs have been done |
 | 🟡 | **the paint-order tie-break** (Q3) | eight candidates refuted; costs one element's blend on one screen |
 | 🟡 | **GamePart ids behind the buttons** (Q4) | the *screens* are measured; the ids are a name match onto the executable's class names |
-| 🟡 | **the boot transitions in code** (Q6) | `GamePart_Title` has **two nested state fields** — a 5-way phase at `this+132` and a 10-way state at `this+136` inside phase 4. Phase 0 = splash (`LOGO`), phase 2 = title + `PRESS Ⓐ` plate, phase 4 = the menu machine. Unknown: what the event *numbers* mean, and phase 1/3 |
+| 🟡 | **the boot transitions in code** (Q6) | both levels decoded — phase at `this+132` (`entry→2`, `2→0`, `2→3`, `3→4`, `4→2`) and state at `this+136` inside phase 4. Phase 0 = splash (`LOGO`), phase 2 = title + `PRESS Ⓐ`, phase 4 = menu. Unknown: what the event *numbers* mean |
 | ❔ | **builds 0/1 and 10/11**, the `DELTASABER` plates (Q2) | never seen anywhere in the boot path, the title-side screens or the attract loop. A mission load is the remaining candidate and this container kills runs before one completes |
 
 (An earlier version of this table called the audio items blocked on "an emulator

docs/re/METHOD.md

@@ -231,3 +231,10 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   scoped that way reported "no jump tables" for a function with two known ones.
   Scope by `address between <start> and <end_address>` instead, and gate any such
   query on a function whose answer you already know.
+* **Before testing "state X behaves like this", check that your route actually
+  reaches state X.** A test of "does Ⓐ work in phase 4 state 0" was run by
+  pressing Ⓑ, on the strength of a decoded `4 → state 0` edge — but the same basic
+  block also writes the *phase* field, sending it to phase 2. The test probed the
+  wrong state and produced a confident refutation of a live hypothesis. When a
+  transition sets more than one field, read the whole block, not the one store you
+  were looking for.

docs/re/REFUTED.md

@@ -35,9 +35,12 @@ neighbourhood, not just the line.
 
 ## Screens, classes and RTTI
 
-* "the boot title is phase 2 and the attract title is phase 4 state 0, and only
-  phase 2 handles Ⓐ" → **mine, and refuted the next iteration.** Ⓑ from the menu
-  is the decoded edge `4 → 0`, and Ⓐ on that returned title opens the menu.
+* ~~"the boot title is phase 2 and the attract title is phase 4 state 0, and only
+  phase 2 handles Ⓐ" → refuted~~ — **the REFUTATION is withdrawn.** The test
+  assumed Ⓑ lands in phase 4 state 0; the event-0 block actually sets
+  **phase = 2** and state = 0 together, so it probed phase 2. The hypothesis is
+  untested, not dead.
+  [`boot-config-and-gamepart-registry.md`](boot-config-and-gamepart-registry.md)
 * "any title after the first one refuses input" → too broad. The **Ⓑ-returned
   title accepts Ⓐ**; only the **attract**-returned title is inert.
   [`canary-scripted-input-traps.md`](canary-scripted-input-traps.md)

docs/re/boot-config-and-gamepart-registry.md

@@ -535,3 +535,49 @@ Counting `stw rX, 136(r30)` per phase returned **0 for phase 4**, which is known
 to have 18 — the operand text is `r11, 136(r30)` and the pattern did not allow the
 space. The per-phase store counts were discarded. The `bctr` half *does* pass its
 control (phase 4 shows both known tables) and is reported above.
+
+
+## ✅ The phase transitions — and they invalidate yesterday's test
+
+Nine stores to the phase field `this+132` across the `GamePart_Title`
+neighbourhood, attributed to the handler each lives in (control: the same query
+shape finds 30 stores to `this+136`, ≥ the 18 known in phase 4):
+
+| store | sets phase | lives in |
+|---|---|---|
+| `0x821c4fbc` | 2 | outside the handlers (entry/setup) |
+| `0x821c4fe0`, `0x821c4fec` | 4 | outside the handlers |
+| `0x821c5010` | *(not an immediate)* | outside the handlers |
+| `0x821c592c` | **0** | phase 2 |
+| `0x821c5b00` | **3** | phase 2 |
+| `0x821c6370` | **4** | phase 3 |
+| **`0x821c6e04`** | **2** | **phase 4, in the event-0 block** |
+| `0x821c7950` | 2 | the dispatcher |
+
+```
+entry → 2        2 → 0 (splash)   2 → 3        3 → 4        4 → 2 (event 0)
+```
+
+### 🔴 Withdrawing the refutation from the previous iteration
+
+The event-0 block sets **both** fields, one instruction apart:
+
+```
+821c6df8  li   r11, 2
+821c6e00  stw  r28, 136(r30)     ; state = 0
+821c6e04  stw  r11, 132(r30)     ; phase = 2
+```
+
+So **Ⓑ from the menu lands in phase 2**, not phase 4 state 0. The previous section
+tested "Ⓐ on the Ⓑ-returned title" believing it was probing phase 4 state 0 —
+**it was probing phase 2**, the same phase as the boot title.
+
+The test therefore says nothing about phase 4 state 0, and the refutation it
+produced is **withdrawn**. Worse for me and better for the idea: Ⓐ working there
+is exactly what the hypothesis predicts, since phase 2 is the phase that
+references `BUTTON`.
+
+**Status of the hypothesis: untested, and now consistent with two observations**
+(Ⓐ works on the boot title and on the Ⓑ-returned title, both phase 2). What it
+still needs is the **attract**-returned title's phase — the one thing no test so
+far has read.

docs/re/canary-scripted-input-traps.md

@@ -660,7 +660,7 @@ state 0 (`sub_821C6458`). Same screen, different code. See
 **Candidate:** the boot title is phase 2; the attract-returned title is phase 4
 state 0; only one of them wires up Ⓐ.
 
-### 🔴 Tested the same day — and the candidate is dead
+### ⚠️ Tested the same day, and the TEST was invalid — see the withdrawal below
 
 There was a cheaper test than reading `this+132`: the state graph says Ⓑ from the
 main menu goes `4 → 0`, so **the Ⓑ-returned title *is* phase 4 state 0**. If phase
@@ -673,12 +673,18 @@ main menu goes `4 → 0`, so **the Ⓑ-returned title *is* phase 4 state 0**. If
 | *control* — Ⓐ on the boot title | → main menu ✅ |
 | Ⓐ on the **Ⓑ-returned** title | → **main menu** ✅ |
 
-So phase 4 state 0 does wire up Ⓐ, and "the boot title is phase 2, the returned
-title is phase 4 state 0, only phase 2 handles Ⓐ" is **refuted**. (Conditional on
-the graph reading that Ⓑ lands in state 0 — that edge is decoded, but which
-*title* it produces is my inference.)
+**🔴 Withdrawn.** Reading the event-0 block in full shows it sets **two** fields,
+one instruction apart: `stw r28, 136(r30)` (state = 0) *and* `stw r11, 132(r30)`
+with `r11 = 2` — **phase = 2**. So Ⓑ lands in **phase 2**, the same phase as the
+boot title, and this test never probed phase 4 state 0 at all.
 
-### ✅ What the test did establish — the puzzle is narrower than this page says
+The refutation is withdrawn. Ⓐ working on the Ⓑ-returned title is exactly what
+the hypothesis predicts — phase 2 is the phase that references `BUTTON`.
+
+### ✅ What the test DID establish — the puzzle is narrower than this page says
+
+(This part stands: it is a measurement, independent of which phase the returned
+title turns out to be.)
 
 This page frames the problem as *the boot title accepts Ⓐ, a later title does
 not*. That is too broad. **The Ⓑ-returned title accepts Ⓐ perfectly well** — a