Why

The 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.

What Changes

• Give stage actions one dispatch path across keyboard, pointer, and programmatic intents.
• Separate game session work, scene presentation, and pack data copying into focused modules while preserving current public APIs and play behavior.
• Extract board rendering passes, stage scene drawing, animation projections, and INDEX progress storage at existing module seams.
• Format the minified application styles so layout changes are reviewable.
• Add reusable engine lookup structures for rule and movement work without changing turn order or event shape.
• Record architecture boundaries and a staged plan for stateful mechanics, snapshots, solver keys, and further renderer extraction.
• Add focused conformance checks for rule changes, controls, mod loading, Undo, and scene transitions.

Capabilities

New Capabilities

• runtime-boundaries: stable simulation, application, stage, and data ownership; one action dispatch and deterministic observable behavior across entry points.

Modified Capabilities

None. This refactor preserves the current gameplay and sharing requirements.

Impact

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.