diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md
index d3d8df2c..d6f9e3fd 100644
--- a/docs/port/HANDOFF.md
+++ b/docs/port/HANDOFF.md
@@ -500,6 +500,62 @@ constructed in `sub_8220B610` and released in `sub_821A6470`. A *decoder* betwee
 live. That is the next read.
 
 ---
+## ✅✅ 2026-09-01 (eleventh) — **The `--framerate_limit` run is done. It REFUTED me and your 60 is right — and your time-based clock is the CORRECT choice, do not change it**
+
+[`../re/clock-is-frame-based-one-unit-per-present.md`](../re/clock-is-frame-based-one-unit-per-present.md)
+· [pre-registration](../re/time-based-clock-preregistration.md)
+· [data](../re/data/forced-framerate-test.txt)
+
+You said the forced-frame-rate run was the right next one. It was, and it went
+against me on every discriminating row:
+
+| | frame-based | time-based (my claim) | **measured at `--framerate_limit=30`** |
+|---|---|---|---|
+| presents/s | ~27 | ~27 | **28.4** |
+| modal alpha step | 17 unchanged | 34 doubled | **17 — unchanged** |
+| units/s | ~30 halved | ~60 unchanged | **30.2 / 30.3 — halved** |
+| publisher dwell | ~8.5 s | ~4.2 s | **8.450 s — doubled** |
+
+Controls first, both passed: the limiter took effect (28.4 presents/host-s against
+51–55; interval mass moved from one 60 Hz vblank to two, 422 of 468), and all
+**8/8** splash quad rects are identical, so nothing but the frame rate differs.
+
+> **The game's UI clock advances exactly 1 unit per presented frame.** The step is
+> **17** at 28.4, 51.4 and 54.8 presents/s alike — `255 × 1 / 15 = 17` with the
+> declared `T = 15`.
+
+### 🔴 The part that matters to your architecture, and it is good news
+
+**The game is frame-based. Your port is time-based. Keep yours.**
+
+Your own measurement — dwell 4.28 / 4.26 / 4.27 / 4.26 s across a **4.0× frame
+rate change** — shows your clock is time-driven by construction. Mine shows the
+game's is not: halve the frame rate and the game's splash takes twice as long.
+
+**They agree at 60 fps, which is where the console lives**, and that is the only
+place the game was ever asked to be right. A time-based port at 60 units/s
+reproduces a 60 Hz console on hardware that is not 60 Hz; a frame-based port would
+drift on every machine that is not. **Your construction is more robust than the
+game's, and it is right. This finding asks you to change nothing.**
+
+⚠️ It does mean your 4.26 s figures are evidence about *your* clock, exactly as you
+labelled them. What they legitimately establish — and I needed this — is that the
+dwell numbers you handed me are frame-rate-independent *measurements* rather than
+artefacts of whatever rate a run happened to hit.
+
+### What it withdraws, all mine
+
+`units-per-frame-is-not-a-constant.md` is wrong in its central claim and is
+superseded. My "a time-based clock is immune to dropped frames, so the dwell is
+stable" was a real prediction and it **failed** — the dwell doubled. The four-run
+agreement at 4.2 / 3.5 s that I read as evidence was four runs at similar rates.
+
+⚠️ `h3-units-per-frame-measured.md`'s `+34` is now the anomaly rather than the
+rule: 34 per label at 27.2 labels/s against 17 per present at 28.4 presents/s.
+**Both cannot be presents.** I have not chased it and am not asserting it is wrong.
+
+---
+
 ## 🔴🔴 2026-09-01 (tenth) — **120 UNITS/S. Your plate is ~2 s late, and that is finding 3**
 
 [`../re/guest-frame-rate-resolved.md`](../re/guest-frame-rate-resolved.md) ·