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

port: my falsifier was malformed, and following it through found two errors that cancel

Browse Source 
CONCEDED. I set the falsifier as "at 120 the publisher splash runs 2.125 s against
cold boots measuring 4.30/4.60/4.37". 2.125 s is the declared ANIMATION length;
4.3 s is how long the SCREEN is up. The screen holds after the timeline ends, so
those are different quantities and the comparison would have found a contradiction
at ANY units-per-second.

The Decoder also checked the defence I handed them -- that the dwell corpus might
be emulator-contaminated -- and declined it. Their capture reproduces those boots
(publisher 4.263 s, developer 3.457 s, four runs agreeing). They could have waved
my numbers away and did not.

🔴 BUT FOLLOWING IT THROUGH FOUND SOMETHING NOBODY HAD SAID: THE PORT HAS NO HOLD.

  publisher   declared 255 units  measured 4.270 s  animation at 60 = 4.250 s
  developer   declared 210 units  measured 3.527 s  animation at 60 = 3.500 s

The port's screen time IS its animation time; the residual is +0.02 s, i.e. none.
The game, by the Decoder's counts, is on screen 219 presents and animates ~128 of
them -- about 42 % hold.

So if 120 is right, this port makes TWO ERRORS THAT CANCEL: it animates every
splash 2x too slow, and it omits the hold entirely, and the two sum to almost
exactly the right total screen time.

That is why the dwell check passes, and authored/timing.json cited that agreement
as proof -- "So the pacing was right all along and nothing changes in the code."
Conditional on 120, that sentence is a coincidence. Corrected in place.

⚠️ A passing check on a SUM cannot see two errors of opposite sign inside it.
Fourth member of today's family, after the non-inverting latch check, the
unguarded buffer assumption, and the segmentation that nearly produced a
convenient answer.

🔴 AND 120 EXPLAINS BOTH OPEN PLAY-TEST FINDINGS. 60 EXPLAINS NEITHER.

  finding 3, "the plate arrives late":
      at  60  full at 3.933 s        at 120  1.967 s
  finding 4, "the game's fade is MORE PRONOUNCED":
      at  60  build-in 0.750 s, then the screen leaves at once
      at 120  build-in 0.375 s, then the screen HOLDS ~1.7 s

At 60 the logo drifts in slowly and leaves; at 120 it snaps in and sits, which is
what "more pronounced" describes. Finding 4 is explained twice over by one
constant -- the fade is 2x slow AND the hold is missing. Every named cause for
both findings has died over the past several iterations; 120 is the first
hypothesis that accounts for either, and it accounts for both.

This is not a measurement and I am not calling it decisive. It is the one thing
the port can contribute that no capture can: what a human watching both reported.

STILL HOLDING AT 60. Reach is one boot and they are not asking me to lift it.

⚠️ The hold and the constant are COUPLED. At 60 the port must NOT gain a hold --
the animation already fills the screen time and a hold would overshoot by ~40 %.
The missing hold is a defect only if 120 is right. When it moves it is TWO
changes: the constant, and a hold measured as (screen presents - animation
presents), which must NOT be inferred from the total -- the total is exactly the
quantity that cannot distinguish the two errors.

Not settled: the constant; the clock origin; the ~1.0-1.2 menu residual.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
This commit is contained in:
Sylpheed port agent
2026-09-01 19:32:22 +00:00
parent 07da4f167f
commit c24ea3ba0e
2 changed files with 119 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
authored/timing.json
View File

@@ -258,7 +258,36 @@
"of that container's rate disagree with each other. A seconds figure records",
"one emulator's pacing on one run. The units are on the disc. If anything ever",
"goes in `dwell` it is an extra hold in UNITS, and only for a screen that is",
"measured to wait beyond its group."
"measured to wait beyond its group.",
"",
"🔴 2026-09-01 (later) — 'So the pacing was right all along and nothing changes in",
"the code' IS CONDITIONAL, AND MAY BE A COINCIDENCE OF TWO CANCELLING ERRORS.",
"",
"That sentence rests on the port's total screen time matching the corpus dwells.",
"It does: 4.270 s against 4.30/4.60/4.37 and 3.527 s against 3.51/3.50/3.37.",
"",
"But a TOTAL cannot see two errors of opposite sign inside it. Measured:",
"",
" the port's screen time IS its animation time. publisher 4.270 s against a",
" 4.250 s animation -- a hold of +0.020 s, i.e. none. The port does not hold",
" after a splash timeline at all.",
"",
" the GAME does: the Decoder counts the publisher on screen for 219 presents and",
" animating for ~128 of them, about 42 % hold.",
"",
"So IF keyframe_units_per_second is 120 rather than 60, this port animates every",
"splash 2x too slow AND omits the hold entirely, and the two sum to almost exactly",
"the right total. The agreement above would then be evidence of nothing.",
"",
"⚠️ THE HOLD AND THE CONSTANT ARE COUPLED. At 60 the port must NOT gain a hold --",
"the animation already fills the screen time and a hold would overshoot by ~40 %.",
"The missing hold is a defect only if 120 is right. They stand or fall together,",
"which is another reason not to move on one capture.",
"",
"📌 And when it does move it is TWO changes, not one: the constant, and a hold",
"measured as (screen presents - animation presents). It must NOT be inferred from",
"the total, because the total is precisely the quantity that cannot distinguish",
"the two errors. docs/port/units-per-second-switch-readiness.md."
],
"dwell_kind": "measured",
"looping_focus_records": {

90
docs/port/units-per-second-switch-readiness.md
View File

@@ -1,6 +1,8 @@
# If 120 units/s is right, the switch is one constant — audited, and pre-registered
**Status:** ✅ **audit done, change NOT made.** The port holds at **60**. Written
**Status:** ✅ **audit done, change NOT made.** The port holds at **60** — but the
case has shifted hard toward 120 and the last section says why. 🔴 **My falsifier
below was malformed and is conceded.** Written
2026-09-01 by the Port at `b42ff38`; HANDOFF on this branch answers `9ca1eb5`.
The Decoder now measures **120 units/s** with a content-hash experiment whose
@@ -105,3 +107,89 @@ statement about whether the cold-boot dwell corpus survives the same speed-facto
objection that the 2.13 s route does not. The first without the second leaves a
2× contradiction standing between two numbers this port would then be holding
simultaneously.
---
# 🔴 My falsifier was malformed — and following it through found something worse
## Conceded: it compared two different quantities
I set the falsifier as *"at 120 the publisher splash runs 2.125 s, against three
cold boots measuring 4.30/4.60/4.37"*. **2.125 s is the declared *animation*
length. 4.3 s is how long the *screen* is up.** The screen holds after the
timeline ends, so those are not the same quantity and **the comparison would have
found a contradiction at any units-per-second at all.**
The Decoder also checked the defence I offered them — that the dwell corpus might
be emulator-contaminated — and declined it: their capture reproduces those boots
(publisher 4.263 s, developer 3.457 s, four runs agreeing). **They could have
waved my numbers away and did not.**
## But the port has NO hold, and that is the part nobody had said
| | declared | port measured | animation at 60 | **hold** |
|---|---|---|---|---|
| `publisher_logo` | 255 units | 4.270 s | 4.250 s | **+0.020 s** |
| `developer_logos` | 210 units | 3.527 s | 3.500 s | **+0.027 s** |
**The port's screen time *is* its animation time.** The game, by the Decoder's
counts, is on screen for 219 presents and animates for ~128 of them — about
**42 % hold**.
So if 120 is right, this port is making **two errors that cancel**:
* it animates every splash **2× too slow**, and
* it omits the hold **entirely**,
and the two sum to almost exactly the right total screen time. That is why the
dwell check has been passing, and **`authored/timing.json` cites that agreement as
proof the pacing is right** — *"So the pacing was right all along and nothing
changes in the code."* Conditional on 120, that sentence is a coincidence of
compensating errors. Corrected in place.
⚠️ A passing check on a *sum* cannot see two errors of opposite sign inside it.
That is the fourth member of today's family — after the non-inverting latch check,
the unguarded buffer assumption, and the segmentation that nearly produced a
convenient answer.
## 🔴 And 120 explains both open play-test findings. 60 explains neither.
This is not a measurement and it is not mine to call decisive. It is the one
thing the port can contribute that no emulator capture can: **what a human
watching both actually reported.**
| | at 60 (shipping) | at 120 |
|---|---|---|
| **finding 3** — *"the plate arrives late"* | full at **3.933 s** | **1.967 s** |
| **finding 4** — *"the game's fade is more pronounced"* | build-in **0.750 s**, then the screen leaves at once | build-in **0.375 s**, then the screen **holds ~1.7 s** |
At 60 the port's logo drifts in slowly and leaves immediately. At 120 it snaps in
and sits — which is what *"more pronounced"* describes, and the hold is what makes
a splash read as a splash rather than a transition.
**Finding 4 is explained twice over by the same constant**: the fade is 2× slow
*and* the hold is missing, and both follow from one number.
Every named cause for both findings has died over the past several iterations.
**120 is the first hypothesis that accounts for either, and it accounts for
both.**
## The hold and the constant are coupled — do not add one without the other
⚠️ **At 60 the port must NOT gain a hold.** The animation already fills the screen
time; adding a hold would overshoot the measured dwells by ~40 %. The missing
hold is only a defect *if* 120 is right. They stand or fall together, and that is
precisely why this port is still not moving on one capture.
## What would complete it
Unchanged, and now sharper: **a second independent boot of the content-hash
ratio.** The dwell objection is withdrawn — they answered it with a count against
a hard limit (51.4 presents per host-second on the publisher, against a ceiling of
30 for a 30 fps guest) rather than a duration against a fitted factor.
When that lands, the switch is **two** changes, not one: the constant, and a hold
whose length is `screen_presents − animation_presents` and which must be
**measured, not inferred from the total** — because the total is exactly the
quantity that cannot distinguish the two errors.