runtime-boundaries Specification

Purpose

TBD - created by archiving change modularize-runtime-boundaries. Update Purpose after archive.

Requirements

Requirement: Scene actions share semantic dispatch

The stage SHALL resolve Pause and Index actions through shared semantic methods across keyboard, pointer, and programmatic entry points. The application SHALL route normalized gameplay intents to named commands. One accepted movement or wait action SHALL cause at most one engine turn.

Scenario: Equal commands from different devices

• WHEN the player invokes undo from a key, the mobile button, or the stage intent API after one successful move
• THEN the same previous board state is restored exactly once and the visible board matches it

Scenario: Menu command is scoped to the active scene

• WHEN the player invokes the Index navigation action while a proof is active
• THEN it does not select another proof or advance the current game turn

Requirement: Simulation owns gameplay state

The game session SHALL own the authoritative engine state. Stage renderers SHALL consume a projection of settled state and animation data without mutating the engine, and scene changes SHALL NOT change object positions or dynamic rules.

Scenario: Pause and resume preserve a rule change

• WHEN a word move changes a dynamic rule and the player pauses and resumes
• THEN the engine state, rendered board, and active rule display agree with the state before the pause

Requirement: Compatible data and event boundaries

The refactor SHALL preserve accepted CommonJS pack data, data-only shared payloads, snapshot restore, and settled event fields. Data cloning SHALL not retain mutable references to caller-owned pack objects.

Scenario: Import and Undo after a pack turn

• WHEN a valid local pack is imported, played, and a successful move is undone
• THEN the pack remains installed, the game restores the prior board and automata phase, and the shared payload contains data rather than executable source

Requirement: Deterministic engine lookups

Turn-local lookup structures SHALL reflect the same object and rule state as the public snapshot after each movement, transformation, and contact phase. Lookup optimization SHALL NOT alter deterministic turn order or settled events.

Scenario: Rules change during an accepted turn

• WHEN a push breaks a rule before an automaton acts
• THEN the automaton observes the refreshed rules, and replay plus Undo reproduce the same positions, phase, and events