From 202a512a12ea0ae3b806481352da66526795e4aa Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sat, 29 Aug 2026 14:48:46 +0000 Subject: [PATCH] re: a refutation attempt that failed -- EXTRAS really is a three-button screen The port reported GP_TITLE entries 6/9 as a three-button submenu. This page and HANDOFF call 6/9 EXTRAS and never recorded a button count, and 18 elements looked like too many for three buttons, so I challenged it -- from the count, without listing the elements. Wrong. `screen info --all --build 6` shows ptbtn11/12/13 among fifteen frame, title, background and effect layers, and entry 9 is identical. Both things are true: 6/9 are EXTRAS (our composite correlates +0.944 whole-frame with the committed live-extras.png) and EXTRAS is a three-button screen. The port established the button count; the corpus did not have it. Recorded per the adversarial duty, which is worth nothing if only the successful challenges get written down. The retraction has gone to the port as well. Also checked in the same pass, and it constrains Q2: entries 5 and 8 have identical element lists and identical button placements, as do 6 and 9. The EN/JP difference lives in the baked sprite pixels, so no layout field will ever separate the members of either pair -- that needs the sprite images or a capture, and the "English is the first half of the data segment" rule stays a heuristic rather than something a field will replace. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd --- docs/re/ui-title-build-map.md | 44 ++++++++++++++++++++++++++++++++++- 1 file changed, 43 insertions(+), 1 deletion(-) diff --git a/docs/re/ui-title-build-map.md b/docs/re/ui-title-build-map.md index e6098cd6..bd873f57 100644 --- a/docs/re/ui-title-build-map.md +++ b/docs/re/ui-title-build-map.md @@ -829,4 +829,46 @@ vertex-colour capture — were built on "the skewed draw is the swoosh", an identification made by *elimination on one screen* and never checked against the draw's own coordinates. The eliminations themselves stand (they were measured against the capture, not against the identification), but the chain of reasoning -that pointed at `ptlogo_back2*` did not. \ No newline at end of file +that pointed at `ptlogo_back2*` did not. + +--- + +## 🟢 Refutation attempt, 2026-08-29 — "entries 6/9 are a three-button submenu". It SURVIVED. + +The port reported `GP_TITLE` entries 6 and 9 as a **three-button** submenu +(`ptbtn11/12/13` at x = 532, y = 282 / 362 / 442). This page and HANDOFF call +6/9 `EXTRAS` and say nothing about a button count, and 18 elements looked like +too many for three buttons, so the claim was challenged. + +**The challenge was wrong and the claim stands.** `screen info --all --build 6`: + +``` +ptframe3.t32 ptframe4.t32 ptbtn11.rat ptbtn12.rat ptbtn13.rat ptmsg2.t32 +pteff20.t32 pteff21.t32 pteff22.t32 pteff23.t32 pttitle.t32 ptbase.t32 +pteff05.t32 pteff02.prm ptloop01.rat ptloop02.rat pteff10.t32 pteff00.prm +``` + +Entry 9 is identical. Three `ptbtn*` elements, and the other fifteen are frame, +title, background and effect layers. Both statements hold at once: 6/9 **are** +`EXTRAS` — our composite of entry 6 correlates **+0.944** whole-frame with the +committed [`live-extras.png`](captures/title-builds/live-extras.png) — **and** +`EXTRAS` is a three-button screen. The corpus had never recorded its button +count; the port established it, and this page now does too. + +⚠️ The challenge was raised from an element *count* without listing the elements, +when a one-line `screen info` was available. Recorded because the protocol's +adversarial duty is worth nothing if only the successful challenges get written +down. + +## ✅ Entries 5 and 8 cannot be told apart by layout — only by pixels + +Checked in the same pass, because it bears on which build is which screen state. +Entries 5 and 8 have **identical element lists** (`pteff00.prm ptbase pteff05 +ptloop01 ptloop02 pteff02.prm ptframe1 ptframe2 pteff10 pteff12 ptbtn01…05 +ptmsg`) and identical button placements. The EN/JP difference between the two +main-menu bundles lives in the **baked sprite pixels**, not in any layout field. + +So the 🟡 rule that "the English member of a pair is the one in the first half of +the data segment" is not going to be replaced by a layout field for this pair — +separating 5 from 8 needs either the sprite images or a capture. The same is true +of 6 vs 9, whose element lists are also identical.