docs: the fix for original_audio is removal, not adoption

The spec already carries the pre-separation mixdown as a stem
({id: full, file: stems/full.ogg}), so the key added a second, redundant
location for audio to a format that already had one. Adopting it into the
spec would make that permanent; the resolution in #933 is to remove it.

No behaviour change — the gate is agnostic about which way a violation
resolves, and only insists that one of the two happens deliberately and in
the open before the code merges. This just stops the exception entry, the
changelog, and the docs from presupposing adoption.

Signed-off-by: topkoa <topkoa@gmail.com>

CHANGELOG.md

@@ -21,7 +21,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   A key that must ship ahead of the spec uses the reserved `x-` prefix (always allowed) or is recorded in
   `feedpak-spec-exceptions.yml` with a tracking issue — and the gate fails if such an exception goes stale,
   so the allowlist can't become somewhere drift hides. `original_audio` is seeded there against #933 so the
-  gate lands green and starts blocking the *next* instance immediately. Docs: [docs/feedpak-spec-gate.md](docs/feedpak-spec-gate.md).
+  gate lands green and starts blocking the *next* instance immediately; the gate takes no position on how
+  #933 resolves (the expected outcome is removing the key, since the spec already carries the mixdown as a
+  stem — not adopting it). Docs: [docs/feedpak-spec-gate.md](docs/feedpak-spec-gate.md).
 
 ### Removed
 - **The classic v2 UI shell is gone — v3 is the only UI (R3a).** `static/index.html`, the

docs/feedpak-spec-gate.md

@@ -23,6 +23,13 @@ The moment core reads a manifest key the spec doesn't define, that promise break
 The rule this gate enforces: **any manifest key core reads must be in the spec before core ships code that
 depends on it.** Spec first, implementation second.
 
+Note that "get it into the spec" is not automatically the right fix for an existing violation — for
+`original_audio` it isn't. The spec already carries the pre-separation mixdown as a stem
+(`{id: full, file: stems/full.ogg}`), so that key added a *second, redundant* location for audio to a format
+that already had one, and the resolution is to remove it rather than bless it. The gate takes no position on
+which way a violation resolves; it only insists that one of the two happens deliberately, in the open,
+before the code merges.
+
 ## What it checks
 
 We can't mechanically prove core *interprets* a key the way the spec means. We can prove three surface

feedpak-spec-exceptions.yml

@@ -25,6 +25,13 @@ exceptions:
       Added by #583 (the full mix played while every stem fader sits at unity,
       since demucs recombination is lossy). Core, lib/enrichment.py, and the
       stems plugin all depend on it, but it was never added to the spec — the
-      drift this gate exists to prevent. Seeded here so the gate lands green and
-      starts blocking the *next* instance immediately; remove once the spec
-      adopts the key.
+      drift this gate exists to prevent.
+
+      The expected resolution is REMOVAL, not adoption: the spec already carries
+      the mixdown as a stem ({id: full, file: stems/full.ogg}), so this key added
+      a second, redundant location for audio to a format that already had one.
+      See #933.
+
+      Seeded here so the gate lands green and starts blocking the *next* instance
+      immediately, rather than blocking on #933. The entry goes away when core
+      stops reading the key.