diff --git a/Twungeon_MVP_Acceptance_Test_and_Build_Checklist.md b/Twungeon_MVP_Acceptance_Test_and_Build_Checklist.md
index d7ae6c7..b6c9e6a 100644
--- a/Twungeon_MVP_Acceptance_Test_and_Build_Checklist.md
+++ b/Twungeon_MVP_Acceptance_Test_and_Build_Checklist.md
@@ -231,14 +231,14 @@ target death, return, death, and escape with the Goblin alive.
- [ ] Generate the next floor and Goblin.
- [ ] Revive, heal, reposition, and refresh self-heal for all participants on
floor advancement.
-- [ ] Reset to a new Floor 1 run immediately after the last participant dies.
-- [ ] Distinguish zero participants from a total-party wipe.
+- [ ] Return the current floor to dormancy immediately after the last participant dies.
+- [ ] Distinguish initial dormancy from defeated-party dormancy.
- [ ] Preserve character identity and state across simulated client reconnects.
- [ ] Verify expected new-run behavior after a simulated backend restart.
- [ ] Run a deterministic multi-floor soak test.
**Checkpoint P6:** A local driver can repeat the entire gameplay loop through
-spawn, action, death, resurrection or advancement, new floors, and wipe reset.
+spawn, action, death, dormant defeat, resurrection or advancement, and new floors.
### Phase 7: Backend API, state stream, and UIs
@@ -403,8 +403,8 @@ successful connection logs.
- [ ] Start with zero participants and wait longer than a maximum Player Phase.
- [ ] Confirm the floor remains loaded, no timer or Enemy Phase runs, the Goblin
- does not act, and the exact `Type !spawn to spawn in the Twungeon!` banner is
- shown.
+ does not act, and the exact two-line `Activate the Extension to spawn your character in the Twungeon!`
+ and `Must be a follower to spawn.` banner is shown.
**Level:** Automated domain/integration plus visual review
**Pass evidence:** State assertions, elapsed-time logs, and screenshot.
@@ -603,25 +603,25 @@ successful connection logs.
**Level:** Automated integration plus live Channel Points redemption
**Pass evidence:** Redacted event, deduplication log, and before/after state.
-### AT-026 — Total-party wipe reset
+### AT-026 — Total-party defeat dormancy
**PRD criterion:** 26
- [ ] Kill the final living participant before exit.
-- [ ] Confirm an immediate new run on Floor 1, new floor/Goblin, every participant
- alive at full HP, refreshed heals, and one wipe/reset log sequence.
+- [ ] Confirm immediate dormancy on the current run and floor, no active timer,
+ every participant still dead, and one party-defeat log entry.
+- [ ] Resurrect one participant and confirm a fresh Player Phase begins.
**Level:** Automated E2E plus live scenario
-**Pass evidence:** Run/floor transition and participant snapshots.
+**Pass evidence:** Before/after phase, run, floor, participant, and log snapshots.
-### AT-027 — Zero players differs from wipe
+### AT-027 — Initial dormancy differs from defeated-party dormancy
**PRD criterion:** 27
-- [ ] Compare a new game with no participants to a run where the final player
- dies.
-- [ ] Confirm the first remains dormant on its current floor and the second
- resets immediately with participants restored.
+- [ ] Compare a new game with no participants to a run where the final player dies.
+- [ ] Confirm both are dormant, while only the defeated run preserves dead
+ participant records and a party-defeat log entry.
**Level:** Automated domain/integration
**Pass evidence:** Side-by-side state-transition assertions.
@@ -655,7 +655,7 @@ successful connection logs.
**PRD criterion:** 30
- [ ] Run a multi-floor soak containing spawns, concurrent actions, expiry,
- combat, heal, death, resurrection, escape, advancement, and wipe reset.
+ combat, heal, death, defeated-party dormancy, resurrection, escape, and advancement.
- [ ] Confirm integration, phase, player, Goblin, generator, and log invariants
remain valid throughout.
diff --git a/Twungeon_MVP_PRD_Current.md b/Twungeon_MVP_PRD_Current.md
index f65dd8f..16f452b 100644
--- a/Twungeon_MVP_PRD_Current.md
+++ b/Twungeon_MVP_PRD_Current.md
@@ -18,7 +18,7 @@ tracks build sequencing and evidence without replacing these requirements.
The MVP is intended to prove that the complete interaction loop works at a basic level:
-**Twitch viewer -> follower eligibility -> `!spawn` -> character control -> turn-based dungeon play -> combat -> healing -> death -> resurrection or floor advance -> new floor -> run reset**
+**Twitch viewer -> follower eligibility -> `!spawn` -> character control -> turn-based dungeon play -> combat -> healing -> death -> dormant defeat -> resurrection or a new adventurer -> floor advance**
The MVP is not intended to prove game balance, long-term progression, production presentation, or anti-exploit systems.
@@ -38,7 +38,7 @@ The MVP should demonstrate that multiple Twitch viewers can:
- resurrect through a configured Channel Points reward,
- advance the entire party by reaching the exit,
- revive dead players on floor advancement,
-- and reset the run when all participating players die.
+- and return the current floor to dormancy when all participating players die.
The MVP succeeds if these systems work together reliably enough to test the core concept with real Twitch viewers.
@@ -157,7 +157,7 @@ It must provide clear confirmation of significant game actions and state changes
- Goblin aggro or return behavior when useful,
- floor advancement,
- dormant-state changes,
-- and total-party wipe/run reset.
+- and total-party defeat/dormancy.
Example messages include:
@@ -202,7 +202,8 @@ When the first eligible player spawns:
A player who already died on the current floor remains dead and cannot use `!spawn` to re-enter.
-Zero active players is not considered a total-party wipe.
+Zero active players with no participant history and a defeated party are both
+dormant, but the latter preserves its dead character records and current floor.
The MVP maintains only one active floor at a time. No previous-floor simulation or multi-floor concurrent state is required.
@@ -510,20 +511,19 @@ Bits and Cheers are outside the MVP and must not trigger game-state changes.
---
-## 18. Total Party Wipe
+## 18. Total Party Defeat
If every active participating player is dead before any player reaches the exit:
-**The run resets.**
+**The current floor returns to the Dormant state.**
-On reset:
+On defeat:
-1. The floor counter returns to Floor 1.
-2. A new starting floor is generated.
-3. All participating players return alive.
-4. Player HP returns to full.
-5. Player self-heals refresh.
-6. A new Goblin Guard is generated.
+1. The current run, floor, and Goblin remain loaded.
+2. All defeated characters remain dead and retain their current-floor death markers.
+3. No phase timer runs and the Goblin does not act.
+4. A configured resurrection can revive a dead viewer and begin a fresh Player Phase.
+5. A different eligible viewer may spawn and begin a fresh Player Phase.
---
@@ -655,7 +655,7 @@ The MVP is successful if it demonstrates that:
4. Twungeon successfully receives the Twitch events and chat activity required by the MVP.
5. The Twitch Extension loads and communicates with the Twungeon backend.
6. The stream-facing game view presents the three-section MVP layout: control/status area, main game area, and running action log.
-7. With zero active players, the dungeon enters dormant mode, stops advancing turns, and displays the `Type !spawn to spawn in the Twungeon!` banner.
+7. With zero active players, the dungeon enters dormant mode, stops advancing turns, and displays a two-line banner: `Activate the Extension to spawn your character in the Twungeon!` and `Must be a follower to spawn.`
8. A Twitch follower can intentionally join with `!spawn`.
9. A non-follower cannot spawn a player character.
10. Duplicate spawning for the same Twitch user is prevented.
@@ -674,8 +674,8 @@ The MVP is successful if it demonstrates that:
23. Dead players return when the floor advances.
24. A player who died on the current floor cannot bypass death by using `!spawn`.
25. The configured Channel Points reward can resurrect the correct dead player during the current floor.
-26. A total-party wipe resets the run to Floor 1.
-27. Zero active players is distinguished from a total-party wipe.
+26. A total-party defeat returns the current floor to dormancy without reviving players or resetting the run.
+27. Initial dormancy is distinguished from defeated-party dormancy by preserved participant state and action-log history.
28. An eligible follower who has not died on the current floor can `!spawn` into an otherwise empty current floor.
29. Refreshes and temporary disconnects do not create duplicate characters or corrupt critical identity/game state.
30. The complete loop can repeat across multiple floors without breaking Twitch integration, turns, player state, Goblin state, floor generation, or the action log.
diff --git a/Twungeon_MVP_Technical_Specification.md b/Twungeon_MVP_Technical_Specification.md
index ef1dae2..7a15a46 100644
--- a/Twungeon_MVP_Technical_Specification.md
+++ b/Twungeon_MVP_Technical_Specification.md
@@ -49,7 +49,7 @@ The implementation must optimize for the following goals, in order:
- One character per Twitch user
- Twitch Extension controls
- Shared stream-facing game view and chronological action log
-- Dormant, Player Phase, Enemy Phase, floor transition, and run reset states
+- Dormant, Player Phase, Enemy Phase, floor transition, and administrative run reset states
- AP, movement, combat, AutoGuard, self-heal, death, and resurrection
- One Goblin Guard with guarding, pursuit, and return behavior
- Varied, navigable two-room floors
@@ -276,7 +276,7 @@ type PhaseState =
initialEligiblePlayerIds: string[]
}
| { kind: 'enemy'; phaseId: string }
- | { kind: 'transition'; reason: 'floor-advance' | 'party-wipe' }
+ | { kind: 'transition'; reason: 'floor-advance' | 'admin-reset' }
```
The backend uses a monotonic clock for elapsed phase timing. Wall-clock values
@@ -438,9 +438,9 @@ While no active character exists:
The first accepted `!spawn` creates a living character, removes the banner, and
starts a fresh Player Phase.
-The MVP has no voluntary leave or character-removal command. Temporary
-disconnects therefore do not create dormancy. A total-party death triggers a
-run reset rather than dormancy.
+Temporary disconnects do not create dormancy because disconnected living
+characters use AutoGuard. A total-party death does create dormancy while
+preserving the run, floor, Goblin, and dead character records.
### 9.2 Starting Player Phase
@@ -485,7 +485,7 @@ The living Goblin receives 2 AP and repeatedly selects one deterministic action
until it has no AP or no valid action.
After the Goblin finishes, Guard is discarded and a new Player Phase begins,
-unless the floor advanced or the run reset during the Enemy Phase.
+unless the floor advanced or the party became dormant during the Enemy Phase.
### 9.5 AutoGuard
@@ -633,25 +633,21 @@ When a living player enters the exit:
The previous Goblin and map are discarded.
-### 12.3 Total-party wipe
+### 12.3 Total-party defeat
After any death resolution, if participating characters exist and none is
alive, the backend immediately:
-1. enters transition state;
-2. creates a new run ID;
-3. sets the floor counter to 1;
-4. generates a new starting floor and Goblin;
-5. restores all participating players alive at 3 HP;
-6. clears death markers, AP, and Guard;
-7. refreshes all self-heals;
-8. places all players at the spawn tile;
-9. logs the wipe and reset; and
-10. begins a fresh Player Phase.
+1. enters Dormant state with no deadline;
+2. preserves the current run ID, floor, and Goblin;
+3. preserves each dead character and current-floor death marker;
+4. stops Enemy Phase processing immediately; and
+5. logs the party defeat.
-Because the reset is immediate, a Channel Points redemption cannot interrupt a
-completed total-party wipe. Zero participating characters is explicitly not a
-wipe.
+A valid Channel Points resurrection revives its owner and starts a fresh Player
+Phase from dormancy. A newly eligible viewer may also spawn into the current
+floor and resume play. Initial dormancy has no participants, while defeated-party
+dormancy retains dead participant records.
## 13. Randomness
@@ -771,7 +767,9 @@ starting an empty client-only log.
When phase is dormant, both applicable views prominently display exactly:
-`Type !spawn to spawn in the Twungeon!`
+`Activate the Extension to spawn your character in the Twungeon!`
+
+`Must be a follower to spawn.`
## 16. Failure and Recovery Behavior
@@ -879,10 +877,10 @@ Deterministic tests must cover:
- AutoGuard conversion, hit blocking, misses, and reset;
- player and Goblin hit probabilities through injected rolls;
- heal availability and floor refresh;
-- death, spawn lockout, resurrection, advancement, and wipe reset;
+- death, spawn lockout, resurrection, advancement, and defeated-party dormancy;
- Goblin guarding, aggro on hit or miss, pursuit, return, and death;
- exit entry with a living Goblin;
-- dormant versus total-party-wipe conditions;
+- initial versus defeated-party dormant conditions;
- serial ordering and stale/duplicate command handling; and
- deterministic floor generation and connectivity validation.
@@ -913,7 +911,7 @@ At minimum, the live test plan must demonstrate:
7. Goblin aggro, pursuit, attack, target death, and return;
8. Channel Points resurrection of the correct dead viewer;
9. floor escape with the Goblin alive and dead-player revival;
-10. total-party wipe and Floor 1 reset;
+10. total-party defeat, dormant transition, and resurrection recovery;
11. refresh and temporary disconnect recovery; and
12. repetition across multiple generated floors.
@@ -941,7 +939,7 @@ slices:
2. Implement the deterministic floor generator and static stream rendering.
3. Implement player/Goblin state, commands, turn phases, timer, and action log
using local test drivers.
-4. Implement death, resurrection messages, floor advancement, wipe reset,
+4. Implement death, resurrection messages, floor advancement, defeat dormancy,
dormancy, reconnect, and idempotency.
5. Add the RPGJS adapter without moving rules out of the domain package.
6. Add Twurple chat and follower verification for `!spawn`.
diff --git a/apps/stream-view/public/index.html b/apps/stream-view/public/index.html
index 368b5e7..98227ea 100644
--- a/apps/stream-view/public/index.html
+++ b/apps/stream-view/public/index.html
@@ -5,6 +5,6 @@