docs/re/guest-frame-rate-WITHDRAWN.md

@@ -105,3 +105,50 @@ once per present or once per two. The splash alpha data needed for that is in th
 **Nothing yet, and I have told them so.** Their 60 is no longer *supported* by me,
 but it is not *refuted* either — one route favours 120 and another favours 56. A
 port that changes on this page would be acting on my second guess in one day.
+
+## Refutation attempt on the port's independent constraint — it does NOT exclude 120
+
+The port offers a bracket as its stated reason for keeping 60: the transition quad
+is **declared black for 12 units**, the capture measured that plateau at
+**0.14–0.30 s**, so `12 / 0.30 … 12 / 0.14` = **40–86 units/s** — 60 inside, 120
+outside. They call it frame-free and note it survives everything retired here.
+
+**Frame-free it is. Independent it is not, and the exclusion does not hold. Two
+reasons, either one sufficient.**
+
+### 1 — the low end sits ON the instrument's floor
+
+`title-plate-delay-measured.md` says of that very number, in its own words:
+
+> *"Consistent, at a sampling resolution (**0.125 s**) that cannot do better."*
+
+A 0.125 s sampler cannot report an event shorter than about one sample. **0.14 s
+is one sample.** So the observed low end is not a measurement of the event — it is
+the floor, and every true duration from ~0 to ~0.14 s produces it.
+
+At 120 units/s, 12 units is **0.100 s**. Sampled at 0.125 s that is observed as
+one sample and reported as ≈0.14 s — **exactly the low end that was read as
+excluding it.** The bracket's upper limit of 86 units/s is an artefact of dividing
+by a floored duration.
+
+### 2 — a wall-clock duration off this emulator is not independent of the unknown
+
+Every duration measured off Canary is `true_guest_duration / speed_factor`, so
+apparent units/s = true units/s × speed. **The speed factor is the exact unknown
+that makes all three routes disagree in the first place**, and a constraint built
+on a wall clock inherits it rather than escaping it. The bracket says "if Canary
+ran at real time, units/s is 40–86" — and whether it did is the question.
+
+### What survives, and it is worth keeping
+
+The *declared* side is solid and is a disc fact: the transition opens over
+**12 units**, and `screen-transitions.md` independently confirms it as **6 frames**
+(`255/6 per frame after a half-step start`), which is the already-✅ 2 units per
+frame. **That leg has no wall clock in it at all** and is real evidence — for
+units per *frame*, which was never in dispute. It says nothing about units per
+second.
+
+⚠️ **So the port is keeping 60 for a reason that does not support it.** I have told
+them so. That does not mean they should change it — nothing supports 120 either,
+and my position is unchanged: the value is authored, not measured, until the
+content-hash experiment runs.