clone

fifteen puzzle games for the terminal, with daily puzzles, weekly ladders and xp, built on bubble tea

chore/app-model-decomp
puzzletea / openspec / changes / refactor-root-tui-model / specs / root-tui-architecture / spec.md
spec.md 5.0K rendered
1## ADDED Requirements23### Requirement: Root update dispatch remains behavior-preserving4The root TUI model SHALL preserve existing user-facing behavior while organizing `Update` as a top-level dispatcher for app messages, global shortcuts, active game updates, screen updates, and screen actions.56#### Scenario: Existing app flows remain available7- **WHEN** a user navigates through main menu, play menu, create, continue, daily, weekly, seeded play, export, options, help, stats, theme selection, or an active puzzle8- **THEN** the app SHALL expose the same commands, navigation outcomes, persistence behavior, and view transitions as before the refactor910#### Scenario: Root update delegates by message category11- **WHEN** the root model receives async completion messages, window-size messages, key messages, screen messages, or active game messages12- **THEN** dispatch SHALL route each message to the component that owns the relevant behavior without requiring screens to mutate root model internals directly1314### Requirement: Route and screen management is isolated15The app SHALL isolate route and screen mechanics from workflow behavior so current route, cached screens, screen initialization, active screen lookup, window dimensions, and active-screen resizing are managed through a dedicated app-internal boundary.1617#### Scenario: Screen cache survives refactor18- **WHEN** a screen is updated, resized, left, or re-entered according to the existing app flow19- **THEN** the app SHALL preserve the same screen state retention or reinitialization behavior that existed before the refactor2021#### Scenario: Route management does not own workflows22- **WHEN** a route transition requires creating, resuming, spawning, exporting, saving, applying a theme, or updating persistent state23- **THEN** the route/screen management boundary SHALL delegate that workflow behavior to the owning controller or handler2425### Requirement: Screens emit typed app intents26App screens SHALL remain dependency-light interaction models that update local component state and emit typed app intents for root-level behavior.2728#### Scenario: Screen action applies app behavior29- **WHEN** a screen interaction requires opening another route, starting generation, submitting export, changing theme, opening help, or loading a record30- **THEN** the screen SHALL return a typed action or command that is applied by the root app layer or its controllers3132#### Scenario: Screens avoid direct app dependency ownership33- **WHEN** a screen is constructed or updated34- **THEN** it SHALL NOT require direct ownership of store, config, session lifecycle, or persistence dependencies unless an existing behavior cannot be preserved otherwise3536### Requirement: Session lifecycle has a single owner37The app SHALL centralize active game lifecycle behavior behind session-oriented code.3839#### Scenario: Starting a generated game40- **WHEN** normal mode selection, create flow, seeded play, daily play, or weekly play starts puzzle generation41- **THEN** session lifecycle code SHALL own generation state, cancellation, stale completion handling, game activation, save record creation, and transition into game view4243#### Scenario: Resuming or reviewing a saved game44- **WHEN** the user resumes a saved game or opens a read-only weekly review45- **THEN** session lifecycle code SHALL own import, read-only handling, active game ID setup, completion-saved state, help/window-size propagation, and transition into game view4647#### Scenario: Leaving an active game48- **WHEN** the user exits or quits an active game49- **THEN** session lifecycle code SHALL own save-state persistence, status updates, active game cleanup, and return-state behavior5051#### Scenario: Completing an active game52- **WHEN** an active game becomes solved53- **THEN** session lifecycle code SHALL persist final save data and completed status once, preserving existing error notice behavior when persistence fails5455### Requirement: Global key behavior is owned by active domain56Global keyboard behavior SHALL be routed to the app domain that owns the current state.5758#### Scenario: Pending generation keys59- **WHEN** the app is showing pending puzzle generation and the user presses escape or quit60- **THEN** session lifecycle code SHALL preserve existing cancellation, return-route, and quit behavior6162#### Scenario: Pending export keys63- **WHEN** the app is showing pending export and the user presses escape or quit64- **THEN** export workflow code SHALL preserve existing cancellation, return-route, and quit behavior6566#### Scenario: Active game keys67- **WHEN** the app is showing an active puzzle and the user presses escape, quit, reset, full-help, debug, or enter on a solved weekly puzzle68- **THEN** active game/session handling SHALL preserve existing save, abandon, reset, help propagation, debug, and weekly advancement behavior6970#### Scenario: Normal screen keys71- **WHEN** the app is showing a non-game, non-pending screen and the user presses global quit, debug, or full-help keys72- **THEN** shell-level handling SHALL preserve existing quit, debug toggle, and full-help toggle behavior