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).