1## Why23The game now has dynamic rules, automata, sharing, and several stage scenes. Its two composition files (`stage.js` and `main.js`) mix simulation-facing commands with rendering and input, while engine hot paths repeatedly scan whole boards. This makes future mechanics such as gates, switches, and crumbling tiles difficult to add safely.45## What Changes67- Give stage actions one dispatch path across keyboard, pointer, and programmatic intents.8- Separate game session work, scene presentation, and pack data copying into focused modules while preserving current public APIs and play behavior.9- Extract board rendering passes, stage scene drawing, animation projections, and INDEX progress storage at existing module seams.10- Format the minified application styles so layout changes are reviewable.11- Add reusable engine lookup structures for rule and movement work without changing turn order or event shape.12- Record architecture boundaries and a staged plan for stateful mechanics, snapshots, solver keys, and further renderer extraction.13- Add focused conformance checks for rule changes, controls, mod loading, Undo, and scene transitions.1415## Capabilities1617### New Capabilities1819- `runtime-boundaries`: stable simulation, application, stage, and data ownership; one action dispatch and deterministic observable behavior across entry points.2021### Modified Capabilities2223None. This refactor preserves the current gameplay and sharing requirements.2425## Impact2627`src/stage.js`, `src/main.js`, `src/engine.js`, `src/render/board.js`, `src/juice.js`, `src/scenes/map.js`, pack data helpers, CSS, focused tests, and architecture documentation. Existing mods, snapshots, public `createGame()` and `drawBoard()` shapes, and the game URL remain compatible. No new runtime dependency is required.