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 1b3a9e9086
commit 36c01ae253
3 changed files with 95 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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.