Implement Channel Points Twungeon MVP

.labyricorn/README.md

@@ -6,9 +6,10 @@ This repository owns the public project page and development log for Twungeon.
 - `.labyricorn/devlog/contents.lr` is the development-log index.
 - Each directory below `.labyricorn/devlog/` is one chronological entry.
 
-The project is currently in pre-implementation planning. The PRD and MVP
-definition are complete, the technical specification is approved, and a
-traceable acceptance-test/build checklist now defines the route into
-implementation. Runtime behavior and live Twitch integration are not yet
-claimed complete. Future work should add dated devlog entries as the project
-moves through implementation, testing, release, and maintenance.
+The project now has a runnable local proof of concept backed by an authoritative
+TypeScript game core, deterministic floor generation, production-shaped APIs,
+and shared broadcast/controller views. Its Twitch boundary supports chat,
+follower checks, Extension identity, and a configured Channel Points
+resurrection reward. Automated checks cover the implemented local behavior;
+live-channel, independent-operator, usability, and real-viewer acceptance remain
+future evidence. Add dated devlog entries as those milestones occur.

.labyricorn/project/contents.lr

@@ -18,7 +18,7 @@ repository_url: https://git.labyricorn.com/Labyricorn/Twungeon
 ---
 default_branch: main
 ---
-tags: Twitch, Twitch Extension, RPGJS, Twurple, TypeScript, game design, pre-development, PRD, MVP, planning, architecture, acceptance testing, documentation
+tags: Twitch, Twitch Extension, Channel Points, RPGJS, Twurple, TypeScript, game development, proof of concept, MVP, architecture, acceptance testing, documentation
 ---
 body:
 
@@ -30,20 +30,22 @@ exit.
 
 The MVP is designed to prove the complete interaction loop with real Twitch
 viewers: eligibility, identity binding, spawning, movement, combat, healing,
-death, Bits resurrection, floor advancement, and total-party reset. It uses a
-deliberately small two-room floor with one Goblin Guard so the project can test
-the social game idea before investing in balance, polish, progression, or
-production art.
+death, Channel Points resurrection, floor advancement, and total-party reset.
+It uses a deliberately small two-room floor with one Goblin Guard so the
+project can test the social game idea before investing in balance, polish,
+progression, or production art.
 
 The stream-facing experience has three required regions: a compact
 control/status area, the shared game view, and a running action log. When no
 players are active, the current floor remains loaded in a dormant state and
 invites an eligible follower to type `!spawn`.
 
-The initial technical direction is RPGJS for the prototype game environment,
-Twurple for Twitch integration, and a Twitch Extension for player controls.
-The design keeps Twungeon's game rules separate from RPGJS where practical so
-the prototype can be replaced without discarding the validated concept.
+The runnable proof of concept uses an authoritative TypeScript game core,
+deterministic two-room floor generation, HTTP and WebSocket boundaries, and a
+shared broadcast/controller interface. Twurple supplies the production Twitch
+boundary for chat, follower verification, Channel Points redemptions, and a
+Twitch Extension identity flow. The RPGJS boundary remains an authority-free
+render adapter rather than a completed engine integration.
 
 The product source of truth is the
 [Twungeon MVP Product Requirements Document](https://git.labyricorn.com/Labyricorn/Twungeon/blob/main/Twungeon_MVP_PRD_Current.md).
@@ -53,7 +55,8 @@ defines the authoritative architecture and game behavior. The
 [acceptance-test and build checklist](https://git.labyricorn.com/Labyricorn/Twungeon/blob/main/Twungeon_MVP_Acceptance_Test_and_Build_Checklist.md)
 sequences implementation and maps evidence to all 33 MVP success criteria.
 
-The project remains in pre-implementation planning. These documents establish
-the build baseline, but they do not claim that runtime behavior, Twitch
-integration, or viewer validation is complete. Future records will document
-implementation, testing, release preparation, and maintenance as they occur.
+The repository can run locally with synthetic viewer identities and has passing
+lint, type-check, domain, integration, and production-build gates. This is a
+proof of concept, not an accepted MVP: live Twitch credentials, independent
+setup, first-time-viewer usability, and real-viewer concept validation have not
+yet produced acceptance evidence.