re: phase 0 is the splash, phase 2 is the title -- and a candidate answer

to this corpus's oldest input puzzle

Continuing Q6 on the phases left unread. Strings each phase handler
references, plus whether it carries its own jump table:

  phase 0  sub_821C5690   LOGO                                    no switch
  phase 2  sub_821C5818   BASE_INFO, BUTTON, TITLE_SCREEN         no switch
  phase 3  sub_821C5EC0   (none)                                  one switch
  phase 4  sub_821C6458   BASE_INFO, LOADING, TITLE_MENU, TITLE_SCREEN

Phase 0 referencing LOGO is a second independent confirmation that it is
the developer splash -- the iterate3E notes reached the same function
from the guest side and named the splash's LOGO items. Phase 2 draws the
title WITH the PRESS A plate, which the archive side had already
established is a build of its own.

Which produces something worth more than either: the title is installed
from TWO places, phase 2 and phase 4 state 0. Same screen, different
code. canary-scripted-input-traps.md has recorded for months, and never
explained, that the boot title accepts A while the attract-returned title
accepts nothing, with the giveaway that a draw capture in each is
identical. Two code paths installing one screen is exactly that shape. I
have written it into that page as a candidate with the cheap test named
-- read this+132 on each title -- and marked it untested, because it is.

One query in this iteration failed its own control and I threw its half
away: counting stw rX,136(r30) per phase returned 0 for phase 4, which
has 18, because the operand text has a space the pattern did not allow.
The bctr half passes its control and is reported. METHOD gets the
underlying trap: instructions.function is unpopulated for most rows, so a
query scoped on it silently returns nothing.

docs/re/METHOD.md

@@ -226,3 +226,8 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   rather than a whole wave. They match `BGM_103` exactly — the check had covered
   only the `BGM_0xx` rows of the census, because that is the block that had been
   on screen.
+* **`instructions.function` is unpopulated for most rows in `sylpheed.db`.** A
+  query keyed on it returns *nothing* rather than erroring — a `bctr` search
+  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.

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

@@ -483,3 +483,53 @@ The same function, a few instructions earlier:
 **1103 is a BGM cue id** — `BGM_103`. That closes an open residual from Q8/Q10
 ("which bank is the menu's music is not on the disc"), and it checks out three
 ways; see [`structures/bgm-two-stems.md`](structures/bgm-two-stems.md).
+
+
+## The other phases, characterised — and phase 0 confirms the splash twice over
+
+Same treatment for the phase handlers that were still unread. Strings each one
+references, and whether it carries a jump table of its own:
+
+| phase | handler | size | strings referenced | own switch |
+|---|---|---|---|---|
+| 0 | `sub_821C5690` | 380 | **`LOGO`** | none |
+| 2 | `sub_821C5818` | 1 576 | `BASE_INFO`, **`BUTTON`**, **`TITLE_SCREEN`** | none |
+| 3 | `sub_821C5EC0` | 1 220 | *(none)* | one, `bctr` at `0x821c5ef8` |
+| 4 | `sub_821C6458` | 4 460 | `BASE_INFO`, `LOADING`, `TITLE_MENU`, `TITLE_SCREEN` | two (known) |
+
+**Phase 0 references `LOGO`** — a second, independent confirmation that it is the
+developer splash. The `iterate3E` notes reached `sub_821C5690` from the guest side
+and named the splash's `LOGO` items; this reaches the same function from the
+registration site and finds the same string.
+
+**Phase 2 draws the title *with* the `PRESS Ⓐ BUTTON` plate** — it references
+`TITLE_SCREEN` and `BUTTON`, and [`ui-title-build-map.md`](ui-title-build-map.md)
+established from the archive that the plate is its own build (2/3), composited
+over the title art.
+
+### 🟡 A hypothesis for a puzzle this corpus has had open for months
+
+**The title is installed from two different places**: phase 2, and phase 4's
+state 0. Same screen, different code.
+
+[`canary-scripted-input-traps.md`](canary-scripted-input-traps.md) has long
+recorded, and never explained, that *the title which ends the boot accepts Ⓐ while
+the title the attract loop returns to accepts nothing* — with the giveaway that a
+draw capture in each state is identical, 13 quads at the same rects. Two code
+paths installing the same screen is exactly the shape that would produce that.
+
+**Candidate:** the boot title is **phase 2**; the attract-returned title is
+**phase 4, state 0**. Only phase 2 wires up the Ⓐ handling.
+
+⚠️ **This is a hypothesis and nothing more** — it is consistent with the draw
+captures and with the phase structure, and it is completely untested. **The test
+is cheap**: read `this+132` (the phase field) at runtime on the boot title and
+again on the attract title. If they differ, the puzzle is solved; if they match,
+this is dead.
+
+### ⚠️ One query in this section failed its own control
+
+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.

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

@@ -643,3 +643,23 @@ Two lessons, both cheap:
 The evidence recovered cleanly once the interference stopped — the interrupted
 batch's own run 3 had already reached the menu with the same 40 calls / 6
 `ResolvePath` signature.
+
+
+## 2026-08-28 — a candidate explanation, from the static side
+
+This page's oldest open question is **why the attract-returned title accepts no
+input while the boot title does**, given that a draw capture in each state is
+identical (13 quads, same rects).
+
+`GamePart_Title` turns out to dispatch on an outer **phase** field at `this+132`,
+and **the title screen is installed from two different phases** — phase 2
+(`sub_821C5818`, which references `TITLE_SCREEN` *and* `BUTTON`) and phase 4's
+state 0 (`sub_821C6458`). Same screen, different code. See
+[`boot-config-and-gamepart-registry.md`](boot-config-and-gamepart-registry.md).
+
+**Candidate:** the boot title is phase 2; the attract-returned title is phase 4
+state 0; only one of them wires up Ⓐ.
+
+🟡 **Untested.** The cheap test is to read `this+132` at runtime on the boot title
+and again after the attract loop returns. Different values would settle this
+page's oldest question; identical values kill the idea outright.