@milehimikey/em 1.10.0 → 1.11.0

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling
-em-version: 1.10.0
+em-version: 1.11.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.10.0
+em-version: 1.11.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
@@ -37,6 +37,10 @@ canonical model's names wherever the code matches them); run `em diff <model-nam
 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.
+
 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

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-design
-em-version: 1.10.0
+em-version: 1.11.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
@@ -36,9 +36,19 @@ Goal: a structurally complete, **validated** model with correct patterns and swi
    directly**. Add `translation` slices for external inputs (externally triggered: external →
    translation → command → event, no slice before) and for the system reacting to its own state
    (internally triggered: read model in the slice before → translation → command → event).
-2. **Elaborate scenarios — first pass (step 6).** For each slice, capture the happy-path
-   Given/When/Then and the obvious invariants as short notes. (The full spec is the `slice` phase
-   below.)
+2. **Elaborate scenarios — first pass (step 6).** Scaffold every slice's doc now, one per
+   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
+   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.
 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
@@ -51,13 +61,19 @@ Goal: a structurally complete, **validated** model with correct patterns and swi
    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.
 
-End of phase: render, update state (`em state set-phase slice`), continue with the `slice` phase
-below to write implementation specs.
+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,
+but slicing is deliberate work the team starts when it's ready for it, not this phase's automatic
+next step.
 
 ## Phase: `slice` — deep slice documents
 
-Goal: implementation-ready specs. Go slice by slice (let the user pick order, or follow the
-timeline). Check `README.md`'s Slices table for what's already done (run `em slice index
+Goal: implementation-ready specs. Go slice by slice **in timeline order, starting with the first
+slice on the storyboard** — never ask the user which slice to spec first, and never propose
+starting with whichever slice looks highest-risk or most uncertain instead. Ratification
+proceeds in the same order: later slices' scenarios and invariants depend on earlier slices'
+events already being settled, so working out of order means re-litigating an earlier slice's
+contract mid-spec. Check `README.md`'s Slices table for what's already done (run `em slice index
 <model-name>.em` first if it looks stale).
 
 This is also where **branch / unhappy-path events** are discovered and added to the model — as a
@@ -130,10 +146,13 @@ For each slice:
    `implementedIn` once shipped). Never hand-edit the table; it's a generated block.
 6. Re-render and `em validate`.
 
-When a slice is **ratified** — a human flips its `status` to `ready-to-implement` with every
-open question resolved — it's ready to hand to an implementer. Confirm with
-`em validate <model>.em --slice-ready <key>`, and point whoever (or whatever) implements it
-at the `event-modeling-implement` skill.
+A finished draft doesn't become implementable here: it goes through the review gate and then the
+ratification gate, both human, both outside this phase — see
+`docs/process.md#the-slice-lifecycle-gates` for who runs which and in what order.
+
+Before the project's first slice is implemented it also needs a ratified implementation
+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.

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-discover
-em-version: 1.10.0
+em-version: 1.11.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.10.0
+em-version: 1.11.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
@@ -15,19 +15,30 @@ 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); treat the slice doc as the
+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`.
 
+**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
+to), code style, testing norms, NFR baselines, review/merge norms. It lives at
+`.specify/memory/constitution.md` in a spec-kit project, otherwise `constitution.md` beside the
+model; `em status` reports which, and whether it's there. If it's missing — or its `ratifiedBy:`
+is empty, meaning nobody has signed it off — run `reference/implement.md` §7 ("Before the first
+slice: the constitution") first: ask its questions conversationally, write the answers in, and
+have a human ratify them. Don't decide the project's stack or style yourself to get moving.
+
 That contract applies to any implementing agent, whether or not the session started from
 `/event-modeling` — `em contract` prints it to stdout with no `.claude/` awareness required, for
 an agent that can run a shell but isn't Claude Code.
 
 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 —
-`reference/implement.md` §2 explains where that hand-off happens.
+`reference/implement.md` §2 explains where that hand-off happens, and the constitution's
+routing table (§7) is what names the skill set for each pattern.
 
 Preconditions (tool check, model location) are the same as every other phase — see
 `../event-modeling-shared/reference/operating-principles.md` — but this phase additionally

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

@@ -41,7 +41,22 @@ implementation branch.
 
 ## 2. Read the spec
 
-Read `slices/<slice-key>.md` end to end — every section is load-bearing:
+**First, read the project's constitution** — the house rules for *how* implementation happens
+here (stack and architectural shape, which implementation skill each slice pattern routes to,
+code style, testing norms, NFR baselines, review and merge norms). It lives in one of exactly two
+places, never both:
+
+- **spec-kit project** (a `.specify/` directory exists at or above the model):
+  `.specify/memory/constitution.md` — spec-kit's own slot, which em defers to.
+- **anything else**: `constitution.md` beside the model, where `em scaffold` writes it.
+
+`em status <model>.em --json` reports which one applies and whether it's there
+(`conformance[].constitution`) — existence only; nothing in `em` reads or judges its content.
+**Its rules bound every technical choice you make on this slice** (see §4). If it's missing, or
+its `ratifiedBy:` is empty (spec-kit's file: the `**Ratified**:` footer still a placeholder),
+it isn't ratified — go to §7 before writing code.
+
+Then read `slices/<slice-key>.md` end to end — every section is load-bearing:
 
 | Section | What it is to the implementer |
 |---|---|
@@ -92,7 +107,10 @@ undocumented ordering, a contradiction with adjacent code. The discipline:
   a business person could have an opinion on. Silent divergence is the failure mode the whole
   conformance loop exists to catch — don't manufacture it.
 - Purely technical choices with no behavioral surface (private naming, idiomatic structure,
-  which assertion library) are yours; anything observable in behavior, data, or contract is not.
+  which assertion library) are yours — **within the constitution's rules** (§2); anything
+  observable in behavior, data, or contract is not. If no constitution exists (or its
+  `ratifiedBy` is empty), surface that to the human and do not proceed on unilateral style or
+  stack decisions for a first slice: run the constitution step (§7) first.
 
 ## 5. Definition of done
 
@@ -104,7 +122,7 @@ 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 §7 —
+- Nothing between the slice doc and the code was committed as a source of truth (see §8 —
   work containers are ephemeral; generated or symlinked specs are renderings).
 
 ## 6. At merge: the lifecycle flip
@@ -131,7 +149,55 @@ Then, if the project keeps a model README (from `../../event-modeling-shared/tem
 link — never hand-edit that table. The `implementedIn` link is what the `conform` phase later
 uses to anchor drift-checking — leaving it empty blinds the loop.
 
-## 7. Spec-kit projects: the SDD adapter
+## 7. Before the first slice: the constitution
+
+The first time this project's slices reach implementation — or any time §2 finds no constitution,
+or one whose `ratifiedBy` is still empty — **stop and run this short conversation before writing
+code.** It happens once per project, not once per slice.
+
+Start from the template the skill bundle ships,
+`../../event-modeling-shared/templates/constitution.md`. Each of its five sections opens with the
+question to ask; ask them **conversationally, one section at a time**, and write the answers into
+the document as you go — never fill a section by guessing, by reading the codebase and inferring
+"what they probably do", or by pasting the template's own examples. Unanswerable questions get
+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:`.
+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`
+   citations.
+4. **NFR baselines** — authz model, PII handling, performance defaults, observability: the
+   standing defaults every slice inherits where its own `## Non-Functional Requirements` section
+   is silent.
+5. **Review and merge norms** — who reviews, what blocks a merge, and who runs
+   `em slice mark-implemented` at merge (§6).
+
+**A human ratifies it.** The answers are the project's, not yours — you drafted the wording, they
+sign it off. In the em-native file that's the `ratifiedBy:`/`ratifiedOn:` frontmatter (a named
+person and an ISO date, hand-filled — no `em` command writes this file, and an empty `ratifiedBy:`
+means *draft*). In a spec-kit project it's that file's own `**Ratified**:` footer line — never add
+frontmatter to spec-kit's document. Until it's ratified, treat it as a proposal: you may not
+build a first slice on it.
+
+**In a spec-kit project, merge — never duplicate.** The constitution IS
+`.specify/memory/constitution.md`; em writes no second file and neither do you. Append em's five
+sections to it under their own `##` headings, **leaving every existing section byte-untouched** —
+including spec-kit's own `## Core Principles` and `## Governance`, and any principle a team
+already wrote. If a heading of the same name is already there, add to it rather than replacing it,
+and show the human the diff before writing. Two cautions: spec-kit's `/speckit.constitution`
+command rewrites that whole file from its template, so run it (if at all) **before** this
+conversation, never after — and never use it to author em's sections. If the file is still the
+blank stock template (`[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`, … placeholders), say so: filling
+spec-kit's own placeholders is the team's call, and em's sections go in alongside them either way.
+
+`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
 
 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:
@@ -163,7 +229,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.
 
-## 8. Never do
+## 9. Never do
 
 | Rule | Because |
 |---|---|
@@ -172,10 +238,11 @@ everything a spec holds. Don't introduce an intermediate spec document of your o
 | Never edit the `.em` model | Model edits are ratified decisions — propose, don't write |
 | Never bump `version:` | Versions move only with ratified deltas; see `em ledger` |
 | Never silently decide unspecified behavior | Silent divergence is the disease the conformance loop exists to catch |
+| 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 |
 
-## 9. Afterward: the loop closes
+## 10. 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.10.0
+em-version: 1.11.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
@@ -49,8 +49,19 @@ walk each one with the user, same as any open issue. Update the state file's Par
 section with who attended, and run `em state set-review <date>` to set the `Last stakeholder
 review:` marker (mirrors `Last conformance:`).
 
-End of phase: state file's `Last stakeholder review:` marker updated, every issue captured
-live triaged (resolved on the spot, moved to Open questions / parking lot, or left open on
+**Per-slice outcome.** A slice whose open questions are all resolved in the room →
+`em slice review <model>.em <key> --by <name>` (flips its doc to `status: reviewed` and records
+`reviewedBy:`/`reviewedOn:`). Anything still open stays `draft` — the walkthrough doesn't decide
+it, the next session or the open-questions list does.
+
+**The facilitator never ratifies, never offers to ratify, and never suggests ratification in a
+review session. Ratification is a separate human gate after review**
+(docs/process.md#the-slice-lifecycle-gates). It is typically multi-person, routed through
+CODEOWNERS on `slices/**`, and it is not this session's to run — `em slice ratify` will itself
+refuse a doc that hasn't been through `em slice review`.
+
+End of phase: state file's `Last stakeholder review:` marker updated, every walked slice whose
+questions all closed moved to `status: reviewed`, every issue captured live triaged (resolved on the spot, moved to Open questions / parking lot, or left open on
 purpose). Review doesn't chain to another phase — it's a recurring, scheduled activity like
 `conform`, not a step in the discover → model → slice sequence.
 

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

@@ -15,7 +15,7 @@ Keep `.em` files focused on **structure**; put deep design in markdown linked vi
 em --version                                                  # print the installed em version
 em init [file]                                                # scaffold a starter .em model
 em init [file] -f, --force                                    # overwrite if the file exists
-em scaffold <name>                                            # scaffold a full project: <slug>/<slug>.em, README.md, .event-modeling.md (see docs/cli.md — for just a starter .em, use `em init`; for a multi-model project, pass --under to nest it under a shared parent directory)
+em scaffold <name>                                            # scaffold a full project: <slug>/<slug>.em, README.md, .event-modeling.md, and constitution.md (the implementation constitution — skipped, with a note, in a spec-kit project, where `.specify/memory/constitution.md` IS that document) (see docs/cli.md — for just a starter .em, use `em init`; for a multi-model project, pass --under to nest it under a shared parent directory)
 em scaffold <name> -f, --force                                # overwrite the directory's contents if it already exists
 em scaffold <name> --under <dir>                              # parent directory to scaffold into — writes <dir>/<slug>/ instead of ./<slug>/, the supported multi-model layout (docs/cli.md, "Multi-model projects"): one directory per model, so each model's slices/ never collides with a sibling model's
 em render <file>                                              # transpile a model and render it (or emit DOT)
@@ -52,10 +52,14 @@ em slice new <name> --wire <model-file>                       # also insert the
 em slice index <file>                                         # rewrite the model's sibling README.md's GENERATED Slices table from `em export`'s slice facts (key, pattern, doc status/implementedIn) — the hand-maintained table is deprecated
 em slice index <file> --check                                 # verify the table is current; exit non-zero on drift without writing (CI)
 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 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#what-ratified-means) that makes who ratified, and when, a first-class recorded fact. Idempotent on the same --by/--on pair; refuses to overwrite a different one already recorded; 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 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 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:` (they describe the PRIOR version's sign-off) so a follow-up `em slice ratify --by` applies cleanly; never touches `implementedIn:` or the doc body
+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)
 em changelog <file> --from <rev>                              # start the walk at this revision (inclusive)
 em changelog <file> --to <rev>                                # end the walk at this revision (inclusive; default HEAD)
@@ -96,6 +100,7 @@ em migrate <file> --write                                     # apply the rewrit
 em ledger <file>                                              # check slice docs' version: field agrees with their content across two git revisions (opt-in CI check, MIL-89 — never part of `em validate`, see docs/ci.md)
 em ledger <file> --from <rev>                                 # baseline revision
 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> --tests <dir>                              # directory to scan recursively for test files citing invariant IDs
@@ -148,8 +153,8 @@ em system <manifest>                                          # verify a seam ma
 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 skill install                                              # copy the event-modeling skill bundle into .claude/skills/ (event-modeling, event-modeling-discover/-design/-implement/-conform/-review, event-modeling-shared)
-em skill install -f, --force                                  # overwrite an existing installation
+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)
 em skill sync [path]                                          # update the vendored .claude/skills/ event-modeling skill bundle in [path] to match the installed em package (overwrites unconditionally; local edits are never merged, MIL-93)
 em skill sync [path] --no-agents-md                           # skip writing/updating the AGENTS.md agent-contract section (on by default, MIL-129)
@@ -195,7 +200,7 @@ type Name { field: Type, ... }      # named structured type, reusable from any f
 | `ui` | persona | screen / interface | `@Persona` | `note`, `issue`, `divergence`, `{ fields }` |
 | `command` | API | state-changing request | — | `note`, `issue`, `divergence`, `renamed from`, `{ fields }` |
 | `view` | API | read model / projection | — | `from "Event"…`, `note`, `issue`, `divergence`, `public`, `{ fields }` |
-| `event` | context | recorded fact (past tense) | `@Context` | `note`, `issue`, `divergence`, `public`, `tag`, `renamed from`, field-level `assigned`, `{ fields }` |
+| `event` | context | recorded fact (past tense) | `@Context` | `note`, `issue`, `divergence`, `public`, `tag`, `renamed from`, `loops-to`, field-level `assigned`, `{ fields }` |
 | `processor` / `automation` / `saga` / `translation` | automation | system reaction / adapter | — | `from "…"`, `note`, `issue`, `divergence`, `{ fields }` |
 
 ### Clauses
@@ -220,6 +225,22 @@ type Name { field: Type, ... }      # named structured type, reusable from any f
   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.
+- **`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
+  after the event's name/`@Context`, either on the header line or trailing an
+  inline `{ fields }` block; repeatable (`loops-to "A" loops-to "B"`, or comma-joined). The
+  target must resolve to a `view` instance STRICTLY EARLIER on the timeline — the opposite of
+  `from`'s "nearest at-or-before" rule; pointing at the same slice or later is a validation
+  error naming `from` on a later `view … again` instance as the forward-flowing alternative,
+  and naming a view that doesn't exist is a separate unresolved-target error. A resolved
+  `loops-to` counts as the event being read for both-ends-of-a-flow completeness. **No arrow is
+  ever drawn** for it — drawing one backward would violate the timeline laws — instead the
+  event gets an indigo ↩ corner marker (bottom-left) and the legend gains a "Loops" section:
+  `↩ 1  <Event> re-feeds "<View>"` (the number identifies the event, not the target). `em
+  export` carries it as `loopsTo: { name, ref }[] | null` (`from`'s shape); `model.edges` gains
+  `{ from: <event ref>, to: <view ref>, source: "loops-to" }`; `em query`'s adjacency labels the
+  connection `"loops-to"` too, so `downstream`/`upstream` follow it (cycle-safely).
 - **`note "path.md"`** on ANY element links a markdown doc. Relative to the `.em` file. Renders as
   a clickable marker in SVG and a legend entry in PNG/PDF. **This is how slice docs attach.**
 - **`issue "text"`** on ANY element flags an open question inline — the diagram-visible red
@@ -280,6 +301,25 @@ type Name { field: Type, ... }      # named structured type, reusable from any f
   `=== true` convention as `tag`. **Reach for this before echoing a server-set field onto the
   command just to silence a fields-completeness warning** — that misrepresents what the client
   actually sends.
+- **`derived`** (view fields only, MIL-200): marks a field as computed from which events have
+  landed, rather than copied from a single source event's payload (a status stepping through
+  states as events arrive, a computed ordinal, an availability flag two events can flip).
+  Trails a field's type, or the bare name of a typeless field — bare `derived` (no traced
+  source) or traced `derived from "Event A", "Event B"` (the two-word form parsed before the
+  bare check, same discipline as `renamed from` vs. plain `from`). A field whose ENTIRE text is
+  just `derived` is a field named `derived`, not a clause. `derived`/`derived from` on a
+  command/event/`ui`/`type` field is a parse error. Excludes the field from
+  `fields-completeness/view-field-no-source` entirely (and thus from `--slice-ready`). The
+  traced form still checks something: every named event must resolve among the view's ACTUAL
+  sources (its own `from` list, or the same-slice events for a `from`-less view) — an
+  unresolved name is a validation error, `derived-from-unresolved`. `em export` carries it as
+  `derived: boolean` on the field (always present, same `=== true` convention as `tag`/
+  `assigned`) and `derivedFrom: string[] | null` (the traced event name(s), `null` on a bare
+  `derived` field). **Reach for this instead of dropping a computed field out of the `.em` and
+  into doc-only prose** — the marker keeps `em export`/the model aware the field exists (the
+  `doc-model-field-mismatch` doc↔model check does not compare view field tables at all today —
+  see the slice template's field-table guidance — so this is an export-side win specifically,
+  not yet a doc-drift check).
 - **Fields:** `command Place Order { orderId: UUID, items: LineItem[], customerId }` — inline or
   one-per-line. Types are free text (no semantic checking) UNLESS the type string names a
   declared `type` (see Named types below), in which case it resolves to a structured
@@ -521,6 +561,14 @@ it to the slice that displays the read model, or drop it.
    a ref naming a version higher than the target's own `version:`. A `split-from`/`merged-from`
    naming a key absent from the tree is deliberately silent — that's the normal state after a
    real split/merge (see the four `lineage-*` codes in the table below).
+10. **`loops-to` not earlier, or unresolved** — an event's `loops-to "View"` naming a view at the
+    same slice or later (`loops-to-forward`; that's what `from` on a later `view … again`
+    instance is for), or naming a view that doesn't exist at all, or a name that resolves to a
+    non-view (`loops-to-unresolved`).
+11. **`derived from` names an unresolved event** — a view field's traced `derived from "Event
+    A", "Event B"` clause naming an event that isn't among the view's actual sources (its own
+    `from` list, or the same-slice events for a `from`-less view) — `derived-from-unresolved`.
+    Name one of the view's real sources, or drop the traced event.
 
 **Warnings (should fix):**
 1. **Reaction with no command** — a `processor`/`automation`/`saga`/`translation` that triggers
@@ -537,9 +585,11 @@ it to the slice that displays the read model, or drop it.
 5. **Event nobody reads** — the mirror of (4): recording an event no read model projects is a
    write with no reader. Follow every write slice with the read slice that consumes its event.
    Counts as read when a `view` names it in `from` (any `again` instance will do), when a view
-   with no `from` of its own sits in its slice, or via an explicit `event -> view` arrow.
-   (Events marked `public` are exempt — their reader is outside the model; same for a
-   `public` view and the no-consumer warning.)
+   with no `from` of its own sits in its slice, via an explicit `event -> view` arrow, or via a
+   resolved `loops-to "View"` clause (a loop-back is a real consumer too — an UNRESOLVED or
+   forward `loops-to` does not count, so the event still warns as unread alongside its own
+   `loops-to-forward`/`loops-to-unresolved` error). (Events marked `public` are exempt — their
+   reader is outside the model; same for a `public` view and the no-consumer warning.)
 6. **Read model without source** — add `from "Event"` or place the view in a slice with an event.
 7. **Duplicate name** — the same name defined N times; references resolve to the first. Rename.
    (A duplicate `type` name always warns, unlike a duplicate element name — there's no
@@ -549,7 +599,8 @@ it to the slice that displays the read model, or drop it.
    fail while any remain open.
 9. **View field with no source** — a `view` field whose name matches no field on any instance
    of its source events. Only checked once BOTH the view and at least one source event declare
-   `{ fields }`.
+   `{ fields }` — unless the field is marked `derived` (optionally `derived from "Event A",
+   "Event B"`, whose names must be among the view's sources), which exempts it entirely.
 10. **Event field not from a command** — an `event` field whose name matches no field on any
     command in the same slice. Only checked once BOTH the event and at least one same-slice
     command declare `{ fields }`. This is the payoff of the fields feature for slicing rigor:
@@ -597,6 +648,7 @@ not the prose above has caught up yet. `--slice-ready <key>`-only codes are excl
 | `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. |
 | `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`. |
 | `doc-model-element-not-in-doc` | warning | Model element the doc doesn't mention | Add the matching marker to the doc, or remove the element from the model. |
 | `doc-model-element-not-in-model` | warning | Doc names an element the model doesn't have | Add the element to the model, or fix/remove it in the doc. |
 | `doc-model-field-mismatch` | warning | Doc/model field mismatch | Reconcile the field table with the model's fields — names and types. |
@@ -616,6 +668,8 @@ not the prose above has caught up yet. `--slice-ready <key>`-only codes are excl
 | `lineage-ref-cycle` | error | Lineage cycle | Break the cycle — a slice can't be its own ancestor. |
 | `lineage-ref-malformed` | error | Malformed lineage ref | Fix the value to `<slice-key>@v<N>`, or remove it. |
 | `lineage-version-impossible` | error | Impossible lineage version | Fix the referenced version, or ratify the target slice first. |
+| `loops-to-forward` | error | `loops-to` target not earlier on the timeline | Point `loops-to` at an earlier view, or use `from` on a later `view … again` instance instead. |
+| `loops-to-unresolved` | error | `loops-to` target unresolved | Name a view that exists, or declare it before this event. |
 | `note-binding-dangling` | warning | Dangling cross-slice note | Create the doc at that path, or fix/remove the note. |
 | `note-binding-extra` | warning | Extra doc-binding note, ignored | Remove the note, or point it at the slice's actual bound doc. |
 | `note-binding-unratified` | warning | Unratified cross-slice note | Add `covers: <this-slice-key>` to that doc's frontmatter, or correct the note's path. |

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

@@ -56,13 +56,15 @@ to decide `frontmatter-invalid` without re-deriving frontmatter-shape rules of i
 | `schemaVersion` | integer | `1` (current dialect version) | its *value* is not read back by any `em` command today (reserved) — but its *presence* is required by `hasUsableFrontmatter()`: a doc omitting it is `frontmatter-invalid` (see below) |
 | `pattern` | string | `state-change` \| `state-view` \| `automation` \| `translation` | authored/informational only — `em catalog` and `em export` both derive pattern from the `.em` AST instead (`em export`'s `slice.pattern`, schema `1.4`) |
 | `swimlane` | string | free text, `<Persona> → <Context>` | display-only |
-| `status` | string, case-insensitive | `draft` \| `reviewed` \| `ready-to-implement` \| `implemented` | `em catalog`, `em render`/`em watch` header coloring; joined into `em export`'s `slice.doc.status` (schema `1.4`); paired with `implementedIn` to compute `slice.doc.driftSignal` (schema `1.5`, MIL-85) and `em validate`'s frontmatter-coherence check (MIL-85 — see [validation.md#frontmatter-coherence](https://github.com/milehimikey/em/blob/main/docs/validation.md#frontmatter-coherence)) |
+| `status` | string, case-insensitive | `draft` \| `reviewed` \| `ready-to-implement` \| `implemented` | written by `em slice review` (→ `reviewed`, MIL-201), `em slice ratify`/`em slice reratify` (→ `ready-to-implement`) and `em slice mark-implemented` (→ `implemented`); read by `em catalog`, `em render`/`em watch` header coloring; joined into `em export`'s `slice.doc.status` (schema `1.4`); paired with `implementedIn` to compute `slice.doc.driftSignal` (schema `1.5`, MIL-85) and `em validate`'s frontmatter-coherence check (MIL-85 — see [validation.md#frontmatter-coherence](https://github.com/milehimikey/em/blob/main/docs/validation.md#frontmatter-coherence)) |
 | `version` | integer | positive integer, starts at `1` | joined into `em export`'s `slice.doc.version` (schema `1.4`, MIL-91) |
 | `implementedIn` | string | free text (PR/commit link) | joined into `em export`'s `slice.doc.implementedIn` (schema `1.4`, MIL-91); paired with `status` to compute `slice.doc.driftSignal` (schema `1.5`, MIL-85) and `em validate`'s frontmatter-coherence check (MIL-85 — see [validation.md#frontmatter-coherence](https://github.com/milehimikey/em/blob/main/docs/validation.md#frontmatter-coherence)) |
 | `split-from` | single ref | `<slice-key>@v<N>` | joined into `em export`'s `slice.doc.splitFrom` (schema `1.4`, MIL-91) and `em diff`'s `slice-added` entries (schema `1.6`, MIL-84); current-tree referential checks by `em validate` (MIL-84 — see [validation.md#lineage](https://github.com/milehimikey/em/blob/main/docs/validation.md#lineage)) |
 | `merged-from` | list of refs | comma-separated `<slice-key>@v<N>, ...` | joined into `em export`'s `slice.doc.mergedFrom` (schema `1.4`, MIL-91) and `em diff`'s `slice-added` entries (schema `1.6`, MIL-84); current-tree referential checks by `em validate` (MIL-84 — see [validation.md#lineage](https://github.com/milehimikey/em/blob/main/docs/validation.md#lineage)) |
 | `superseded-by` | list of refs | comma-separated `<slice-key>@v<N>, ...` | joined into `em export`'s `slice.doc.supersededBy` (schema `1.4`, MIL-91) and `em diff`'s `slice-removed` entries (schema `1.6`, MIL-84); current-tree referential checks by `em validate` (MIL-84 — see [validation.md#lineage](https://github.com/milehimikey/em/blob/main/docs/validation.md#lineage)) |
 | `covers` | list of slice keys | comma-separated `<slice-key>, ...` (plain keys — **not** the `<slice-key>@v<N>` ref grammar above) | ratifies a cross-slice binding (MIL-121 — see [Cross-slice coverage](#cross-slice-coverage-covers) below): read by `em export`'s doc join, `em validate --slice-ready`, and (best-effort) `em render`/`em watch`'s Slice Status legend |
+| `reviewedBy` | string | free text (typically the facilitator's or reviewer's name) | written only by `em slice review` (MIL-201 — see [cli.md](https://github.com/milehimikey/em/blob/main/docs/cli.md#em-slice-review-file-slice-key---by-name)); joined into `em export`'s `slice.doc.reviewedBy` (schema `1.11`) and `em slice index`'s Reviewed by column |
+| `reviewedOn` | string | `YYYY-MM-DD` | written only by `em slice review` (MIL-201); joined into `em export`'s `slice.doc.reviewedOn` (schema `1.11`) |
 | `ratifiedBy` | string | free text (typically a person's name) | written only by `em slice ratify` (MIL-165 — see [cli.md](https://github.com/milehimikey/em/blob/main/docs/cli.md#em-slice-ratify-file-slice-key---by-name)); joined into `em export`'s `slice.doc.ratifiedBy` (schema `1.8`) and `em slice index`'s Ratified by column |
 | `ratifiedOn` | string | `YYYY-MM-DD` | written only by `em slice ratify` (MIL-165); joined into `em export`'s `slice.doc.ratifiedOn` (schema `1.8`) |
 | `owner` | string | free text (typically a person or team name) | hand-filled — no `em` command writes it; joined into `em export`'s `slice.doc.owner` (schema `1.9`, MIL-171), `em slice index`'s Owner column, and `em status`'s per-slice `owners[]` |
@@ -84,6 +86,7 @@ convention, not parser-enforced.
 | `implementedIn` | optional | optional | optional | required once the slice has *ever* reached `implemented` — may still name a **prior** version's PR during re-ratification, see below |
 | `split-from`, `merged-from`, `superseded-by` | optional in every state — present only on docs created by a split/merge, or on a doc that has been retired |
 | `covers` | optional in every state — present only on a doc that deliberately also serves another slice (MIL-121, see below); most docs never carry it |
+| `reviewedBy`, `reviewedOn` | optional in every state — present once `em slice review` (MIL-201) has run at least once; a doc that never went through the review gate, or was hand-flipped to `reviewed`, simply omits both. `em slice ratify` never clears them; `em slice reratify` does (they describe the version that shipped) |
 | `ratifiedBy`, `ratifiedOn` | optional in every state — present once `em slice ratify` (MIL-165) has run at least once; a doc predating this feature, or ratified by hand, simply omits both |
 | `owner`, `tracking` | optional in every state — hand-filled whenever a team wants a who-holds-this / external-tracker link; most docs never carry either (MIL-171) |