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

Parent

#35

What to build

The Project Intent language is defined once, as the wire schemas and domain types docs/architecture.md prescribes: Zod for the authoring shape, one mapper into the domain types. Every Project Intent document in the repository is parsed with it: the accepted worked examples, the refusal fixtures, the negative fixtures and the platform-owned project files. A document either maps to the domain model or yields coded diagnostics that carry a document path.

• Unions are unions. A grant is discriminated by engine (kv, database, transit, per 0085); a probe is http, tcp or none.
• The 17 closed vocabularies are enumerations in the schema and nowhere else in code. The test constant that re-types AlertClass goes.
• The placeholder language in env files (${secret:...}, ${dependency:...}, ${exposure:...}, ${identity:...}) has a written grammar, and an env file parses into literals and placeholders.
• JSON Schema is generated from the input variant of each schema and committed.

Settled in this ticket:

• stateful is deleted from the language, from chapter 10 and its class diagram, from chapter 20's authority table and from the examples. The object kind derives from lifecycle and volumes; in every example today stateful: true appears exactly where volumes do.
• A Process has zero or more env files. Chapter 10's diagram and prose say so. Three example Processes (auth-ui, platform-rabbitmq, platform-valkey) have none today.

The indentation-based checks in the simplification and diagram-consistency tests are replaced by checks over the parsed model. Each refusal fixture's expect: header is replaced by a committed <input>.diagnostics.json beside it: the set of (code, path) pairs the model emits, with schema as the code for a schema failure and the path an RFC 6901 JSON Pointer into the canonical intent document.

Parity

This ticket is the TypeScript half of the Task 1 metamodelling work (due 2026-09-25) and commits the first oracle files of the parity contract:

• expected/intent.json for every accepted Project Intent example: the parsed document as RFC 8785 canonical JSON, absent optional fields absent, never null.
• <input>.diagnostics.json for every refusal and negative fixture.
• spec/v1/examples/expected/descriptor.json for the Project Intent metamodel: every class, feature, type, multiplicity and closed vocabulary, built from the Zod schemas with Zod's native z.toJSONSchema() and a normaliser. The normaliser's output shape is the contract's, not Zod's.

The oracle files are reviewed by hand when committed; CI compares against them and never regenerates them. The Java counterpart (the hand-written project-intent.ecore, the Xtext grammar that imports it and parses the same YAML files, and the Complete OCL invariants for document-level refusals) is its own ticket and must match these files byte for byte.

Acceptance criteria

• Every Project Intent document under the examples parses, or fails with exactly the (code, path) set its diagnostics.json names.
• A document with an unknown key, an out-of-vocabulary value, or a kv field on a transit grant fails schema validation with a document path.
• No test reads YAML by indentation.
• stateful appears nowhere in the specification, CONTEXT.md or the examples.
• The committed JSON Schema regenerates without a diff.
• The mapper is covered at the use-case seam, per docs/architecture.md §Testing.
• Every accepted example has a committed expected/intent.json, and the TypeScript parser's canonical output equals it byte for byte.
• Every refusal and negative fixture has a committed diagnostics.json, and the emitted (code, path) set equals it.
• The committed descriptor equals the normalised z.toJSONSchema() output, and a Zod schema change without a descriptor change fails.

Blocked by

• Run the suite on Vitest and make the tooling strict TypeScript #22
• Write down the rules the compiler will be held to #30