Two new findings from the human, both about WHEN a title animation starts, and
both handed over rather than guessed:
F5 Does (A) SNAP the title to finished, or ACCELERATE it? The human says they
cannot tell and is right that they cannot -- a three-frame acceleration and a
one-frame cut look identical to an eye. Two routes that should agree: a
per-frame capture (acceleration shows intermediate alphas, a cut shows none)
and the code (assigning a target time and raising a rate multiplier are
different instructions). Their "looks more like a snap on multiple attempts"
is recorded as a PRIOR, not a result.
F6 The title's sweeping white glow -- ptloop01/ptloop02, the blue PCB-like lines
-- starts only when the plate appears in the real game, and starts earlier in
the port. A lead from the exported declaration, mine and unverified: those
elements are keyed at t = 0, 70, 100, 238, 250 while the plate reaches full
alpha at 236, with pteff02 keyed at exactly 236 and ptlogo_back2eff and
ptcopyright at 238. 236-238 is a synchronisation point in the declared data
and a human just reported a behaviour change there. Flagged AGAINST itself
too: 238...250 looks equally like an exit ramp -- ptcopyright uses that shape
and starts nothing -- and the sweep lives in a nested .rat leaf with its own
timeline.
F6 bears on clock: "shared" and on F4: if a title element does not move until
the plate arrives, either the declared data says so and our keyframe reading is
wrong, or something at the plate's arrival STARTS it, which is a mechanism
nobody has proposed.
And the process change, which is the human's and outlives this item:
"attacking the 'whole' mission was too big for them to handle. Split the given
missions and tasks into even smaller tasks which they can tackle and give to
a human for feedback."
PROTOCOL.md gains "Work in units a human can check in a minute". A milestone is
not a unit of work, it is a bag of them. A unit is right-sized when it ends in
something a person can judge in under a minute WITHOUT READING ANYTHING, and
each one states its question, what the human looks at, and what it does NOT
cover. Do one, hand it over, stop -- an unverified fix under a second change
makes a regression two-variable.
The evidence for the rule is this week: the splash sat through a whole milestone
and took one day once scoped to "does it animate?". The bar is a HUMAN check,
not a green tool -- three instruments passed a frozen screen.
I wrote "whether the game snaps both clocks forward" into yesterday's F4 and the
human asked which clocks. There are none: authored/flow.json sets
`clock: "shared"`, so the title's two composited builds -- build 4 the artwork
(finishes t~=118) and build 2/3 the plate (full alpha t=236) -- run on ONE clock
started together. Left standing, that phrasing sends an agent hunting for a
second clock this corpus says does not exist.
Corrected in both briefs and in the playtest page, marked as a correction rather
than silently edited.
And the question is better than I first framed it. `clock: "shared"` is
AUTHORED, and the port's own plate-arrival-halves.md calls it "not falsified...
not confirmed to better than ~20 % either", with an unresolved anchor
disagreement inside one binary: the reconciliation picked t=118 while
settle_time() returns 160 and the boot prints "settles at t=160".
So F4 is a TEST OF THAT PREMISE, and the discriminator is observable -- press (A)
early, while the wordmark is still building in, and watch the ARTWORK rather
than the plate:
advances the shared clock -> the artwork SNAPS to finished
only forces the plate -> the artwork KEEPS ANIMATING its build-in
Both briefs now say to answer F4 before building on `shared`, and tell the port
not to choose what "jump" means.
"Menu walk and navigation is fine. Video skips too. Extras open. New Game
shows new game intro video." -- 2026-09-02
P5 is done. Its gate was "a human clicks through it", the retro said it had been
waiting on that and not on code for the whole milestone, and it has happened.
PORT-MISSION.md updated. The NEW GAME gap is accepted as-is.
Four findings, three of them the Decoder's:
F1 THE MENU REPEATS ON A HELD DIRECTION AND OURS DOES NOT. One step per
deflection was authored as the conservative choice because nobody knew; a
human has now watched the real game and it repeats, "at a medium pace... slow
enough to see which item is selected". That settles the existence half of H1
against us. The RATE is still unmeasured and must not be guessed -- the
description bounds it and supplies no number. Decoder measures initial delay
and repeat interval as frame counts; the port implements the mechanism and
waits for the numbers.
F2 THE SFX ARE TOO LOUD BECAUSE THERE IS NO MIX AT ALL. Measured: confirm
-17.7 dB mean / -0.0 dB peak, 3 dB hotter in mean than the music and 6.4 dB
above move. No volume or gain value exists anywhere in export/ or authored/,
so every clip plays at unity on one bus. Decoder: is per-cue or per-bus gain
on the disc -- the cue table is the obvious place and cue 1103 is already
decoded. Port: gains at PLAYBACK as data, and explicitly NOT normalisation in
the exporter, which destroys the relationship between clips and cannot be
undone by a modder.
F3 SOMETHING IS MISSING ON THE TITLE SCREEN. The export carries one music file
and the port plays nothing on the title. Which cue does the title play, and
is there a sting on the plate or on accept? A negative needs a positive
control: find the menu's cue by the same method first.
F4 (A) SKIPS FORWARD THROUGH THE BOOT AND WE IMPLEMENT TWO OF THREE PRESSES.
In the game: skip video, reveal plate immediately, accept plate. The middle
one is missing here. Whether the game snaps both clocks forward or only
reveals the plate is a question, not a detail -- and it is a cheap second
route to the plate-arrival question, since a press that skips to the plate
says where the game thinks the plate belongs.
H3, the plate delay, is ACCEPTED -- "feels the same... sufficient". Left
unattributed rather than closed green.
