The media plan (#4906, docs/releases/v0.9.2-media-plan.md) already specifies the
procedure and references a tape at docs/evidence/v092-first-fleet-session.tape.
That tape did not exist, and the acceptance checklist was prose. This supplies
both, so the only thing left is the part that genuinely needs a human: running
it and judging whether the take is worth showing.
The tape replays the plan's four beats at 120x32. It sets a plain dark terminal
theme rather than a hand-written "Blue Stage" palette: Blue Stage is a
Codewhale theme and the TUI paints its own cells, so an emulator palette
imitating it would be invented colors fighting the real ones. The product theme
is selected from the sealed config instead.
record-session.sh exists because a recording is published footage, and the
failure mode is not a bad take — it is a take containing a home directory or a
credential. It refuses rather than producing something that must be scrubbed:
it checks the installed binary embeds this exact HEAD, refuses a dirty tree,
scans the environment for anything key-shaped, seals HOME/CODEWHALE_HOME, and
writes a capture.json naming the source commit and asset digests so the asset
can be re-shot instead of aging into a lie about the UI.
check-media-assets.py turns the mechanical half of the checklist into a command.
It parses MEDIA_BUDGETS out of web/lib/media-manifest.ts rather than duplicating
the numbers, so it cannot drift from the contract the web tests already enforce,
and it reports rather than fails on the issue's stricter ~3 MB README target
since that is a different budget from the site fallback.
Neither script judges the take, and the validator says so on success: whether
the session is worth showing, whether every frame is real, and whether the
caption cues match remain human calls.
Hmbown
0d7a628e24