From 826599cab8bd9bcbdf85199a442d9bf012e56220 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 18:49:29 +0000 Subject: [PATCH] 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) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/port/HANDOFF.md | 31 +++++++++++++++-------- docs/re/METHOD.md | 10 ++++++++ docs/re/data/fade-four-transitions.txt | 35 ++++++++++++++++++++++++++ tools/re-capture/fade_decompose.sh | 10 +++++++- 4 files changed, 75 insertions(+), 11 deletions(-) diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index e143dfca..3350d80d 100644 --- a/docs/port/HANDOFF.md +++ b/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. diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index 295d516b..e790114e 100644 --- a/docs/re/METHOD.md +++ b/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. diff --git a/docs/re/data/fade-four-transitions.txt b/docs/re/data/fade-four-transitions.txt index f3f8d7f4..c6eb255a 100644 --- a/docs/re/data/fade-four-transitions.txt +++ b/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. diff --git a/tools/re-capture/fade_decompose.sh b/tools/re-capture/fade_decompose.sh index 275d51f4..4d28f432 100755 --- a/tools/re-capture/fade_decompose.sh +++ b/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)"