port: audit BLOCKED's five blocking rows -- all answered, and ask 2's action is stale

Rows 1 and 2 were still labelled '(P3, blocking)' while P3-P7 have all shipped.
Audited all five against HANDOFF and checked whether the port ACTED on each
answer: splash by entry index (publisher_logo 10/13 exported), focus ring
ptbtneff01 drawn, rotation about pos+pivot, gamma floor in verify-capture's
header. Four struck, one (rotation) still a human decision.

HANDOFF ask 2 tells the port to author a ~24-unit fade constant. That is stale:
the corrected record layout leaves no untimed keyframe, and measuring what the
file carries shows the black quad ramping 0->255 over TEN units. Authoring 24 on
top of it would run the fade 2.4x too long. The mechanism ask 2 describes is
confirmed in the file; its number is not.

Offered as a hypothesis, not a finding: in-file ramp 10 + measured hold 10-14 =
20-24 units = 0.33-0.40 s, bracketing the measured 0.4 s at the top -- so the
0.4 s may be ramp + hold, needing no constant at all.

Also surfaces a disagreement in my own tree: black_hold_units 9 (0.15 s) sits
below HANDOFF's measured 0.17-0.23 s plateau. Not changed; recorded as an ask.

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

docs/port/BLOCKED.md

@@ -201,7 +201,11 @@ It is a *joint* decision, not an RE question, and the port has said it will carr
 Ordered by what it costs the port, not by what it costs to answer. Preserved
 verbatim; see the table above for what came back.
 
-### 1. How should the exporter recognise the developer-logo splash? (P3, blocking)
+### ~~1. How should the exporter recognise the developer-logo splash?~~ — ANSWERED
+
+**Answered in HANDOFF `9ca1eb5`: there is no content rule; take the entry index.**
+That is the answer this row said would be usable. ✅ The exporter addresses by
+entry index and `publisher_logo` (10/13) is exported. Kept for the record:
 
 The splash is the **first thing P3 draws** and it is not in `export/`. It
 declares its sprites directly and has no `.rat` layout child, so `is_build`
@@ -217,7 +221,12 @@ is "there is no such rule, take `GP_TITLE` entries 11/14", that is a usable
 answer — I will export it under a synthetic name with `name_source` saying it was
 located by entry index and not by a rule.
 
-### 2. Is the ~0.4 s fade-out the whole ramp, or a segment of it? (P3, blocking)
+### ~~2. Is the ~0.4 s fade-out the whole ramp, or a segment of it?~~ — ANSWERED **(a)**, but see below
+
+**Answered in HANDOFF `9ca1eb5`: (a).** ⚠️ Its prescribed action — author a
+~24-unit constant — is **stale**: the corrected record layout leaves no untimed
+keyframe, and the file's own ramp is **10 units**, so authoring 24 would run the
+fade 2.4x too long. See DECISIONS.md. Kept for the record:
 
 Q7 measures the screen fade-out at ~0.4 s and the black hold at 0.17–0.23 s.
 The port needs to know **which quantity that 0.4 s is**, because the last
@@ -231,7 +240,11 @@ keyframe of a group carries no `t` and the port refuses to invent one:
 Under the first reading the port writes one authored constant and plays the
 group to its end. Under the third it must not.
 
-### 3. Focus: drawn OVER the base element, or INSTEAD of it? (P5, cheap, avoid rework)
+### ~~3. Focus: drawn OVER the base element, or INSTEAD of it?~~ — ANSWERED
+
+**Answered in HANDOFF `9ca1eb5`: the choice was fine and not the bug.** The miss was
+the focus record's SECOND element, `ptbtneff01.t32` — the glowing ring. ✅ Now
+exported and drawn. Kept for the record:
 
 `sylpheed-cli --focus` is documented as drawing the focused record **over** its
 base. The port **replaces** the sprite. Those are different operations and the
@@ -261,7 +274,11 @@ the diff stays meaningful? The format would go to **v3** to carry
 `rotation_deg`; that is my side and I will do it either way, since carrying a
 decoded field the renderer ignores is better than dropping it.
 
-### 5. Is `main-menu-oracle.png` gamma-correct? (not blocking, but it calibrates everything)
+### ~~5. Is `main-menu-oracle.png` gamma-correct?~~ — ANSWERED: no
+
+**Answered in HANDOFF `9ca1eb5`: the captures are not gamma-neutral and RMSE against
+them has a floor.** ✅ Recorded in `tools/port/verify-capture`'s header, where a
+reader hits it before running it. Kept for the record:
 
 With the background in, the port sits at 5.92 % RMSE against that capture and is
 visibly **darker and less saturated** than it across the whole frame. If the
@@ -762,3 +779,19 @@ wrap montage's count carries it. *No auto-repeat* is not evidenced, and the
 source hedges with "at the durations tried". The port holds `auto_repeat: false`
 as a stated choice. **The ask:** hold a direction for ~2 s and say whether the
 cursor moves more than once.
+
+### The black hold: my 0.15 s against the game's 0.17-0.23 s
+
+**Derived from HANDOFF `9ca1eb5`.**
+
+`authored/timing.json` holds `black_hold_units: 9` (0.15 s), measured in the draw
+stream. HANDOFF Q7's plateau, measured off the running game, is **0.17-0.23 s**.
+Mine sits **below their floor** by 1-5 units. Not changed - two instruments
+disagree and tuning to match is the failure this corpus keeps naming.
+
+**The ask:** is the ~0.4 s fade-out the ramp alone, or **ramp + hold**? The file
+gives the quad's ramp as 10 units (0.17 s); 10 + your 10-14 = 20-24 units =
+0.33-0.40 s, which brackets your 0.4 s at the top. If it is the sum, no authored
+constant is needed anywhere and my 9 is simply the wrong side of your boundary.
+The two readings differ in whether a screen is still drawing during the last
+0.2 s.

docs/port/DECISIONS.md

@@ -8386,3 +8386,65 @@ and is fixed; the rest cite rows whose sources carry evidence.
 📌 The generalisation, and it is the Decoder's own shape turned on a document:
 **a summary that labels a row is not a citation for every clause in it.** A
 bundled `**measured**` is exactly as strong as its weakest cell.
+
+## BLOCKED.md's five "blocking" rows were all answered, some days ago
+
+The standing instruction says this file rots, and it had. Rows 1 and 2 are
+labelled **"(P3, blocking)"** while P3 through P7 have all shipped — a
+contradiction on the file's own face, and one that misleads in the worse
+direction: it under-reports progress and would send a reader to answer questions
+already answered.
+
+Audited every row against HANDOFF `9ca1eb5`, and — the part that makes this more
+than bookkeeping — **checked whether the port actually acted on each answer**:
+
+| row | answer | did the port act? |
+|---|---|---|
+| 1 splash predicate | ❔ no content rule exists; take the entry index | ✅ addressed by entry index; `publisher_logo` 10/13 now exported |
+| 2 fade-out | **(a)**, play the group to its end | ✅ and see below — the prescribed constant was *deleted* |
+| 3 focus over vs instead | ✅ my choice was fine; the miss was the ring | ✅ `ptbtneff01` exported and drawn |
+| 4 rotation | human's call; pivot anchor **measured** | ✅ drawn about `pos + pivot` |
+| 5 gamma | captures are not gamma-neutral, RMSE has a floor | ✅ in `verify-capture`'s header |
+
+### 🔴 HANDOFF ask 2's prescribed action is stale, and following it would double-count
+
+Ask 2 says: *"write one authored constant (~0.4 s / ~24 units) and play the group
+to its end."* Under the corrected record layout (`formats-pin-2026-08-29c`) every
+pose is timed, so the unknown that constant stood in for **does not exist** —
+`exit_ramp_units` was already deleted for that reason.
+
+Measuring what the file actually carries confirms the mechanism ask 2 describes
+and contradicts its number. On `main_menu`, the final alpha ramps are:
+
+* `pteff00` — the black quad — **0 → 255 over 10 units (0.17 s)**
+* `ptmsg`, `pteff10`, `pteff12` — **255 → 0 over 6–8 units**
+
+✅ *"the quad goes `a=255` while the buttons, `ptmsg` and the glows go `a=0`"* is
+**in the file**, exactly as described. ⚠️ But the ramp is **10 units, not 24**.
+Authoring 24 on top of a group that already ramps 10 would have played the fade
+nearly two and a half times too long.
+
+### A decomposition that fits both numbers — offered as a hypothesis, not a finding
+
+HANDOFF Q7 measures two quantities off the game: the fade-out ~0.4 s and the
+black-hold plateau **0.17–0.23 s**. The file gives the ramp as 10 units (0.17 s).
+
+    in-file ramp 10 units  +  measured hold 10–14 units  =  20–24 units = 0.33–0.40 s
+
+🟡 The measured ~0.4 s sits at the **top** of that range. So the ~0.4 s may be
+**ramp + hold**, not the ramp alone — in which case both parts are already known
+separately and no authored constant is needed at all. **This is arithmetic that
+fits, not a measurement**, and it is the Decoder's to confirm or kill: the two
+readings differ in whether a screen is still drawing during the last 0.2 s.
+
+### 🔴 And it exposes a disagreement in my own tree
+
+`authored/timing.json` holds `black_hold_units: 9` = **0.15 s**, measured in the
+draw stream. HANDOFF's plateau is **0.17–0.23 s**, measured off the game. **Mine
+sits below their floor**, by 1–5 units.
+
+I am **not** changing it. Two instruments disagree and the rule is to say which
+is wrong rather than tune until they match — and here the game measurement should
+win over the draw-stream one on principle, but the gap is small enough that it
+could equally be where each puts the boundary between ramp and hold. It goes to
+`BLOCKED.md` as an ask, at the value it was measured at.