port: the plate's ramp was already in my export, and the renderer reproduces it

The Decoder is paused and could not take the capture I asked for, and said the disc
half might not need them. It did not, and it did not need a new decode either: the
ramp is already in export/screens/title/press_start.json. ptbtn00f carries eight
keyframes on a 120-unit loop, alpha in the high byte of fade_argb, 0 -> 80 -> 0
with the peak held across t=35..50.

Two things follow with no oracle. The blind phase is confirmed from the disc rather
than inferred from rendering: alpha is exactly 0 at phase 0. And the renderer
applies the ramp faithfully -- rendered contribution against declared alpha across
six phases gives r = +0.9982, slope 0.4036 levels per alpha unit.

So when and how strongly the port draws the highlight is verified. Only the
composite is open, and the existing capture cannot settle it under either reading
of the clock: posed at t=237 the phase is 117 where alpha is about 0, and the
harness independently pins loop-phase 0 where alpha is exactly 0. Both agree, which
is worth stating because I did not have to assume which clock the record runs on.

The ask therefore narrows from "a mid-pulse instant" to a named window: one capture
anywhere in t mod 120 in [35, 50], where alpha holds at its peak of 80.

docs/port/BLOCKED.md

@@ -171,9 +171,16 @@ measured blend moved 26 319 px at phase 20 while reporting exactly zero here.
 What is unverifiable on my side is whether *my renderer* now reproduces it. One
 capture of the title with the plate at a visibly mid-pulse instant closes it.
 
-⚠️ Cheap alternative if a fresh capture is expensive: the plate's alpha at a known
-phase, from the existing `plate-pulse-measured.md` run, would let me check the
-level rather than the picture.
+✅ **NARROWED 2026-08-31, and the cheap alternative is no longer needed** — the
+ramp was already in my own export. `ptbtn00f` declares eight keyframes on a
+120-unit loop peaking at α **80** and holding it across **t = 35…50**, and the port
+reproduces that ramp at **r = +0.9982** against the declared values. So *when* and
+*how strongly* the port draws the highlight is verified without an oracle.
+
+📌 **The ask is now one capture in a named window: t mod 120 ∈ [35, 50].** Only the
+composite is open. The existing capture provably cannot answer it — at t=237 the
+phase is 117 (α ≈ 0), and the harness independently pins phase 0 (α exactly 0);
+both readings of the clock agree.
 
 ## New ask, 2026-08-31 — three, derived from today's completed blend delivery, port `HEAD` `49a6333`
 

docs/port/DECISIONS.md

@@ -16432,3 +16432,40 @@ plate cannot see the plate's pulse.** Now stated in the tool, next to the pose.
 ⚠️ **Not verified against the oracle.** The blend is theirs and measured; that the
 *port* now draws it correctly is not something any capture I hold can confirm,
 because every title-plate capture is at the blind phase. Filed.
+
+### The plate's ramp was already in my export, and the renderer applies it correctly
+
+The Decoder is paused and could not take the capture I asked for, and pointed out
+that the disc half might not need them. It did not — **and it was already in
+`export/screens/title/press_start.json`.** `ptbtn00f` carries eight keyframes on a
+120-unit loop, alpha in the high byte of `fade_argb`:
+
+| t | 0 | 6 | 29 | 35 | 50 | 58 | 97 | 105 |
+|---|---|---|---|---|---|---|---|---|
+| α | **0** | 6 | 74 | **80** | **80** | 74 | 6 | **0** |
+
+✅ **Two things follow without an oracle.**
+
+**1. The blind phase is confirmed from the disc.** α is *exactly 0* at phase 0 —
+so `verify-capture`'s pose sees nothing, and that is a property of the data, not an
+artefact of how I rendered it.
+
+**2. My renderer applies the ramp faithfully.** Rendered contribution against
+declared α across the cycle:
+
+| phase | 0 | 20 | 40 | 60 | 80 | 100 |
+|---|---|---|---|---|---|---|
+| declared α | 0 | 47.4 | 80.0 | 70.5 | 35.6 | 3.8 |
+| rendered Δ | 0.00 | 20.70 | 32.55 | 29.24 | 16.55 | 2.59 |
+
+**r = +0.9982**, slope 0.4036 levels per α unit. So *when* and *how strongly* the
+port draws the highlight is right; only the **composite** is unverified.
+
+📌 **And the capture cannot settle it, under either reading of the clock.** It is
+posed at t=237; 237 mod 120 = **117**, where α ≈ 0 — and the harness independently
+pins `--loop-phase=0`, where α is exactly 0. Both readings agree, which is worth
+stating because I did not have to assume which clock the record runs on.
+
+⚠️ So the ask narrows to one number and gets a precise window: **a capture anywhere
+in t mod 120 ∈ [35, 50]**, where α holds at its peak of 80. Everything else about
+the plate is now settled on my side.