50be9578c5
A snapshot of the non-game files as of0148cb8("port: F5/F6 hand-off -- one-minute human checks, and a refutation attempt that survived", 2026-09-04), the tip of auto/port-p6-audio. The branch was deleted from the server on 2026-09-17 during the consolidation cleanup; issue #7 asks for this work as a reviewable PR, so it is recovered here before the commits are garbage collected. Contents: the 84 files the branch changed relative to its fork pointb305aa4, which is this commit's parent. The tree is therefore 0148cb8's tree with the 854 exported game assets left out -- export-probe/, export-probe2/, three .wav renders of game audio and adv-v2-screenlog.tsv. Game data stays out of git; the exporter regenerates those from the disc. docs/port/DECISIONS.md still refers to them by name. Not recovered: the branch's own 366 commits. Keeping them would make those assets reachable again, so this is one snapshot instead. The original commits stay unreferenced in the server's object store, and in this clone under the local branch archive/port-p6-audio, until either is garbage collected. Refs #7. The OPTIONS work that issue #6 asks for is a subset of this branch, also recovered as recover/options-menu. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
4.3 KiB
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,
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.mdflags 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.