From eb21c977efca527b999862666ffe7ea11bd5f803 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 26 Aug 2026 20:47:15 +0000 Subject: [PATCH] tools: classify the mission briefing instead of filing it as `menu` The briefing map is cyan and satisfies every clause of the menu rule (b-r > 30, r < 45, little white), with no earlier rule claiming it -- so it was labelled `menu`. That made wait_screen.sh report NEVER REACHED READY ROOM on a run that had successfully done LOAD GAME -> slot 01 -> YES and was three screens further on: a working route scored as a failed one, pointing the next debugging step at an input path that was fine. Cyan has b and g nearly equal (b-g ~ 5) where the menu's blue leads its green (b-g ~ 32), so `r < 20 and g > 30 and b - g < 20` separates them; the r floor keeps the title screen out. The file's own docstring already carried the briefing's mean as an aside -- it just never had a class. Verified against all eight signatures the file documents (2 menu variants, title, ready room, flight, 3 briefing measurements): no regressions, and the captured briefing image now reads `briefing`. --- docs/re/screen-id-briefing-misclass.md | 60 ++++++++++++++++++++++++++ tools/re-capture/screen_id.py | 20 ++++++++- 2 files changed, 79 insertions(+), 1 deletion(-) create mode 100644 docs/re/screen-id-briefing-misclass.md diff --git a/docs/re/screen-id-briefing-misclass.md b/docs/re/screen-id-briefing-misclass.md new file mode 100644 index 00000000..d773a048 --- /dev/null +++ b/docs/re/screen-id-briefing-misclass.md @@ -0,0 +1,60 @@ +# ✅ `screen_id.py` filed the mission briefing as `menu` — a successful route scored as a failure + +**Confidence: ✅ CONFIRMED and FIXED.** Measured 2026-08-26. + +## Symptom + +`launch_mission.sh`'s nav ran to completion and `wait_screen.sh readyroom 300` +reported: + +``` +NO readyroom within 300s (last seen: menu) +NEVER REACHED READY ROOM +``` + +The obvious reading — and the one taken at first — is that the presses after the +main menu never landed. That reading was wrong twice over: + +1. Pad input *was* landing. With the game's own cursor counter as the oracle, two + `dpad down` presses moved it `24 → 26 → 28`. +2. The run was not on the main menu. It was on the **mission briefing map** + ("Glasner Training Area", Ⓐ:Continue / Ⓑ:Back / START:Skip) — three screens + past the menu, i.e. `LOAD GAME → slot 01 → YES` had all worked. + +![briefing misread as menu](captures/briefing-misclassified-as-menu.png) + +## Cause + +The briefing is **cyan**; the menu rule tests for *dark and blue* and the +briefing satisfies every clause of it — `b - r > 30`, `r < 45`, `white < 0.075`. +With no earlier rule claiming it (the ready-room rule needs `b > 110`, the flight +rule needs green), it fell through and was labelled `menu`. + +Ironically the file's own docstring already recorded the distinguishing number: +it notes the briefing as "cyan rather than blue at (4.6, 47.7, 54.5)" — as an +aside justifying the ready-room threshold, never as a class of its own. + +## Fix + +Cyan has blue and green nearly equal; the menu's blue runs far ahead of its green: + +| screen | measured means | `b - g` | +|---|---|---| +| briefing | (1.4, 45.2, 49.6), (5.5, 49.1, 54.3), (4.6, 47.7, 54.5) | ~5 | +| main menu | (25, 38, 70), (13, 26, 59) | ~32 | + +So `r < 20 and g > 30 and b - g < 20` → `briefing`, placed above the menu rule. +The `r < 20` floor keeps the title screen (52.8, 66.1, 74.5, `b - g` 8.4) out; +the ready room (`b - g` ~97) and flight (green rule) are already claimed above. + +Verified against **every** signature the file documents — the two menu variants, +title, ready room, flight, and three briefing measurements: 8/8 classify as +intended, no regressions. The real capture above now reads `briefing`. + +## Why it mattered + +This is the expensive failure mode, not a cosmetic one: a route that *worked* +was reported as broken, and the conclusion drawn from it — "the presses are not +landing" — would have sent the next iteration to debug an input path that was +fine. Compare the same file's earlier note about a run that "sat on a plainly +visible MAIN MENU for 300 s": same class of bug, second occurrence. diff --git a/tools/re-capture/screen_id.py b/tools/re-capture/screen_id.py index 8997e92f..5a09dad3 100755 --- a/tools/re-capture/screen_id.py +++ b/tools/re-capture/screen_id.py @@ -23,7 +23,7 @@ Measured on known-good captures of each screen (1280x720, no menu bar): movie green 0% white varies no green at all Usage: screen_id.py [--json] -Prints one of: title | menu | readyroom | flight | other, plus the features. +Prints one of: title | menu | briefing | readyroom | flight | other, plus the features. """ import json import subprocess @@ -73,6 +73,24 @@ def classify(f): # which put one run in OPTIONS and the next in BRIEFINGS. if f["b"] > 110 and f["r"] < 40 and f["b"] - f["g"] > 60: return "readyroom" + # The mission BRIEFING map is cyan, not blue, and without this rule it falls + # straight through to the menu test below (dark, b - r > 30, r < 45, little + # white -- all true of it). MEASURED 2026-08-26: that mislabel made + # `wait_screen.sh readyroom` report NEVER REACHED READY ROOM on a run that + # had in fact navigated LOAD GAME -> slot 01 -> YES and was sitting on the + # briefing three screens further on, which is the worst kind of failure -- + # a successful route scored as a failed one. + # + # What separates them is that cyan has blue and green nearly equal, while + # the menu's blue runs far ahead of its green: + # + # briefing (1.4, 45.2, 49.6) (5.5, 49.1, 54.3) (4.6, 47.7, 54.5) b-g ~ 5 + # main menu (25, 38, 70) (13, 26, 59) b-g ~ 32 + # + # The r < 20 floor keeps the title screen (52.8, 66.1, 74.5, b-g 8.4) out; + # the ready room (b-g ~ 97) and flight (green rule) are already claimed above. + if f["r"] < 20 and f["g"] > 30 and f["b"] - f["g"] < 20: + return "briefing" # The main menu is dark and strongly blue. TWO measured signatures, not one: # # white 3.5% mean (25, 38, 70) the 2026-07 reference at the top