port: a capital letter hid a refuted claim; and band levels answer what alignment could not

Three findings, two of them defects in my own checkers.

Changing the KIND of quantity answered the P4 fidelity question on the first
attempt. Four attempts at sample-exact difference-signal alignment produced four
failures and no verdict -- well past the Decoder's rule that two failed attempts
at the same measurement are evidence the quantity is wrong, not the parsing. Band
energies need no alignment at all: both transcodes match their sources to 0.66 dB
worst-case across four bands, while an unrelated movie lands at 19-20 dB. Two
populations an order of magnitude apart, so the 1.5 dB tolerance sits between
measured values rather than being picked. Asserting in check-all with the known
negative on every run, not behind a flag. It also diagnoses the failure it
replaced: matching spectra mean same content at same level, so the difference
signal's failure is my alignment, now by evidence rather than assumption. The
difference path stays report-only. Band agreement cannot tell a faithful
transcode from one that kept the spectrum and mangled the waveform -- weaker than
P4 wanted, and what I can support.

check-claims held 'no loop-point field has been identified' in its register the
whole time and matched case-sensitively, so a capital N at the start of a sentence
hid a registered dead claim in BLOCKED.md -- the one document whose job is to say
what is still open. The correction had reached authored/audio.json and not the
blocked list, which is exactly the failure that file's own why warns about.
Matching is case-insensitive now and immediately surfaced five more unmarked
sites, including a whole DECISIONS section still describing the refuted state. All
six fixed: four tokened, two rewritten with the shipped values. Controlled with a
planted capitalised revival.

And --control caught its own harness: it perturbed only the first occurrence of an
anchor, and the Decoder's delivery heading now appears twice, so the check read the
untouched duplicate and passed a wrong contract. A perturbation that does not
reach every copy makes a check untestable silently. First time a control has
failed because of a change in someone else's document rather than my code.

Not accepted from the same message: the (A)-skips-a-movie row is NOT stale. It
reads (a) ANSWERED, cites Q9, and points at flow.json's skippable: true. Reported
back rather than quietly 'fixed' -- marking a live row stale is the error their
own message is about.

Every asserting check passes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF

docs/port/BLOCKED.md

@@ -122,7 +122,7 @@ HANDOFF.
 |---|---|---|---|
 | ~~P6 audio~~ | ~~which cue fires on move / confirm / back~~ | Q8 | ✅ **answered 2026-08-28** — the RE agent retracted "cannot be extracted". The waves are located in `Static.slb` by playing them: **move `0x1ec0`** (8 192 B, 0.533 s), **confirm `0x5d6c0`** (12 288 B, 1.016 s), **back `0x0ec0`** (4 096 B, 0.344 s), and ⬅➡ play nothing. Move and back reproduce across two boots. 🟡 that the cursor's wave is the cue *named* `SE_UI_CURSOR` is still a name match, and Ⓐ's wave is not separated between `SE_UI_DECIDE` and `SE_UI_SUB_WIN_OPN`. P6 can now export real audio; the exporter has to grow an SE path. **✅ TAKEN at P6, 2026-08-29.** The three offsets now live in `authored/audio.json` `se.*` — *not* in the exporter — because MISSION §3 puts a measured value in `authored/` and a measured offset compiled into a Rust `const` is a measurement wearing the costume of a decoded field. `sylpheed_formats::media::se_wave_riff` does the assembly. |
 | ~~P6 audio~~ | ~~which BGM the menu plays~~ | Q10 | 🔴 **THIS ROW WAS WRONG WHEN IT WAS WRITTEN, and the port acted on it.** It read *"not on the disc … the port is choosing a track, and that choice is authored"*, and P6 duly picked `BGM_001` and labelled it arbitrary. **The menu's music is `BGM_103`, and it is in HANDOFF at `9ca1eb5` — the exact commit this page says it was reconciled against.** Not stale: misread. HANDOFF's negative is bounded and the bound is the whole content of it — the *tables* (`SOUNDS`, `FILES`, bank headers) name no screen; `GamePart_Title`'s `sub_821C5580` carries `li r5, 1103`, cue 1103 is `BGM_103`, and `BGM_103.slb`'s two declared waves (3 876 864 / 3 930 112 B) are byte-for-byte the two streams the XMA probe saw decoding at the main menu. HANDOFF's own sentence: *"The port does not have to choose a track."* **The lesson is not "re-read HANDOFF" — this page's own staleness check passed.** It is that a row here must quote the reach of a negative, because a negative summarised without its bound reads as a bigger negative than it is. |
-| P6 looping | where a menu loop restarts | Q10 | ❔ **still open, and the port shipped the ugly answer on purpose.** No loop-point field has been identified in any bank — `BGM_001` is the one characterised end to end (fades out at 167.663 s into 6.15 s of silence) and nothing suggests `BGM_103` differs in kind. `authored/audio.json` sets `loop: "restart"` — replay from sample 0 — so the listener hears the fade-out and the trailing silence at the seam. **Trimming to the fade would sound better and be worse**: it would invent a loop point, and an invented one is indistinguishable from a decoded one a month later. What settles it: a loop-point field, or a capture of the real menu looping. ⚠️ **The cost is now measured, 2026-08-30.** The bed loops at 87.8 s against the track's own 87.7 — `loop: "restart"` behaves exactly as authored — and the seam is **36 consecutive near-silent 50 ms windows, 84.40–87.80 s**: about **3.4 seconds of silence** after a fade from RMS 2057 to 431. Long enough to read as the music having stopped rather than looped. That does **not** license trimming to the fade, which would still invent a loop point; it is recorded so the missing field's price is a number rather than an adjective. |
+| ~~P6 looping~~ | ~~where a menu loop restarts~~ | Q10 | ✅ **ANSWERED AND SHIPPED, and this row stood stale for days while the fix was live.** The loop is a **runtime** field — `loop_start`/`loop_end` in the XMA decoder context, set by `XMASetLoopData` — and for `BGM_103` it is **[9.44 s, 71.31 s], cycling every 61.87 s**. `authored/audio.json` has shipped `loop_start_s: 9.44` / `loop_end_s: 61.87` since, and its `loop_why` marks the dead sentence `[refuted]`. 🔴 **The correction reached the manifest and not this file**, which is the exact failure `audio.json`'s own `why` warns about — *a correction that does not reach the artifact a consumer reads has not been made*. Found by the Decoder reading my file, not by my checker: `check-claims` held the phrase but matched **case-sensitively**, and the copy here begins a sentence, so a capital **N** hid a registered dead claim in the one document whose job is to say what is still open. Matching is case-insensitive now, which immediately surfaced **five more** unmarked sites.
 | ~~P5 focus marker~~ | ~~the focus ring's spin PERIOD, and whether it loops~~ | Q1 + *"groups hold"* | ✅ **answered 2026-08-29, and NOT ON `main` YET.** The Decoder pointed at it over the message channel and the pointer resolves: branch `auto/no-disc-and-menu-captures`, commit **`4fa3099`** (branch head `66e74d4`), file `docs/re/focus-ring-spin-measured.md`, frames under `docs/re/captures/focus-ring/`. **The ring spins continuously — period 2.177 s wall-clock, eight evenly spaced autocorrelation peaks over nine revolutions**, with no angle estimated anywhere (both angle estimators failed their own controls and were not used). It also reconciles with the declared `t=120` without a new constant: 120 units = 60 rendered frames, which is 2.00 s at a true 30 Hz and 2.08–2.17 s at the 27.6–28.8 fps this emulator runs, so the measurement sits at the top of the predicted band. 🟡 The Decoder is explicit that this is *consistency, not closure* — the guest frame rate was not measured in the same run. ⚠️ **Do not read `captures/focus-ring/ring-20s-mean-uniform.png` as a frame**: the spin averages to a uniform circle, which is the finding, not a headless ring. **The port has not implemented this yet** — it still draws 0°, which the same corpus says is a pose the game never shows. That is next iteration's work and it is no longer blocked. |
 | ~~P3/P5 — the title screen~~ | ~~does the idle post-boot title show the `PRESS Ⓐ` plate?~~ | Q2 | ✅ **STALE — struck 2026-08-30, and it had been wrong for weeks.** Every factual claim in it is now false: the boot does **not** end on a plateless build 4, `press_start` is **not** unused, and the port **has** drawn two builds at once since the plate-delay work. Verified this iteration — `boot ends on title + press_start`, `overlay press_start … drew 1: ptbtn00`, plate region mean **95.70** against 33.6 for the bare title. 🔴 The row directly below it was already marked *answered and TAKEN* for the same question: two rows on one question, one struck and one live claiming the opposite, and the live one was the stale one. That is this page's own documented failure mode, caught by auditing it rather than by reading it. ⚠️ What remains open is a **different** question and has its own row: whether the plate *stays up* after its 8-unit window. |
 | P5 — Ⓑ on the main menu | ~~is Ⓑ what returns to the title, or the idle timer?~~ **how long does Ⓑ take?** | Q5 | 🟡 **the ORDERING is answered, the latency is not — and this row's own argument is refuted, 2026-08-30.** It reasoned that *"the title self-returns after ~8–10 s idle, so one unrecorded observation cannot separate them"*. HANDOFF `27938aa` measures the main menu as **not self-returning for ≥ 60 s untouched**, and places the ~8–10 s idle on the **title**, not the menu — so the confound the row was built on does not exist. Ⓑ is delivered (Canary logs `vk=5801`) and is the only input in ≥ 100 s before the return: **the ordering is measured**. What stays open is only the latency, from a backlogged run. `authored/flow.json` already implements the ordering and is now under-claiming rather than over-claiming. Surfaced by `blocked-provenance` at score 10.6 against `9a10258`, unread for a day. |
@@ -151,8 +151,8 @@ HANDOFF.
 
 | Milestone | Needs | HANDOFF | State |
 |---|---|---|---|
-| P4/P7 — transcode fidelity | **nothing from anybody; my instrument cannot answer yet** | `0159527` | 🔴 **THE GATE HAS NEVER CARRIED A FIDELITY CLAIM, and now it says so.** `AUDIO-VERIFICATION.md` §1 calls this the question P4 actually raised; nothing implemented it, and `verify-video-audio` explicitly declines it. `tools/port/verify-transcode-fidelity` exists and is **report-only**: best alignment is corr 0.763 on `S00A` and 0.075 on `ADV`, and both still report the difference *louder* than the source, which is impossible for two aligned signals at equal level — so the fault is on my side of the instrument, not necessarily in the transcodes. Four traps reproduced on the way, three of which §1 names and one (**`-ss` before `-i` returning 4.6 s for a 4.0 s request**) it does not. ⚠️ A tool printing "not faithful" in this state would put a **false defect on the exporter**. |
-| P4/P7 — a `§1` addition for the HUMAN | **add the imprecise-seek trap to `AUDIO-VERIFICATION.md` §1?** | `0159527` | 🟡 **proposed, not done.** §1 lists three ways the measurement lies; a fourth is now reproduced — a container-level seek returns a different span than requested, so the two windows cover different audio and no shift can align them (best corr 0.172). It is **indistinguishable from the alignment trap §1 already names**. §1 is the human's document, so this is a proposal rather than an edit. |
+| P4/P7 — transcode fidelity | ~~nothing from anybody~~ **the WAVEFORM half is still open** | `0159527` | 🟡 **PARTLY ANSWERED, by changing the kind of quantity.** Band energies need no alignment, and both transcodes match their sources to **0.66 dB worst-case across four bands** while an unrelated movie lands at **19–20 dB** — two populations an order of magnitude apart, so the 1.5 dB tolerance sits between measured values. Asserting in `check-all`, with the known negative on every run. ⚠️ **This is weaker than P4 wanted**: band agreement cannot distinguish a faithful transcode from one that kept the spectrum and mangled the waveform. The difference-signal half stays report-only and asserts nothing — and the band result now **proves** its failure is my alignment, since matching spectra mean same content at same level. Earlier text: 🔴 **THE GATE HAS NEVER CARRIED A FIDELITY CLAIM, and now it says so.** `AUDIO-VERIFICATION.md` §1 calls this the question P4 actually raised; nothing implemented it, and `verify-video-audio` explicitly declines it. `tools/port/verify-transcode-fidelity` exists and is **report-only**: best alignment is corr 0.763 on `S00A` and 0.075 on `ADV`, and both still report the difference *louder* than the source, which is impossible for two aligned signals at equal level — so the fault is on my side of the instrument, not necessarily in the transcodes. Four traps reproduced on the way, three of which §1 names and one (**`-ss` before `-i` returning 4.6 s for a 4.0 s request**) it does not. ⚠️ A tool printing "not faithful" in this state would put a **false defect on the exporter**. |
+| P4/P7 — a `§1` addition for the HUMAN | **add the imprecise-seek trap to `AUDIO-VERIFICATION.md` §1?** | `0159527` | 🟡 **proposed, not done — and NARROWED 2026-08-30 before it was written up.** The Decoder reproduced it independently (4.597 s on `ADV`, 4.256 s on `S00A` for a 4.0 s request, correlations −0.03 and −0.34 at zero shift: different content, not a shift) and established that the **VIDEO** container-seek on this disc is **exact** — byte-identical frames at 20 s. So the trap belongs to the **audio stream**, not to `-ss` placement, and the phrasing matters in the direction that bites: a check looking only at video would clear a path still unsafe for audio. Original: 🟡 **proposed, not done.** §1 lists three ways the measurement lies; a fourth is now reproduced — a container-level seek returns a different span than requested, so the two windows cover different audio and no shift can align them (best corr 0.172). It is **indistinguishable from the alignment trap §1 already names**. §1 is the human's document, so this is a proposal rather than an edit. |
 
 ## Not blocking, recorded so nobody re-investigates — 2026-08-30, HANDOFF `91ada14`
 

docs/port/DECISIONS.md

@@ -9,7 +9,7 @@ dies, which is what this file is for.
 
 <!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
 
-257 sections. Search this before re-deriving anything.
+260 sections. Search this before re-deriving anything.
 
 * [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
 * [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -268,6 +268,9 @@ dies, which is what this file is for.
 * [🔴 I measured my own claim and it is wrong: the player skips, heavily](#i-measured-my-own-claim-and-it-is-wrong-the-player-skips-heavily)
 * [🔴 Correcting the correction: the frame probe is an UPPER BOUND, and my contrast was contention](#correcting-the-correction-the-frame-probe-is-an-upper-bound-and-my-contrast-was-contention)
 * [The P4 fidelity question, attempted: four traps reproduced, no verdict yet](#the-p4-fidelity-question-attempted-four-traps-reproduced-no-verdict-yet)
+* [Changing the KIND of quantity answered it on the first attempt](#changing-the-kind-of-quantity-answered-it-on-the-first-attempt)
+* [🔴 My seek trap was over-general — the Decoder narrowed it](#my-seek-trap-was-over-general--the-decoder-narrowed-it)
+* [A capital letter hid a refuted claim in the file whose job is to say what is open](#a-capital-letter-hid-a-refuted-claim-in-the-file-whose-job-is-to-say-what-is-open)
 
 <!-- /INDEX -->
 ## P0 — the exporter, 2026-08-28
@@ -1594,7 +1597,15 @@ halving is a mix decision nobody made — and because a sum can clip, the peak i
 
 ### The loop seam is ugly on purpose
 
-No loop-point field has been identified. `loop: "restart"` replays from sample 0,
+🔴 **SUPERSEDED — see *"the menu BGM loop window"* below and `authored/audio.json`'s
+`loop_start_why`.** The loop point exists: it is a **runtime** field set by
+`XMASetLoopData`, and for `BGM_103` it is **[9.44 s, 71.31 s], cycling every
+61.87 s**, which the exporter has trimmed to since. This section is kept because
+it is what the port believed when it shipped the seam, and the reasoning below —
+that inventing a loop point is worse than an ugly one — is why the wait was
+cheap. Every claim in the paragraph that follows is dead.
+
+No loop-point field has been identified [refuted]. `loop: "restart"` replays from sample 0,
 so a listener hears the track's own fade-out and its trailing silence before the
 music comes back.
 
@@ -13250,3 +13261,139 @@ right move is to propose the addition rather than edit it silently.
 are faithful to their sources. After this iteration that is *less* settled than
 it looked yesterday, because the question now has an instrument that says it
 cannot answer yet, instead of no instrument at all.
+
+## Changing the KIND of quantity answered it on the first attempt
+
+The Decoder's rule, from two failed attempts of their own: **two failed attempts
+at the same measurement are evidence the quantity is wrong, not the parsing.** I
+was four attempts into sample-exact difference-signal alignment with no verdict —
+well past the point where that rule applies.
+
+So the quantity changed. **Band energies need no alignment at all**: a statistic
+over the window cannot be corrupted by a lag of any size.
+
+| band | `ADV` | `S00A` |
+|---|---|---|
+| 0–500 Hz | −0.15 dB | −0.02 dB |
+| 500–2 000 Hz | −0.28 dB | −0.15 dB |
+| 2 000–6 000 Hz | −0.66 dB | −0.22 dB |
+| 6 000–16 000 Hz | −0.63 dB | −0.29 dB |
+
+**Worst deviation 0.66 dB**, transcode consistently a fraction of a dB quieter,
+which is what lossy encoding should look like. The **known negative runs on every
+invocation, not behind a flag**: comparing each source against the *other* movie's
+transcode gives **20.02 dB** and **19.10 dB** — two populations an order of
+magnitude apart, so the 1.5 dB tolerance sits between measured values rather than
+being picked. Now an asserting step in `check-all`.
+
+### It also diagnoses the failure it replaced, by elimination
+
+Matching spectra within 0.66 dB mean the two decodes **are the same content at
+the same level**. So the difference-signal result — difference louder than source
+— cannot be a level mismatch or a content mismatch. **It is my alignment, and now
+that is evidence rather than my assumption.** The difference path stays in the
+tool, report-only, asserting nothing.
+
+⚠️ **The honest limit, stated in the tool's own output:** band agreement cannot
+distinguish a faithful transcode from one that preserved the spectrum and mangled
+the waveform. That is exactly what the difference signal was for, and it is still
+open. **This is a weaker claim than P4 wanted, and it is the one I can support.**
+
+## 🔴 My seek trap was over-general — the Decoder narrowed it
+
+I wrote *"`-ss` before `-i` is a container-level jump"* as though inexactness
+followed from the placement. They checked it on the same movies: the **video**
+container-seek here is **exact** — a frame taken at 20 s via container seek is
+**byte-identical** to one from a full decode, on both films.
+
+📌 So on this disc it is a property of the **audio stream**, not of `-ss`
+placement as such. The correction matters in the direction that bites: **a check
+that only looked at video would clear a path that is still unsafe for audio.**
+Narrowed in the tool's own trap list rather than in prose only.
+
+✅ Their reproduction is independent and closer than I expected — 4.597 s on
+`ADV` and 4.256 s on `S00A` for a 4.0 s request, against my 4.6 on a different
+file in a different container, with correlations −0.03 and −0.34 at zero shift.
+**Different content, not a shift**, which is the distinction that makes this trap
+imitate the one §1 names.
+
+📌 And their cheap defence for the boundary family is now in the tool: **print
+the search range beside the answer, so an edge reads as an edge.** The refusal
+path was already there; the range was not, and a refusal that does not say what
+it was searching is one an impatient reader widens by guessing. **Four instances
+between us now, and the control caught all four.**
+
+### 🔴 And the control caught its own harness
+
+`check_extras_resets` reported **`PASSES A WRONG CONTRACT — it checks nothing`**.
+Not a broken check: the Decoder's delivery heading now appears **twice** in
+HANDOFF, and `--control` perturbed only the **first** occurrence
+(`h.replace(old, new, 1)`), so the check found the untouched duplicate and passed.
+
+📌 **A perturbation that does not reach every copy of the anchor makes the check
+untestable, and does it silently — because the check keeps passing.** The only
+reason this surfaced is that the control asserts *the check must fail*, so a
+check that could no longer be broken became a loud failure instead of a quiet
+pass. Fixed to replace every occurrence, in both the HANDOFF and walk paths.
+
+⚠️ Worth naming: **this is the first time a control has failed because of a
+change in someone else's document rather than in my code.** The anchors couple me
+to their prose, which we both knew; what is new is that *duplicating* a sentence
+is enough to disarm a check without either of us touching a checked value.
+
+## A capital letter hid a refuted claim in the file whose job is to say what is open
+
+The Decoder read my `BLOCKED.md` and found the `P6 looping` row still asserting
+**"No loop-point field has been identified in any bank"** — days after
+`authored/audio.json` shipped `loop_start_s: 9.44` / `loop_end_s: 61.87` and
+marked that very sentence `[refuted]` in its own `why`.
+
+📌 **The correction reached the manifest and not the blocked list**, which is the
+exact failure `audio.json`'s `why` warns about in its own text: *a correction that
+does not reach the artifact a consumer reads has not been made.* I wrote that
+sentence and then did it.
+
+### 🔴 And my checker held the phrase and could not see it
+
+`check-claims` has carried `no loop-point field has been identified` in its
+register the whole time. It matched **case-sensitively**, and the copy in
+`BLOCKED.md` begins a sentence — so **a capital `N` hid a registered dead claim**,
+and the check reported clean on every run.
+
+This is the Decoder's finding of the same day in its cheapest possible form.
+Theirs was a register missing a revival that kept the claim and changed the second
+clause; mine was one letter. **A register matching exact wording does not protect
+the documents that rewrite most, and capitalising a sentence is the smallest
+rewrite there is.**
+
+✅ Matching is case-insensitive now, and it **immediately surfaced five more
+unmarked sites** the old check had never been able to see:
+
+| | |
+|---|---|
+| `authored/flow.json`, `authored/timing.json` | *"the boot is KNOWN TOO FAST [refuted] on both splashes"* — inside its own withdrawal, untokened |
+| `tools/port/verify-screen` | *"composited rather than standalone"* [refuted] — likewise |
+| `tools/port/check-claims` | my new comment quoting the phrase while explaining it — the recursion, again |
+| `docs/port/DECISIONS.md` | **a whole section, *"The loop seam is ugly on purpose"*, still describing the refuted state** |
+
+All six fixed: five tokened, and the two that were **stale rather than
+un-tokened** — the `BLOCKED` row and the `DECISIONS` section — rewritten with the
+shipped values and the supersession stated. Controlled: a planted **capitalised**
+revival fails the check, and removing it passes.
+
+### What I am not accepting from the same message
+
+⚠️ They also flagged **"P4/P7 video — whether Ⓐ skips a movie"** as stale in my
+file. **It is not.** That row reads *"🟡 (a) ANSWERED, (b) still open"*, cites
+HANDOFF Q9, and points at `authored/flow.json`'s `skippable: true` with its `why`
+carrying the 57 s against 193 s baseline. The open half **(b)** is a different
+question. Reported back rather than quietly "fixed", because accepting a
+correction to a row that is already right would put a false stale-marker on a
+live one — and their own message is about an index amplifying exactly that kind
+of error.
+
+📌 Their root-cause note is worth keeping and applies to my pages too: **a
+negative about the METHOD written as a negative about the SUBJECT.** *"`Static.slb`
+resists static scanning"* became *"SE audio is not extractable"* — and the wrong
+one was the heading. Every ❔ row I write asserting something *cannot be known*
+should be checked for whether it means *my instrument cannot see it*.