Keep one megamodel and derive provenance from it #53

Parent

#35

What to build

One small megamodel lists every artefact kind in the pipeline (Intent Fragment, Platform document, node contract, images lock, ClusterState snapshot, participants, composed intent, composition lock, Resolved Deployment, Resolved Application, trace, object model, rendered tree, Migration Proof, pin file with its annotations, held fragment, Rendered artifact) with its metamodel and schema version, and every operation (publish on a release tag, compose, resolve, project, render, serialize, pin, pause, roll back) with the kinds it consumes and produces. A diagram of it is generated.

• Provenance, the composition lock's fields and the render hash's inputs are checked against it. Today chapters 20, 30 and 40 record what went into a render with three different key sets.
• The Resolved Application viewpoint is defined in it once, as the filter that produces the projection.
• A render card is one more artefact: the snapshot's age, stale participants, open ledger entries, and the open premises the render rests on, so a reviewer sees how far to trust a render.

Parity

The megamodel lists artefact kinds and operations, not implementations. The oracle files (intent.json, resolved.json, diagnostics.json, the descriptor, the rendered tree) are artefacts of the kinds already listed, so provenance and the render hash name the same input set whichever implementation produced a render. Nothing in the megamodel names a TypeScript module or a Java module.

Acceptance criteria

• Provenance, the lock and the hash inputs name the same input set, checked by a test.
• Adding an input kind without updating the megamodel fails.
• The megamodel diagram regenerates without a diff.
• The megamodel names no implementation, and both implementations' renders of one case carry identical provenance.

Blocked by

• Compose the estate: a compose use-case and CLI, pin annotations and fragment versions #197
• Publish versioned JSON Schemas for the Resolved Deployment, the composition lock and the pin annotations #198