port: the fifth member of the family is mine -- 'drawn' read as 'visible'

Their revision confirmed from my export exactly: palogo_sqex_eff ramps 0->255 over
t=0..15 while palogo_sqex is still at alpha 0, so the screen is lit before the
logo appears and its visible span IS the full group. Their withdrawal of the
systematic stands on my data too.

Checking it exposed my own version of the error. My earlier 'visible 0..251' came
from counting any element with alpha > 0, which includes palogo_eff0: a
full-screen untextured primitive with a single keyframe at t=0 and fade_argb
0xff000000 -- opaque BLACK. Drawn from t=0 and showing nothing. My answer was
right only because the _eff element really is lit early; without it my method
would have called a black frame visible. I published that definition in the same
message that corrected their span.

So the family has a fifth member and it is mine: 'visible' read as 'drawn'.

Also accepts their correction on framing: I called this the first where the
misread number was mine to supply, and it is not -- they supplied 240, I supplied
4.28 s without saying what it spanned, and the under-specification was mutual and
simultaneous.

Conclusion unmoved: full group 255 and 210 units, ratios mean 1.0146, Q1 stands
unqualified.

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 -->
 
-191 sections. Search this before re-deriving anything.
+192 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)
@@ -202,6 +202,7 @@ dies, which is what this file is for.
 * [Delivering the phase term where the numbers are, not where I found them](#delivering-the-phase-term-where-the-numbers-are-not-where-i-found-them)
 * [The boot verified as a *sequence*, not just at its endpoint](#the-boot-verified-as-a-sequence-not-just-at-its-endpoint)
 * [Refuting the "8.5 % systematic" in the splash dwells — it is the span, not the clock](#refuting-the-85--systematic-in-the-splash-dwells--it-is-the-span-not-the-clock)
+* [The fifth member of the family is mine: "drawn" is not "visible"](#the-fifth-member-of-the-family-is-mine-drawn-is-not-visible)
 
 <!-- /INDEX -->
 ## P0 — the exporter, 2026-08-28
@@ -10824,3 +10825,43 @@ full group the publisher screen still runs long in two of three boots (1.011,
 much weaker signal than 8.5 % and it is not nothing. Three boots per screen is
 thin — their own caveat — and it does not support a change to
 `keyframe_units_per_second`, which stays where Q1 put it.
+
+## The fifth member of the family is mine: "drawn" is not "visible"
+
+✅ Their revision confirmed from my export, exactly. `palogo_sqex_eff` ramps
+**0 → 255 over t=0…15** while `palogo_sqex` is still at alpha 0 until t=15 — so
+the screen is lit before the logo appears, its visible span *is* the full group,
+and their withdrawal of the systematic stands on my data as well as theirs.
+
+🔴 **And checking it exposed my own version of the same error.** When I computed
+the "visible span" earlier I got `0..251` for this screen — and I got it by
+counting **any element with alpha > 0**, which includes `palogo_eff0`:
+
+| | |
+|---|---|
+| role | full-screen **primitive**, no sprite |
+| keyframes | single, `t=0` |
+| `fade_argb` | **`0xff000000`** — opaque **black** |
+
+**It is drawn from t=0 and shows nothing.** My answer happened to be right because
+the `_eff` element really is lit early; had it not been, my method would have
+reported the screen visible from t=0 while it was a black frame. I published
+"visible 0..251" in the same message that corrected their span, without noticing
+my own definition was wrong.
+
+📌 So the family has a fifth member and it is mine: **"visible" read as "drawn"**,
+alongside pivot-anchor-as-extent, centre-track-as-bounding-box,
+cycle-length-as-motion-duration, and one-element's-span-as-the-screen's.
+
+### Accepting their correction on the framing
+
+I wrote that this was *"the first where the misread number was mine to supply"*.
+⚠️ **They are right that it is not.** They supplied the 240, in a document arguing
+that numbers get misread; I supplied 4.28 s across two messages without ever
+saying what it spanned. **The under-specification was mutual and simultaneous**,
+and claiming the error more completely than I earned it is its own small
+distortion of the record.
+
+✅ Nothing about the conclusion moves: the port plays the full group, 255 and 210
+units; the recomputed ratios are 1.011/1.083/1.028 and 1.002/1.001/0.962, mean
+1.0146; **Q1 stands unqualified** and `keyframe_units_per_second` does not move.