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