Sylpheed/docs/agents/PLAYTEST-2026-09-02-menus.md

Play-test, 2026-09-02 (second) — P5 IS MET, and four findings

✅ P5's gate is MET — the human clicked through it

"Menu walk and navigation is fine. Video skips too. Extras open. New Game shows new game intro video."

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 now happened. PORT-MISSION.md is updated.

The human also confirmed the NEW GAME gap is understood and acceptable: "Deliberate AFAIK, in actual game the difficulty select comes first." The port announces the two screens it skips; that stays as it is.

---

F1 — 🔴 The menu DOES repeat on a held direction. Ours does not.

"Moving stick up/down and holding only moves one item. In game it actually continues to move when holding up/down, just at a medium pace so player does not need to move pad middle↔up/down, but also slow enough to see which item is selected and move to target."

This settles the existence half of H1, and it settles it against us. One step per deflection was authored as the conservative choice precisely because nobody knew. Now somebody has watched the real game: it repeats.

⚠️ The RATE is still not measured, and it must not be guessed. The human's description bounds it usefully and does not supply a number: fast enough that a player need not return the stick to centre, slow enough to read the selection as it passes. That is a range, not a value.

• Decoder — measure it. Hold a direction in Canary and count. Two numbers: the initial delay before the first repeat, and the repeat interval after it. Frames between cursor moves, at a stated present rate — a count, not a stopwatch reading (TEMPORAL-VERIFICATION.md). Also: does the d-pad differ from the stick? Does the rate accelerate while held, or stay flat?
• Port — implement the mechanism, take the number from the Decoder. Do not ship a placeholder rate: an invented interval here is indistinguishable from a measured one a month from now, and this is the exact field where that has already cost us once.

F2 — 🔴 The sound effects are too loud. There is no mix at all.

"Largely OK. Biggest notice is the volume, many effects are too loud."

Measured, and the human is right. Every clip plays at unity gain, because no volume or gain value exists anywhere — not in export/, not in authored/, not in the manifest:

	mean	max
se/confirm	−17.7 dB	−0.0 dB — at full scale
se/move	−24.1	−1.4
se/back	−21.0	−5.7
bgm/main_menu	−20.7	−4.2

confirm is the loudest thing in the export: 3 dB hotter in mean than the music and 6.4 dB above move. A game mixes SE against BGM on separate buses; this port has one bus and no gains.

• Decoder — is the mix ON THE DISC? The obvious place is the cue table: a cue record commonly carries volume alongside the wave index, and sub_821C5580 is already known to play cue 1103. If per-cue or per-bus gain is there, it is decoded and nobody has to choose. If it is provably not, say so with reach and it becomes an authored mix.
• Port — do not normalise in the exporter to fix this. Re-levelling the file destroys the relationship between clips and cannot be undone by a modder. Gains belong at playback, as data, where a measured value can replace a chosen one without re-exporting.

F3 — ❔ Something is missing on the title screen

"I also think that there is a sound track or effect missing at the title screen."

The export carries exactly one music track, bgm/main_menu.ogg, and the port plays nothing on the title. Whether the game does is unestablished.

• Decoder: which cue, if any, does the title play? The menu's is decoded (cue 1103 = BGM_103 via sub_821C5580); the same route should answer the title. And is there a one-shot sting when the plate appears, or when Ⓐ is accepted? Either would read as "something missing" to a player.
• ⚠️ A negative here needs a positive control (R4): show the method finding the menu's cue before concluding the title has none.

F4 — 🔴 Ⓐ SKIPS FORWARD through the boot. We only implement one of the three.

"In the game one can get the plate to immediately show by pressing Ⓐ, essentially skip to it. So after the logos one can immediately skip to the main menu by pressing Ⓐ three times: 1. skip intro video, 2. show plate, 3. the plate itself."

A measured behaviour of the real game, and a good one — it is how a returning player gets past the boot.

press	in the game	in the port
Ⓐ #1	skips the intro video	✅ implemented
Ⓐ #2	completes the title build-in and shows the plate immediately	❌ missing
Ⓐ #3	activates the plate → main menu	✅ implemented

• Port: Ⓐ during the title build-in should jump the sequence to the plate's arrival rather than being swallowed. ⚠️ Careful what "jump" means, and do not choose it. See below — it is a test of an authored premise, not a detail.
• Decoder: what does Ⓐ do to the clock? This is also a second, cheap route to the plate-arrival question — a press that skips to the plate tells you where the game thinks the plate belongs.

🔴 F4 is a TEST OF clock: "shared", which is authored and only ~20 % confirmed

Correction, by the human who wrote this page: an earlier draft said "both clocks". There is only ONE. authored/flow.json sets "clock": "shared": the title is two composited builds — build 4 the artwork, build 2/3 the plate — and they run on one clock started together. Build 4's artwork finishes at t ≈ 118; the plate reaches full alpha at t = 236. Saying "both clocks" would send someone hunting for a second one that this corpus says does not exist.

With that fixed, the question is sharp and observable:

if Ⓐ …	then pressing EARLY looks like
advances the shared clock	the title artwork snaps to finished, and the plate appears
only forces the plate visible	the artwork keeps animating its remaining build-in while the plate appears over it

So film a boot, press Ⓐ while the wordmark is still building in, and watch the artwork, not the plate.

📌 Why this matters beyond the feature. clock: "shared" is authored, and plate-arrival-halves.md says in its own words that it is "not falsified… not confirmed to better than ~20 % either". There is also 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.

If Ⓐ snaps the artwork, that is evidence for one shared clock. If the artwork carries on while the plate appears, the plate has a timeline of its own and the authored premise is in trouble. Answer F4 before building on shared.

• 📌 And it bears on REFUTED.md: "any title after the first one refuses input" is already narrowed to the attract-returned title. This is a third input the boot title accepts.

---

F5 — Ⓐ: does the animation SNAP, or accelerate? A human cannot tell.

Follow-up from the same human, and the honesty in it is the useful part:

"I think the animation speeds up to the finished state. So it is not a snap in the sense of a cut, but rather becoming much quicker — which however feels instant too, so it is difficult to discern by a human. It might also actually snap/cut to the finished state, but appear as a quick animation… Similar to how videos work by quickly playing distinct frames. So I cannot tell certainly which it is. Upon multiple attempts it does look more like a snap. Decoder still should verify."

This is a question the oracle-by-eye cannot answer, and it is being handed over as such rather than guessed. A three-frame acceleration and a one-frame cut are indistinguishable to a person; they are trivially distinguishable to an instrument. Two independent routes, and they should agree:

1. Per-frame capture. Press Ⓐ mid-build-in and read the submitted alphas frame by frame. An acceleration shows intermediate values; a cut shows one transition and none. This is a counting question — see TEMPORAL-VERIFICATION.md, and note that the eye failing here is exactly why.
2. The code. Whatever Ⓐ does to the clock is a store somewhere: does it assign the target time, or raise a rate multiplier? A snap and a speed-up are different instructions, and the image says which.

⚠️ The human's "looks more like a snap on multiple attempts" is a prior, not a result. Do not let it stand in for the measurement, and say so if the measurement disagrees with it.

F6 — 🔴 The title's sweeping glow starts TOO EARLY in the port

"…blue geometric lines (like on a PCB, straight lines and rectangular or 45° turns). These have a white glow moving on them as an animation. In the game this animation only starts when the plate is shown — basically the animation starts the same as the 'insert' of the plate. In the port it already starts before the plate arrives."

The elements are ptloop01 and ptloop02 — already known to this corpus as the sweeps whose leaf "sweeps a 400 px quad whose left edge travels −639…1521", and whose free-running on the settled title is a ❌ entry in REFUTED.md (they do free-run). Nothing there says when they start, and that is the whole of this finding.

📌 A lead, from the exported declaration — MINE, unverified, check it first

title.json gives ptloop01 and ptloop02 keyframes at:

t = 0, 70, 100, 238, 250

and the plate reaches full alpha at t = 236. They are not alone: pteff02 has a key at exactly 236, and ptlogo_back2eff and ptcopyright at 238. 236–238 is a synchronisation point in the declared data, and the human has just reported a behaviour change at that instant.

So the first question is cheap: is the sweep's motion declared to begin at 238, with the port instead free-running the leaf from t=0? If so this is a decode question with a decoded answer, and nothing needs authoring.

⚠️ Two reasons not to take that lead as the answer. The 238…250 pair looks just as much like an exit ramp — ptcopyright and ptlogo_back2eff use exactly that shape and they are certainly not starting anything. And the sweep lives in a nested .rat leaf with its own three keyframes, so the parent's envelope and the leaf's motion are different timelines. Which of the two the human is watching is the thing to establish.

Why this one is worth prioritising

It bears directly on F4 and on clock: "shared". If a title element does not begin moving until the plate arrives, then either the declared data says so — in which case the shared clock survives and our reading of the keyframes is wrong — or something at the plate's arrival starts it, which is a mechanism nobody has proposed. Either answer constrains the clock question that F4 is also probing.

H3 — the plate delay is ACCEPTED

"Delay feels the same. Cannot verify it is exact same, but is sufficient."

Good enough to stop working on, not established as correct. Leave the row as unattributed rather than closing it green; if the duration question is ever settled by the pipeline work, check it against this rather than re-opening it from scratch.