Sprint 4 Design Pack — GWP-171

Triage Decision: STAYS DEFERRED

This is a deferral-confirmation pass, not a design pack. After reading the existing spec at docs/software/runtime/pcm-voice-bark.md (Status: PROPOSED, Apr 13 2026) and the architectural context, the recommendation is to leave GWP-171 deferred and remove it from Sprint 4 candidacy. Three reasons:

1. Architecture has shifted under the original spec. The April 13 PCM-voice-bark spec is built around the YM2149 4-bit-DAC playback trick — commandeering Channel C’s amplitude register and feeding 4-bit samples at 8 kHz. ADR-0017 (Accepted 2026-04-19) reassigns YM2149 synthesis to the Pico 2 coprocessor with I2S out direct to the MAX98357A DAC/amp. In that world the YM2149-as-DAC technique is moot — the MAX98357A is a real DAC, fed from I2S, so PCM playback becomes a cleanly-defined Pico-side feature rather than a register-write hack. The existing spec needs a full architectural rewrite before it’s actionable; it can’t be sprinted as written.
2. Cipher already has a voice and it’s load-bearing-text. The narrative driver — CIPHER-LINE on the auxiliary OLED (ADR-0015) — is the canonical voice surface. Barks are a supplement, not a need-to-ship for v0.1. Defer matches the device’s intent: the amber screen (and now the OLED) carry the voice; PCM barks are a polish layer for after the prototype is alive.
3. Hardware bring-up is on the critical path. Until Stage 1c bring-up validates real audio path latency 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 bark-playback budgets. Designing into a phantom audio stack is wasted cycles.

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 — see below — so that the next triage pass knows the explicit gate.
• Owner of the unblock: Platform Engineering, after Pico audio path is validated on real hardware.

Stays-deferred-until conditions (the gate)

GWP-171 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. We know what the audio stack actually looks like under load.
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. Barks remain a supplement — we should not commit to building them before we know the OLED voice alone isn’t enough.
3. Existing PCM-voice-bark spec rewritten for the I2S/MAX98357A path. The April 13 spec assumes a YM2149-DAC playback model that ADR-0017 obsoleted. Before sprint dispatch, somebody (Gameplay Design + Platform Engineering, half-day session) needs to update docs/software/runtime/pcm-voice-bark.md to: (a) move playback from YM2149 reg-10 abuse to a Pico-side PCM channel mixed alongside the YM2149 PSG output before I2S; (b) revisit sample-rate and bit-depth budget (the I2S path can carry 16-bit/22 kHz easily — the 4-bit/8 kHz constraint was a YM2149 artifact); (c) update the cartridge flash bark-table layout if needed (likely simpler now); (d) re-decide max bark count and total bark-table footprint given the storage shift to USB-MSC SD per ADR-0019.

Edge Cases (≥2)

1. The existing pcm-voice-bark.md is now stale. It carries Status: PROPOSED but its technical foundation (YM2149-as-DAC) is wrong post-ADR-0017. Two options: (a) leave it as a historical-context doc with a banner pointing at this triage note, or (b) move it to docs/_archive/. Surfaced to Josh below — recommendation is (a) until the rewrite happens, because the gameplay rationale (when barks fire, narrative role, design constraint of “supplement, never replace”) is still right and worth preserving.
2. Author tooling implications if barks ship. The current cartridge-authoring chain has no story for how a cart author records or commissions a bark sample, packs it into the .kn86 container, or auditions it on the emulator. Whenever GWP-171 unblocks, an authoring-tools sub-task will spawn. Worth flagging now so it’s not a surprise then.

Engineering Hand-off Notes

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

• Owner at unblock time: Platform Engineering for the audio-path rewrite (lead) + Gameplay Design for the bark-firing rules and authoring UX (consulting).
• First action when unblocked: rewrite docs/software/runtime/pcm-voice-bark.md § 2 Technical Approach to use the Pico/I2S/MAX98357A path. Then re-cost.
• Add a follow-on task at unblock time for the cartridge-authoring tooling (record → 4-bit (or 16-bit) sample → pack into .kn86 bark table → emulator audition).

Open Questions for Josh

• Confirm: defer this one. Recommendation is to leave GWP-171 in Planning/Backlog until the gate fires. Confirm or override.
• Stale spec disposition. Leave docs/software/runtime/pcm-voice-bark.md in place with a “needs ADR-0017 rewrite” banner, or move to docs/_archive/? Recommendation: leave in place + banner.
• Should Bareterm or any v0.1 launch cart depend on PCM barks? If yes, the gate accelerates; if no, the gate stays patient. Current launch-titles design bibles do not assume bark playback — confirm.