From b2206b46a6264af14e9b6c3df06544df591a6630 Mon Sep 17 00:00:00 2001
From: Sylpheed RE agent <agent@localhost>
Date: Wed, 26 Aug 2026 23:08:11 +0000
Subject: [PATCH] re: the guarded route now verifies end-to-end, and the menu
 order is confirmed

With the sliver stopped at both ends (914ada4 producer, 6aa31e5 consumer) a full
guarded run reached Stage 02 and asserted it: "guard: menu confirmed (1279x675)"
then "OK: UN_f101_TCAF_Acropolis is in the 14 definitions", exit 0.

Read the menu the guard confirmed rather than continuing to assume it:
NEW GAME / LOAD GAME / TUTORIAL / OPTIONS / EXTRAS with the cursor on NEW GAME.
So dpad-down x1 = LOAD GAME is correct and dpad-down x2 = TUTORIAL, one press
further -- exactly consistent with the observed mis-selection when the guard was
being fed a sliver.  Capture committed as captures/main-menu-items.png.

Stated plainly: n=1 for "reproducible", and why the game window leaves the window
tree during a load was guarded against, not investigated.
---
 docs/re/nav-guards.md | 51 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/docs/re/nav-guards.md b/docs/re/nav-guards.md
index 3ba415da..b679eee6 100644
--- a/docs/re/nav-guards.md
+++ b/docs/re/nav-guards.md
@@ -53,3 +53,54 @@ below 640×360 return `none` rather than a screen name (commit `30e53f5`).
 * Why the capture came back as a sliver at all when `bin/screenshot` is supposed
   to take the largest `xenia_canary` window by area. It succeeded for the other
   shots in the same run (1279×675), so it is intermittent, not systematic.
+
+---
+
+## ✅ Both ends fixed, and the route now verifies end-to-end
+
+The sliver had to be stopped at **both** ends, because either alone leaves the
+failure reachable:
+
+* **Producer** (`bin/screenshot`, commit `290cbe3`) — the app really does own two
+  windows of class `xenia_canary`, listed in the tree right now as
+  `10x10+10+10` and `1280x745+1+20`. Largest-by-area picks the game window while
+  both are present, but during a load the game window is briefly *absent* and the
+  10×10 helper wins by default; cropping 720 rows at its `+10` gives exactly the
+  `10x710` seen. Candidates narrower than 640 are now ignored, so nothing is
+  selected and the existing fall-through hands back the raw root grab — itself a
+  valid full frame. Verified on the selection logic directly: both windows listed
+  → unchanged `1280x745+1+45`; only the helper listed → old logic returned
+  `10x10+10+10`, new logic selects nothing.
+* **Consumer** (`screen_id.py`, commit `30e53f5`) — captures below 640×360 return
+  `none` instead of a screen name.
+
+A full guarded run then went through cleanly:
+
+```
+guard: menu confirmed (1279x675)
+loaded ... READYROOM ... armed ... >>> HUD
+FLIGHT: flight green=0.0143
+=== GUARD 2 ===
+OK: UN_f101_TCAF_Acropolis is in the 14 definitions
+exit=0
+```
+
+**Stage 02, asserted rather than assumed.**
+
+## ✅ The menu order is confirmed by looking at it
+
+![main menu](captures/main-menu-items.png)
+
+`NEW GAME · LOAD GAME · TUTORIAL · OPTIONS · EXTRAS`, cursor on **NEW GAME**.
+So `dpad down` ×1 → `LOAD GAME` is right, and `dpad down` ×2 → **TUTORIAL** —
+one press further. That is exactly the observed failure: a single extra or
+mistimed press, issued while the guard was looking at a sliver, lands on the
+tutorial. (`structures/ui-paint-order-key.md` already recorded this item list;
+this confirms it visually and pins the cursor's start position.)
+
+## ❔ Still open
+
+* **n = 1.** One clean run after the fix. The mechanism is understood and
+  unit-tested, but "the route is now reproducible" rests on a single success.
+* Why the game window leaves the window tree during a load at all was not
+  investigated — only guarded against.