re: break the EXTRAS n=1 cap -- which I had wrongly called structural

I recorded EXTRAS as able to supply only one gap measurement because "its sole
exit is (B) to the menu", and called that n=1 STRUCTURAL -- a word that retires a
question. The disc refutes it in one command: build 6 declares three buttons,
ptbtn11/ptbtn12/ptbtn13, all kind 0x3002. The cap was an unverified assertion I
had already written into HANDOFF twice.

Measured EXTRAS -> a screen outside GP_TITLE via (A): outgoing quad rises across
frames 36-40 (4-5 frames, matching build 6's declared 10-unit close), then THREE
empty frames at 42, 43, 44, then a different archive builds (23-28 draws/frame
against GP_TITLE's 11-14). Gap = 3.

So EXTRAS as outgoing gives {2, 3}, and seven transitions now group as:
menu {0,1,1} n=3, EXTRAS {2,3} n=2, title {3,3,3} n=3.

A pairwise control that holds the destination class constant: menu -> another
archive gives 1, EXTRAS -> another archive gives 3. Same kind of destination, gap
differs by outgoing screen. That is the strongest support yet for the
outgoing-screen dependence because it removes the destination as the variable.

But the clean ordering is GONE: EXTRAS {2,3} and title {3,3,3} overlap at 3, so
"menu < EXTRAS < title" no longer separates them. What survives is weaker -- the
outgoing screen constrains the gap to a ~2-wide band and the bands are not
disjoint.

METHOD: a structural limit is a claim and needs checking like any other.
"Structural" and "impossible" are the two words most worth distrusting in your own
notes, because they retire a question rather than answering it and nothing later
re-opens them.

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

docs/port/HANDOFF.md

@@ -28,12 +28,21 @@ authored version can be deleted.
 Your `black_hold_units` is escalated because four gaps gave no rule. A fifth
 transition orders them. [`data/fade-four-transitions.txt`](../re/data/fade-four-transitions.txt).
 
-| transition | black gap | outgoing screen |
-|---|---|---|
-| menu → title (Ⓑ) | **0** | menu |
-| menu → EXTRAS (Ⓐ) | **1** | menu |
-| EXTRAS → menu (Ⓑ) | **2** | EXTRAS |
-| title → menu (Ⓐ) ×3 | **3, 3, 3** | title |
+| outgoing screen | gaps | n | destinations |
+|---|---|---|---|
+| menu (build 5) | **0, 1, 1** | 3 | title, EXTRAS, another archive |
+| `EXTRAS` (build 6) | **2, 3** | 2 | menu, another archive |
+| title (build 4) | **3, 3, 3** | 3 | menu ×3 |
+
+📌 **A pairwise control holding the destination class constant:** menu → another
+archive gives **1**, `EXTRAS` → another archive gives **3**. Same kind of
+destination, gap set by the outgoing screen — the strongest support for that
+dependence, since it removes the destination as the variable.
+
+🔴 **But the clean ordering is gone.** `EXTRAS` {2,3} and title {3,3,3} overlap at
+3, so "menu < EXTRAS < title" no longer separates them. What survives is weaker:
+the outgoing screen constrains the gap to a ~2-wide band, and the bands are not
+disjoint.
 
 📌 **The gap tracks the screen being LEFT — but CONSTRAINS rather than determines
 it.** ⚠️ Corrected the same day, prompted by `sylpheed-port` asking for *"a second
@@ -42,10 +51,12 @@ value on any one outgoing screen"*: **the menu already has two, and they differ*
 the gap" is too strong and I withdraw that phrasing. What holds is an ordering:
 menu {0, 1} < `EXTRAS` {2} < title {3, 3, 3}.
 
-⚠️ **And their ask is answerable only from the menu.** The title's sole exit is Ⓐ
-to the menu and `EXTRAS`'s sole exit is Ⓑ to the menu, so neither can supply a
-second destination. The menu is the only screen in this archive with more than one
-way out, which caps what these five transitions can establish.
+⚠️ 🔴 **"`EXTRAS`'s sole exit is Ⓑ" was WRONG and is withdrawn** — an unverified
+structural claim, refuted by the disc within an hour of my making it. Build 6
+declares **three buttons**, `ptbtn11`/`ptbtn12`/`ptbtn13`, all kind `0x3002`. So Ⓐ
+on `EXTRAS` leaves it by a different route, and its `n=1` was **not** a property of
+the archive — it was a limit I asserted without checking. ⚠️ The title's sole exit
+*is* Ⓐ to the menu (its Ⓑ does nothing, measured), so that half stands.
 
 * **Direction is ruled out** — `EXTRAS → menu` (2) and `menu → EXTRAS` (1) are the
   same pair both ways and differ.

docs/re/METHOD.md

@@ -552,6 +552,16 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   discipline as "state what the number is a number of", applied to scope rather
   than to units.
 
+* ⚠️ **A structural limit is a claim, and it needs checking like any other.** I
+  recorded that `EXTRAS` could supply only one measurement because *"its sole exit
+  is Ⓑ to the menu"*, and called the resulting `n=1` **structural** — a word that
+  closes a question. The disc refutes it: build 6 declares **three buttons**
+  (`ptbtn11/12/13`, kind `0x3002`), so Ⓐ leaves by another route entirely.
+  📌 **"Structural" and "impossible" are the two words most worth distrusting in
+  your own notes**, because they retire a question rather than answering it, and
+  nothing later re-opens them. The check here cost one `screen info` invocation
+  against a claim I had already written into `HANDOFF.md` twice.
+
 ## Runtime / emulator
 
 * **Look at the PNG** — and check its dimensions.

docs/re/data/fade-four-transitions.txt

@@ -211,3 +211,38 @@ frame  untextured full-screen   textured (distinct)        draws tex
 # 🔴 Still not predictive. Nothing declared separates 0/1 from 2 from 3: the
 # outgoing closes are 5, 5, 4 frames for menu, EXTRAS, title against gaps of
 # {0,1}, {2}, {3}. And EXTRAS still has n=1 with no way to get a second value.
+
+################################################################################
+# SEVENTH TRANSITION: EXTRAS -> a screen outside GP_TITLE, via (A). 2026-08-30.
+#
+# 🔴 Taken because my own claim that EXTRAS had a SOLE EXIT was wrong. I recorded
+# its n=1 as STRUCTURAL; the disc refutes that -- build 6 declares three buttons,
+# ptbtn11/ptbtn12/ptbtn13, all kind 0x3002. The cap was an unverified assertion.
+#
+#   frames 28-35   EXTRAS settled ([64]); textured content fades 31-35
+#   frames 36-40   outgoing quad 25, 178, 229, 255 -- 4-5 frames, matching
+#                  build 6's declared close of 10 units = 5 frames
+#   frames 42,43,44  EMPTY: 3 draws, 0 textured  -- THREE frames
+#   frames 45+     a different archive builds (23-28 draws/frame against
+#                  GP_TITLE's 11-14)
+#
+# ✅ GAP = 3. So EXTRAS as outgoing screen gives {2, 3}.
+#
+################################################################################
+# SEVEN TRANSITIONS, BY OUTGOING SCREEN
+#
+#   outgoing            gaps        n   destinations
+#   menu   (build 5)    0, 1, 1     3   title, EXTRAS, another archive
+#   EXTRAS (build 6)    2, 3        2   menu, another archive
+#   title  (build 4)    3, 3, 3     3   menu x3
+#
+# 📌 A PAIRWISE CONTROL that holds the destination class constant: menu -> another
+# archive gives 1, EXTRAS -> another archive gives 3. Same kind of destination,
+# gap differs by the outgoing screen. That is the strongest support yet for the
+# outgoing-screen dependence, because it removes the destination as the variable.
+#
+# 🔴 BUT THE CLEAN ORDERING IS GONE. EXTRAS {2,3} and title {3,3,3} now OVERLAP at
+# 3, so "menu < EXTRAS < title" no longer separates them. What survives is weaker:
+# the outgoing screen constrains the gap to a 2-wide band, and different outgoing
+# screens have different bands that are not disjoint. Still not predictive, and
+# now not even cleanly ordered.

tools/re-capture/fade_decompose.sh

@@ -101,7 +101,7 @@ elif [ "$WHERE" = "menu2other" ]; then
   shot "$OUT/armed-on-menu.png"
   echo "  arming on: $(python3 "$SD/which_title_screen.py" "$OUT/armed-on-menu.png")"
   BTN=A
-elif [ "$WHERE" = "extras" ] || [ "$WHERE" = "menu2extras" ]; then
+elif [ "$WHERE" = "extras" ] || [ "$WHERE" = "menu2extras" ] || [ "$WHERE" = "extras2other" ]; then
   BRANCH="extras-family: navigate to EXTRAS"
   python3 "$SD/pad.py" tap A 0.5
   for _ in 1 2 3 4 5 6; do
@@ -144,6 +144,14 @@ elif [ "$WHERE" = "extras" ] || [ "$WHERE" = "menu2extras" ]; then
     echo "  back on menu: $(python3 "$SD/which_title_screen.py" "$OUT/back-on-menu.png")"
     BTN=A
     BRANCH="menu2extras: back on the MENU with focus restored -> press (A)"
+  elif [ "$WHERE" = "extras2other" ]; then
+    # A SECOND value for EXTRAS as the outgoing screen. I had recorded EXTRAS as
+    # having a sole exit -- (B) to the menu -- and called its n=1 STRUCTURAL. The
+    # disc refutes that: build 6 declares three buttons, ptbtn11/12/13, all kind
+    # 0x3002. So (A) on EXTRAS leaves it by a different route and the cap was an
+    # unverified assertion, not a property of the archive.
+    BTN=A
+    BRANCH="extras2other: arm on EXTRAS -> press (A), leaving by a button"
   else
     BTN=B
     BRANCH="extras: arm on EXTRAS -> press (B)"