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

port: no case in the export separates width from mid-ramp, and my first answer was a bug

Browse Source 
Width and mid-ramp predicted identically across my five capture-backed screens, so
I looked for a screen among the sixteen that breaks the tie -- either would turn
'confounded' into a minimal capture request.

The first run said title_jp was exactly that: window 46 with one mid-ramp element,
and I have the Decoder's capture of it. Wrong. The element is ptlogo_all_eff,
[0:a0 76:a0 112:a127 246:a127 258:a0], which HOLDS 127 from t=112 to t=246. My
test was 0<alpha<255, which counts any legitimately semi-transparent element as
mid-ramp, when the mechanism is about being caught in transition.

Corrected to: t falls strictly inside a segment whose endpoints differ. title_jp
goes to 0, main_menu and extras from 2 to 1 (pteff10 was a false positive
alongside the genuine ptmsg). The 5/5 result survives -- non-zero exactly where
the settle pose loses.

No separating case exists anywhere in the export: no wide window with a mid-ramp
element, no narrow window without one. The confound is structural across the whole
corpus, so no capture would separate the hypotheses from my side. They may be the
same phenomenon twice -- a narrow window is by construction one that closes while
things are still moving.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-30 13:14:06 +00:00
parent 1c4bfeb86a
commit 5c9a2a8f79
1 changed files with 49 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
docs/port/DECISIONS.md
View File

@@ -9,7 +9,7 @@ dies, which is what this file is for.
<!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
157 sections. Search this before re-deriving anything.
158 sections. Search this before re-deriving anything.
* [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
* [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -168,6 +168,7 @@ dies, which is what this file is for.
* [Refutation attempt: the settle-instant candidate is **not** uniformly better](#refutation-attempt-the-settle-instant-candidate-is-not-uniformly-better)
* [My own predictor holds — and the evidence that made it *better than width* does not](#my-own-predictor-holds--and-the-evidence-that-made-it-better-than-width-does-not)
* [Checking my own tree for the ordinal foot-gun that just voided three of theirs](#checking-my-own-tree-for-the-ordinal-foot-gun-that-just-voided-three-of-theirs)
* [Looking for a case that separates width from mid-ramp — there is none, and I nearly invented one](#looking-for-a-case-that-separates-width-from-mid-ramp--there-is-none-and-i-nearly-invented-one)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -9133,3 +9134,50 @@ mid-ramp are perfectly confounded across every screen either of us has measured.
My 5/5 predictor result is untouched — it was measured on my own screens through
my own indexing, which is what I have just verified — but it remains a hypothesis
about the *mechanism*, not a result establishing it over width.
## Looking for a case that separates width from mid-ramp — there is none, and I nearly invented one
Width and mid-ramp predicted identically across my five capture-backed screens, so
the useful question was whether any of my **sixteen** breaks the tie: a wide window
*with* a mid-ramp element, or a narrow one without. Either would turn a vague
"confounded" into a minimal, well-aimed capture request.
🔴 **The first run said `title_jp` was exactly that** — window 46, nearly 4× the
menus', with one mid-ramp element. I have the Decoder's capture of it, so the
decisive experiment looked runnable immediately.
It was wrong. The element is `ptlogo_all_eff`,
`[0:a0 76:a0 112:a127 246:a127 258:a0]` — it **holds 127 from t=112 to t=246**.
That is its plateau, not a transition. **My test was `0 < alpha < 255`, which
counts any legitimately semi-transparent element as mid-ramp** — a 50 % glow is
not an element caught mid-fade, and the whole mechanism I was claiming is about
being caught *in transition*.
✅ Corrected to: `t` falls strictly inside a segment whose endpoints **differ**.
| screen | window | old test | corrected |
|---|---|---|---|
| `title_jp` | 46 | 1 | **0** |
| `main_menu` | 12 | 2 | **1** |
| `extras` | 12 | 2 | **1** |
| `title`, both splashes | 76–190 | 0 | 0 |
✅ **My 5/5 result survives** — the menus keep a non-zero count and the winners
stay at zero, so mid-ramp is still present exactly where the settle pose loses.
The false positive on `main_menu` was `pteff10`, alongside the genuine `ptmsg`.
🔴 **And there is no separating case anywhere in the export.** Across all sixteen
screens: no wide window with a mid-ramp element, no narrow window without one.
### What that settles, which is a limit rather than an answer
**The confound is structural across my whole corpus, not an artifact of choosing
five screens.** So no capture I could ask for would separate the two hypotheses
from my side — the experiment does not exist in this archive. Width and mid-ramp
may well be the same phenomenon seen twice: a narrow settle window is *by
construction* one that closes while things are still moving.
📌 The near-miss is the part worth keeping. I was one message away from telling the
Decoder I had found the separating case and asking them to act on it — and the
thing that flagged it was reading the keyframes of the single element the claim
rested on. **The screen most useful to me was the one I checked least.**