# 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`](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`](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.