re: the title presents at 28.5 fps idle -- the keyframe unit is settled at

1/60 s, and the 60 Hz reading is excluded

ui-keyframe-time-unit.md named its own re-test and nobody had run it: time
300 submitted frames on the IDLE title, where nothing is streaming from
the ISO. Reaching the title is cheap now that one A skips the intro, so
this cost one boot.

Two clean trials: 300 frames in 10.40 s and 10.60 s, i.e. 28.8 and 28.3
fps. That is the same rate as the 27.6 fps measured during the loading
splash, which is exactly the page's own criterion for "the game is 30 Hz
and the unit is 1/60 s". The 60 Hz alternative is now excluded rather
than disfavoured: it needs the emulator at 47% of real time while sitting
idle on a screen the capture says costs 1526 draws over 300 frames, about
five per frame. Nothing there halves an emulator.

So the durations stand as written -- title 4.2 s, main menu 1.1 s, EXTRAS
0.87 s -- and Q1 leaves the handoff's open-residue table. It stays
MEASURED, not decoded: no field on the disc says sixtieths of a second.

One trap, and it nearly cost the conclusion. My first attempt reported
39.5 fps, which sits between the two hypotheses and would have left the
question open. It was a harness bug: I polled the log for a "done" line
rather than for the COUNT of them increasing, so it matched a capture
that had already completed and timed 0.1 s of nothing. METHOD gets the
general form -- a log-polling probe must compare a count, not test for
presence.

docs/re/METHOD.md

@@ -184,3 +184,9 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   XACT string at all. The names came from the authoring tool and survived into the
   shipped data. Check for the magic before committing to a parser for the format
   the extension advertises.
+* **A log-polling probe must compare a COUNT, not test for presence.** Timing an
+  operation by waiting for its "done" line in a log gives an instant false
+  positive if any earlier run left one there. This produced a confident
+  "39.5 fps" that was really 0.1 s of matching a stale line — and it disagreed
+  with the true 28.5 fps by enough to have flipped a conclusion. Snapshot
+  `log.count(marker)` before starting and wait for it to *increase*.

docs/re/ui-keyframe-time-unit.md

@@ -109,14 +109,46 @@ fit are:
 t = 16 … 269) is then **4.2 s**, and the main menu build (build 5, t = 12 … 80)
 **1.1 s**.
 
-**The reach of this negative:** the present rate was measured *during the boot
-splash*, where the guest is also streaming from the ISO, so it is a lower bound on
-the emulator's speed and cannot by itself exclude the 60 Hz reading. What would
-settle it is the same 300-frame timing taken on the **idle title screen**, where
-nothing is loading — if that also comes out near 28 fps the game is 30 Hz and the
-unit is 1/60 s; if it doubles to ~55 fps the game is 60 Hz and every duration on
-this page halves. Until then the port should treat **2 units per rendered frame**
-as the measured fact and `1/60 s` as the working conversion.
+**The reach of this negative** *(as written before the test below — kept for the
+reasoning)*: the present rate was measured *during the boot splash*, where the
+guest is also streaming from the ISO, so it is a lower bound on the emulator's
+speed and cannot by itself exclude the 60 Hz reading. What would settle it is the
+same 300-frame timing taken on the **idle title screen**, where nothing is
+loading — if that also comes out near 28 fps the game is 30 Hz and the unit is
+1/60 s; if it doubles to ~55 fps the game is 60 Hz and every duration on this page
+halves.
+
+## ✅ That test was run — 2026-08-28. The game is 30 Hz; `1 unit = 1/60 s`
+
+Reached the title with a single Ⓐ to skip the intro
+([`movie-binding.md`](movie-binding.md)), let it settle 12 s so nothing was
+loading, then armed the bounded 300-frame capture and timed it to its own
+`[UI-CAP] done` line:
+
+| | 300 frames in | rate |
+|---|---|---|
+| idle title, trial 1 | 10.40 s | **28.8 fps** |
+| idle title, trial 2 | *arm produced no capture* | — |
+| idle title, trial 3 | 10.60 s | **28.3 fps** |
+| *(prior)* boot splash | 10.87 s | 27.6 fps |
+
+**~28.5 fps on an idle title — the same rate as the loading splash.** By this
+page's own criterion that settles it: the title presents at **30 Hz**, the
+timeline ticks at **60 units/second**, and **`1 unit = 1/60 s`**.
+
+**The 60 Hz reading is now excluded, not merely disfavoured.** It would require
+the emulator to be running at 47 % of real time *while sitting idle on a static
+title* — and the capture says that screen costs **1 526 draws over 300 frames,
+about 5 draws per frame**. Nothing there is expensive enough to halve the
+emulator's speed, and the splash and the idle title returning the same rate is
+exactly what a constant ~95 %-of-real-time emulator looks like.
+
+So the durations on this page stand as written: title build 4 ≈ **4.2 s**, main
+menu build 5 ≈ **1.1 s**, and `EXTRAS` build 6's declared fade-in ≈ **0.87 s**.
+
+⚠️ Still **measured, not decoded** — no field on the disc says "sixtieths of a
+second". What changed is that the measurement now has an idle-state control and
+the competing reading is ruled out.
 
 ## What this does not say