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

port: withdraw 'the boot is known too fast' -- the splash dwells are declared and the port already played them

Browse Source 
The Decoder measured both splashes over 3 cold boots: publisher t=0..255,
developer t=0..210, the developer agreeing with wall clock to 1.1%. The port
emits each declared value plus the 9-unit black hold, exactly. No code change.

My error was the generalisation, not the arithmetic: build 4 is the title, whose
exit is caused from outside its timeline, so it holds; a splash's exit is caused
by nothing, so it plays out. I used the one boot screen the port is unaffected
by to overturn the two it governs. Declining to scale by 9x while adopting the
conclusion that implied was half a caution.

Also refutes their two splash boundaries as not comparably anchored: 2.237 vs
2.414 units/frame in one boot, and the publisher has a glow symmetric with the
developer's three.

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-29 21:32:08 +00:00
parent b366e404ee
commit be643ba58a
5 changed files with 153 additions and 79 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
docs/port/BLOCKED.md
View File

@@ -431,31 +431,21 @@ without it, against a measured order. See `DECISIONS.md`.
---
## The two splash dwells, now known-wrong rather than merely unmeasured
## ~~The two splash dwells~~ — ✅ answered 2026-08-29, and the row was my over-correction
*Derived from HANDOFF `9ca1eb5`. Raised 2026-08-29 by the Decoder's clock-freeze
measurement on build 4.*
*Derived from HANDOFF `9ca1eb5`. Closed by the Decoder over 3 cold boots.*
The port advances from `publisher_logo` and `developer_logos` **the instant each
group settles** — t=235 (3.92 s) and t=190 (3.17 s). That was filed as "the
disc's own pacing". It is not: on the one screen anybody has measured, the game
held for roughly **nine times** the declared timeline, because the top-level
clock stops at the settle window and waits for something to make the screen
leave.
**The dwells are declared on the disc** — publisher t=0…255, developer t=0…210 —
and the port was **already playing them**, each plus the 9-unit black hold, to
4.400 s and 3.650 s. The developer's declared value agrees with wall clock to
**1.1 %**.
⚠️ This does **not** license scaling the splashes by nine. Build 4 is the title,
and there is no reason a title's wait and a logo splash's wait are the same
quantity — the title's is plausibly "until the attract timer fires", which no
splash has. **A ratio measured on one screen is not a unit of pacing.**
🔴 So this row should never have been filed. I generalised build 4's ~9× hold
onto two screens it does not govern: the title's exit is caused from outside its
timeline, a splash's is caused by nothing. See `DECISIONS.md` — the withdrawal is
recorded there rather than only struck here.
What would settle it: **a capture timing the real boot** — wall-clock from the
first frame of the publisher wordmark to the first frame of the developer logos,
and from there to the intro. Two timestamps answer it completely, and it needs no
frame analysis. The numbers go in `authored/flow.json` `dwell`, which has been
sitting empty and correctly shaped for this since P3.
🔴 Bounded by the Decoder's own blocker: a single Ⓐ press on the title faults the
guest in their container, so **menu-side dynamic RE is unavailable there**. The
boot timing above needs no button press and should survive that — three runs in
the same session that pressed nothing all completed — but it is their call
whether it is safe to attempt.
⚠️ And the ask itself was wrong-shaped: I asked for **two wall-clock timestamps**.
The Decoder's own container timed these same dwells 15–20 % long, so a seconds
figure records one emulator's pacing. Anything that ever goes in
`authored/flow.json` `dwell` is in **units**.

75
docs/port/DECISIONS.md
View File

@@ -5167,3 +5167,78 @@ unaffected** — it is the boot's end state and holds indefinitely. The two scre
this actually governs, `publisher_logo` and `developer_logos`, have no measured
dwell at all. The port's boot is **known too fast on both, by an unmeasured
amount**. Nothing here is a number for them.
## 🔴 Withdrawn — "the boot is known too fast". The splash dwells are declared, and the port was already playing them
Last iteration I took the Decoder's build-4 measurement — declared ~120 presented
frames, dwelled ~1 100 — and wrote into three files that the port's boot is
**"known too fast on both splashes, by an unmeasured amount"**. That is
**withdrawn**. It was wrong, and the way it was wrong is the interesting part.
They then measured the splashes directly, over 3 cold boots:
| splash | declared | at 60 units/s | corpus wall clock |
|---|---|---|---|
| publisher (entries 10, 13) | t = 0…**255** | 4.250 s | 4.30 / 4.60 / 4.37 |
| developer (entries 11, 14) | t = 0…**210** | 3.500 s | 3.51 / 3.50 / 3.37 |
The developer agrees to **1.1 %**, two of its three runs to 0.3 %. And the port
emits **4.400 s and 3.650 s** — each declared value plus the 9-unit black hold,
exactly. ✅ **The pacing was right the whole time and no code changes.**
### What I actually did wrong
Not the arithmetic — the generalisation. Build 4 is the **title**, whose exit is
caused by something outside its timeline, so it holds. A splash's exit is caused
by nothing, so it plays its declared timeline and leaves. **The title is the
exception, not the rule.** I had one screen, it was the one screen in the boot the
port is structurally unaffected by, and I used it to overturn the two it governs.
I wrote at the time that a ratio from one screen is not a unit of pacing, and
declined to scale the splashes by nine. That refusal was right and is the only
reason this cost nothing but documentation. But refusing to apply the number
while adopting the *conclusion* it implied was half a caution: I still let one
screen's behaviour rewrite what the port claimed about two others. **The correct
move was to file build 4 as measured and leave the splashes alone**, which is
what the file now says.
### And the unit stays units
🔴 The Decoder's own container timed those same two dwells **15–20 % longer** than
both the declared values and the corpus — same disc, same declared timeline — and
three independent readings of that container's frame rate disagree with each
other. A seconds figure is one emulator's pacing on one run. The declared units
are on the disc. `authored/flow.json` `dwell` therefore takes **units**, and only
for a screen measured to wait beyond its group.
This also retires the "two timestamps would settle it" ask I filed: timestamps
were the wrong thing to author, and the measurement's own result says so.
## Refutation attempt — their two splash boundaries are not anchored the same way
Their draw stream reports *"publisher wordmark frames 6–119"* and *"developer
glows 123, wordmarks 140–209"*. Taking those spans against the declared groups:
| splash | declared units | their frames | units / frame |
|---|---|---|---|
| publisher | 255 | 6…119 = 114 | **2.237** |
| developer | 210 | 123…209 = 87 | **2.414** |
**Within one continuous boot, on one guest, those should be the same number.**
They differ by **7.9 %**, and the discrepancy runs the same direction as the
error split they have open — publisher +4.1 % where the developer is 1.1 %.
The file suggests why, and it is not the guest's clock: **the two boundaries are
anchored on different elements.** The developer span starts at its *glows*; the
publisher span is reported as starting at its *wordmark*. Those are 15 units
apart — every wordmark on both splashes is `alpha > 0` from t=16, every glow from
t=1 — and the publisher **has a glow**, `palogo_sqex_eff`, visible t=1…44,
structurally identical to the developer's three. So either frame 6 is the
publisher's glow and is mislabelled, or the publisher span genuinely starts 15
units later than the developer's and the two are not comparable quantities.
⚠️ I cannot tell which from here — it is their log, and the answer is one grep for
`palogo_sqex_eff` in it. Recording it because a 7.9 % internal inconsistency and
an unexplained 4.1 % error on the same screen are more likely one problem than
two. ⚠️ It also does **not** touch the corpus comparison, which is a separate
instrument (3 cold boots, not this draw log); their 4.1 % may still be real.