re: the title part's states are named in the executable -- TITLE_SCREEN,

TITLE_MENU, LOADING

Taking the one residual I had ranked as worth doing: sub_821C6458, which
the previous note left explicitly unread.

It is the title part's screen-state function -- 4460 bytes, has EH,
called from exactly one place, sub_821C7850, which sits beside the
creator the registration site points at. Its string references are
TITLE_SCREEN, TITLE_MENU, LOADING and BASE_INFO. Those are precisely the
states measured off the running game, in the game's own words, and
BASE_INFO is this corpus's own marker for a screen-config lookup rather
than a table read.

That sharpens Q6's negative rather than overturning it. The title part
DOES ask for configuration keyed by TITLE_SCREEN and TITLE_MENU, and
config.ini -- the disc's only config -- has no such sections, only an
empty [SYSTEM] and [LANGUAGE]. So the game asks the question, the shipped
disc does not answer it, and the defaults live in code. The port can
transcribe the state names even though it must author their contents.

Marked amber, not green: this is characterisation from string references
and call counts, not a read of the control flow. Two self-references
inside the function look like jump tables, which is what a state machine
compiles to, but I did not confirm that and nothing here shows which
state leads to which.

One refutation recorded because it looked like a find for several
minutes: the {func, func, ptr} triples at 0x820a3b48 read convincingly as
a state/handler table and are nothing of the kind -- the bytes before
them are the tail of a RegisterToFactory diagnostic string and the data
column is zero-filled descriptors. Static-init records, not dispatch.

docs/port/HANDOFF.md

@@ -193,7 +193,12 @@ authored version can be deleted.
   movie manifest carries assets not transitions, the requested GamePart id lives
   **only as a stack argument in flight** (no persistent field, no literal store),
   and the string `GP_ADVERTISE_DEMO` has **zero xrefs**. A transition is a call
-  with an id argument, chosen by code. The sequence itself is fully measured:
+  with an id argument, chosen by code.
+  🟡 **The states do have names, though.** `sub_821C6458`, the title part's state
+  function, references `TITLE_SCREEN`, `TITLE_MENU` and `LOADING` — the three
+  states measured off the game, in the game's own words — and asks for screen
+  config under those keys. `config.ini` has no such sections, so the contents are
+  code defaults. The port can transcribe the **names**, not the values. The sequence itself is fully measured:
   splash → `ADV.wmv` → title + `PRESS Ⓐ` → (idle ~8–10 s → `ADV.wmv` in full →
   title) → Ⓐ → main menu, with Ⓑ from the main menu returning to the title.
 
@@ -270,7 +275,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) | bounded as code-not-data, not proven. `sub_821C6458` — the substantial function in `GamePart_Title`'s neighbourhood — has **not been read** |
+| 🟡 | **the boot transitions in code** (Q6) | `sub_821C6458` is the title's state function and **names its states** — `TITLE_SCREEN`, `TITLE_MENU`, `LOADING`. It asks for config under those keys and `config.ini` has no such sections, so the defaults are in code. Which state leads to which is still unread |
 | ❔ | **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