1## Why23Level data currently crosses several validation boundaries with slightly4different rules. `createGame()` infers object kinds and accepts legacy5automaton direction strings, while the CommonJS loader validates a related6shape and normalizes it later. Data-only sharing has another copy of the same7normalization. This makes a level valid through one path but invalid through8another, and makes future mechanics expensive to add safely.910## What Changes1112- Define one pure, host-owned level normalization and validation boundary for13 authored level data.14- Make direct engine creation, trusted CommonJS loading, and data-only sharing15 use that boundary before their own context-specific error adapters.16- Preserve the current legacy level shorthand during a documented migration:17 inferred `kind`, case-insensitive word tokens, and `U`/`D`/`L`/`R`/`W`18 automaton steps are accepted at input and materialized as canonical data.19- Add parity fixtures proving valid data, invalid data, legacy normalization,20 and CommonJS/share round trips agree before play or installation.2122## Capabilities2324### New Capabilities2526- `level-schema-boundary`: canonical level normalization, validation, and27 adapters for engine, CommonJS, and data-only sharing.2829### Modified Capabilities3031- `commonjs-mods`: use the canonical level boundary instead of maintaining a32 second level validator.33- `level-sharing`: validate and normalize shared levels through the same34 boundary used by local CommonJS previews and direct engine creation.3536## Impact3738The implementation will add a small data/schema module and reduce duplicated39level checks in `src/engine.js`, `src/mods.js`, and `src/share.js`. It will add40focused tests for direct creation, local module loading, shared payloads, and41export/import. Existing normalized pack fields, level IDs, rules semantics,42and trusted-local CommonJS execution remain unchanged.