From 7ecbed1d09c0f6c228f70cac8a06d599e930eba4 Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Sun, 30 Aug 2026 11:16:02 +0000 Subject: [PATCH] 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) Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF --- docs/port/BLOCKED.md | 41 +++++++++++++++++++++++++--- docs/port/DECISIONS.md | 62 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 99 insertions(+), 4 deletions(-) diff --git a/docs/port/BLOCKED.md b/docs/port/BLOCKED.md index 40251d58..d174da32 100644 --- a/docs/port/BLOCKED.md +++ b/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. diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index c7be251a..446effc8 100644 --- a/docs/port/DECISIONS.md +++ b/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.