Sprint 4 Design Pack — GWP-163

Story narrative

GWP-163 is a container task, not an implementation task. It exists to give every v0.1-deferred feature exactly one canonical Notion home so the backlog doesn’t fork. Sub-tasks parented here include GWP-165 (mission board generation), GWP-167 (phase-chain hot-swap), GWP-171 (PCM voice barks — see Sprint 4 Wave 1 triage), GWP-172 (haptic feedback), GWP-173 (in-game music — see Sprint 4 Wave 2 triage), GWP-174 (12 deferred capability modules umbrella), GWP-175 (kn86-firmware tree — see also GWP-227), GWP-176 (Tauri flasher GUI), GWP-177 (bootfs/rootfs producer).

The 2026-04-25 reconciliation note in the task body already closes 4 shipped items (GWP-166 cipher grammar, GWP-168 REPL, GWP-169 nEmacs, GWP-170 token prediction) and lists the 9 remaining children. This is healthy — the catalog is doing its job.

The reason GWP-163 surfaced in this Sprint 4 candidacy review is not because it has work to do (it doesn’t — the constraint is “Catalog is read-only until v0.1 ships. No sub-task goes In Progress while GWP-152 is open.”), but because PM should periodically audit the catalog for accuracy and confirm the 9 remaining children are still valid deferral targets. The 2026-04-25 reconciliation was that audit; nothing has materially changed since.

Recommendation: leave GWP-163 in Planning, don’t dispatch. The next time it should surface for triage is when v0.1 ships (GWP-152 closes) — at that point the catalog graduates from “read-only inventory” to “active backlog feeder,” and PM does a fresh audit picking which children promote to active sprints first.

Acceptance criteria expanded (≥4 testable items with file paths)

These are the catalog’s standing acceptance criteria, restated and expanded against the current state:

1. Every deferred item has exactly one Notion task parented under GWP-163. Current state: 9 active children listed in the 2026-04-25 reconciliation note (GWP-165, 167, 171, 172, 173, 174, 175, 176, 177). Verified — the children are unique and each represents one logical feature. Pass.
2. No deferred item is represented in the backlog twice. Stale C-handler entries (GWP-87 / GWP-91 / GWP-95) are noted as superseded by the unified GWP-174 “12 deferred capability modules umbrella” rather than carrying duplicate Lisp-rewrite siblings. The reconciliation note handles this. Pass.
3. Catalog moves to Done only after all sub-tasks are promoted into active waves or reclassified as won’t-do. Current state: catalog is open, 9 children open, none promoted (correct — v0.1 not shipped). Pass.
4. Reconciliation cadence: the catalog gets re-audited at each major wave boundary (v0.1 ship; first post-v0.1 sprint; whenever a child triages out — e.g., GWP-171 stays deferred per Sprint 4 Wave 1, GWP-173 stays deferred per Sprint 4 Wave 2, both updates land in their own Notion bodies, not in GWP-163). The 2026-04-25 reconciliation was the most recent; next mandatory audit is at v0.1 ship.
5. The constraint “no sub-task In Progress while GWP-152 open” is respected. Current state: no sub-task is in In Progress. Confirm by querying Notion for parent == GWP-163 AND status == "In Progress" periodically. Pass at the time of this design pack.

Edge cases (≥2)

1. Deferred items that triage individually during open sprints (the GWP-171, GWP-173 pattern). When PM triages a single child during a sprint and decides “stays deferred until X,” the deferred-until note lives in the child’s body, not GWP-163’s. GWP-163 only tracks the roster of deferred items, not the per-item gates. This boundary is correct and should be preserved — adding per-item gates to GWP-163 would duplicate state and create a sync hazard.
2. Items that get reframed mid-deferral. If a deferred item’s scope changes substantively (e.g., GWP-173 is reframed from “in-game music” to “PSG-only ambient music + post-Pico mix story”), the right pattern is: edit the child’s title and body, leave the GWP-163 catalog row pointing at the same child. Don’t fork the child. The 2026-04-25 reconciliation note’s “see also GWP-227” cross-reference for GWP-175 is a good example of this pattern (GWP-175 still exists; GWP-227 is the active sibling).
3. Items that complete without explicit promotion. GWP-166 (cipher grammar), GWP-168 (REPL), GWP-169 (nEmacs), GWP-170 (token prediction) shipped during Sprint 1–3 work without first being “promoted” out of GWP-163 in a ceremonial way — they just got done as part of larger feature pushes. The 2026-04-25 reconciliation note correctly reflects this by closing them. The pattern is fine: if a child ships, mark it Done in the catalog and move on. The catalog doesn’t need a formal promotion ritual.

Engineering hand-off notes

No engineering brief. This is a meta-task.

• Owner: PM. The catalog lives in Notion; no source file represents it. (If we ever want a source-of-truth file, recommend docs/_meta/deferred-work-catalog.md mirroring the Notion children list, but there’s no demand right now.)
• Cadence: re-audit at major wave boundaries (v0.1 ship; first post-v0.1 sprint kickoff; any time a sub-task triages individually). Add a fresh callout block to the body each time a child closes or a triage happens.
• No PR. No code, no docs, no commit needed for this design pack beyond the file being landed for the Sprint 4 record.
• Test strategy: Notion query — confirm parent == GWP-163 returns exactly the 9 children listed in the 2026-04-25 reconciliation note (or whatever the current count is post-Sprint 4 triages).
• What “Sprint 4 dispatch” looks like for this task: nothing. This is filed under Wave 2 design enrichment because Josh added it to the Planning column for review, not because it needs work. The right answer is to mark it “audited 2026-04-27, no changes needed” and leave it.

Open questions for Josh

1. Confirm GWP-163 stays in Planning, not dispatched. Recommendation: leave as-is. No sprint slot needed. The 2026-04-25 reconciliation is still current.
2. Should GWP-163 mirror to a docs/_meta/deferred-work-catalog.md source file? Recommendation: no, until there’s demand. The Notion view is the canonical home; an _meta mirror would create a sync hazard. Re-evaluate post-v0.1 if the catalog graduates to a longer-lived planning surface.
3. Trigger for next audit: v0.1 ship date (whenever GWP-152 closes), or sooner if Josh wants. Confirm v0.1 ship is the next audit trigger.