port: their withdrawn 14-unit hold does not touch my authored 9 -- it supports it

Two warnings. The first does not reach me: nothing is authored from
screen-transitions.md's 0.87/0.97/4.08 s spans, and nothing in this port reads
keyframe times outside the crate -- their stale fade_quads.py failure mode cannot
occur here by construction.

The second is about black_hold_units: 9. Testing their structural claim on my
export: pteff00 on main_menu is [0:a255 12:a0 70:a0 80:a255], rising to black over
70->80, while content fade-outs start at 58-60. That is 12 units of lead, exactly
six frames at 30 Hz, matching their measurement off the running game -- disc and
capture agreeing by independent routes. They say the two overlap; mine has a
2-unit gap, one frame, inside their stated resolution.

The arithmetic: quad ramp 10 units + my authored 9 = 19 units = 0.317 s against
their measured blackout of 18 units = 0.30 s. One unit apart, inside their own
resolution. The measurement that withdrew the 14 supports my 9.

It survived because I declined to author the 14 when the arithmetic was available
and fit -- I wrote that it was arithmetic rather than a measurement and left the
value where it had been measured. Had I adopted the composition I would now carry
24 units against a measured 18, which is the dead black they are warning about.

Not adjusting 9; one transition, one run, +/-1 frame.

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 -->
 
-159 sections. Search this before re-deriving anything.
+160 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)
@@ -170,6 +170,7 @@ dies, which is what this file is for.
 * [Checking my own tree for the ordinal foot-gun that just voided three of theirs](#checking-my-own-tree-for-the-ordinal-foot-gun-that-just-voided-three-of-theirs)
 * [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)
 
 <!-- /INDEX -->
 ## P0 — the exporter, 2026-08-28
@@ -9232,3 +9233,62 @@ exact and `a=127` holds flat across 134 units with position and scale constant.
 and a 200 % scale, and nobody has put that in front of the running game. The
 correction to my mid-ramp test stands on the numbers alone and needs no reading of
 what the element depicts — which is how it should have been written.
+
+## Their withdrawn "~14 units of black hold" — my authored 9 survives it
+
+Two warnings arrived. The first does not touch me: ✅ nothing of mine is authored
+from `screen-transitions.md`'s 0.87 / 0.97 / 4.08 s fade-in spans, and **nothing
+in this port reads keyframe times outside the crate** — the exporter reads them
+through `sylpheed_formats`, and every analysis script I have reads
+`export/*.json` downstream of it. Their `fade_quads.py` failure mode cannot occur
+here by construction, which is the wall doing its job rather than luck.
+
+The second is about a value I ship: `authored/timing.json` `black_hold_units: 9`.
+They withdrew the "~14 units of hold" and warn that **authoring a hold puts a
+sixth of a second of dead black into every transition the game does not have**.
+
+### Testing their structural claim on my own export
+
+*"Content elements start fading about six frames before the black quad's ramp
+begins."* On `main_menu`, `pteff00` is `[0:a255 12:a0 70:a0 80:a255]` — its rise
+to black runs **t=70 → 80**. The content fade-outs start at:
+
+| element | starts | ends |
+|---|---|---|
+| `ptmsg` | **58** | 64 |
+| `pteff10`, `pteff12` | 60 | 68 |
+| `ptbtn05` | 60 | 64 |
+
+✅ **12 units of lead — exactly six frames at 30 Hz**, matching their measurement
+off the running game. Two independent routes, disc and capture, same number.
+
+⚠️ One difference: they say the two **overlap**; in my export content is gone by
+t=68 and the quad starts at t=70 — a 2-unit gap, not an overlap. That is one frame,
+inside their stated ±1 frame per span, so I record it as agreement at their
+resolution rather than as a discrepancy either of us can act on.
+
+### The arithmetic, which is the part that matters
+
+Their new figure: **total blackout 9 frames ≈ 0.30 s = 18 units**, gap between
+screens one frame.
+
+| | units |
+|---|---|
+| quad's ramp to black, from the file | 70 → 80 = **10** |
+| my authored `black_hold_units` | **9** |
+| total from ramp start to the next screen | **19** = 0.317 s |
+| their measured blackout | **18** = 0.30 s |
+
+✅ **One unit apart — inside their own resolution.** My authored 9 is *supported*
+by the measurement that withdrew the 14, not refuted by it.
+
+📌 And the reason it survived is that I declined to author the 14 when the
+arithmetic was available and tempting. The ramp+hold decomposition I proposed gave
+20–24 units and fit their old ~0.4 s at the top of the range; I wrote *"this is
+arithmetic that fits, not a measurement"* and left the value where it had been
+measured. **Had I adopted the composition, I would now be carrying 24 units
+against a measured 18** — the exact sixth of a second of dead black they are
+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.