port: the oracle harness was nondeterministic and I quoted it for a dozen iterations

verify-capture's main_menu row reads 13.30 / 13.27 / 13.25 / 13.26 across runs
this session while every other row is identical to the digit. I cited those
numbers repeatedly, including in the rest() adjudication.

Cause: the focus ring spins on time_units raw rather than the pose clamped by
holding -- deliberate and correct, since the ring is the one thing on a settled
screen that keeps moving -- so its angle at capture is set by the wall clock.
extras is stable because nothing there spins.

--loop-phase already existed and did not cover it: it pins the looping focus
record phase, while the spin is a second free-running clock I guarded once and
never connected. Extended loop_phase_units to pin the spin too, and verify-capture
now passes --loop-phase=0 at all four render sites.

The control matters because the drift was intermittent -- three unpinned runs gave
13.25, 13.26, 13.26, so three pinned runs agreeing would prove nothing. Phases
0/30/60/90 give 13.2583 / 13.1991 / 13.2637 / 13.2588: the pin is live and the
0.065 spread is the whole of the observed drift.

Non-finding recorded so nobody mines it: phase 30 scoring lowest is not evidence
about the ring's real phase -- 0.065 against a ~13.2 gamma floor is 200x too
small. A margin only means something against the noise it sits on.

No conclusion changes: the smallest margin any of them turned on was 0.14%
differing area.

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

docs/port/DECISIONS.md

@@ -9,7 +9,7 @@ dies, which is what this file is for.
 
 <!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
 
-172 sections. Search this before re-deriving anything.
+173 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)
@@ -183,6 +183,7 @@ dies, which is what this file is for.
 * [`exit_ramp_units`: the refuted constant was living in a default](#exit_ramp_units-the-refuted-constant-was-living-in-a-default)
 * [Auditing the whole tree for "a deleted value that something still supplies"](#auditing-the-whole-tree-for-a-deleted-value-that-something-still-supplies)
 * [Counting the fallbacks instead of inspecting them — and one I had misjudged](#counting-the-fallbacks-instead-of-inspecting-them--and-one-i-had-misjudged)
+* [The oracle harness was nondeterministic, and I quoted its numbers for a dozen iterations](#the-oracle-harness-was-nondeterministic-and-i-quoted-its-numbers-for-a-dozen-iterations)
 
 <!-- /INDEX -->
 ## P0 — the exporter, 2026-08-28
@@ -9851,3 +9852,57 @@ an in-range fallback dangerous, shown rather than argued.
 ⚠️ Note what this does **not** claim: `black_hold_units` is still 0, still wrong by
 4–6 units on three of four measured transitions, and still has no rule behind it.
 What changed is only that its *absence* is now audible.
+
+## The oracle harness was nondeterministic, and I quoted its numbers for a dozen iterations
+
+Reviewing my own logs: `verify-capture`'s `main_menu` row reads **13.30 / 13.27 /
+13.25 / 13.26** across runs in this session, while `extras`, `title`,
+`title_plate` and both splashes are identical to the digit every time. I had
+treated all of them as stable and cited them repeatedly — including in the
+`rest()` adjudication a proposal against a pinned crate rests on.
+
+### Cause: the one thing on a settled screen that is *supposed* to keep moving
+
+The focus ring spins on `time_units` **raw**, not the pose clamped by `holding` —
+deliberately, and correctly: *"a spinning ring is the one thing on the settled main
+menu that keeps moving, and the whole point of the finding is that it does not
+stop."* So its angle at the moment of capture is set by the wall clock. `extras`
+is stable because nothing there spins.
+
+⚠️ `--loop-phase` already existed and did **not** cover this. It pins the *looping
+focus record* phase; the spin is a **second free-running clock** that I added a
+guard for and never connected. Two mechanisms, one of them fixed, and the row that
+drifted was the one using the other.
+
+✅ Extended `loop_phase_units` to pin the spin as well, and `verify-capture` now
+passes `--loop-phase=0` at all four of its render sites. Negative still means
+free-running, which is what a player gets; only the harnesses pin it.
+
+### The control, because three passing runs would not have been evidence
+
+The drift was **intermittent** — three unpinned runs gave 13.25, 13.26, 13.26. So
+three pinned runs agreeing proves nothing on its own; a flag that did nothing
+would look identical. The test that separates them is whether the pin **changes**
+the answer:
+
+| phase | RMSE |
+|---|---|
+| 0 | 13.2583 |
+| 30 | **13.1991** |
+| 60 | 13.2637 |
+| 90 | 13.2588 |
+
+✅ Live. The spread is **0.065**, which is the size of the drift I observed — so
+the spin is the whole of it. Three pinned runs then return 13.26 exactly.
+
+📌 **A non-finding worth stating so nobody mines it later.** Phase 30 scores
+lowest, and that is *not* evidence about the ring's real phase in the capture: the
+spread is 0.065 against a gamma floor of ~13.2, roughly 200× smaller. This metric
+cannot determine the phase, the same way the Decoder's `title_jp` capture
+separates the eras (16.7) but cannot separate the pose policies (1.5) against its
+own 1.2 flatness. **A margin only means something against the noise it sits on.**
+
+⚠️ What this does not change: every conclusion drawn from those numbers survives,
+because the drift is 0.065 RMSE and the smallest margin any of them turned on was
+0.14 % differing area. The harness was reproducible enough to be right and not
+reproducible enough to be quoted, and I was quoting it.