re: one A skips the intro, and NEW GAME was never a hang

Two corpus claims died in one boot, and both were costing us.

Q9's last row: a movie IS skippable with a single A. One tap ~45s into
the boot put the title up at ~57s, against a ~193s no-input baseline
measured over three boots, and Canary's own keystroke counter went 3->4
so exactly one press was delivered. The skipped-to title is fully
functional -- it draws the PRESS A plate and a second A opens the main
menu. What actually breaks the boot is hammering: the 88-press run in the
traps doc. The scripts' "tapping breaks the title" comment is too broad
and costs every scripted boot two and a half minutes.

Q4's last row: A on NEW GAME does not hang. It opens DIFFICULTY
(EASY/NORMAL/HARD/BACK, focus on NORMAL), then SELECT DATA, and only then
does the guest throw -- at PC 0x82307128, which is inside sub_823070B0,
the cache-manager STL erase this corpus already documents and which has
nothing to do with the menu path. The screen sat unchanged for 90s
because it was a menu waiting for input from a loop that never pressed
anything. That is now a METHOD line: a screen that never changes is not
necessarily hung, and the fix is to look at it and press something.

Also METHOD: never run ps -ef in this container -- all three long-lived
processes carry the entire loop prompt as argv.

docs/re/METHOD.md

@@ -169,3 +169,12 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   drive every correlation toward zero and the ranking becomes noise; one control
   frame scored 0.000 and another tied the wrong movie at 0.98. Read a dark
   frame's runner-up as *no evidence*, not as evidence for the runner-up.
+* **A screen that never changes is not necessarily hung — it may be a menu.** A
+  90-second screenshot loop that presses nothing will report a perfectly healthy
+  `DIFFICULTY` menu as a standing hang, and that reading survived in this corpus
+  for months. Before calling a static screen a hang, *look at it*, and press
+  something.
+* **Never run `ps -ef` in this container.** Each of the three long-lived
+  processes carries the whole loop prompt as its argv, so the listing is tens of
+  kilobytes of the prompt you already have. Use `pgrep -x <name>` or
+  `ps -o pid=,stat= -C <name>`.

docs/re/REFUTED.md

@@ -35,6 +35,14 @@ neighbourhood, not just the line.
 
 ## Screens, classes and RTTI
 
+* "Ⓐ on `NEW GAME` leads to a standing black-screen hang" → it opens
+  **`DIFFICULTY`**, then **`SELECT DATA`**. What looked like a hang was a menu
+  waiting for input that nobody pressed; the crash that follows is the already
+  documented `sub_823070B0` cache throw.
+  [`menu-navigation-semantics.md`](menu-navigation-semantics.md)
+* "tapping Ⓐ during the boot movie breaks the title" → **one** tap skips the
+  movie cleanly and the title works normally. It is *hammering* (88 presses) that
+  breaks it. [`movie-binding.md`](movie-binding.md)
 * "the attract movie runs ~85 s, so it is not `ADV.wmv` (137 s)" → **mine, and
   wrong.** Sampling began 39 s into the movie, so what was timed was its tail.
   The attract movie **is** `ADV.wmv`, played in full.

docs/re/menu-navigation-semantics.md

@@ -75,3 +75,45 @@ transition, and works under `--gpu=null` with no screenshots at all. ⚠️ Note
 those values are **not** GamePart ids — `GP_TITLE` is GamePart 0 and `GP_EXTRAS`
 is 5, but the word reads 1 and 4 — so it is a third enumeration and mapping it to
 the id table is itself unfinished work.
+
+## ✅ `NEW GAME` — measured 2026-08-28, and it is not a hang
+
+The one destination this page could not test has been driven. **Ⓐ on `NEW GAME`
+does not hang.** It opens two more menus first:
+
+```
+NEW GAME  ->  DIFFICULTY  ->  SELECT DATA  ->  guest crash
+```
+
+* **`DIFFICULTY`** — `EASY` / `NORMAL` / `HARD` / `BACK`, footer
+  `Ⓐ : OK  Ⓑ : Back`, opening focused on **`NORMAL`**
+  ([capture](captures/newgame-path/newgame-difficulty.png)). It sat unchanged for
+  90 s with the emulator healthy — a menu waiting for input, which is exactly
+  what "a standing hang" looks like to a screenshot loop that never presses
+  anything.
+* Ⓐ on `NORMAL` → **`SELECT DATA`**, a save-slot picker headed
+  `Current Storage: Dummy HDD`, prompting to pick a file for the auto-save.
+* Then the guest throws, and Xenia pauses with `PC: 0x82307128`
+  ([capture](captures/newgame-path/newgame-selectdata-crash.png)).
+
+**That crash is already in the corpus and is not new**: `0x82307128` is inside
+`sub_823070B0`, the cache-manager STL erase documented in
+[`title-crash-stl-tree.md`](title-crash-stl-tree.md), whose trigger is an
+incomplete on-disc shader/code cache — not the menu path. The corpus also already
+holds `captures/select-data-crash.png`.
+
+So Q4's last row closes as **measured**:
+
+| button | screen it opens |
+|---|---|
+| `NEW GAME` | **`DIFFICULTY`** (then `SELECT DATA`) |
+
+🟡 The GamePart ids for these two are unmeasured, like the rest — `24 GP_DIALOG`
+and `3 GP_LOAD` / `2 GP_SELECT_STORAGE` are name-match candidates and nothing
+more.
+
+### Initial focus — a fourth data point, and it still varies
+
+This boot opened the main menu on **`NEW GAME`**. Running tally across four
+boots of the same harness: `TUTORIAL`, `TUTORIAL`, `NEW GAME`, `NEW GAME`.
+Unchanged conclusion: **do not hardcode it.**

docs/re/movie-binding.md

@@ -97,3 +97,31 @@ are in play order and the key *is* the role. That is not the whole driver — it
 says what plays, not what decides to advance — but it is the first file-side
 piece of Q6's second half, and it means the boot-side asset order does not have
 to be authored.
+
+## ✅ Skippable — settled 2026-08-28: **one Ⓐ skips the movie**
+
+The test named above was run, and the answer is unambiguous.
+
+| | |
+|---|---|
+| baseline: title arrives with **no** input | ~193 s, ~196 s, ~193 s (three boots) |
+| **one Ⓐ tapped at ~45 s into the boot** | **title at ~57 s** |
+
+The press is provably the cause and provably singular: Canary's own
+`[RE-INPUT] XamInputGetKeystrokeEx reached the driver` counter went **3 → 4**
+across the tap, so exactly one keystroke was delivered, and the title arrived
+~12 s later instead of ~150 s later.
+
+**And the skipped-to title is fully functional**, which is the part that matters
+for the harness folklore: it draws the `PRESS Ⓐ BUTTON` plate (2 408 plate pixels
+by the same probe used elsewhere), and a second Ⓐ opened the main menu normally
+([`title-after-single-A-skip.png`](captures/newgame-path/title-after-single-A-skip.png)).
+
+### So what is `skip_intro.sh` protecting against?
+
+Not a single tap. The failure recorded in
+[`canary-scripted-input-traps.md`](canary-scripted-input-traps.md) is run G —
+**88 presses at 4 s intervals through the whole boot** — which left a permanent
+black screen. Hammering breaks it; one press does exactly what the button is for.
+The scripts' `waiting it out (tapping breaks the title)` comment is **too broad**,
+and it costs every scripted boot ~2.5 minutes.