# Do LOAD GAME, TUTORIAL and OPTIONS remember their cursors?
# 2026-08-30. ❔ STILL UNMEASURED. Two sweeps, two different instrument faults.
#
# The main menu PERSISTS; EXTRAS RESETS. Two screens, two behaviours, so every
# screen needs measuring and none can be inferred. NEW GAME stays deliberately
# untested. These three are what is left, and they are still open.
#
################################################################################
# SWEEP 1 -- voided by a reader that only works on one screen.
#
# All three voided on "the ring did not move" after a DELIVERED DOWN:
#   LOAD GAME  ring 288.0 -> 288.0
#   TUTORIAL   ring 385.0 -> None
#   OPTIONS    ring 287.5 -> 287.5
#
# 🔴 THE RING HAD MOVED. Differencing S1 against S2 shows exactly where:
#   LOAD GAME  0.25% of frame changed, x  97..231
#   TUTORIAL   2.31%                   x 338..1099
#   OPTIONS    2.59%                   x 153..479
#
# ring_row.py scans x 500:542 -- the MAIN MENU's gutter. EXTRAS happened to put
# its ring in that column, which is why the EXTRAS measurement was sound; these
# three do not. The reader was finding a STATIC element and reporting no motion.
# ⚠️ A reader calibrated on one screen is not a reader for the others, and
# "it worked last time" is what made that invisible.
#
################################################################################
# SWEEP 2 -- the reader replaced, and defeated by an OVERLAY instead.
#
# Decision rule changed to need no ring at all: S1 and S2 differ ONLY by cursor
# position, so compare the re-entry frame to each over the whole frame.
# ✅ CONTROLLED on the EXTRAS frames, whose answer is already known:
#      E1 vs E2 (the move) 2.70%  -> localised, control passes
#      E3 vs E1 (opened)   0.02%
#      E3 vs E2 (left on)  2.71%   verdict RESETS, and RESETS is the known answer.
#
#   LOAD GAME  S1 opened (glyph 12838), DOWN changed 6.00% -- control PASSED
#              then: TIMEOUT waiting for the main menu. TUTORIAL and OPTIONS
#              skipped, because the probe refuses to measure from an unknown
#              state rather than pressing on.
#
# 🔴 THE GUEST HAD CRASHED -- and it is the crash this corpus already documents.
# PC 0x82307128, guest thread 9, Access Violation read at 0x000000010000000C,
# preceded by HostPathDevice::ResolvePath(\aab216c3) and "Guest attempted to
# throw a C++ exception!" -- the STL map/set erase of title-crash-stl-tree.md.
# ⚠️ NOT a new finding: that page has it, and autopilot-knowledge-sources.md
# counts 384 dumps at the same PC. The first dump here is at log line 2204, so it
# fired EARLY IN THE BOOT and the dialogs stacked; it is not something Ⓑ did.
#
# ⚠️ AND THE "MORE ROBUST" RULE WAS THE MORE FRAGILE ONE. Xenia's crash dialog
# covers the middle of the screen, so a WHOLE-FRAME identity test can never match
# again once it appears. The narrow ring column the dialog does not cover read the
# screen correctly the whole time. A global comparison is defeated by any overlay;
# a narrow measured feature survives it. I replaced the reader with the global
# rule *because* the reader had just failed, and traded one blindness for another.
#
################################################################################
# ✅ REFUTATION ATTEMPT -- "Ⓑ on a submenu returns to the parent with focus
# restored to the item you entered from" (4/4, another agent's). IT SURVIVES, and
# the run that looked like a failure is what corroborates it.
#
# The stuck frame -- main menu visible behind the crash dialog -- has the ring at
# y 303.5, which the calibrated reader names LOAD GAME. That is exactly the item
# the probe entered from. So Ⓑ did return AND did restore focus; only my screen
# test failed. A FIFTH instance, from a run I had written off.
#
# ❔ WHAT IS STILL OPEN: whether LOAD GAME, TUTORIAL or OPTIONS persist. Nothing
# here measures it. What a third attempt needs is a per-screen ring locator (the
# S1->S2 difference gives the cursor's own region on each screen) plus a screen
# test that ignores the dialog rectangle -- or a boot without the crash.
