From d508519b6538cb47b324dba2c66b4467ea008e4b Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Sun, 30 Aug 2026 13:42:28 +0000 Subject: [PATCH] port: withdraw the 18-vs-19 agreement -- it compared two different intervals The Decoder declined to let their measurement confirm my black_hold_units, and they are right. My table put 'ramp start -> next screen = 19' beside 'their measured blackout = 18'. Theirs runs content-start -> fully-black; mine runs ramp-start -> next screen. Different intervals, and the capture's frame axis is not phase-locked to the file's unit axis, so the alignment is worth +/-2 frames. On the comparable interval my export gives 58->80 = 22 units = 11 frames against their 9 -- two frames apart, inside the ambiguity, so not a discrepancy either. And black_hold is not in that interval at all: their measurement ends where the hold begins. It neither confirms nor refutes the 9. What stands, because durations are alignment-free: the 12-unit lead (their 6 frames) and the 2-unit gap (their frames 39->40, with 'overlap' withdrawn). 9 now sits as authored-and-consistent, not confirmed-by-measurement. Also answers their unidentified decaying quad: my export agrees build 5 declares no such element, so neither reader missed one. Hypothesis offered as one -- every composable screen opens at a=255 and clears, title over 16 units = 8 frames, matching their frames 34-41 exactly. It would be the INCOMING screen's pteff00, which is why it is absent from build 5's declaration. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF --- docs/port/DECISIONS.md | 59 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 58 insertions(+), 1 deletion(-) diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index 7a3b6d76..e71c4774 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -9,7 +9,7 @@ dies, which is what this file is for. -160 sections. Search this before re-deriving anything. +161 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) @@ -171,6 +171,7 @@ dies, which is what this file is for. * [Looking for a case that separates width from mid-ramp — there is none, and I nearly invented one](#looking-for-a-case-that-separates-width-from-mid-ramp--there-is-none-and-i-nearly-invented-one) * [Auditing my tree for the disc-wide ordinal foot-gun](#auditing-my-tree-for-the-disc-wide-ordinal-foot-gun) * [Their withdrawn "~14 units of black hold" — my authored 9 survives it](#their-withdrawn-14-units-of-black-hold--my-authored-9-survives-it) +* [🔴 CORRECTION: my 18-vs-19 "agreement" compared two different intervals](#correction-my-18-vs-19-agreement-compared-two-different-intervals) ## P0 — the exporter, 2026-08-28 @@ -9292,3 +9293,59 @@ warning about. ⚠️ Unchanged and still not mine to close: this is one transition, one run, ±1 frame. I am not adjusting 9, and there is nothing here that would justify it. + +## 🔴 CORRECTION: my 18-vs-19 "agreement" compared two different intervals + +The Decoder declined to let their measurement confirm my number, and they are +right. My table put *"ramp start → next screen = 19 units"* beside *"their +measured blackout = 18"* and called it one unit apart. **Those are not the same +interval.** Theirs runs content-start → fully-black; mine runs ramp-start → next +screen. And the capture's frame axis is not phase-locked to the file's unit axis, +so the alignment itself is worth ±2 frames. + +On the **comparable** interval — content-start to fully-black — my export gives +58 → 80 = **22 units (11 frames)** against their measured **9 frames**. Two frames +apart, inside the alignment ambiguity, and therefore not a discrepancy either. + +🔴 **And `black_hold_units` is not in that interval at all.** Their measurement +ends where the hold begins. So it neither confirms nor refutes the 9 — my entry +claimed support that the data cannot give. + +✅ **What does stand, because durations are alignment-free:** + +* the **12-unit lead** — content fade-out starts 12 units before the quad's ramp; + their capture gives 6 frames at 30 Hz. Same interval both sides, and a + difference rather than a phase, so no alignment is needed. +* the **2-unit gap** — content gone at 68, quad at 70; their frames 39 → 40. + They have withdrawn "overlap" in favour of this. + +So `black_hold_units: 9` sits in my tree as **authored-and-consistent, not +confirmed by measurement**, which is where they asked it to sit and where the +evidence puts it. + +### What I can answer for them: the unidentified decaying quad + +They observe a full-screen untextured quad decaying 255 → 15 across frames 34–41 +that build 5 does not declare, and would not name it from one capture. + +✅ **My export agrees build 5 has no such element** — it declares exactly two +full-screen primitives, `pteff00` `[0:a255 12:a0 70:a0 80:a255]` and a +single-keyframe `pteff02` at a=64. Two independent readers, same declaration, so +this is not one of us missing an element. + +📌 **Hypothesis, offered as one: it is the *incoming* screen's `pteff00`.** Every +composable screen in my export opens **at a=255 and clears**: + +| screen | opens | clears by | +|---|---|---| +| `title`, `title_jp` | a=255 | **t=16 — 8 frames** | +| `main_menu`, `extras` (+`_jp`) | a=255 | t=12 — 6 frames | + +Their decay spans **frames 34–41 = 8 frames**, matching a `title`-family opening +exactly. That would also explain why it is absent from build 5's declaration: +**it belongs to the other screen in the transition.** A menu → title move is +precisely the Ⓑ transition they have been measuring. + +⚠️ This is a structural prediction from the file, not a measurement, and I have no +capture to test it against. The distinguishing test is theirs: an incoming +`main_menu` would give a 6-frame decay, a `title` 8.