docs(design): define tyrant game stories

design/concepts/game-state-machine.md

@@ -0,0 +1,35 @@
+---
+type: Design Concept
+title: Tyrant Game State Machine
+description: Defines lifecycle, succession, selection, and pause behavior for a Tyrant game.
+---
+
+# Tyrant Game State Machine
+
+## Lifecycle
+
+The game begins unstarted. An administrator starts it by assigning the first Tyrant; the administrator may explicitly assign the first Vigilante or allow selection from eligible recently active players. A running game may be paused without deleting its state and later resumed.
+
+Pausing freezes gameplay progression, role inactivity checks, pending-selection deadlines, ability cooldowns, and daily-use timers. Role and class effects are suppressed while paused and restored on resume.
+
+## Tyrant succession
+
+When a player directly kills the Tyrant, that killer becomes the new Tyrant. When no player is credited with the death, an eligible opted-in player active during the preceding 24 hours is selected randomly. The former Tyrant is excluded when another candidate exists.
+
+Every Tyrant death ends the reign, clears all role-side assignments, resets the former Tyrant's reign progression, and requires a new Vigilante. The new Tyrant receives one starting unlock choice.
+
+## Vigilante succession
+
+Every Vigilante death ends that assignment regardless of cause. A replacement is selected randomly from eligible opted-in players active during the preceding 24 hours. The Tyrant is never eligible. The previous Vigilante is excluded when another eligible non-Tyrant exists and may be selected again only as a fallback. Followers are cleared rather than transferred.
+
+A Tyrant earns progression from the death only when the Tyrant personally killed the Vigilante.
+
+## Pending selections
+
+An offline random selectee has 24 hours of unpaused time to log in and confirm the assignment. Failure causes another selection. When no eligible candidate exists, the position remains vacant and selection retries periodically without assigning the Tyrant to both roles.
+
+## Related stories
+
+- [Start, pause, and administer the game](../user-stories/us-001-start-pause-and-administer.md)
+- [Transfer and reset the Tyrant role](../user-stories/us-002-transfer-and-reset-tyrant.md)
+- [Handle inactivity and pending selections](../user-stories/us-010-handle-inactivity-and-selection.md)

design/concepts/index.md

@@ -0,0 +1,5 @@
+# Design Concepts
+
+- [Game state machine](game-state-machine.md) - Running, paused, succession, and pending-selection states.
+- [Role and class model](role-and-class-model.md) - Role relationships, eligibility, assignments, and unlocks.
+- [Persistence model](persistence-model.md) - Durable game and player state requirements.

design/concepts/persistence-model.md

@@ -0,0 +1,19 @@
+---
+type: Design Concept
+title: Persistence Model
+description: Defines the durable state and timekeeping needed to restore a Tyrant game safely.
+---
+
+# Persistence Model
+
+State is keyed by player UUID while retaining the latest known player name for display. Durable global state includes lifecycle status, current and pending role holders, selection deadlines, paused durations, and the current Tyrant reign.
+
+Durable player state includes participation status, opt-out deadline, login history, role or class, Tyrant level, purchased unlocks, unspent choices, Follower relationship, ability cooldowns, daily intelligence use, bound-item delivery state, and captured mobs.
+
+Elapsed-time rules use UTC instants. Paused time is excluded from timers. Saves use atomic replacement where supported, preserve unknown fields where practical, and reject corrupt records rather than granting powers, assignments, or duplicated entities.
+
+## Related stories
+
+- [Inform players and manage participation](../user-stories/us-011-inform-and-manage-participation.md)
+- [Configure and persist game state](../user-stories/us-012-configure-and-persist-state.md)
+- [Use class ability items](../user-stories/us-014-use-class-ability-items.md)

design/concepts/role-and-class-model.md

@@ -0,0 +1,38 @@
+---
+type: Design Concept
+title: Role and Class Model
+description: Defines Tyrant-side classes, Vigilante-side membership, progression, and assignment constraints.
+---
+
+# Role and Class Model
+
+## Roles and affiliations
+
+A running game has one Tyrant and, when an eligible player is available, one Vigilante. The Vigilante may recruit Followers through invitations that require acceptance. The Tyrant may assign the Assassin, Fixer, and Tamer classes after unlocking them.
+
+Role alignment and Tyrant-side class are independent. A Vigilante or Follower may simultaneously hold one Tyrant-side class, allowing divided loyalties. A player cannot simultaneously be the Tyrant, Vigilante, and/or a Follower, and cannot hold more than one Tyrant-side class. Each Tyrant-side class may be assigned to only one player at a time. Opted-out players are ineligible for every assignment.
+
+## Tyrant progression
+
+The Tyrant starts each reign at level zero with one starting unlock choice. Personally killing the Vigilante grants one level and one additional choice. Each of these unlocks can be purchased once per reign:
+
+- Assassin class
+- Fixer class
+- Tamer class
+- Vigilante roster intelligence
+- Permanent Resistance
+- Permanent Strength
+
+## Proximity
+
+Unless a more specific rule applies, "near the Tyrant" means in the same world and within a configurable 50-block three-dimensional distance.
+
+## Effect safety
+
+Vigilante Follower scaling is capped by default at Strength V and Resistance IV, with validated configurable caps. Permanent and conditional class effects are reapplied after ordinary Minecraft removal while the game is running and the assignment remains valid.
+
+## Related stories
+
+- [Progress and purchase Tyrant unlocks](../user-stories/us-003-progress-and-purchase-unlocks.md)
+- [Assign unlocked classes](../user-stories/us-004-assign-unlocked-classes.md)
+- [Support the Vigilante and Followers](../user-stories/us-008-support-vigilante-and-followers.md)