1## ADDED Requirements23### Requirement: Levels MAY declare a deterministic property automaton4A level MAY author automata records with `{ id, subject?, property, pattern, phase? }`. `pattern` SHALL be an ordered list of `{ action: 'move', dx, dy, cue?, sound? }` or `{ action: 'wait', cue?, sound? }` objects. Move deltas SHALL be cardinal. A missing `subject` SHALL enable property-carried mode; a present subject SHALL restrict matching to that noun. Runtime state MAY add derived fields, but `carriers`, flattened `instanceIds`, `active`, and `next` SHALL NOT be required authored mod fields. An absent automata field SHALL preserve current level behavior.56#### Scenario: A property-carried automaton starts at phase zero7- **WHEN** a level declares `{ id: 'clock', property: 'TICK', pattern: [{ action: 'move', dx: -1, dy: 0 }, { action: 'wait' }] }`8- **THEN** the initial state reports automata entry `clock`, phase zero, and the first normalized pattern step910#### Scenario: A subject restricts the carrier11- **WHEN** a level declares `{ id: 'mouse-clock', subject: 'MOUSE', property: 'TICK', pattern: [{ action: 'move', dx: -1, dy: 0 }] }`12- **THEN** only the noun matched by `MOUSE IS TICK` follows the automaton and other nouns matched by `IS TICK` do not1314#### Scenario: A legacy level remains compatible15- **WHEN** a level has no automata field16- **THEN** the engine uses existing board-rule state and exposes no automata entry1718### Requirement: Board rules SHALL activate and transfer property-carried automata19An automaton SHALL be active for each entity whose noun is currently matched by the parsed `SUBJECT IS PROPERTY` rule, subject to an optional automaton subject restriction. The property word SHALL remain part of the visible board sentence, and pushing it SHALL transfer or remove the active behavior after the next rule parse without mutating global rules.2021#### Scenario: A visible property rule activates a carrier22- **WHEN** the board forms `MOUSE IS TICK` for an automaton with property `TICK`23- **THEN** the current MOUSE entity is active for that automaton and follows its current pattern step2425#### Scenario: Pushing the property word transfers the carrier26- **WHEN** a player pushes the `TICK` word so the board changes from `MOUSE IS TICK` to `BELL IS TICK`27- **THEN** the next parsed state removes MOUSE as an active carrier and makes BELL active for the automaton2829### Requirement: Turns SHALL resolve player and automaton actions deterministically30For an accepted player turn, the engine SHALL resolve the player move first, re-parse rules and transformations, resolve automaton actions for current active entities, re-parse rules and transformations again, then resolve `SINK`, `DEFEAT`, and `WIN`. Automaton actions SHALL use the existing atomic push rules, move front-first along their action direction, and tie by stable entity ID. A blocked player input SHALL not start a turn.3132#### Scenario: Player movement precedes automaton movement33- **WHEN** a player move pushes a property word into a new sentence34- **THEN** the engine reparses that sentence before selecting active entities and the new active entity acts in the same accepted turn3536#### Scenario: Automaton movement uses front-first pushing37- **WHEN** two active entities act right with a PUSH chain ahead38- **THEN** the engine resolves the front-most entity first, applies the same atomic push rules as YOU, and produces stable automated movement entries3940#### Scenario: Contacts settle after both movement phases41- **WHEN** an automaton action moves an entity into SINK, DEFEAT, or WIN contact42- **THEN** the engine resolves those contacts only after the second parse/transform phase and exposes the settled result4344### Requirement: Phase SHALL advance on active accepted turns45If at least one entity is active for an automaton after the player phase, its shared phase SHALL advance exactly once after the automaton beat, including when the action is blocked or is `wait`. A blocked or invalid player input SHALL not advance phase. The automata state SHALL retain `id`, optional `subject`, `property`, `pattern`, `phase`, and `active`.4647#### Scenario: An active entity advances phase48- **WHEN** a player makes an accepted turn while at least one entity is active for `TICK`49- **THEN** the automata state increments phase once and the next pattern step becomes the step used by the following turn5051#### Scenario: A blocked automaton action still consumes the beat52- **WHEN** an accepted player turn occurs but the active entity's move is blocked by STOP or bounds53- **THEN** the entity stays in place, `automated` reports the block, and phase still advances once5455#### Scenario: Explicit wait is a beat56- **WHEN** the active automaton step has `action: 'wait'` and the player makes an accepted turn57- **THEN** no automaton entity moves, phase advances once, and the `automated` entry carries any cue or sound5859#### Scenario: No active entity pauses the automaton60- **WHEN** an accepted player turn leaves no entity matched by the automaton property61- **THEN** phase and the automata entry remain unchanged and no automated movement is emitted6263### Requirement: State and events SHALL expose automated movement and beat feedback64The settled state and event automata entries SHALL expose the normalized authored fields `id`, optional `subject`, `property`, `pattern`, and `phase`, plus derived `active`, `carriers: [{ noun, instanceIds }]`, flattened `instanceIds`, and `next`, where `next` is the action object at `pattern[phase]`. Settled events SHALL additionally expose an `automated` array whose entries report action, entity ID, from/to coordinates when moved, blocked details when blocked, and optional cue/sound. The presentation MAY derive current/next beat labels from these fields and SHALL expose that feedback in visible and accessible text; reduced motion SHALL apply the same state immediately. Derived fields SHALL not be required authored mod fields.6566#### Scenario: An automated move is observable67- **WHEN** an accepted turn advances an active automaton move68- **THEN** the settled event automata entry includes the derived carrier groups, flattened `instanceIds`, and `next` action, and `automated` includes action `move`, entity ID, from/to coordinates, and cue/sound when supplied6970#### Scenario: A blocked automated action is observable71- **WHEN** an active automaton move is blocked72- **THEN** the `automated` entry includes the action, entity ID, and block details while the state retains the entity position and the automata entry still exposes its derived carriers, `instanceIds`, and `next`7374#### Scenario: Derived carrier fields follow active rules75- **WHEN** a rule word is pushed and the active rule changes from `MOUSE IS TICK` to `BELL IS TICK`76- **THEN** the next state and event automata entry reports `carriers` for BELL, flattened BELL `instanceIds`, and the action object at `pattern[phase]` without requiring those fields in the authored level data7778#### Scenario: Reduced motion keeps beat feedback readable79- **WHEN** reduced motion is enabled during an automaton turn80- **THEN** the stage derives and displays the current/next pattern steps immediately without changing the simulation result8182### Requirement: Automata SHALL be validated in local and shared pack paths83The host SHALL validate automaton IDs, optional subject, property vocabulary, object action tokens, cardinal move deltas, pattern bounds, phase bounds, cue/sound values, and duplicate IDs before registering or installing a pack. Trusted local CommonJS modules MAY provide automata data; data-only shared payloads SHALL carry normalized records and SHALL never execute code.8485#### Scenario: A valid local automaton is registered86- **WHEN** a trusted local module exports a level with valid object pattern steps87- **THEN** the loader registers the normalized automata entry only after complete pack validation8889#### Scenario: Invalid automaton data is rejected atomically90- **WHEN** a pack contains an unknown action, non-cardinal delta, invalid property, or duplicate automaton ID91- **THEN** validation reports the pack and level path and registers none of its automata or levels9293#### Scenario: A shared automaton remains data-only94- **WHEN** a shared payload contains normalized automata entries95- **THEN** the decoder validates and previews the entries without evaluating module source or installing before explicit confirmation9697### Requirement: Automata state SHALL be part of Undo, reset, replay, and solver state98Undo snapshots, reset state, deterministic replay records, and solver state keys SHALL include normalized automata `id`, optional subject, property, pattern, phase, and active state. Undo SHALL restore the preceding phase and active state; replay and solver SHALL reproduce the same automated movement and phase sequence for the same accepted intents.99100#### Scenario: Undo restores a phase transition101- **WHEN** the player undoes a turn that advanced an automaton from phase 3 to phase 4102- **THEN** the prior phase, active state, board, and resolved rules are restored exactly103104#### Scenario: Reset restores native automata state105- **WHEN** the player resets after automaton turns106- **THEN** every automata entry returns to its declared phase or zero and no prior automated movement remains107108#### Scenario: Solver distinguishes phase states109- **WHEN** two search nodes have identical board coordinates but different automata phases or active states110- **THEN** the solver treats them as distinct states and does not collapse one path into the other111112### Requirement: Automata SHALL provide a visual feedback handoff113The presentation handoff SHALL use normalized pattern steps, phase, `active`, and `automated` cue/sound fields to show the current and next pattern actions. It SHALL keep this feedback separate from simulation geometry and preserve readable state under reduced motion.114115#### Scenario: A pattern step is ready for visual review116- **WHEN** an author supplies normalized automata data and a settled automated event117- **THEN** reviewers can map phase and action objects to the current/next visual feedback and movement result118119#### Scenario: Missing optional cue does not block play120- **WHEN** a valid automaton step omits cue or sound121- **THEN** the engine and stage retain the normalized action and phase and use the default visual/audio treatment