@milehimikey/em 1.11.0 → 1.12.0

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling
-em-version: 1.11.0
+em-version: 1.12.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

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-conform
-em-version: 1.11.0
+em-version: 1.12.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

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-design
-em-version: 1.11.0
+em-version: 1.12.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,8 +40,11 @@ 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
@@ -115,6 +118,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 +160,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.12.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.12.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,22 @@ 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` 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 +72,42 @@ 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.
+- **`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 +121,26 @@ 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` — `--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 +162,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 +184,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 +231,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 +267,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 +368,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 +380,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.12.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

package/.claude/skills/event-modeling-shared/reference/em-dsl.md

@@ -54,10 +54,10 @@ em slice index <file> --check                                 # verify the table
 em slice mark-implemented <file> <slice-key> <pr-url>         # flip a slice doc's frontmatter to `status: implemented` / `implementedIn: <pr-url>` — the one edit an implementing agent makes to a ratified doc at merge (MIL-103, replaces the em-sdd-bridge `em-sdd-mark-implemented` script; see reference/implement.md §6). Idempotent on the same URL; refuses to overwrite a different one; never touches `version:` or the doc body
 em slice review <file> <slice-key>                            # flip a slice doc's frontmatter to `status: reviewed` and record `reviewedBy:`/`reviewedOn:` — the FIRST of the two human gates (MIL-201, docs/process.md#the-slice-lifecycle-gates): the room walked this slice and every open question it raised is resolved. Ratification is a separate, later gate (`em slice ratify`). Legal from `status: draft`; idempotent on the same --by/--on pair; refuses to overwrite a different one already recorded; refuses a doc already `ready-to-implement`/`implemented`; never touches `version:` or the doc body
 em slice review <file> <slice-key> --by <name>                # the reviewer's (or facilitator's) name
-em slice review <file> <slice-key> --on <date>                # review date, YYYY-MM-DD (default: today)
+em slice review <file> <slice-key> --on <date>                # review date, YYYY-MM-DD (default: today, local date)
 em slice ratify <file> <slice-key>                            # flip a slice doc's frontmatter to `status: ready-to-implement` and record `ratifiedBy:`/`ratifiedOn:` — the handoff sign-off (MIL-165, docs/process.md#the-slice-lifecycle-gates) that makes who ratified, and when, a first-class recorded fact. Refuses a doc that never passed the review gate (`em slice review`) unless --skip-review is passed. Idempotent on the same --by/--on pair; refuses to overwrite a different one already recorded; never touches `version:` or the doc body
 em slice ratify <file> <slice-key> --by <name>                # the ratifier's name
-em slice ratify <file> <slice-key> --on <date>                # ratification date, YYYY-MM-DD (default: today)
+em slice ratify <file> <slice-key> --on <date>                # ratification date, YYYY-MM-DD (default: today, local date)
 em slice ratify <file> <slice-key> --skip-review              # ratify without a recorded review — prints a loud notice on stderr
 em slice reratify <file> <slice-key>                          # bump `version:` and flip a shipped slice doc's frontmatter back to `status: ready-to-implement` — the re-ratification mechanical edit (MIL-161, mirrors `em slice mark-implemented`). Only applies to a doc at `status: implemented`; clears any stale `ratifiedBy:`/`ratifiedOn:`/`reviewedBy:`/`reviewedOn:` (they describe the PRIOR version's review and sign-off) so a follow-up `em slice ratify --by` applies cleanly — and needs no fresh review; never touches `implementedIn:` or the doc body
 em changelog <file>                                           # render a model's git history as a business-readable ledger (see docs/cli.md)
@@ -81,7 +81,7 @@ em conform-scope <file> --seed-asis                           # write <model>-as
 em conform-supersede <file> <report-path>                     # stamp a conformance report with a "superseded as of <rev>" banner once its findings have been ruled on (MIL-164, docs/process.md#what-ratified-means) — the companion step to run at ratification time so a reader following the report's file:line citations knows they describe an ancestor of the current model. Additive-only splice, never a rewrite of the report; idempotent on the same --as-of/--findings/--on stamp; refuses if the report doesn't exist
 em conform-supersede <file> <report-path> --as-of <rev>       # the revision this ruling was made against — same value passed to `em state set-conformance`
 em conform-supersede <file> <report-path> --findings <spec>   # which finding number(s) this stamps as ruled, e.g. "1-3" or "1,2,4"
-em conform-supersede <file> <report-path> --on <date>         # ruling date, YYYY-MM-DD (default: today)
+em conform-supersede <file> <report-path> --on <date>         # ruling date, YYYY-MM-DD (default: today, local date)
 em watch <file>                                               # re-render on every save
 em watch <file> -o, --out <path>                              # output path (extension picks the format)
 em watch <file> -T, --format <fmt>                            # output format (svg, png, pdf, ...)
@@ -102,9 +102,10 @@ em ledger <file> --from <rev>                                 # baseline revisio
 em ledger <file> --to <rev>                                   # compare revision (default: current working tree)
 em ledger <file> --waive <slice-key>                          # excuse a doc-content-without-version-bump finding for this slice key (repeatable; MIL-185, see docs/cli.md) — never waives a version regression or bump-without-content-change
 em ledger <file> --json                                       # print a JSON document instead of the text report (see docs/cli.md)
-em coverage <file>                                            # check that every INV-* invariant ID cited in a ready-to-implement/implemented slice doc is cited by a test under --tests <dir> (MIL-130) — mechanizes reference/implement.md's definition-of-done citation check; advisory by default, --strict for CI
+em coverage <file>                                            # check that every INV-* invariant ID cited in an implemented slice doc is cited by a test under --tests <dir> (MIL-130/MIL-207) — mechanizes reference/implement.md's definition-of-done citation check; advisory by default, --strict for CI; --include-ready also counts ready-to-implement docs (forward-looking report); a continuation slice (an `again` view instance with no doc of its own, MIL-208) is excluded from the report — its invariants, if any, live in the originating slice's own doc
 em coverage <file> --tests <dir>                              # directory to scan recursively for test files citing invariant IDs
 em coverage <file> --strict                                   # exit non-zero if any invariant ID has zero citations (CI)
+em coverage <file> --include-ready                            # also count ready-to-implement docs, not just implemented (MIL-207)
 em coverage <file> --json                                     # print a JSON document instead of the text report (see docs/cli.md)
 em status <files>                                             # deterministic state-of-the-system rollup over one or more .em models: slices by lifecycle status, driftSignal breakdown, invariant coverage totals (with --tests), open issue markers + unchecked Open Questions, and last-conformance commits-behind-HEAD (MIL-163, see docs/cli.md)
 em status <files> --tests <dir>                               # directory to scan for INV-* test citations — enables invariant coverage totals
@@ -152,7 +153,7 @@ em query path <files> --json                                  # print a JSON doc
 em system <manifest>                                          # verify a seam manifest (system.yaml) against its models' exports — every `public` event/view bound to a reaction in another model, the cross-model half of "both ends of a flow" (MIL-194, see docs/cli.md)
 em system <manifest> --json                                   # print a JSON document instead of the text report (see docs/cli.md)
 em contract                                                   # print the packaged implementation contract (reference/implement.md) to stdout — the agent-neutral discovery path for any agent that can run a shell, not just Claude Code (MIL-129); see docs/cli.md
-em mcp                                                        # start an MCP (Model Context Protocol) server over stdio (MIL-21) — a structured, agent-facing alternative to shelling out to `em`; see docs/mcp.md for the full, current tool table (the list changes as commands gain MCP parity, so it's not repeated here — MIL-187). Equivalent to running the `em-mcp` bin directly
+em mcp                                                        # start an MCP (Model Context Protocol) server over stdio (MIL-21) — a structured, agent-facing alternative to shelling out to `em`; every tool mirrors a CLI `--json` surface byte-for-byte. docs/mcp.md isn't vendored into the skill bundle — for the handshake and the full, current tool table (the list changes as commands gain MCP parity, so it's not repeated here — MIL-187) see https://github.com/milehimikey/em/blob/main/docs/mcp.md. Equivalent to running the `em-mcp` bin directly
 em skill install                                              # copy the event-modeling skill bundle into .claude/skills/ (event-modeling, event-modeling-discover/-design/-implement/-conform/-review, event-modeling-shared); across a structural bundle change (e.g. the MIL-157 split of the old single event-modeling/ directory into this six-directory bundle), `em skill sync` is the migration path — --force now performs the same reconcile (MIL-180)
 em skill install -f, --force                                  # overwrite an existing installation, reconciling added/updated/removed files within the bundle's own managed directories the same way `em skill sync` does — never touching an unrelated sibling skill (MIL-180)
 em skill install --no-agents-md                               # skip writing/updating the AGENTS.md agent-contract section (on by default, MIL-129)
@@ -224,7 +225,11 @@ type Name { field: Type, ... }      # named structured type, reusable from any f
   connected to one another — continuity is implied by the shared name, and the events reaching each
   instance are what show the view changing. `again` with no earlier declaration is a validation error.
   Use `again` (not a plain repeated `view` name) whenever the view is referenced by a
-  `from`/`arrow` — plain repeats are only warning-free while unreferenced.
+  `from`/`arrow` — plain repeats are only warning-free while unreferenced. A later instance is
+  also a **continuation** for the doc lifecycle (MIL-208): it stays a slice on the timeline but
+  is not a spec unit — no doc, no status, no ratification, no PR of its own; the originating
+  slice's doc carries its behavior and `em export`'s `alsoReads` carries the union of events it
+  reads. See `slice-doc-schema.md`'s "Continuations" section for the full contract.
 - **`loops-to "View"`** (events only): marks an event as re-feeding an earlier read model — a
   poll/retry loop where a later fact must re-trigger an automation that already ran (a lapsed
   reservation re-notifying the next person waiting in line, and similar re-triggers). Written
@@ -516,6 +521,11 @@ slice "Read Quote — created" {
   Keep the read model adjacent to its event, and keep a sub-flow that detours into another context
   together rather than parking it at the end of the model.
 
+What this means for whoever builds a slice, not just whoever draws it: a `ui` trigger or
+consumer is an obligation to ship an endpoint, no `ui` means internal-only, and `public` marks
+the published integration surface — see `reference/implement.md`'s "Interface obligations"
+paragraph in the `event-modeling-implement` skill (§2).
+
 ### Reaction wiring — no positional gotcha
 
 A reaction's command is inferred from **same-slice presence**, exactly like `ui -> command`: put
@@ -646,6 +656,7 @@ not the prose above has caught up yet. `--slice-ready <key>`-only codes are excl
 | `both-ends-of-a-flow/ui-unbacked` | warning | `ui` with no read model or command | Add a `view` it displays, or the command it triggers. |
 | `both-ends-of-a-flow/view-unconsumed` | warning | Read model with no consumer | Add a `ui` or reaction that consumes it, or drop this instance. |
 | `connection-legality/illegal-pair` | error | Illegal connection | Only ui→command→event→view→ui and view→reaction→command are legal — the message names the missing step. |
+| `continuation-has-own-doc` | warning | Continuation slice has its own doc | Fold this doc's scenarios into slices/<originating-key>.md and delete it; a later `view X again` instance is documented by the view's originating slice. |
 | `cross-model-slice-doc-collision` | warning | Colliding slice doc path across models | Give each model its own directory (see docs/cli.md, "Multi-model projects"). |
 | `dangling-public-event` | warning | Public event/view no seam consumes | Declare the seam that reads it, or drop `public` if nothing outside the model does. |
 | `derived-from-unresolved` | error | `derived from` names an unknown event | Name one of the view's actual sources, or drop the traced event from `derived from`. |

package/.claude/skills/event-modeling-shared/reference/slice-doc-schema.md

@@ -180,6 +180,12 @@ reads a bound doc's canonical fields (`em export`'s `slice.doc`, `em validate --
 `implementedIn`/lineage/Open Questions, not the covered slice's own (nonexistent) file. A doc
 covers its own canonical slice key implicitly — `covers` never needs to list it.
 
+`em catalog` (MIL-137) is one such consumer, via the same filename+frontmatter `covers:` scan
+(`src/catalog/coverage.ts`), never the `note` clause itself: a covered slice's detail page shows
+the covering doc's Status, but a "Documented as part of <covering slice>" banner instead
+of the covering doc's body — linking to the covering slice's own catalog page rather than
+inlining content authored under a different slice's name.
+
 `covers` is a plain list of slice keys (`<slice-key>`, e.g. `detect-unpaid-orders`), **not** the
 `<slice-key>@v<N>` ref grammar the lineage keys use above: coverage is a standing "this doc also
 serves that slice" declaration, with no version component — unlike lineage, which records a
@@ -195,6 +201,39 @@ the mismatch, as its own separate rule (MIL-126) — see
 that just doesn't ratify (`covers` doesn't list this slice back), and an extra note doing nothing
 in a slice that's already bound elsewhere, each get their own diagnostic there.
 
+## Continuations
+
+Since `em` 1.12.0 (MIL-208): a `view X again` instance is a **continuation** of the slice
+holding `X`'s first (originating) declaration — one read model, fed by more than one event over
+the timeline — not a spec unit of its own. Unlike `covers` above, this is fully automatic and
+structural: no frontmatter, no `note`, nothing to author. A slice is a continuation iff every
+non-`ui` element it declares is a `view` with `again === true`; the doc join resolves it
+straight through to the originating slice's own doc, exactly the way a ratified `covers:`
+binding resolves a covered slice — same `doc.found`/`status`/`driftSignal`, plus a
+`continuationOf: <originating-key>` field naming why. `em export`, `em status`, `em coverage`,
+`em slice index`, `em catalog`, and the render pipeline's Slice Status legend all resolve a
+continuation slice this way; `em slice ratify`/`review`/`reratify`/`mark-implemented` and
+`em slice new --wire` refuse on one outright, naming the originating slice to act on instead —
+a continuation slice has no status/ratification of its own to flip.
+
+The originating slice's own `em export` object also gains `alsoReads: [{ event, atSlice }]` —
+the union of events every later `again` instance of that view reads via `from`, in timeline
+order — so implementing the read model from one export never means walking every `again`
+slice's doc by hand to assemble the full event list.
+
+**Authoring convention:** a continuation's behavior belongs in the originating doc's own
+`## Scenarios (Given / When / Then)` section — one scenario per event a later `again` instance
+feeds — rather than in a doc of its own; no new frontmatter is needed to record it.
+
+**Legacy own doc wins.** A slice that would otherwise be a continuation but still carries its
+own doc — a `note "slices/<again-key>.md"` binding it, or a stray `slices/<again-key>.md` file
+left over from before this rule existed — keeps today's per-instance behavior unchanged: its own
+doc, its own status, its own ratification. `em validate`'s `continuation-has-own-doc` warning
+(see [validation.md](https://github.com/milehimikey/em/blob/main/docs/validation.md)) flags it either way, so an author can fold that doc's
+scenarios into `slices/<originating-key>.md` and delete it. This is the migration path — an
+existing model with per-`again`-instance docs keeps working exactly as before until each one is
+folded in.
+
 ## Delta section: grammar and lifecycle
 
 `## Delta` is the body section that pairs with a re-ratification (see "`status` under

package/.claude/skills/event-modeling-shared/templates/constitution.md

@@ -46,6 +46,9 @@ technical choice" an implementing agent would otherwise make alone.
 - **Architectural pattern:** {{e.g. event-sourced CQRS with vertical slices; layered service over
   a relational store; functional core / imperative shell}}
 - **Where a slice's code lives:** {{one package per slice, per context, ...}}
+- **Interface conventions:** {{resource style — REST/RPC/GraphQL, etc.; error/rejection mapping;
+  versioning; auth at the edge — the shape every `ui`-triggered command or `ui`-consumed view's
+  endpoint follows, decided once here rather than invented per slice}}
 
 Routing — which implementation skill or approach each of the four slice patterns uses:
 
@@ -105,7 +108,11 @@ it is silent, these apply.
 - **Reviewers:** {{who — a team, a CODEOWNERS rule, the slice's ratifier}}
 - **What blocks a merge:** {{e.g. a failing suite, an uncovered invariant, a gap that belongs back
   at the model}}
-- **Branch / commit conventions:** {{...}}
+- **Branch / commit conventions:** {{...}} — name only branch naming and commit-message style
+  here. **One slice doc = one PR is the implement contract's rule, not this document's to
+  amend** — a `covers:` doc ships as one PR for both keys; a read model is one doc, so a later
+  `again` instance is a continuation of the doc that first declared it, not a PR of its own. See
+  the agent guide's §5/§10.
 - **At merge:** run `em slice mark-implemented <model>.em <slice-key> <pr-url>` — the one edit an
   implementing agent makes to a ratified slice doc, run by {{the PR author | CI}}. Never bump
   `version:`; that moves only when a delta is ratified.

package/dist/catalog/build.js

@@ -13,10 +13,12 @@
 import { existsSync, readFileSync } from "node:fs";
 import { copyFile, mkdir, writeFile } from "node:fs/promises";
 import { basename, dirname, extname, join } from "node:path";
+import { continuationOf } from "../model/continuation.js";
 import { layoutDot, composeSvg, writeRendered } from "../render/render.js";
 import { buildSliceDiagram } from "../render/sliceDiagram.js";
 import { dedupe, kebabSlug } from "../util/slug.js";
 import { classifySlicePattern } from "./classify.js";
+import { readCoverageDocs } from "./coverage.js";
 import { detectSliceDocCollisions } from "./modelCollisionValidate.js";
 import { parseSliceDoc } from "./sliceDoc.js";
 import { renderIndexPage, renderSlicePage } from "./pages.js";
@@ -51,6 +53,11 @@ export async function buildCatalog(inputs, opts) {
         if (refs.diagnostics.length > 0)
             diagnostics.push({ file, diagnostics: refs.diagnostics });
         const sliceSummaries = [];
+        // MIL-137: built lazily, only if some slice below actually lacks its own doc — same
+        // shared scan (src/catalog/coverage.ts) the render pipeline's Slice Status legend uses
+        // (src/render/sliceStatus.ts), so a covered slice never resolves to a different doc
+        // depending on which command asked.
+        let coverageDocs = null;
         for (let i = 0; i < model.slices.length; i++) {
             const slice = model.slices[i];
             const sliceKey = refs.sliceKeys[i];
@@ -63,7 +70,40 @@ export async function buildCatalog(inputs, opts) {
             // instead of silently rendering the first slice's doc content on both pages.
             const docRelPath = join("slices", `${sliceKey}.md`);
             const docPath = join(dirname(file), docRelPath);
-            const doc = existsSync(docPath) ? parseSliceDoc(readFileSync(docPath, "utf8")) : null;
+            const ownDoc = existsSync(docPath) ? parseSliceDoc(readFileSync(docPath, "utf8")) : null;
+            // MIL-137: no own doc -> fall back to a sibling doc that ratifies coverage of this slice
+            // (MIL-121 `covers:`). The covering doc's status/pattern act as this slice's own for the
+            // index Status column and this page's header badge (same "one doc, one status" rule the
+            // render pipeline's Slice Status legend already applies), but its BODY is never inlined —
+            // the detail page shows a "documented as part of" banner linking to the covering slice's
+            // own page instead, never the covering doc's content rendered under a different slice's
+            // name.
+            let doc = ownDoc;
+            let coveredBy = null;
+            if (!ownDoc) {
+                coverageDocs ??= readCoverageDocs(join(dirname(file), "slices"));
+                const covering = coverageDocs.get(sliceKey);
+                if (covering) {
+                    doc = covering.doc;
+                    const coveringIndex = refs.sliceKeys.indexOf(covering.key);
+                    coveredBy = { key: covering.key, name: coveringIndex >= 0 ? model.slices[coveringIndex].name : covering.key, kind: "covers" };
+                }
+                else {
+                    // MIL-208: still no doc — check whether this slice is a CONTINUATION (an again-view-
+                    // only slice) of another slice's own file, filename-convention resolution's own
+                    // fallback (mirrors render/sliceStatus.ts's readSliceDocs). Checked last, after both
+                    // the own-file and MIL-121 covers: lookups have already come up empty.
+                    const continuation = continuationOf(model, refs, i);
+                    if (continuation) {
+                        const originatingPath = join(dirname(file), "slices", `${continuation.sliceKey}.md`);
+                        if (existsSync(originatingPath)) {
+                            doc = parseSliceDoc(readFileSync(originatingPath, "utf8"));
+                            const originatingSlice = model.slices[continuation.sliceIndex];
+                            coveredBy = { key: continuation.sliceKey, name: originatingSlice.name, kind: "continuation" };
+                        }
+                    }
+                }
+            }
             // Same sibling-file convention as the doc lookup above, one extension over: a
             // slice diagram authored by `em render --slice` (per the event-modeling skill)
             // is copied in as-is so the catalog stays self-contained; otherwise built
@@ -103,6 +143,7 @@ export async function buildCatalog(inputs, opts) {
                 pattern,
                 elementRefs,
                 doc,
+                coveredBy,
                 docExpectedPath: docRelPath,
             });
             await writeFile(join(slicesDir, `${sliceKey}.html`), page, "utf8");