fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: the black gap tracks the OUTGOING screen -- direction and button ruled out

Browse Source 
Applied my own log-line rule to my own instrument first, which is the "rule
written down is not a rule applied" failure I have on record three times. Every
branch of fade_decompose.sh now announces its EFFECTIVE configuration -- derived
from the variables in force, not from $WHERE, per sylpheed-port's sharpening --
and the run REFUSES if no branch announced itself. That is the guard that would
have caught last iteration's silent fall-through at a glance.

With it in place, took the measurement that failed last time: menu -> EXTRAS, the
reverse of the pair measured at a 2-frame gap. Navigation verified both ways
(extras margin 11.23, back on menu 11.60) and the config block confirmed the right
branch.

Result: outgoing quad rises across 5 frames matching build 5's declared 10-unit
close, then ONE logged empty frame. Quoted as 1 with an upward uncertainty, since
its two neighbours carry no frame header at all.

Five transitions now order by the screen being LEFT:

  menu -> title    (B)     0        outgoing menu
  menu -> EXTRAS   (A)     1        outgoing menu
  EXTRAS -> menu   (B)     2        outgoing EXTRAS
  title -> menu    (A) x3  3,3,3    outgoing title

Direction is ruled out: EXTRAS->menu (2) and menu->EXTRAS (1) are the same pair
both ways and differ. Button is ruled out: (B) gives 0 and 2, (A) gives 1 and 3.
Incoming screen is ruled out: an incoming menu takes 3 from the title and 2 from
EXTRAS.

NOT a rule, and recorded as such. Three outgoing screens with one value each means
"each outgoing screen has its own gap" restates the data rather than predicting,
and nothing declared predicts it -- outgoing closes are 5,5,5,4 frames against
gaps 0/1,2,3, inverted if anything, on three points.

What it changes for the port: a UNIFORM black_hold_units is now positively
excluded rather than merely unsupported.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 18:33:40 +00:00
parent 3e525756bf
commit a9b6e78c8f
3 changed files with 95 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
docs/port/HANDOFF.md
View File

@@ -23,6 +23,43 @@ There is no fourth kind. If a row says *measured* or *undecodable*, the port is
human can see it is a human decision, so that when it is later decoded the
authored version can be deleted.
## 🟡 2026-08-30 — the black gap tracks the OUTGOING screen. Direction and button are ruled out.
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 |
📌 **The gap is a property of the screen being LEFT.** Two transitions leaving the
menu give 0 and 1; the one leaving `EXTRAS` gives 2; the three leaving the title
give 3 every time.
* **Direction is ruled out** — `EXTRAS → menu` (2) and `menu → EXTRAS` (1) are the
same pair both ways and differ.
* **Button is ruled out** — Ⓑ gives 0 and 2, Ⓐ gives 1 and 3.
* **Incoming screen is ruled out** — an incoming menu takes 3 (from the title) and
2 (from `EXTRAS`).
🔴 **It is still not a rule, and I would not author from it.** Three outgoing
screens with one value each (bar the title's three) means "each outgoing screen has
its own gap" merely restates the data — a rule would *predict*. And nothing
declared does: the outgoing screen's own closing ramp is 5, 5, 5, 4 frames against
gaps of 0/1, 2, 3, which if anything inverts, on three points.
📌 **What it changes for you:** a *uniform* `black_hold_units` is now positively
excluded rather than merely unsupported — the value differs by outgoing screen
across a 0–3 frame range. If you ever key it, key it on the screen being left, and
only once someone has measured more than one value per screen.
⚠️ Reach: five transitions, all `GP_TITLE`, three of the five being the same pair.
The one-frame gap on `menu → EXTRAS` is one *logged* empty frame with two
neighbours absent from the capture, so it is 1 measured with an upward uncertainty.
## ✅ 2026-08-30 — the sweep leaves: what is settled, and what is not
Closing a long thread so its conclusions are reachable here rather than only in

40
docs/re/data/fade-four-transitions.txt
View File

@@ -133,3 +133,43 @@ frame untextured full-screen textured (distinct) draws tex
# 🟡 STILL OPEN: menu -> EXTRAS, the reverse of the pair measured at a 2-frame
# gap. The instrument is fixed (WHERE=menu2extras now reaches its branch) and the
# run has not been taken.
################################################################################
# FIFTH TRANSITION: menu -> EXTRAS via (A). 2026-08-30.
# The reverse of the pair already measured at a 2-frame gap, taken to test whether
# the black gap is a property of the screen PAIR or of the DIRECTION.
#
# Navigation verified both ways before arming: extras margin 11.23, back on the
# menu margin 11.60, against the discriminator's 9.9-11.7 control band. And the
# run announced its effective configuration -- "branch taken = menu2extras: back
# on the MENU with focus restored -> press (A)" -- which is the guard added after
# the previous run silently took the wrong branch.
#
# frames 42-46 outgoing quad 51, 102, 153, [45 absent], 255 -- 5 frames,
# matching build 5's declared close of 10 units = 5 frames
# frame 49 EMPTY: 3 draws, 0 textured
# frames 51+ EXTRAS building
#
# ⚠️ Frames 48 and 50 carry no `--- frame` header at all, so the gap is ONE logged
# empty frame with two unlogged neighbours. Quoted as 1, not silently rounded to 3.
#
################################################################################
# ALL FIVE, ORDERED BY OUTGOING SCREEN -- which is the first thing that orders them
#
# transition black gap outgoing outgoing close (disc)
# menu -> title (B) 0 menu (build 5) 10 units = 5 frames
# menu -> EXTRAS (A) 1 menu (build 5) 10 units = 5 frames
# EXTRAS -> menu (B) 2 EXTRAS (build 6) 10 units = 5 frames
# title -> menu (A) x3 3, 3, 3 title (build 4) 8 units = 4 frames
#
# 🟡 THE GAP TRACKS THE OUTGOING SCREEN, not the direction and not the button: the
# two transitions leaving the MENU give 0 and 1, the one leaving EXTRAS gives 2,
# and the three leaving the TITLE give 3 every time. Direction is ruled out --
# EXTRAS->menu (2) and menu->EXTRAS (1) are the same pair in both directions and
# differ; button is ruled out -- (B) gives 0 and 2, (A) gives 1 and 3.
#
# 🔴 BUT THAT IS NOT YET A RULE. With three outgoing screens and one value each
# (bar the title's three), "each outgoing screen has its own gap" only restates
# the data; a rule would PREDICT. And nothing declared does: the outgoing close is
# 5, 5, 5, 4 frames against gaps 0/1, 2, 3 -- if anything inverted, on three
# points. Recorded as a narrowing of WHERE to look, not as a rule.