re: WITHDRAW the 8.5 % dwell systematic -- I measured one element, not the screen

sylpheed-port said the port plays the full group (255 and 210 units) rather than
my 240/195, and they are right for a reason sharper than either of us first had.
The _eff elements ramp alpha 0 -> 255 over t=0..15 while the main logo is still
fully transparent:

  palogo_sqex.t32      0:a=0  15:a=0    30:a=255  ... 255:a=0
  palogo_sqex_eff.t32  0:a=0  15:a=255  30:a=212  45:a=0

So the SCREEN is visible from within t=0..15 and its visible span is the full
group. My "240 units visible" was ONE ELEMENT's visible span, computed while
another element of the same build was already on screen -- which is exactly the
error class I was writing up when I made it.

Recomputed against the screen: publisher 1.011/1.083/1.028, developer
1.002/1.001/0.962, mean 1.0146 with one measurement BELOW unity, against my
1.085 with none below. That is not a clock at 54 u/s. The systematic is gone and
Q1 stands unqualified.

The consequence was wrong too: "a port playing 240 units at 60 shows the splash
0.42 s less" -- it plays 255, so the gap is 0.174 s, and on the developer splash
the port runs longer than my mean. No direction to correct in.

What survives weakly: against the full group the publisher runs long in all three
boots while the developer sits at unity. Three boots per screen is thin and it is
not a systematic.

METHOD: state the number, and state what it is a number OF. Four instances of
this family now -- pivot anchor as extent, centre track as bounding box, cycle
length as motion duration, one element's visible span as the screen's -- and two
of the four arose because the PUBLISHER of the number never said what it spanned.
The reader reasoned correctly from the only definition available each time.
Publishing a quantity's extent in the same breath is cheaper than every check in
that file.

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

docs/re/METHOD.md

@@ -409,6 +409,21 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   and where the latency is unknown, sample repeatedly rather than once, so a slow
   effect is distinguishable from no effect.
 
+* 📌 **State the number, and state what it is a number OF.** This corpus has now
+  produced four instances of one family, and they cost more than any other class of
+  error here: a **pivot anchor** read as a drawn extent (a zero measured where
+  nothing moves), a **centre track** read as a bounding box, a **cycle length** read
+  as a motion duration (a rate 10 % wrong), and **one element's visible span** read
+  as the screen's (an 8.5 % "systematic" that did not exist). ⚠️ Two of the four
+  arose because the *publisher* of the number never said what it spanned —
+  `sylpheed-port` quoted a dwell of 4.28 s across two messages without once saying
+  which span it covered, and I quoted 240 units without saying it was one element's.
+  Each time the reader reasoned correctly from the only definition available.
+  **The fix is cheaper than every check in this file: when you publish a quantity,
+  publish its extent in the same breath.** It is the same shape as an observation
+  window shorter than the effect — a mismatch between what you are looking at and
+  what you believe you are looking at.
+
 ## Runtime / emulator
 
 * **Look at the PNG** — and check its dimensions.

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

@@ -89,7 +89,46 @@ 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
+## 🔴 WITHDRAWN — "the game runs them ~8.5 % long". I measured one element's span and called it the screen's.
+
+**Retracted the same day.** `sylpheed-port` said the port plays the **full group**
+— 255 and 210 units — not my 240/195, and they are right for a reason sharper than
+either of us first had. The `_eff` elements ramp **α 0 → 255 over t=0..15**, while
+the main logo is still fully transparent there:
+
+```
+palogo_sqex.t32      0:a=0   15:a=0    30:a=255  235:a=255 239:a=232 251:a=32 255:a=0
+palogo_sqex_eff.t32  0:a=0   15:a=255  30:a=212   45:a=0
+```
+
+So **the screen is visible from within t=0..15**, and its visible span is 0→255
+and 0→210 — the full group. My "240 units visible" was **one element's** visible
+span, computed while another element of the same build was already on screen.
+
+Recomputed against the screen:
+
+| | ratios | |
+|---|---|---|
+| publisher (255 u = 4.250 s) | 1.011, 1.083, 1.028 | |
+| developer (210 u = 3.500 s) | 1.002, 1.001, **0.962** | one **below** unity |
+| **mean** | **1.0145** | against 1.085 before |
+
+A 1.5 % mean with a measurement below unity is not a clock running at 54 u/s.
+**The systematic is gone and Q1 stands unqualified.**
+
+⚠️ **And the consequence I drew was wrong too.** "A port playing 240 units at 60
+shows the publisher splash 0.42 s less" — it plays 255, so the gap is 0.174 s, and
+on the developer splash the port runs *longer* than my mean. There is no direction
+to correct in, and nothing here supports moving `keyframe_units_per_second`.
+
+🟡 **What survives, weakly:** against the full group the publisher still runs long
+in all three boots (1.011, 1.083, 1.028) while the developer sits at unity. Three
+boots per screen is thin and it is not a systematic.
+
+📌 **This is the fourth instance of one family** — pivot anchor read as drawn
+extent, centre track as bounding box, cycle length as motion duration, and now
+**one element's visible span read as the screen's**. Every one is a number used as
+though it described the thing beside it.
 
 `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: