Test schema migrations as model-to-model steps #54

Parent

#35

What to build

Each schemaVersion step is a small migration from one wire shape to the next, with a before/after fixture pair, an explicit list of what does not survive, and a run over every example in CI. A field is retired through a deprecation ledger (owner, reason, review date), never dropped silently: chapter 40 already warns that the union is silent about what it drops.

The harness is proved on a synthetic minor bump before a real one is needed. 0066's settling test, the first real schemaVersion bump, is its first production use.

Parity

Not a parity case. Migrations are a TypeScript concern: the Java implementation under emf/ reads the current schemaVersion only and is deleted before a second supported version is likely. When a migration changes the current shape, the Java grammar and metamodel follow in the same pull request as any other model change.

Acceptance criteria

• A synthetic 1.0 to 1.1 migration passes its fixture pair and runs over every example.
• A migration that drops a field without a deprecation ledger entry fails.

Blocked by

• Declare the Project Intent metamodel once and parse every example with it #38