Files
Sylpheed/docs
sylph-decoder ac1ee549f3 re: the gap is a property of the ORDERED PAIR -- and the guard verified in a run
Two things in one run, on the screen that motivated both.

First, the effective-config guard I had flagged as "not yet verified" -- leaving a
doubt in my own file, which is the shape sylpheed-port had just caught themselves
in. Verified now:

    arming on       = menu  [screen_id: cannot separate menu/EXTRAS]
    discriminator   = extras  rmse=18.94  (other main_menu 30.09, margin 11.15)

Before the fix this run would have announced "arming on = menu" while armed on
EXTRAS. The ambiguity is visible instead of hidden.

Second, a replicate of the table's weakest cell. Second EXTRAS -> menu: outgoing
quad 229, 255, 255 across frames 29-31, then TWO empty frames at 32 and 33. Gap =
2, identical to the first.

Eight transitions now say something sharper than the outgoing-screen story, which
is superseded a second time:

  title  -> menu    3, 3, 3   n=3   repeats agree
  EXTRAS -> menu    2, 2      n=2   repeats agree
  menu   -> title   0         n=1
  menu   -> EXTRAS  1         n=1
  menu   -> other   1         n=1
  EXTRAS -> other   3         n=1

Every repeated pair is identical -- five replicates, no variation -- and every
differing value comes from a different pair. The same origin gives different
values to different destinations (menu 0 vs 1, EXTRAS 2 vs 3). So the origin
CONSTRAINS the gap and the ORDERED PAIR determines it, reproducibly.

For the port: a constant black_hold_units is excluded and keying on the outgoing
screen is excluded too. Any keyed version must be keyed on the ordered pair, with
a measured value per pair -- six known, two replicated, none predicted by anything
declared.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 19:02:19 +00:00
..