Sprint 4 Design Pack — GWP-173

Triage decision: STAYS DEFERRED

This task has no body in Notion (the cell is empty) — it exists as a stub child of GWP-163’s deferred-catalog umbrella. The single-line title in the catalog reads: “In-game music system — ambient / tempo tracks beyond per-event PSG SFX.” After reading the catalog parent, ADR-0017, and the existing audio surface in docs/software/api-reference/grammars/coprocessor-protocol.md, the recommendation is to leave GWP-173 deferred and remove it from Sprint 4 candidacy. Three reasons, mirroring GWP-171’s verdict but with one wrinkle:

1. Same architectural-drift gate as GWP-171, plus an additional one. The sibling task GWP-171 (PCM voice barks) was deferred this sprint because the April 13 spec assumed YM2149-as-DAC playback that ADR-0017 obsoleted. GWP-173 has no spec at all yet — there’s no design document to update, just the line in the catalog. Before this can sprint, somebody has to write the spec from scratch in the post-ADR-0017 audio world (Pico 2 owns YM2149 synthesis with I2S out to MAX98357A; the Pi never touches the audio stack). Authoring a music-system spec into a phantom audio architecture is wasted cycles.
2. Music is a polish layer, not a v0.1 ship gate. The Cipher voice (CIPHER-LINE OLED, ADR-0015), the per-event PSG SFX (the existing sfx-* and sound-* primitives in ADR-0005), and the Pico-driven YM2149 synthesis are the canonical voice surfaces of the deck. Music — ambient layer, mission-tempo tracks, publisher splash stings beyond a 2-second beep — is a supplement to those, not a need-to-ship for v0.1. Defer matches the deck’s intent: the amber screen, the OLED, and short PSG SFX carry the audio identity; an ambient music layer is a future enhancement.
3. Hardware bring-up is on the critical path. Until Stage 1c bring-up validates real audio path latency and headroom on the Pico → I2S → MAX98357A chain (target Sprint 5–6 territory based on ADR-0017’s amendment plan), there’s no way to design realistic music-playback budgets. Music has different constraints than voice barks (longer sample tables, looping behavior, envelope automation, tempo synchronization to gameplay events) and they can’t be costed against a phantom audio stack.

The wrinkle vs GWP-171: PSG-only music is theoretically possible today (the YM2149 has 3 tone channels + envelope, which is the original sound chip on Yamaha CX5M / MSX-AUDIO and the sound chip on Atari ST / Amstrad CPC — entire chiptune scenes existed on it). If Josh wants a PSG-only music option, it could ship pre-Pico-bring-up by composing tracks against the existing psg-write and sound-tone primitives and authoring a “music tracker” or .ymp (YM-pattern) data block in cart format. That’s a smaller, sprintable design — but it’s not what this task asks for. The task title says “beyond PSG SFX” which I read as “more than 1-shot SFX cues; ambient/tempo layered alongside SFX.” That probably means PSG + sample mixing, which needs the Pico audio path.

Recommendation

• Keep status as Planning / Priority Low. No change to Notion task state.
• Do not include in Sprint 4 dispatch.
• Add a “stays deferred until X” note to the Notion task body so the next triage pass knows the gate.
• Owner of the unblock: Gameplay Design (spec author) + Platform Engineering (audio path costing) after Pico bring-up validates the audio chain on real hardware.
• If Josh wants PSG-only music to ship sooner, that’s a separate, smaller task — file as new work, not as GWP-173. The “beyond PSG SFX” framing in this task’s title rules out the PSG-only path by definition.

Stays-deferred-until conditions (the gate)

GWP-173 becomes sprint-ready when all of the following are true:

1. ADR-0017 audio path measured on prototype. Stage 1c bring-up has captured real Pico → I2S → MAX98357A latency, jitter, and power figures under PSG-synthesis-plus-PCM-mix workload. We know what mixing budget the audio stack actually has.
2. CIPHER-LINE OLED voice has shipped and been playtested. The text-voice surface (ADR-0015) is on the device and Josh has played enough sessions to call its narrative weight sufficient or insufficient. If sufficient, music is a polish-tier nice-to-have; if insufficient, music gets a stronger justification in the playloop.
3. Spec authored from scratch under the post-ADR-0017 audio world. Half-day session by Gameplay Design + Platform Engineering producing a new docs/software/runtime/in-game-music.md covering: (a) PSG-track + PCM-mix architecture (the Pico can mix one or more PCM streams with the YM2149 synth output before I2S out); (b) cart-side music data format (.kn86music block? extension to existing .kn86 static-data sections?); (c) playback primitives (Lisp-side music-play <handle>, music-fade <ms>, music-stop); (d) authoring tooling (compose → pack into cart → audition on emulator); (e) memory + power budget under typical workload; (f) interaction with PSG SFX (does music duck for SFX? mix at fixed levels? channel-priority rules?); (g) loop semantics (sample-perfect loop points vs. cross-fade); (h) tempo-sync to gameplay events (does music change beat on phase advance? on threat-level escalation?). This is the load-bearing piece of work — the implementation is meaningless without a clear gameplay spec.

Edge cases (≥2)

1. No existing spec to mark as stale. Unlike GWP-171 (which has pcm-voice-bark.md to flag with a banner), GWP-173 has no doc to update — the only artifact is the one-line entry in the GWP-163 deferred catalog. The deferred-until note in the Notion task body is the sole load-bearing artifact of this triage. Make sure it gets appended.
2. Author tooling implications, again. Same shape as GWP-171’s edge case: when GWP-173 unblocks, an authoring-tools sub-task spawns (compose → pack into cart → audition on emulator → ship). Music is harder than barks because compositions are longer, have loop points, and may need tempo-sync hooks. Worth flagging now so it’s not a surprise then.
3. Setec Astronomy / Marty Glitch fiction tension. The publisher splash for Setec Astronomy uses a “wobbling detuned C5 on Channel B” for the anagram-reveal beat. If music is on the deck eventually, the splash beats become a music-system showcase rather than a hand-rolled PSG arrangement. Not a blocker — just a fiction beat to remember when GWP-173 unblocks.

Engineering hand-off notes

No engineering brief in this sprint. Hand-off when the gate conditions clear:

• Lead at unblock time: Gameplay Design for the music spec (when does music play? how does it interact with phase changes / Cipher voice / PSG SFX? what’s the sample / track library shape?) + Platform Engineering for the audio-path costing (consulting).
• First action when unblocked: write docs/software/runtime/in-game-music.md from scratch (no prior spec exists to amend). Then re-cost.
• Add a follow-on task at unblock time for cartridge-authoring tooling (compose → pack into cart’s static data section → audition on emulator).
• Tag the task to GWP-163’s deferred-catalog parent so the catalog stays the canonical anchor.

Open questions for Josh

1. Confirm: defer this one. Recommendation is to leave GWP-173 in Planning/Backlog until the gate fires. Confirm or override.
2. PSG-only music option as a separate task? If Josh wants ambient PSG music now (before Pico audio path is validated), that’s a distinct, smaller task — recommend filing as new work and tagging GWP-173 as “tracks the post-Pico mix story.” Confirm whether to spin that off.
3. Does any v0.1 launch cart depend on music? Current launch-titles design bibles do not assume music playback (they describe SFX cues only) — confirm.