@milehimikey/em 1.11.0 → 1.13.0

package/.claude/skills/event-modeling/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: event-modeling
-em-version: 1.11.0
+em-version: 1.13.0
 description: >-
   Use when the user runs `/event-modeling` (with or without a phase name), or wants to resume an
   event-modeling session without specifying which part of the process applies. Reads the model's
@@ -30,7 +30,9 @@ phase lives in.
 ## Routing logic
 
 1. Check the tool: `em --version`. If missing, tell the user to run `npm i -g @milehimikey/em`
-   and stop until installed.
+   and stop until installed. Then check this vendored bundle's own currency against it — see
+   `../event-modeling-shared/reference/operating-principles.md`'s Preconditions step 2: a bundle
+   more than a minor version stale is a STOP, not a warning.
 2. Parse `$ARGUMENTS` for a phase name.
    - **A recognized phase name** (`discover`, `extract`, `model`, `slice`, `implement`,
      `conform`, `validate`, `watch`, `review`): look it up in the table above and invoke that

package/.claude/skills/event-modeling-conform/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-conform
-em-version: 1.11.0
+em-version: 1.13.0
 description: >-
   Use when checking a ratified event model (and its slice docs) for drift against the codebase
   that implements it — advisory only, never a gate, never an unprompted edit — or when walking
@@ -33,18 +33,29 @@ or doc; write the as-is picture into that scratch model (`<model-name>-asis.em`,
 canonical model's names wherever the code matches them); run `em diff <model-name>.em
 <model-name>-asis.em --json` and let `em` decide the structural deltas; classify every finding
 (real drift / model gap / internal inconsistency / uncertainty) with cited evidence; write
-`conformance/<date>-report.md` with proposed `issue "conformance: …"` red notes; apply only the
-proposals the user ratifies, then re-render and validate; run `em state set-conformance
-<revision> --report <path>` to update the state file's `Last conformance:` marker.
+`conformance/<date>-report.md` **and its structured twin `conformance/<date>-findings.json`**
+(one entry per finding, `em conform-findings check <path>` to verify) with proposed `issue
+"conformance: …"` red notes; apply only the proposals the user ratifies, then re-render and
+validate; run `em state set-conformance <revision> --report <path>` to update the state file's
+`Last conformance:` marker.
 
 Ruling on a finding is a human gate, like ratifying a slice
 (docs/process.md#the-slice-lifecycle-gates): the sweep gathers evidence and proposes, a person
-decides, and `em state set-conformance` records the decision — never run it on your own judgment.
+decides, and `em conform-supersede ... --locus <model|doc|code|none> --by <name>` records the
+ruling on the findings record (and stamps the report) — never rule on your own judgment. Once
+every finding touching a slice is ruled, `em slice conform <model-name>.em <key> --at <rev>`
+certifies that version of the slice.
 
-End of phase: state file's `Last conformance:` marker updated (via `em state set-conformance`),
-Decisions log entry if any
-proposals were applied. Conform doesn't chain to another phase — it's a recurring loop, run
-again whenever the codebase has moved.
+End of phase: state file's `Last conformance:` marker updated (via `em state set-conformance` —
+refuses while any `implemented` slice still has an unruled finding; `--partial` escapes with a
+loud notice), Decisions log entry if any proposals were applied. Conform doesn't chain to
+another phase — it's a recurring loop, run again whenever the codebase has moved.
+
+A full (non-`--partial`) `em state set-conformance` also **certifies the model's current design
+version** (MIL-218, `docs/process.md#model-versions`) — it refuses if no design version has ever
+been bumped ("bump a model version first") or if the model changed during this run without a
+re-bump; run `em model version bump <model-name>.em --by <name>` before the final `em state
+set-conformance` call if either applies.
 
 ## Phase: `validate`
 

package/.claude/skills/event-modeling-conform/reference/conform.md

@@ -234,10 +234,22 @@ step 2 — sorts into exactly one class:
   which finding. Cite `slice.doc.driftSignal` and `slice.doc.version` together as evidence.
 - **Extraction uncertainty** — no evidence either way. Never reported as drift or a gap.
 
+**Read-model exposure (MIL-215).** Two rulings apply the classes above to a `view`'s exposure —
+whether it ships a query endpoint — instead of leaving each case to fresh judgment:
+
+- An **internal view** (no `ui` reads it, and it isn't marked `public`) implemented as
+  criteria-sourced state (a reaction's own read, no materialized projection — the general idiom
+  step 2 already names) or as an unexposed projection is **Conformant, never dead code to
+  flag**. It's the read operation the model draws to say an automation or translation *must*
+  read, not an endpoint promise; don't propose deleting it.
+- An **endpoint in code on a view the model shows no `ui` reading and no `public` marking** is a
+  **Model gap** — "add the `ui` or remove the endpoint" — **never Real drift to delete**.
+  Nobody decided whether that view is exposed; deleting the code decides it for them.
+
 Every classification must cite the evidence recorded in step 2 (or the `em diff` entry, for
 structural findings) — a finding with no citation isn't ready to report.
 
-### 5. Report + proposals
+### 5. Report + findings record + proposals
 
 Write `conformance/<YYYY-MM-DD>-report.md` in the model directory, from
 `../../event-modeling-shared/templates/conformance-report.md`. For a real-drift or model-gap finding, propose a
@@ -250,6 +262,71 @@ stays auditable) but don't ask the user to ratify what's already ratified. **You
 canonical model or a slice doc unprompted** — walk the report with the user, apply only the
 proposals they approve, then re-render and `em validate`.
 
+**Also write the findings JSON (MIL-214).** Alongside the report, write
+`conformance/<YYYY-MM-DD>-findings.json` — one entry per `### n.` finding, ids matching the
+report's own numbering. Shape (`findingsSchemaVersion: "1.0"`, additive-only, 2-space indent,
+keys sorted, findings sorted by `id`, trailing newline):
+
+```json
+{
+  "findingsSchemaVersion": "1.0",
+  "model": "checkout.em",
+  "report": "conformance/YYYY-MM-DD-report.md",
+  "revision": "<target-repo revision>",
+  "findings": [
+    {
+      "id": 1,
+      "surface": "structural",
+      "class": "Real drift",
+      "slice": "checkout",
+      "evidence": "code shows X at path/to/File.kt:42",
+      "locus": null,
+      "resolvedBy": null,
+      "resolvedOn": null
+    }
+  ]
+}
+```
+
+`surface` is one of `structural` (`.em` <-> code — step 3's diff), `spec` (slice doc <-> code —
+step 2's invariant/scenario walk), `internal` (slice doc <-> `.em` — step 2's `doc-model-*`
+diagnostics), or `other`. `class` is the step-4 classification verbatim (Real drift, Model gap,
+Internal inconsistency, Accepted divergence, Unpropagated delta, Extraction uncertainty). `slice`
+is the concerned slice's export key, or `null` for a finding that isn't attributable to one
+(counts as in-scope for every slice's unruled-findings check). `locus`/`resolvedBy`/`resolvedOn`
+start `null` — a later `em conform-supersede --locus --by` call fills them in once a human rules.
+Run `em conform-findings check conformance/YYYY-MM-DD-findings.json` before ending the session —
+a headless run's mechanical proof it wrote a valid record.
+
+**Ruling on a finding (MIL-214) — once the user decides.** Run, per finding or batch of findings
+ruled the same way:
+
+```
+em conform-supersede <model-name>.em conformance/YYYY-MM-DD-report.md --as-of <target-repo revision> \
+  --findings <spec> --locus <model|doc|code|none> --by <name>
+```
+
+— this records `locus`/`resolvedBy`/`resolvedOn` on the named findings in the JSON (refusing to
+silently overwrite an already-different `locus`) AND stamps the report's "superseded as of `<rev>`"
+banner in the same call (see below). `locus: code` on an unresolved finding is the carrier for
+"the spec is right, the code is wrong" — no doc delta required for that case any more; `locus:
+model` means fix the `.em` (apply the proposed red note, or a stronger edit the user chose
+instead); `locus: doc` means the slice doc needs a delta/re-ratification; `locus: none` covers
+Accepted divergence/Unpropagated delta/Extraction uncertainty, where nothing needs to change.
+
+**Certifying a slice, once every finding touching it is ruled (MIL-214).** For each in-scope
+slice with no unruled findings left:
+
+```
+em slice conform <model-name>.em <slice-key> --at <target-repo revision>
+```
+
+— records `conformedVersion`/`conformedAt`/`conformedOn` on that slice's doc, so
+`driftSignal` reads `in-sync` again (it reads `uncertified` for an implemented slice that's never
+been through this) instead of just trusting `implementedIn`. Legal only for `status: implemented`
+with a link, and itself refuses if an unruled finding for that slice still exists at this
+revision — the mechanical proof this step comes only after rulings, not before.
+
 End of run: update the state file's `Last conformance:` marker with
 
 ```
@@ -258,14 +335,21 @@ em state set-conformance <target-repo revision> --report conformance/YYYY-MM-DD-
 
 — the revision is the one you just diffed against, so the next run's scope starts from here.
 The command writes the exact format step 1 parses back out; never hand-edit the bullet.
+**Refuses (MIL-214) while any `implemented` slice still has an unruled finding** in the findings
+JSON beside the report — rule on every finding first (or certify what's already ruled via `em
+slice conform` above), or pass `--partial` to record the marker with a loud notice instead
+(`notice: conformance marker recorded as PARTIAL — N finding(s) unruled`) when the team
+deliberately wants to advance the marker without finishing every ruling this session.
 **The marker only advances with the human in the loop**: in an interactive session, run it
-after walking the report with the user; a headless/scheduled run writes the report but never
-the marker (nobody ratified the outcome), so the next run re-walks the same span — see
-`docs/ci.md`. If any proposals were ratified and applied, log a Decisions entry noting what
+after walking the report with the user; a headless/scheduled run writes the report and findings
+JSON but never the marker (nobody ratified the outcome), so the next run re-walks the same span —
+see `docs/ci.md`. If any proposals were ratified and applied, log a Decisions entry noting what
 changed and why.
 
-**Superseding the report you just walked (MIL-164).** Once the user has ruled on this run's
-findings, also run:
+**Superseding the report you just walked (MIL-164).** The `--locus`/`--by` call above already
+stamps the report's banner in the same call when a ruling was recorded; if a finding's ruling
+doesn't need `--locus`/`--by` recorded (a migration-path report predating the findings JSON, or
+a ruling you're only banner-stamping after the fact), run the same command without them:
 
 ```
 em conform-supersede <model-name>.em conformance/YYYY-MM-DD-report.md --as-of <target-repo revision> --findings <spec>
@@ -298,10 +382,23 @@ each call adds its own stamp rather than overwriting the last.
 ## Completion & handoff
 
 Conform is complete when: every in-scope slice has been walked (step 2), the scratch model has
-been diffed (step 3), every finding is classified with cited evidence (step 4), the report is
-written (step 5), the state file's `Last conformance:` marker is updated, and the user has seen
-the report and said which proposals (if any) to apply. Applied proposals get re-rendered and
-re-validated before you call the run done.
+been diffed (step 3), every finding is classified with cited evidence (step 4), the report AND
+its findings JSON are written (step 5), the state file's `Last conformance:` marker is updated
+(or deliberately left as `--partial`), and the user has seen the report and said which proposals
+(if any) to apply and which findings resolve to which locus. Applied proposals get re-rendered
+and re-validated before you call the run done.
+
+A full (non-`--partial`) `em state set-conformance` does one more thing (MIL-218): it also
+**certifies** the model's current design version — writes `certified: { at, on, report,
+findings }` into that version's `model-versions/v<N>.json` manifest, and rewrites the state
+file's `Certified:` bullet. This is the "conform ran clean against version N" fact a
+stakeholder or a release note can point at. It only works on an already-**bumped** design
+version — `em state set-conformance` refuses (pointing at `em model version bump`) if no
+manifest exists yet, or if the model has drifted since the last bump (the certification would
+otherwise name a version that isn't what conform actually walked). If the model changed during
+this conform run (a slice's `version:` moved, or the `.em` file itself changed), bump a new
+design version (`em model version bump --by <name>`) before the final `em state
+set-conformance` call. `--partial` never certifies. See `docs/model-versions.md`.
 
 Conform doesn't chain to another phase automatically — it's a recurring loop, not a step in
 building the model. Suggest running it again next time the target codebase has moved, at

package/.claude/skills/event-modeling-design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-design
-em-version: 1.11.0
+em-version: 1.13.0
 description: >-
   Use when structuring a draft event model into swimlanes and the four patterns (State Change,
   State View, Automation, Translation), evaluating a model's structural completeness, or writing
@@ -40,15 +40,22 @@ Goal: a structurally complete, **validated** model with correct patterns and swi
    slice, none skipped: `em slice new "<slice name>" --pattern <state-change|state-view|
    automation|translation> --swimlane "<Persona> → <Context>" --wire <model>.em` writes
    `slices/<slice-name>.md` at `status: draft` (the same command, flags, and `--wire`
-   note-binding the `slice` phase's step 2 below documents in full). Then, for each freshly
-   scaffolded doc, hold a first-pass Socratic pass and write the happy-path Given/When/Then into
+   note-binding the `slice` phase's step 2 below documents in full). A slice whose only element
+   is a `view X again` instance is a **continuation** (MIL-208), not a slice to scaffold —
+   `--wire` refuses it and names the originating slice holding `X`'s first declaration; its
+   scenarios go into that doc instead. Then, for each freshly scaffolded doc, hold a first-pass
+   Socratic pass and write the happy-path Given/When/Then into
    its `## Scenarios (Given / When / Then)` section and the obvious invariants known so far into
    its `## Invariants / Business Rules` section — **into the doc, never into the state file.**
    Keep this pass shallow (no field tables, alternate/error flows, or NFRs yet — that's the full
    deep-dive in the `slice` phase below); the docs are the home for everything collected from
    here on, not yet implementation-ready specs. Because every doc already exists by the time the
    `slice` phase begins, its own step 2 scaffolding call is then a no-op — that phase picks up
-   at its step 1's deeper pass.
+   at its step 1's deeper pass. For a purely exploratory/backbone-mapping model that only needs
+   status coloring right now (not a full spec per slice yet), `em slice stub-all <model>.em` is
+   the one-command fast path: a near-free stub per undocumented slice, wired, in slice order
+   (MIL-184) — skip the per-slice `em slice new` calls above and deepen individual docs later
+   when the team is ready.
 3. **Evaluate completeness (step 7).** Walk the model: every slice is a **complete** pattern, not a
    half-slice — **every command has something that triggers it**, every command emits an event,
    **every event is read by a read model**, **every read model has a consumer**, every view has a
@@ -60,6 +67,10 @@ Goal: a structurally complete, **validated** model with correct patterns and swi
    For an unread event, don't just bolt on a view to silence the warning: ask the user who looks at
    this fact and what they do with it. The honest answers are "here's the read model we missed" or
    "nobody — so why are we recording it", and both improve the model.
+   **Per `view`, also ask who reads it (MIL-215):** a person or client reads it → draw the `ui`
+   that reads it; another model/system reads it → mark it `public`; only an automation reads
+   it → nothing, it's internal by design. No new keyword — reachability is already what `ui` and
+   `public` mean.
 
 End of phase: render, update state (`em state set-phase slice` — the mechanical marker the state
 machine expects), and stop. Every slice already has a draft doc ready to receive the deep spec,
@@ -115,6 +126,9 @@ For each slice:
    "slices/<slice-name>.md"` line straight into the `.em`, onto the slice's primary element (the
    command for State Change, the view for State View, the processor for Automation, the
    translation for Translation), matched by export key — see step 4 for when it refuses instead.
+   A slice whose sole candidate view is a later `view X again` instance is a **continuation**
+   (MIL-208): `--wire` refuses it and names the originating slice holding `X`'s first
+   declaration — write this slice's scenarios into that doc instead of scaffolding a new one.
    Both `--pattern` and `--swimlane` are required; an invalid `--pattern` is refused with the
    valid choices listed. Never hand-type this block, and never fall back to a placeholder
    pattern/swimlane to dodge the flags. Then fill in every judgment section below the stub from
@@ -154,5 +168,7 @@ Before the project's first slice is implemented it also needs a ratified impleme
 constitution (stack, code style, testing norms, NFR baselines, review norms) — the
 `event-modeling-implement` skill elicits it, see its `reference/implement.md` §7.
 
-End of phase: every slice that should exist has a doc, `README.md`'s Slices table is current,
-and the model validates clean. Suggest `event-modeling-implement` for each ratified slice.
+End of phase: every slice that should exist has a doc — except a continuation slice (MIL-208, a
+later `view X again` instance), which has none by design and is documented by the originating
+slice instead — `README.md`'s Slices table is current, and the model validates clean. Suggest
+`event-modeling-implement` for each ratified slice.

package/.claude/skills/event-modeling-discover/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-discover
-em-version: 1.11.0
+em-version: 1.13.0
 description: >-
   Use when starting a brand-new event model from scratch — greenfield discovery: brainstorming
   past-tense events, storyboarding the happy path, finding the commands and read models — or when

package/.claude/skills/event-modeling-implement/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-implement
-em-version: 1.11.0
+em-version: 1.13.0
 description: >-
   Use when building a single ratified event-modeling slice (status: ready-to-implement) into
   merged, tested code — the one phase where the agent builds rather than facilitates. Gates on
@@ -16,11 +16,17 @@ the agent builds rather than facilitates.
 **Read `reference/implement.md` before doing any implement work and follow it as the
 contract.** In short: gate on `em validate <model>.em --slice-ready <key>` (stop and hand
 back if it fails — never edit the doc to make the gate pass); read the project's implementation
-constitution before writing code and stay inside its rules; treat the slice doc as the
-spec (read-only, except the merge-time `status`/`implementedIn` flip); surface every gap to
-the user instead of deciding it silently; cover every `INV-<MNEMONIC>-n` and every scenario with
-tests; in spec-kit projects, allocate via em-sdd-bridge (redirect mode) and never run
-`/speckit.specify`.
+constitution before writing code and stay inside its rules; before a project's first slice PR,
+land a one-time foundation PR holding every model event (plus the shared interface shell) so
+slices only ever import contracts, never invent or reach into a sibling's; build in dependency
+order from `em query upstream`, not timeline order; treat the slice doc as
+the spec (read-only, except the merge-time `status`/`implementedIn` flip); implement exactly one
+slice doc per PR — a `covers:` doc's two keys ship together in that one PR, an `again` view
+instance gets its own; ship the endpoint a
+`ui`-triggered command or `ui`-consumed view obligates, and surface — never invent — one the
+model doesn't show; surface every gap to the user instead of deciding it silently; cover every
+`INV-<MNEMONIC>-n` and every scenario with tests; in spec-kit projects, allocate via
+em-sdd-bridge (redirect mode) and never run `/speckit.specify`.
 
 **Gate: no constitution, no first slice.** The constitution is the project's ratified house rules
 — stack and architectural shape (including which implementation skill each slice pattern routes

package/.claude/skills/event-modeling-implement/reference/implement.md

@@ -26,18 +26,23 @@ em validate <model>.em --slice-ready <slice-key> --json
 ```
 
 `<slice-key>` is the slice's export key — the kebab-case slug of its name (`"Place Order"` →
-`place-order`). Read the JSON document's `ready` field — don't infer it from the exit code or
-any printed text. `ready: true` means: the slice has a doc bound via `note "slices/<key>.md"`,
-its frontmatter is usable, `status: ready-to-implement`, every `## Open Questions` checkbox is
-checked, and no status/version/link incoherence is flagged — `gates` names each of those 4
-conditions individually (`docBound`/`frontmatterUsable`/`statusReady`/
-`noUncheckedOpenQuestions`) if you need to say which one is blocking.
-
-**`ready: false` means stop.** Report which `gates` entries are `false` (and any `diagnostics`
-entries concerning this slice) and hand the slice back to the humans. Never make the gate pass
-yourself — checking an open-question box, flipping `status`, or editing frontmatter are
-ratification decisions, and ratification happens in a facilitated session, not in an
-implementation branch.
+`place-order`). Don't guess it or hand-slug the name yourself: list every slice's key with
+`em export <model>.em | jq -r '.model.slices[].key'`. Read the JSON document's `ready` field —
+don't infer it from the exit code or any printed text. `ready: true` means: the slice has a doc
+bound via `note "slices/<key>.md"`, its frontmatter is usable, `status: ready-to-implement`,
+every `## Open Questions` checkbox is checked, and no status/version/link incoherence is flagged
+— `gates` names each of those 4 conditions individually (`docBound`/`frontmatterUsable`/
+`statusReady`/`noUncheckedOpenQuestions`) if you need to say which one is blocking.
+
+**`ready: false` means stop** — with one named exception: a slice already `status: implemented`
+with `driftSignal: in-sync` or `uncertified` (MIL-214) also reads `ready: false` (its
+`statusReady` gate fails because nothing is newly ratified), and that specific case is
+re-implementation/repair, not a blocker — see §3's third mode before treating it as one. For
+every other `false`, report which `gates`
+entries are `false` (and any `diagnostics` entries concerning this slice) and hand the slice
+back to the humans. Never make the gate pass yourself — checking an open-question box, flipping
+`status`, or editing frontmatter are ratification decisions, and ratification happens in a
+facilitated session, not in an implementation branch.
 
 ## 2. Read the spec
 
@@ -68,18 +73,44 @@ Then read `slices/<slice-key>.md` end to end — every section is load-bearing:
 | `## Non-Functional Requirements` | Authz, PII, performance — implement or consciously surface, never skip |
 | `## Dependencies & Read Models Affected` | The blast radius — what else to check before and after |
 
+**Interface obligations follow from the model, not from the doc's prose.** The DSL already
+encodes what's reachable — see `em-dsl.md`'s "Headless / API systems & repeated read models"
+section — and the routing from it is mechanical, not a technical choice you make while coding:
+
+- A **command with a `ui` trigger** ships the endpoint that dispatches it as part of this slice
+  — shape, verb, status codes, and error mapping follow the constitution's interface conventions
+  (§7). Because: the model already said this command is reachable from outside; leaving it
+  reachable only through an internal gateway silently narrows what the model ratified.
+- A **view with a `ui` consumer** ships the query endpoint as part of this slice, same
+  conventions.
+- **No `ui`** on the trigger or the consumer (a command dispatched by a processor or a
+  translation, a view read only by a reaction) means internal-only: no endpoint. If one seems
+  needed anyway, that's a gap to surface (§4), not a technical choice to make mid-implementation
+  — adding a route the model doesn't show is exactly the kind of silent divergence §4 exists to
+  catch. An endpoint on a view the model shows no `ui` reading is a gap to surface the same way
+  (MIL-215) — conform will classify it as a **model gap**, never drift to delete, once you flag
+  it (`../../event-modeling-conform/reference/conform.md`, Flow step 4).
+- **`public` events and views** are the model's published integration surface: their shape is a
+  contract, not an implementation detail. `em validate --list-public` lists them; `em typespec`
+  is the POC generator for a downstream schema. Changing a public element's shape is a ratified
+  delta, never an implementation-time choice.
+
 For timeline context, read the slice's surroundings in the `.em` (what triggers it, what
 consumes its output) — the slice's own diagram (`slices/<slice-key>.svg`) shows its canonical
 pattern shape. For machine-readable facts, use `em export <model>.em --slice <slice-key>`
 rather than parsing the DSL or the doc's frontmatter yourself: it returns just this slice's
 object — `pattern`, element refs, fields, and the joined doc metadata (`slice.doc.status`,
 `version`, `driftSignal`) — without piping the whole model's export to find one `slice.doc`.
+When the view repeats later via `again` (MIL-208), that same call on the *originating* slice
+also returns `alsoReads: [{ event, atSlice }]` — the union of every event the read model
+consumes across all its later continuations, in timeline order — so implementing it never means
+walking each continuation by hand to assemble the full event list.
 
 If the project ships pattern-specific implementation skills (for example an Axon/DCB skill
 set keyed on a slice doc's `pattern:` frontmatter), route by the slice's pattern and follow
 those.
 
-## 3. Two modes: first version vs. ratified delta
+## 3. Three modes: first version, ratified delta, re-implementation/repair
 
 Check the doc's `version:` and `## Delta` section (or `em export`'s `slice.doc.driftSignal`):
 
@@ -93,6 +124,29 @@ Check the doc's `version:` and `## Delta` section (or `em export`'s `slice.doc.d
   **Never regenerate merged code wholesale from the model** — after merge, code is owned by
   the people who've edited it (generated-then-owned); regeneration is legal only for slices
   whose code never merged.
+- **Re-implementation / repair** (`status: implemented`, `implementedIn` set, `driftSignal:
+  in-sync` **or** `uncertified` (MIL-214 — certification status is orthogonal to whether the doc
+  changed; most shipped slices sit at `uncertified` until a conform sweep certifies them, which
+  doesn't change which mode this is) — `--slice-ready` reports `ready: false` purely because
+  `statusReady` fails, with no other gate false and no doc content changed): the doc hasn't
+  changed, but the shipped code
+  needs rebuilding or fixing — deleted code, a reverted PR, a bug in behavior the doc already
+  specifies. **The doc is still the spec.** The gate's `false` here means "nothing new is
+  ratified," not "stop" — it is not license to self-initiate: proceed only when a human has
+  asked for this specific re-work. Scope the change to what the repair needs, exactly like a
+  delta (generated-then-owned still applies — don't regenerate the whole slice wholesale just
+  because the gate reads oddly); if what you'd change is really a change in behavior rather than
+  a repair of it, that's a ratified delta (the bullet above), not this mode — when unsure which
+  one you're in, ask the human rather than guess.
+
+  No lifecycle flip is needed unless `implementedIn` changes. If it does,
+  `em slice mark-implemented <model>.em <slice-key> <new-pr-url>` will **refuse** rather than
+  overwrite: a doc already `implemented` with a different `implementedIn` URL is left untouched
+  and the command reports the conflict (`src/cli/markImplemented.ts`) instead of silently
+  replacing provenance. That refusal is correct, not a bug to route around — never hand-edit the
+  frontmatter to force it through. Surface the conflict to the human instead: they decide whether
+  the new PR supersedes the recorded one (and re-run `mark-implemented` themselves, or ask you to,
+  once they've decided) or whether the existing link should stand.
 
 ## 4. Gaps: propose, never decide
 
@@ -114,6 +168,20 @@ undocumented ordering, a contradiction with adjacent code. The discipline:
 
 ## 5. Definition of done
 
+**The unit is the slice doc: one slice doc = one PR.** A doc that `covers:` another slice (an
+automation's to-do-list view and its reaction, MIL-121) is one spec, not two — it ships in one
+PR, and `mark-implemented` runs for both keys against the same URL. A read model is one doc,
+even when a `view X again` clause repeats it across later positions on the timeline (MIL-208):
+the later instance is a **continuation** of the slice holding `X`'s first declaration, not a
+spec unit of its own — no doc, no status, no ratification, no PR of its own. Its behavior
+belongs in the originating doc's `## Scenarios` (one scenario per event the later instance
+feeds), not a doc of its own; `em export --slice <originating-key>` lists the full union of
+events the read model consumes across every position via `alsoReads` (§2). Never fold multiple
+slice docs' implementations into one PR because they touch the same read model, ship together,
+or seem small — see §10.
+
+- The PR description cites exactly one slice doc (plus its `covers:` keys, if any) and lists
+  that doc's invariants alongside the tests that cover them.
 - Every `INV-<MNEMONIC>-n` invariant has at least one test that cites its ID — checked mechanically by
   `em coverage <model>.em --tests <dir>` (MIL-130); run it (add `--strict` in CI) rather than
   eyeballing citations by hand.
@@ -122,11 +190,15 @@ undocumented ordering, a contradiction with adjacent code. The discipline:
 - Alternate/error flows (idempotency included) are covered by tests.
 - The build and full test suite are green; the model still validates (`em validate` in CI —
   you didn't touch the `.em`, so this only fails if something else broke).
-- Nothing between the slice doc and the code was committed as a source of truth (see §8 —
+- Nothing between the slice doc and the code was committed as a source of truth (see §9 —
   work containers are ephemeral; generated or symlinked specs are renderings).
 
 ## 6. At merge: the lifecycle flip
 
+The PR being merged here is the one doc's PR (§5) — its description cites exactly this slice doc
+(plus any `covers:` keys) and nothing else, which is what makes the flip below unambiguous: one
+PR, one `implementedIn` URL, applied to every key that PR's doc covers.
+
 When the PR merges, exactly **two** frontmatter fields change on the slice doc:
 
 ```yaml
@@ -165,7 +237,11 @@ parked in the document as open items, exactly like a slice doc's Open Questions:
 1. **Stack and architectural shape** — languages/runtimes, frameworks, the architectural pattern,
    where a slice's code lives, and the routing table: which implementation skill or approach each
    of the four slice patterns uses (for example, State Change slices → the `axon-*` skill set).
-   That table is what you obey in §2 when you read a slice's `pattern:`.
+   That table is what you obey in §2 when you read a slice's `pattern:`. This is also where the
+   **interface conventions** question gets asked — resource style, error/rejection mapping,
+   versioning, auth at the edge — so the shape of every endpoint the interface obligations
+   paragraph (§2) and the foundation step (§8) require is decided once, here, instead of
+   invented per slice.
 2. **Code style** — formatter/linter, naming, module layout, and what "idiomatic" means here.
 3. **Testing norms** — which test levels each pattern requires, where invariant and scenario
    tests live, and the test-naming convention that lets `em coverage` trace `INV-<MNEMONIC>-n`
@@ -197,7 +273,76 @@ spec-kit's own placeholders is the team's call, and em's sections go in alongsid
 `em status` will then report `constitution: present` for the model. That's the whole mechanical
 check — em stores and locates this document, and never validates a word of it.
 
-## 8. Spec-kit projects: the SDD adapter
+## 8. Foundation: contracts first
+
+Once per project, before the first slice PR ever opens, land one **foundation PR** that turns
+the model's events — and the cross-cutting shell the constitution names — into code, and
+nothing else. Skip this and the failure is the same on every project that's skipped it: the
+first slice PR ships fine, then the second one needs an event the first slice already defined
+informally, and every PR after that either redefines it slightly differently or reaches into a
+sibling slice's package to reuse it — the boundary the constitution drew is gone within a week.
+
+1. **What it contains.** Every event `em export <model>.em` lists in `events[]`, each placed in
+   the home the constitution's "where a slice's code lives" rule assigns to its *emitting*
+   slice — not a separate shared "events" module, so nothing about where an event lives depends
+   on this PR existing rather than the constitution. Fields come verbatim from the slice docs'
+   Event tables, with types mapped per the constitution's stack conventions. Add the
+   cross-cutting shell the constitution names: shared ports, and the request/response boundary
+   and error mapping the interface obligations above (§2) plug their endpoints into. **No
+   handlers, no projections — contracts only.** Because: a handler or a projection belongs to
+   the slice that owns the behavior behind it; folding one into the foundation PR turns a shared
+   contract into a pre-empted slice.
+2. **It merges before any slice PR opens.** Every slice branch is cut from `main` *after* the
+   foundation PR has landed there — never from a commit that predates it, and never alongside an
+   open, unmerged foundation PR. A slice PR never carries foundation files. Because: a slice PR
+   opened while the foundation is still in review shows a diff dominated by files the slice
+   didn't write and can't be held accountable for, and its merge depends on someone else's
+   review timeline instead of its own.
+3. **A slice never creates, edits, or reaches into another slice's code.** It *imports* events —
+   only events — from wherever the foundation placed them; a sibling slice's handlers, storage,
+   and other internals stay off limits. Because: the boundary the constitution drew only holds if
+   every slice actually stays inside it — a slice that quietly builds on a sibling's internals has
+   erased that boundary informally, one import at a time.
+4. **A ratified delta that adds or changes an event re-runs this step for that event, first.**
+   Land the code change for the new or changed event — in its emitting slice's home, following
+   rule 1 — before the slice's delta PR opens, exactly as if it were the first pass. Because: the
+   same contract-before-consumer ordering that applies once per project applies again every time
+   the contract itself changes; an event isn't a stable shared type just because it was one
+   yesterday.
+
+### Order of work
+
+The foundation PR above answers most of "which slice next" by itself — once every event exists
+as a contract, a read slice no longer has to wait for the write slice that will eventually
+produce it. What's left is ordering the slice PRs against each other, and that ordering comes
+from the dependency graph, not from where a slice sits on the timeline:
+
+1. **Foundation first removes most ordering constraints.** With every event already landed as a
+   contract (rules 1–4 above), a slice's remaining dependency is on other *slices*, not on
+   events existing at all — that's what turns "order every slice against every other slice"
+   into the short, per-pattern list below.
+2. **Then take dependency order from the graph, not the timeline.** Before starting a slice,
+   run `em query upstream <model>.em --of <slice's command-or-view ref>` — anything it returns
+   that's still `ready-to-implement` is a candidate to build first; `em query producers
+   <model>.em --event <name>` names the slices that own a specific event's producing commands
+   when you need to check one directly. Concretely, per pattern:
+   - **State Change** with no upstream is always startable — nothing but the foundation gates it.
+   - **State View** is startable as soon as the events it reads exist as contracts (the
+     foundation alone satisfies this), but build it *after* their producing slices have merged
+     when you can — its fixture tests then exercise real commands instead of hand-rolled event
+     fixtures.
+   - **Automation** goes after both the command it triggers and the to-do-list view it reads
+     (bound via `covers:` when the two are written as one doc) — a reaction can't be tested
+     against a command handler or a to-do list that doesn't exist yet.
+   - **Translation** goes after the command it triggers, same reasoning as an Automation's
+     triggered-command dependency.
+3. **Timeline order is the ratification order, not the build order.** Ratifying slices in
+   timeline order is deliberate — it's the order stakeholders reason about the business process
+   in. Carrying that same order into implementation is the mistake this section exists to head
+   off: build order comes from the dependency graph above, and the two orders routinely
+   disagree.
+
+## 9. Spec-kit projects: the SDD adapter
 
 If the repository uses spec-kit (a `.specify/` directory exists), do not hand-author spec-kit
 artifacts — allocate through **em-sdd-bridge**, redirect mode preferred:
@@ -229,7 +374,7 @@ plan/tasks as FEATURE_SPEC. The rules that keep redirect mode safe:
 No spec-kit (or any SDD tool)? Implement straight from the slice doc — it already contains
 everything a spec holds. Don't introduce an intermediate spec document of your own.
 
-## 9. Never do
+## 10. Never do
 
 | Rule | Because |
 |---|---|
@@ -241,8 +386,10 @@ everything a spec holds. Don't introduce an intermediate spec document of your o
 | Never invent the house rules a first slice needs (stack, style, testing, NFR defaults) | They're the project's decision, ratified in the constitution — §7, not your judgment call |
 | Never regenerate merged code from the model | Generated-then-owned: post-merge code belongs to its owners |
 | Never commit an authored intermediate spec | The slice is the spec; anything between it and the code is a rendering |
+| Never open a slice PR before the foundation PR has merged | The foundation is what makes an event a stable shared contract — a slice built ahead of it is building on a moving target (§8) |
+| Never implement more than one slice doc in a PR | The PR is the durable record of one spec's implementation; `mark-implemented`, coverage, and conformance all key on one doc ↔ one `implementedIn` |
 
-## 10. Afterward: the loop closes
+## 11. Afterward: the loop closes
 
 Implementation isn't the end of the slice's story. On a cadence — or whenever someone asks —
 the `conform` phase checks implemented slices against the code, using the `implementedIn` link

package/.claude/skills/event-modeling-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-review
-em-version: 1.11.0
+em-version: 1.13.0
 description: >-
   Use when starting em's live browser viewer (`em watch --serve`) so a team can watch a model
   update in real time, or facilitating a SCHEDULED stakeholder walkthrough that steps through
@@ -39,6 +39,10 @@ screen. Use Prev/Next (or the left/right arrow keys) to step through slices in d
 order — each one pans/zooms into view with everything else dimmed, so the room's attention
 tracks one slice at a time.
 
+**When a State View slice is on screen, ask who reads it (MIL-215):** a person or client in the
+room → the `ui` should draw it; another system → `public`; only an automation → nothing, it's
+internal by design and needs no endpoint.
+
 **Live capture:** when a stakeholder raises something unresolved, add `issue "..."` to the
 relevant element in the `.em` file and save — exactly the same mechanism `event-modeling-conform`
 uses for any other issue. The browser updates over the existing SSE push within moments, without