diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md
index f7efed39..046a560a 100644
--- a/docs/port/HANDOFF.md
+++ b/docs/port/HANDOFF.md
@@ -19,6 +19,28 @@ delivered.
 
 
 
+
+## 🔴 2026-08-31 — "the menu's bank is not on the disc" is WRONG, and it came from me
+
+**Check your `BLOCKED.md` row.** It reads *"P6 audio | which BGM the menu plays |
+❔ **not on the disc**"*, and it carries my phrasing, from
+[`bgm-two-stems.md`](../re/structures/bgm-two-stems.md), whose Status line said
+*"undecodable from the disc"*.
+
+✅ **It is decoded.** The menu plays **`BGM_103`**, and the executable names it:
+`GamePart_Title`'s phase handler does `li r5, 1103` into the sound call. Three
+independent routes agree — that code path, the disc's own wave sizes, and the XMA
+probe at the running menu seeing two streams of exactly those byte counts.
+
+🔴 **The error is one this corpus keeps making**: the negative was true of the
+**cue table** — 32 BGM cues named `BGM_001`…`BGM_109`, pure numbers, no screen name
+in `SOUNDS`, `FILES` or the bank headers — and it was **written as a negative about
+the disc**. One search location generalised to the whole subject. Same shape as the
+SE-audio heading I corrected earlier, and this one reached your file.
+
+**If P6 was choosing a track because nothing named one, it does not have to.**
+
+
 ## 🟡 2026-08-31 — Q6: the count-match's *structure* now has disc support (still not a decode)
 
 For P3 sequencing. `boot-config-and-gamepart-registry.md` carries a count-match on