diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index 3ad8fbec..427311cc 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -9,7 +9,7 @@ dies, which is what this file is for. -190 sections. Search this before re-deriving anything. +191 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) @@ -201,6 +201,7 @@ dies, which is what this file is for. * [The leaf thread, closed — one export value verified against the game, one self-check abandoned](#the-leaf-thread-closed--one-export-value-verified-against-the-game-one-self-check-abandoned) * [Delivering the phase term where the numbers are, not where I found them](#delivering-the-phase-term-where-the-numbers-are-not-where-i-found-them) * [The boot verified as a *sequence*, not just at its endpoint](#the-boot-verified-as-a-sequence-not-just-at-its-endpoint) +* [Refuting the "8.5 % systematic" in the splash dwells — it is the span, not the clock](#refuting-the-85--systematic-in-the-splash-dwells--it-is-the-span-not-the-clock) ## P0 — the exporter, 2026-08-28 @@ -10777,3 +10778,49 @@ route. And the 144.76 s video is unexamined beyond playing. "has now been wrong in two opposite directions". **That is at least the fourth time this session the answer was already written down** — but this time reading it cost one command, because I looked before concluding rather than after. + +## Refuting the "8.5 % systematic" in the splash dwells — it is the span, not the clock + +They challenged my dwell agreement: declared spans **240 u** and **195 u** at +Q1's 60 u/s give 4.000 s and 3.250 s, against six cold-boot measurements whose +ratios all exceed 1 (mean **1.085**), implying 54–56 units/s rather than 60. And +pointedly: *"240 units at exactly 60 should give you 4.000 and you're reporting +4.28."* + +🔴 **The port does not play 240 units.** Their 240 is the *visible* span — the logo +element's 15→255. The port plays the **whole group from t=0**, and my export gives +the full spans as **255** and **210** units, i.e. **4.250 s** and **3.500 s**. My +observed 4.28 and 3.58 are those plus a frame or two of transition overhead, not +an 8.5 % overshoot of anything. + +Recomputed against the interval the port actually plays: + +| | their ratios (vs 240/195) | recomputed (vs 255/210) | +|---|---|---| +| publisher | 1.074, 1.151, 1.093 | 1.011, 1.083, **1.028** | +| developer | 1.079, 1.078, 1.036 | 1.002, 1.001, **0.962** | +| mean | **1.085** | **1.0145** | +| below unity | 0 of 6 | **1 of 6** | + +✅ **The systematic largely dissolves.** A mean deviation of 1.5 % with one +measurement below unity is not a clock running at 54 u/s; it is six numbers +scattered around a declared duration. + +⚠️ **And the practical consequence they drew does not follow.** *"A port playing +240 units at 60 u/s shows the publisher splash 0.42 s less than the game."* The +port plays 255 units, so the gap is **0.174 s** — and on `developer_logos` the +port is **0.041 s longer** than the oracle mean, the opposite sign. There is no +direction to correct in. + +📌 **Same family as the three we have already catalogued** — a pivot anchor read +as a drawn extent, a centre track read as a bounding box, a cycle length read as a +motion duration. Here: **a visible span read as a played span.** Fourth instance, +and the first where the misread number was mine to supply and I had not stated +which span my port plays. + +🟡 **What survives, and I would not want it lost in the refutation.** Against the +full group the publisher screen still runs long in two of three boots (1.011, +1.083, 1.028) while the developer screen sits at 1.002, 1.001, 0.962. That is a +much weaker signal than 8.5 % and it is not nothing. Three boots per screen is +thin — their own caveat — and it does not support a change to +`keyframe_units_per_second`, which stays where Q1 put it.