re: the splash dwells run ~8.5 % long, six for six -- a qualification on Q1

sylpheed-port reported verify-dwell at 4.28 s / 3.58 s and called it agreement
with my three cold boots. Checked the arithmetic instead of the impression, and
it is not agreement with the DISC.

  publisher  240 u = 4.000 s at Q1's 60 u/s   measured 4.297/4.604/4.370  mean 4.424
  developer  195 u = 3.250 s                  measured 3.508/3.503/3.366  mean 3.459

All six ratios exceed 1 -- 1.074, 1.151, 1.093, 1.079, 1.078, 1.036, mean 1.085 --
implying 54.3 and 56.4 units/s. The port's own two numbers imply 56.1 and 54.5.
Four estimates, none at 60.

The obvious explanation fails: a detector triggering early and late would lengthen
the interval, but the declared span IS 15->255 and outside it the alpha is 0, so
there is nothing on screen to trigger on. An 8.5 % overshoot is 20 units, ten
rendered frames, which no threshold can manufacture from a blank screen.

Recorded as an open qualification on Q1 rather than a correction: three boots per
screen is thin, and Q1 was measured on a different quantity. It is also NOT the
same discrepancy as the sweep leaf's, which runs ~50 % slow rather than 8.5 %.

For the port: the dwells remain decoded and should still not be authored, but a
port playing 240 units at exactly 60 u/s shows the publisher splash for 0.42 s
less than the game does.

METHOD gains the reusable half of the (A) result, which the port named: a probe
whose observation window is shorter than the effect reports a CLEAN NEGATIVE.
(A) takes 4-6 s; a script that presses and looks 0.5 s later concludes the press
was dropped, with nothing in its log to say otherwise. Check the window against
the latency before believing a null, and sample repeatedly when the latency is
unknown.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

docs/re/METHOD.md

@@ -400,6 +400,15 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   with the number that closed each one; a negative with reach is deliverable, and a
   fit without a residual is not.
 
+* **A probe whose observation window is shorter than the effect reports a clean
+  negative.** Ⓐ on the boot title takes **4–6 s** to reach the menu; a script that
+  presses and looks 0.5 s later sees the title and concludes the press was
+  dropped — with nothing in its log to say otherwise. `sylpheed-port` hit the same
+  shape with a capture that fired before its own script. ⚠️ **Before believing a
+  null, check that the window was wider than the latency you are testing for** —
+  and where the latency is unknown, sample repeatedly rather than once, so a slow
+  effect is distinguishable from no effect.
+
 ## Runtime / emulator
 
 * **Look at the PNG** — and check its dimensions.

docs/re/boot-order-and-splash-dwell.md

@@ -89,6 +89,37 @@ title — [`ui-keyframe-time-unit.md`](ui-keyframe-time-unit.md)).
 ✅ **Classified decoded.** The port reads **240 units** for the publisher and
 **195 units** for the developer and authors nothing.
 
+## 🟡 But the game runs them ~8.5 % LONG, six times out of six
+
+`sylpheed-port` reported their `verify-dwell` at 4.28 s / 3.58 s and called it
+agreement with these boots. Checking the arithmetic rather than the impression:
+
+| | declared | at Q1's 60 u/s | measured (3 cold boots) | ratio |
+|---|---|---|---|---|
+| publisher | 240 u | **4.000 s** | 4.297 / 4.604 / 4.370, mean **4.424** | **1.106** |
+| developer | 195 u | **3.250 s** | 3.508 / 3.503 / 3.366, mean **3.459** | **1.064** |
+
+**All six ratios exceed 1** — 1.074, 1.151, 1.093, 1.079, 1.078, 1.036 — mean
+**1.085**. The implied unit rate is **54.3** and **56.4 units/s**, and the port's
+own two numbers imply **56.1** and **54.5**. Four estimates, none at 60.
+
+⚠️ **The obvious explanation does not work.** A detector triggering early and
+late would lengthen the interval — but the declared span *is* `15 → 255`, and
+outside it the alpha is **0**, so there is nothing on screen to trigger on. An
+8.5 % overshoot is 20 units, ten rendered frames, which a threshold cannot
+manufacture from a blank screen.
+
+🟡 **So this is a real systematic and its cause is not established.** Either the
+title's timeline advances at ~55 units/s rather than Q1's 60, or the boot inserts
+something between the declared span and what a capture sees. ⚠️ It is **not** the
+same discrepancy as the sweep leaf's (which runs ~50 % slow, not 8.5 %), and I am
+recording it as an open qualification on Q1 rather than a correction to it — three
+boots per screen is thin, and Q1 was measured on a different quantity.
+
+📌 **For the port:** these dwells are still *decoded* and still should not be
+authored — but a port that plays 240 units at exactly 60 u/s will show the
+publisher splash for **0.42 s less** than the game does.
+
 ⚠️ **Reach of the ±:** a correlation crossing a threshold during a fade is not a
 sharp edge, so an individual span is good to roughly ±0.2 s. The developer's
 first two runs agree to **5 ms**, which is the instrument at its best; run 2's