From 0148cb836c944bb27bfd70a1c7dc4f956d721c25 Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Fri, 4 Sep 2026 13:45:42 +0000 Subject: [PATCH] =?UTF-8?q?port:=20F5/F6=20hand-off=20=E2=80=94=20one-minu?= =?UTF-8?q?te=20human=20checks,=20and=20a=20refutation=20attempt=20that=20?= =?UTF-8?q?survived?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- docs/port/f5-f6-ready-for-human-check.md | 79 ++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 docs/port/f5-f6-ready-for-human-check.md diff --git a/docs/port/f5-f6-ready-for-human-check.md b/docs/port/f5-f6-ready-for-human-check.md new file mode 100644 index 00000000..3481066c --- /dev/null +++ b/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.