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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd

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.
+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.