re: the focus reader was two items out -- initial focus is NEW GAME, and my labels were wrong

menu_focus.py's row centres are design-space rows from screenshot output; my
probes fed it whole-display x11grab frames carrying Xenia's chrome and a surface
scaled 1.060. Caught by ground truth, not by a control: the probe announced 'on
EXTRAS', pressed A, and opened OPTIONS.

Measured directly with ring_row.py: initial focus on a fresh boot is NEW GAME,
2/2 fresh boots, both the first menu entry. That agrees with boot_menu.sh's own
line and menu-state-in-memory.md's four-downs, and withdraws this page's
'TUTORIAL 2/2' as the outlier.

Persistence stands and is now geometry-free -- 384.0 vs 385.5, 1.5 px apart. An
equality test is immune to a constant offset, which is why the conclusion survived
a broken reader when the published item names did not.

The control was structurally blind: 'two DOWNs move two items' tests relative
motion, and a constant offset preserves it exactly.

EXTRAS remains unmeasured; that run navigated to OPTIONS.

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

docs/port/HANDOFF.md

@@ -11,6 +11,36 @@ delivered.
 
 
 
+
+## 🔴 2026-08-30 (later) — correcting today's focus delivery: the names were wrong
+
+**Read this before the persistence section above.** Two things change, one of
+them a value you may have taken.
+
+* 🔴 **The item names I gave for the persistence run were two positions out.**
+  Reported `TUTORIAL → EXTRAS → EXTRAS`; the truth is
+  **`NEW GAME → TUTORIAL → TUTORIAL`**. My focus reader used design-space rows
+  against whole-display captures that carry Xenia's window chrome and a surface
+  scaled 1.060.
+* ✅ **The persistence conclusion is unchanged and is now geometry-free** — the
+  ring sits at y 384.0 before the round trip and 385.5 after, 1.5 px apart. An
+  equality test is immune to a constant offset, which is exactly why the
+  conclusion survived a reader the labels did not.
+* ✅ **Initial focus on a fresh boot is `NEW GAME`** — measured directly, 2/2
+  fresh boots, both the *first* menu entry. **Your authored `NEW GAME` is now a
+  measured value.** I said earlier today that nothing confirmed it; that is no
+  longer true.
+* ⚠️ **My control could not have caught this.** "Two DOWNs move two items" tests
+  relative motion, which a constant offset preserves. It passed on a reader two
+  items wrong.
+
+❔ **EXTRAS is still unmeasured** — the run that was to settle it navigated to
+OPTIONS believing it was EXTRAS, so nothing about EXTRAS was observed and your
+`initial_focus: ptbtn11` label remains undecided.
+
+[data](../re/data/menu-focus-reader-offset.txt)
+
+
 ## ✅ 2026-08-30 — the main menu remembers its cursor; re-entry is not a reset
 
 **measured, and it changes what `on_cancel` should do.** Ⓑ from the menu to the

docs/re/data/menu-focus-reader-offset.txt

@@ -0,0 +1,60 @@
+# The focus reader was wrong on x11grab frames -- and what that changes.
+# MEASURED 2026-08-30.
+#
+# menu_focus.py's row centres YS = [166,241,315,390,465] are DESIGN-SPACE rows,
+# derived from `screenshot` captures. My probes feed it ffmpeg x11grab frames of
+# the whole X display, which include Xenia's title bar and menu bar and show the
+# game surface SCALED. Same numbers, different coordinate system.
+#
+# CAUGHT BY GROUND TRUTH, not by a control: the probe announced "on EXTRAS",
+# pressed A, and opened OPTIONS. I looked at the frame.
+#
+# THE OFFSET, measured directly rather than assumed -- brightest gutter cluster
+# (x 500:542), excluding the y<50 window-decoration band and the footer:
+#
+#   reach/1-F1.png  ring y = 225.5     (first menu entry of a fresh boot)
+#   reach/2-F2.png  ring y = 384.0     (after 2 delivery-confirmed DOWNs)
+#   reach/4-F3.png  ring y = 385.5     (after B -> title -> A -> menu)
+#
+#   spacing = (384.0 - 225.5) / 2 = 79.25 px per item
+#   design spacing is 74.75, so the surface is scaled by 1.060 -- UP, not down
+#   capture_y = 49.5 + 1.060 * design_y      (checks: 241->305 vs 304.75 seen,
+#                                                     315->383.4 vs 384.0 seen)
+#
+# ⚠️ MY FIRST CORRECTION WAS ALSO WRONG. I assumed the 1280x675-inside-1280x720
+# note meant the surface was scaled DOWN by 0.9375. Applying that gave F2 =
+# OPTIONS, i.e. three rows below F1 where only two DOWNs were delivered -- the
+# arithmetic refused it. Measuring the spacing settled it in one step.
+#
+################################################################################
+# WHAT THIS CHANGES
+#
+# ✅ INITIAL FOCUS ON A FRESH BOOT IS **NEW GAME**, not TUTORIAL.
+#    F1's ring at y=225.5 is design row 166 = item 0. Two fresh boots, both the
+#    FIRST menu entry of the boot, both NEW GAME (this run, and the earlier run
+#    whose old-reader value of LOAD GAME is the same frame misread).
+#
+#    That AGREES with boot_menu.sh's own closing line and with
+#    menu-state-in-memory.md's four-downs-to-EXTRAS, which only counts from NEW
+#    GAME. menu-navigation-semantics.md's "TUTORIAL, 2/2" is the outlier.
+#
+# ✅ THE PERSISTENCE FINDING STANDS, and is now confirmed WITHOUT any geometry:
+#    F2 ring y = 384.0, F3 = 385.5. 1.5 px apart. The cursor is where it was
+#    left. An equality test is immune to a constant offset, which is exactly why
+#    that conclusion survived a broken reader.
+#
+# 🔴 BUT THE ITEM NAMES I PUBLISHED FOR IT WERE WRONG.
+#    Reported: F1 TUTORIAL -> F2 EXTRAS -> F3 EXTRAS.
+#    Truth:    F1 NEW GAME -> F2 TUTORIAL -> F3 TUTORIAL.
+#    Two positions out. The conclusion does not change; the labels do.
+#
+# 🔴 AND MY CONTROL COULD NOT HAVE CAUGHT IT. "Two DOWNs must move the cursor
+#    exactly two items" tests RELATIVE motion, and a constant offset preserves
+#    relative motion exactly. A control that only checks differences is blind to
+#    every error in the origin. It passed on a reader that was two items out.
+#
+# ❔ THE EXTRAS QUESTION IS STILL UNANSWERED. The probe navigated to OPTIONS
+#    believing it was EXTRAS, so E1/E2/E3 are the OPTIONS screen and a different
+#    screen respectively (E3 glyph 1776 is the title's plate band -- A on the
+#    wrong screen went somewhere else entirely). Nothing about EXTRAS was
+#    measured. sylpheed-port's `initial_focus: ptbtn11` label is still undecided.

docs/re/menu-navigation-semantics.md

@@ -30,6 +30,40 @@ with [`tools/re-capture/menu_focus.py`](../../tools/re-capture/menu_focus.py).
 Wrap holds on both screens tested — the 5-item main menu and the 3-item `EXTRAS`
 submenu — so it is a menu rule, not a per-screen table.
 
+## 🔴 2026-08-30 (later) — the item NAMES below were wrong, and initial focus is NEW GAME
+
+**The reader was broken and my control could not see it.** `menu_focus.py`'s row
+centres are **design-space** rows read off `screenshot` output; my probes fed it
+whole-display `x11grab` frames, which carry Xenia's title bar and menu bar and
+show the game surface scaled by **1.060**. Caught by ground truth, not by a
+control: the probe announced *"on EXTRAS"*, pressed Ⓐ, and opened **OPTIONS**.
+
+Ring rows measured directly (`tools/re-capture/ring_row.py`), no assumed geometry:
+
+| frame | ring y | true item |
+|---|---|---|
+| first menu entry, fresh boot | **225.5** | **`NEW GAME`** |
+| after 2 delivery-confirmed DOWNs | 384.0 | `TUTORIAL` |
+| after Ⓑ → title → Ⓐ → menu | **385.5** | `TUTORIAL` |
+
+* ✅ **Initial focus on a fresh boot is `NEW GAME`** — 2/2 fresh boots, both the
+  *first* menu entry. That agrees with `boot_menu.sh`'s own closing line and with
+  [`menu-state-in-memory.md`](menu-state-in-memory.md)'s four-downs-to-`EXTRAS`,
+  which only counts from `NEW GAME`. ~~"initial focus, main menu — TUTORIAL"~~ in
+  the Q5 table below is **withdrawn**: it is the outlier, and this reading is the
+  direct one.
+* ✅ **Persistence stands, and is now geometry-free**: 384.0 vs 385.5, 1.5 px
+  apart. An equality test is immune to a constant offset, which is why that
+  conclusion survived a broken reader when the labels did not.
+* 🔴 **The names I published for it were two positions out** — reported
+  `TUTORIAL → EXTRAS → EXTRAS`, truth `NEW GAME → TUTORIAL → TUTORIAL`.
+* ⚠️ **The control was structurally blind to this.** "Two DOWNs must move the
+  cursor exactly two items" tests *relative* motion, and a constant offset
+  preserves relative motion exactly. **A control that only checks differences
+  cannot see an error in the origin.**
+
+[data](data/menu-focus-reader-offset.txt)
+
 ## ✅ 2026-08-30 — the menu REMEMBERS its cursor across menu → title → menu
 
 **measured** — [`data/focus-persists-across-title.txt`](data/focus-persists-across-title.txt),