Re-base the proposal and the coursework plan on the repository's model

[ExtraToast]

Parent

#35

What to build

(Amended 2026-09-14.) #101 and #102 already rewrote the proposal: the appendix and its listings are gone, the tooling and deliverables sections are replaced by one Implementation Approach section, and the proposal defines two metamodels (Project Intent as source, Resolved Deployment as target) with the Deliverable Set as generated files. The Listings alignment, Metamodels, Tooling mapping and Evidence items below are superseded by that text and are not to be redone. What remains open for the next task is the Delivery architecture and Output layout wording, and the coursework README's task table.

The Task 0 proposal describes the repository's model. The edits are made in Overleaf and then re-mirrored, because the mirror is never hand-edited.

• Listings alignment struck 2026-09-17, see the amendment below: The source listing and the rendered listings are copies of the auth worked example and its rendered tree, including the serializer's GENERATED line. The PrometheusRule listing goes, since the model no longer renders the kind. The line counts in the generated-code section are recomputed. Today the source listing breaks the specification five times (an alertClass outside the vocabulary and outside observability, a scrape naming a port, port 80, a grant without rotation, a missing grant) and the rendered listing contradicts it three times (containerPort: 80, readOnlyRootFilesystem: false, the PrometheusRule).
• Delivery architecture: Align the delivery wording across 02-solution.tex, 06-architecture.tex, and 08-deliverables.tex. The proposal must not describe delivery as static repo inventory polling or imperative local shell commands (kubectl apply -k). Delivery is either:
  1. Direct apply from the pipeline where action execution and test gating occur, or
  2. Centralized GitOps where the deployed manifests are fetched directly from the output/artifact of the pipeline action (not polled from a detached hand-maintained inventory).
     In both patterns, delivery is decoupled from the core Project Intent model specification (per the docs/adr/deferred contract).
• Output layout: One tree for the estate, laid out per project and Application by the path plan and produced by six adapters run once over the composed union, not one bundle per application.
• Platform data: Platform data is Platform Intent as chapter 14 defines it, and the vocabulary follows CONTEXT.md.
• Metamodels: The metamodels section (05-metamodels.tex) names four metamodels (Project Intent, Platform Intent, Resolved Deployment, the object model), each declared twice by hand (Ecore under emf/, Zod under src/), and what each course task delivers.
• Tooling: The tooling section (07-tooling.tex) no longer asks to substitute TypeScript and Zod for the prescribed stack; the course rejected that. It states the two-implementation design instead: the graded implementation uses Ecore, Xtext, Complete OCL, QVT-Operational and Acceleo 4, built headless with Maven and Tycho on JDK 21; the TypeScript implementation is the estate's long-lived compiler; neither is generated from the other. One table row per part of a language definition (Atkinson and Kühne: abstract syntax, concrete syntax, well-formedness, semantics) names the EMF artefact and the TypeScript artefact for it. The section says the EMF implementation is coursework-scoped and when it is removed.
• Evidence: The deliverables section (08-deliverables.tex) names parity as the evidence that the two implementations agree: committed canonical JSON oracles for the parsed intent and the Resolved Deployment, the rendered tree byte for byte, a (code, JSON Pointer) set per refused case, and a metamodel descriptor, each implementation tested against them separately.
• Plan: The coursework README's task table and the proposal's plan follow the task dates (Task 1 2026-09-25, Task 2 2026-10-16, Task 3 2026-10-30) and say which EMF artefact each task delivers.

The coursework README's task table names the metamodels each task covers. A test checks that the mirrored listings equal the worked example files. struck 2026-09-17: there are no listings to check.

Acceptance criteria

• The mirrored listings equal the auth example and its rendered tree, checked in CI. struck 2026-09-17, see the amendment below.
• Delivery wording reflects direct pipeline execution or GitOps consuming action output artifacts, without prescribing delivery mechanics inside the core spec.
• Nothing in the proposal about output layout, platform data or metamodels contradicts the specification.
• The tooling and deliverables sections describe the two implementations and the parity evidence, and contradict nothing in emf/docs/architecture.md or the parity contract.
• The Overleaf project compiles, and the mirror matches a fresh pull.

Blocked by

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

---

Amended 2026-09-17

There are no listings, so nothing can check them. #101 and #102 deleted the
appendix and its code blocks, which is why the 2026-09-14 amendment above lists
Listings alignment among the items superseded and not to be redone. What
survived that deletion was the acceptance criterion built on it, plus one
sentence promising a test. Both are struck: grep for lstlisting and
lstinputlisting across docs/mde/task-0-proposal/Sections/ returns nothing,
so the CI check the criterion asks for would have nothing to read.

The concern behind it did not disappear with the listings, and it is met a
different way. The proposal's remaining numeric claim about the auth example
was recounted rather than estimated, and it was wrong: eleven files of about 620
lines, not ten of about 890. What keeps the worked examples honest now is the
suite, not the proposal: spec/v1/examples/ carries committed oracles that both
implementations are tested against separately, and the rendered trees are
compared byte for byte.

Everything else this ticket still owned landed in #139: the delivery wording, the
output layout, the platform data, and the coursework README's task table.