port: F5/F6 hand-off — one-minute human checks, and a refutation attempt that survived

F5 and F6 were already implemented and verified across prior iterations
(ac1371c, af10a2e, 2b802e0, 94d761e, 1628f0e, edf8979) but there was no
single place stating the one-sentence question, what to look at, and
pass/fail — which PROTOCOL's "units a human can check in a minute" section
asks for. Nothing in this port's own code needed to change this iteration.

Also attempted to refute F6's "the port renders exactly two moving lights"
census by re-deriving element/leaf travel directly from
export/screens/title/title.json rather than trusting the prior read. It
survived: only ptloop01->pteff03 and ptloop02->pteff03a declare any
positional travel among all 24 title elements and their nested leaves.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/port/f5-f6-ready-for-human-check.md

@@ -0,0 +1,79 @@
+# F5 and F6 — ready for a human check
+
+**Why this file exists.** PROTOCOL's "work in units a human can check in a
+minute" asks for the question, what to look at, and what pass/fail mean,
+written down in one place. The investigation for F5 and F6 is long and lives in
+[`f6-what-starts-the-sweep.md`](f6-what-starts-the-sweep.md),
+[`plate-arrives-on-time-but-never-blinks.md`](plate-arrives-on-time-but-never-blinks.md)
+and the commit history (`ac1371c`, `af10a2e`, `2b802e0`, `94d761e`,
+`1628f0e`, `edf8979`). Nobody should have to read that to know what to watch.
+
+**Both are implemented, verified on film (not stills), and out-of-sample
+tested** — a fresh boot the predictions had no hand in producing matched on
+every figure the port actually relies on
+(`edf8979`, `docs/re/f6-out-of-sample-RESULT.md`). Neither is signed off by a
+person yet. That is the ask.
+
+## F6 — the glow no longer starts before the plate
+
+**One sentence:** watch a boot; the traveling glow along the blue lines should
+be invisible until the `PRESS Ⓐ` plate is on its way in, not visible from the
+first logo frame.
+
+**What changed:** the renderer was discarding the parent element's own alpha
+ramp (`0:0 70:0 100:255 238:255 250:0`) when drawing the glow's nested leaf.
+The glow now only draws once the parent has faded in — invisible to `t=70`,
+full by `t=100` — instead of being visible from `t=0`.
+
+**Pass:** on a fresh boot, the sweeping glow is not visible during the two
+publisher/developer splash-adjacent early frames of the title build-in; it
+fades in alongside (not before) the rest of the plate's approach.
+**Fail:** the glow is visible streaking across the screen before anything else
+on the title has appeared.
+
+**Not covered by this unit:**
+* The glow's *speed*, *path*, or whether it should be one streak or several —
+  Unit e in `f6-what-starts-the-sweep.md` flags that the port draws exactly
+  two full-height streaks and the human's original report described something
+  that could be a population of smaller lights on individual PCB traces. That
+  is unresolved and is a different question from *when* it starts.
+* Any fixed "lead time" between the glow and the plate — that number turned
+  out not to be reproducible (0.0996–0.141 across three captures) and nothing
+  is authored against it. F6 as originally reported ("starts too early") does
+  not depend on that number; the fix is the alpha gate above.
+
+## F5 — Ⓐ during the build-in snaps, it does not speed up
+
+**One sentence:** during the title build-in (after the boot logos, before the
+`PRESS Ⓐ` plate normally appears), press Ⓐ once and watch the wordmark —
+it should cut straight to its finished pose in one frame, not animate faster
+toward it.
+
+**What changed:** nothing new to watch for — this is a **confirmation ask**.
+The port's existing behavior (an instant cut, both light-sweep leaves
+restarting at their own declared opening pose in the same frame) was verified
+by frame-by-frame reading of submitted alpha values, which is the only
+instrument that can actually tell a one-frame cut from a several-frame
+acceleration — the human said themselves they could not tell by eye.
+
+**Pass:** the artwork looks the same as the port's current behavior — an
+instant jump, not a visible speed-up.
+**Fail:** the artwork clearly animates faster (rather than cutting) toward the
+finished pose, which would mean the July measurement should be revisited.
+
+**Not covered:** the exact frame Ⓐ targets, which is established as
+undecodable-with-no-observable-consequence (`docs/re/f5-snap-target-undecodable-with-reach.md` /
+the boot.gd comment above `settle_time()`) — there is a window `[160, 238)`
+where any value in it renders identically forever, so nothing is riding on the
+literal.
+
+## What the port did this iteration
+
+Nothing changed in code. This iteration re-read the state left by prior
+iterations, ran `tools/port/check-all` to confirm nothing regressed, and
+attempted to refute the F6 census claim ("the port renders exactly two
+moving lights, nothing else on the title declares positional travel") by
+re-deriving it independently from `export/screens/title/title.json` — every
+top-level element and every nested `.rat` leaf. **It survived**: only
+`ptloop01`→`pteff03` and `ptloop02`→`pteff03a` declare any positional travel
+at all; no other element or leaf has a `pos` keyframe that moves.