re: the A-press dialog is the SIGN-IN dialog -- and the corpus already knew

Answers the open half of the A-press diagnosis, and most of the answer was
already in the tree.

The faulting runs booted with logged_profile_slot_0_xuid = "" -- their own
config dump -- while a profile existed (Found 1 Profiles). With nobody signed
in, A takes the state-0 branch of sub_821D03A0 and calls XamShowSigninUI(1,1);
Canary raises its Sign In dialog with a no-op close handler and nothing in an
unattended run dismisses it. 85 instructions verified against the image, 0
mismatches; the state-3 branch is XamShowDeviceSelectorUI, already ruled out by
storage_selection_dialog = false.

The correlation runs through the tooling: boot_menu.sh passes the profile flag
and Q4/Q5 pressed all five buttons; frame_clock.sh, which produced the faulting
run, does not.

So there is no blocker -- boot with boot_menu.sh. Flagged as retrodicted rather
than A/B tested, since I have not myself booted both ways and pressed A.

The uncomfortable half: canary-scripted-input-traps.md section 3 already named
the sign-in dialog WITH a committed capture, and boot_menu.sh's header already
carried the mechanism and the 8.4 million figure. The fault page searched for
the cause it had hypothesised and never searched for its own symptom. Added to
METHOD.md, along with the more expensive lesson -- a measurement whose only
record is a script comment is invisible to the document that needs it.

What this session did add is the join: that the known blackout is what drives an
unbounded guest queue into a failed 128 MB allocation.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

docs/re/METHOD.md

@@ -1146,3 +1146,38 @@ them free calibration points.
 > random — it is the first N, and what falls in the first N is itself a moving
 > function of the thing you are measuring.** A truncated view looks like a
 > complete view of a smaller set.
+
+## Before calling a failure unexplained, grep the corpus for its *symptom*
+
+`title-a-press-fault.md` spent a session recording that a single Ⓐ faults the guest
+4/4, and closed with *"it does not explain how Q4/Q5 pressed Ⓐ successfully; what
+differs is unfound."*
+
+**It was found, and written down twice, before that page existed.**
+
+* [`canary-scripted-input-traps.md`](canary-scripted-input-traps.md) §3: *"With no
+  profile, Ⓐ **is** handled: the guest calls `XamShowSigninUI` and Xenia pops its
+  Sign In dialog"* — with a committed capture.
+* `tools/re-capture/boot_menu.sh`'s header, which explains the swallow **and quotes
+  the 8.4 million figure**, and is why that launcher passes
+  `--logged_profile_slot_0_xuid`.
+
+The fault page searched for the *cause* it had hypothesised — an unimplemented
+instruction, then a wild pointer — and never searched for its own *symptom*, which
+would have hit both immediately.
+
+⚠️ **Two lessons, and the second is the expensive one:**
+
+1. **Grep for the symptom, not the theory.** "Ⓐ", "signin", "IsUIActive" were all in
+   the tree.
+2. 🔴 **Knowledge in a script header is invisible to the document that needs it.**
+   `boot_menu.sh` had the mechanism and the magnitude, and no `docs/re/` page linked
+   to it. A tool comment is a fine place to explain a flag and a **bad** place to be
+   the only record of a finding. If a script comment is carrying a measurement, that
+   measurement belongs in `docs/re/` with the script pointing at it.
+
+What the later session did add was the **join** — that this known input blackout is
+what drives the guest's unbounded keystroke queue into a failed 128 MB allocation —
+plus the guest code path and a host-vs-guest address retraction. A join between two
+recorded facts is a real finding; but it is much cheaper when neither fact has to be
+rediscovered.