Document MVP planning milestones

2026-08-17 01:09:07 -07:00
parent f3688cd62b
commit 21b845d16e
2 changed files with 104 additions and 0 deletions
@@ -0,0 +1,51 @@
+_model: devlog-entry
+---
+schema_version: 1
+---
+title: Twungeon adopts an acceptance-led MVP build plan
+---
+date: 2026-08-17
+---
+author: ChatGPT 5.6 Sol High Reasoning and Christopher Chambers
+---
+summary: With the technical specification approved, Twungeon gained a sequenced ten-phase build checklist and 33 traceable acceptance tests that define the evidence required before the MVP can be called complete.
+---
+tags: pre-development, technical specification, acceptance testing, build checklist, MVP, planning, Twitch, testing, documentation
+---
+source_commit: f3688cd62bccc25c22a9780f65d719104989104f
+---
+body:
+
+Twungeon's technical specification was approved as the implementation baseline,
+and planning moved into an acceptance-led build sequence. This remains a design
+and execution milestone: no runtime feature, Twitch integration, or viewer test
+is represented as complete merely because its checklist now exists.
+
+The build plan organizes implementation into ten gated phases after the planning
+baseline. It begins with reproducible tooling and a framework-independent domain
+core, then adds dungeon generation, the local turn loop, Goblin behavior, player
+and floor lifecycles, production-shaped APIs and views, Twitch identity and chat,
+Bits resurrection, and finally independent setup and real-viewer validation.
+Each phase has a checkpoint intended to catch failures before work moves into a
+more expensive external integration layer.
+
+The acceptance matrix assigns AT-001 through AT-033 directly to the PRD's 33
+success criteria. It distinguishes automated domain evidence from browser,
+clean-install, live Twitch, multi-viewer, documentation, usability, and concept-
+validation evidence. A mock cannot close a live Twitch criterion, and a checked
+item can be reopened if later evidence invalidates it.
+
+The plan also defines standard quality gates, evidence records, clean-checkout
+verification, change control, and the final MVP acceptance decision. Planning
+work is checked off where it is complete; every implementation and validation
+item starts unchecked.
+
+The execution baseline is the
+[Twungeon MVP Acceptance-Test and Build Checklist](https://git.labyricorn.com/Labyricorn/Twungeon/blob/main/Twungeon_MVP_Acceptance_Test_and_Build_Checklist.md),
+used with the approved
+[technical specification](https://git.labyricorn.com/Labyricorn/Twungeon/blob/main/Twungeon_MVP_Technical_Specification.md)
+and the authoritative
+[MVP PRD](https://git.labyricorn.com/Labyricorn/Twungeon/blob/main/Twungeon_MVP_PRD_Current.md).
+
+The repository baseline for this planning milestone is
+[commit `f3688cd62bccc25c22a9780f65d719104989104f`](https://git.labyricorn.com/Labyricorn/Twungeon/commit/f3688cd62bccc25c22a9780f65d719104989104f).
@@ -0,0 +1,53 @@
+_model: devlog-entry
+---
+schema_version: 1
+---
+title: Twungeon moves from product requirements into technical specification
+---
+date: 2026-08-17
+---
+author: ChatGPT 5.6 Sol High Reasoning and Christopher Chambers
+---
+summary: Technical specification work began for the Twungeon MVP, translating the approved product boundary into authoritative state, component contracts, deterministic game rules, integration boundaries, and a verification strategy.
+---
+tags: pre-development, technical specification, MVP, planning, architecture, Twitch, RPGJS, Twurple, testing
+---
+source_commit: f3688cd62bccc25c22a9780f65d719104989104f
+---
+body:
+
+With the MVP product boundary recorded, Twungeon moved into technical
+specification work. This is still pre-development: the new document describes
+how the required systems should behave and interact, but it does not claim that
+runtime implementation has begun or that Twitch integration has been proven.
+
+The draft establishes one backend as the authority for identities, game state,
+command ordering, random outcomes, phase transitions, and the action log. It
+separates framework-independent Twungeon rules from Twitch, RPGJS, transport,
+and presentation adapters so the prototype engine can later be replaced without
+discarding validated game behavior.
+
+Several rules that needed implementation precision are now explicit. Player
+commands are serialized and validated against the latest state; phase deadlines
+are decided at the backend boundary; attacks are orthogonally adjacent; players
+may share tiles while the Goblin remains blocking; and refreshes reconnect to an
+existing Twitch-user-owned character. The draft also defines late-spawn and
+resurrection timing, Goblin path selection, total-party-wipe ordering, seeded
+floor generation, structured events, and failure behavior.
+
+The specification maps the system into an authoritative backend, a Twurple
+adapter, an authenticated Extension gateway, a portable domain core, an RPGJS
+adapter, and shared broadcast and Extension views. A verification section ties
+unit, integration, live-channel, and multi-floor tests back to the PRD's 33 MVP
+success criteria.
+
+The working draft is recorded in
+[`Twungeon_MVP_Technical_Specification.md`](https://git.labyricorn.com/Labyricorn/Twungeon/blob/main/Twungeon_MVP_Technical_Specification.md).
+It is a technical planning baseline derived from the
+[current Twungeon MVP PRD](https://git.labyricorn.com/Labyricorn/Twungeon/blob/main/Twungeon_MVP_PRD_Current.md).
+Version-specific Twitch scopes, event configuration, the Bits price, and local
+endpoint values remain integration-time decisions that must be documented and
+verified before live acceptance testing.
+
+The repository baseline for this planning milestone is
+[commit `f3688cd62bccc25c22a9780f65d719104989104f`](https://git.labyricorn.com/Labyricorn/Twungeon/commit/f3688cd62bccc25c22a9780f65d719104989104f).