port: WITHDRAW the claim that the port drifted away from the game -- wrong frame

The previous entry scored verify-screen's title_jp frame against the oracle and
concluded the port had moved away from the game. That frame is posed --pose=rest,
which the port does not ship. Posed as it runs, the disputed block scores +0.9994
against the reference's +0.8727, and the whole surface +0.9652 against +0.9200 --
holding under gamma compensation and on the English control (+0.9946 vs +0.9560).
The port is closer to the game than the reference on both title screens.

Mechanism: ptlogo_back2eff1 is (0,0)(98,0)(100,255)(102,255)(104,0) -- a 4-unit
sparkle whose rest.t is the peak of its own flash. Six of them stagger across the
logo, so --pose=rest fires every sparkle at once. The 25.6% excess light was real
and was in a frame nobody sees.

verify-screen is not at fault: it poses rest deliberately, so that both renderers
read one decoder and the run is a consistency check. I used a consistency-check
frame for a correctness question. Its header now says its frames must never be
scored against a capture.

A second claim in that entry was also wrong -- both screens draw those layers
under pose=rest; I had compared a --menu timeline log against a verify-screen
rest log and read a mode difference as a screen difference.

verify-capture takes a fifth per-row field, a capture crop, because this capture
is a full display frame with the surface at +0+45 while the others are
pre-cropped. With it title_jp reads RMSE 20.91 / 1.04%, beside title's 14.16 /
0.21%. The row prints 'no capture' until their branch merges.

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 -->
 
-144 sections. Search this before re-deriving anything.
+149 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)
@@ -155,6 +155,11 @@ dies, which is what this file is for.
 * [State of the port, and a claim I built on for a week without checking](#state-of-the-port-and-a-claim-i-built-on-for-a-week-without-checking)
 * [Identifying their submenu capture: edges where intensity could not](#identifying-their-submenu-capture-edges-where-intensity-could-not)
 * [`on_cancel`: one half measured, and a MEASURED stamp removed from the other](#on_cancel-one-half-measured-and-a-measured-stamp-removed-from-the-other)
+* [BLOCKED.md's five "blocking" rows were all answered, some days ago](#blockedmds-five-blocking-rows-were-all-answered-some-days-ago)
+* [The plate came back in the game and not in the port](#the-plate-came-back-in-the-game-and-not-in-the-port)
+* [🔴 `verify-screen` was nondeterministic, and it looked fine most of the time](#verify-screen-was-nondeterministic-and-it-looked-fine-most-of-the-time)
+* [The JP title capture adjudicates `title_jp` — and it goes against the port](#the-jp-title-capture-adjudicates-title_jp--and-it-goes-against-the-port)
+* [🔴 CORRECTION: the port did not move away from the game — I scored the wrong frame](#correction-the-port-did-not-move-away-from-the-game--i-scored-the-wrong-frame)
 
 <!-- /INDEX -->
 ## P0 — the exporter, 2026-08-28
@@ -8625,3 +8630,68 @@ not bisected them. Naming one now would be a guess dressed as a cause.
 📌 What this does settle: `title_jp`'s `DIFFERS` is **the port's**, not the
 reference's. That reverses this script's usual presumption, and it is the first
 row in the baseline whose direction has ever been established against a capture.
+
+## 🔴 CORRECTION: the port did not move away from the game — I scored the wrong frame
+
+The previous entry concluded, from the JP title capture, that *"the port moved,
+and it moved away from the game"*. **That conclusion is withdrawn.** It is wrong,
+and the way it was wrong is worth more than the answer.
+
+I scored `verify-screen`'s `title_jp` frame against the oracle. That frame is
+posed `--pose=rest`, which this port **does not ship**. Posed as it actually
+runs:
+
+| | disputed block | whole surface |
+|---|---|---|
+| port, `--pose=rest` (the frame I scored) | +0.7462 | — |
+| **port, as shipped** | **+0.9994** | **+0.9652** |
+| reference | +0.8727 | +0.9200 |
+
+✅ Holds under gamma compensation (+0.9928 at γ=1.34) and ✅ on the **English
+control**, same method: port +0.9946 against the reference's +0.9560. The port is
+closer to the game than the reference on **both** title screens.
+
+### Why `rest` produces a frame the game never shows
+
+`ptlogo_back2eff1` on the JP title is `(t, alpha) = (0,0) (98,0) (100,255)
+(102,255) (104,0)` — a **4-unit sparkle**, and its `rest.t` is **100: the peak of
+its own flash**. Six of these stagger across the logo. Posing at `rest` fires
+every sparkle simultaneously at full brightness, which is exactly the "port puts
+light on 25.6 % of the block the capture does not have" I reported as a defect.
+The excess light was real; it was in a frame nobody sees.
+
+⚠️ `verify-screen` is not at fault — it poses `rest` **deliberately**, because
+both renderers read `rest` through one decoder and that is what makes it a
+consistency check. Its header said so. **I used a consistency-check frame to
+answer a correctness question**, and the tool now says in its own header that its
+frames must never be scored against a capture.
+
+### A second, smaller thing in that entry was also wrong
+
+It said the port draws layers "that are transparent at rest on the English
+title". Both screens draw them under `--pose=rest`. I had compared a `--menu`
+run's log (timeline pose) against a `verify-screen` log (rest pose) and read the
+difference as a property of the screens rather than of the two modes.
+
+### What actually stands from that entry
+
+The alignment work survives intact — the measured dy=−45 with the English control
+at (0,0), and the observation that the instrument is fair on a control strip. So
+does the arithmetic. **What failed was choosing which frame to feed it**, and no
+amount of control on the comparison could have caught that: every control I ran
+was a control on the *metric*, and the error was upstream in the *input*.
+
+📌 The generalisation: **a control proves the instrument, not the sample.** Both
+of my last two iterations' errors were of that shape — a live reader pointed at
+the wrong field name, and a fair metric pointed at the wrong frame.
+
+### Wired so it cannot recur
+
+`tools/verify-capture` takes a fifth per-row field, a capture crop, because this
+capture is a full 1280×720 display frame with the surface at +0+45 while every
+other capture in that directory is pre-cropped to 1279×675 — comparing it whole
+would score the port against a 45 px shift. With it, `title_jp` reads **RMSE
+20.91, differing region 1.04 %**, beside `title`'s 14.16 / 0.21 %.
+
+⚠️ The row prints `no capture` until the Decoder's branch merges. Their capture is
+theirs to commit; it was staged locally to test the row and removed.