@milehimikey/em 1.14.1 → 1.15.0

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

@@ -1,13 +1,13 @@
 ---
 name: event-modeling
-em-version: 1.14.1
+em-version: 1.15.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
   `.event-modeling.md` state (or the given phase name) and routes to the right focused skill —
   event-modeling-discover, event-modeling-design, event-modeling-implement, event-modeling-conform,
   or event-modeling-review — or, for building a planned set of ready slices through scoped
-  sub-agents to a stack of PRs (an `em engagement`), event-modeling-engagement. If you already
+  sub-agents to one PR per slice against main (an `em engagement`), event-modeling-engagement. If you already
   know which of those applies — starting a new model, extracting from existing code,
   slicing/writing specs, implementing a ratified slice, leading an engagement, checking drift, or
   running a live/stakeholder view — invoke that skill directly instead of this one.
@@ -28,7 +28,7 @@ phase lives in.
 | `implement` | `event-modeling-implement` — building one ratified slice into merged, tested code |
 | `conform`, `validate` | `event-modeling-conform` — drift-checking a model against its codebase, walking validation diagnostics |
 | `watch`, `review` | `event-modeling-review` — the live browser viewer, facilitated stakeholder walkthroughs |
-| `engagement` | `event-modeling-engagement` — build a planned set of ready slices through scoped sub-agents to a stack of PRs |
+| `engagement` | `event-modeling-engagement` — build a planned set of ready slices through scoped sub-agents to one PR per slice, each against main |
 
 ## Routing logic
 

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-conform
-em-version: 1.14.1
+em-version: 1.15.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.14.1
+em-version: 1.15.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
@@ -51,10 +51,10 @@ evidence"). In short:
 - **Evidence rule.** The `.em` model and the slice docs are the evidence for modeling
   decisions. Never read implementation source, generated contracts or `specs/` to decide a
   modeling question — ask the user. Code is read only in `extract` and `conform`.
-- **Version rule.** Never bump a draft's `version:` on edit. Before any `em slice reratify`,
+- **Version rule.** Never bump a draft's `version:` on edit. Before any `em slice revise`,
   run `em status <model>.em --json`: pre-release = the model's `modelVersion` entry has
-  `design: null` **and** `slices.byStatus.implemented === 0`. Pre-release → never run
-  `reratify`; edit `draft`/`reviewed` docs in place. Released → the re-ratification path in
+  `design: null` **and** `slices.byStatus.shipped === 0`. Pre-release → never run
+  `revise`; edit `draft`/`reviewed` docs in place. Released → the revision path in
   the `slice` phase below.
 - **Pre-commit check.** Stage the session's files, run `em system scope --staged` (STOP on any
   `seam-crossing`), then `git diff --cached --name-only` (STOP on any path outside this model's
@@ -151,7 +151,7 @@ For each slice:
    it in place and leave its `version:` alone. If `slices/<slice-name>.md` already exists with
    `status: implemented` (or is ratified and needs a change), run `em status <model>.em --json`
    first. **Pre-release** (the model's `modelVersion` entry has `design: null` and
-   `slices.byStatus.implemented === 0`): never run `em slice reratify`; a ratified doc holds a
+   `slices.byStatus.shipped === 0`): never run `em slice revise`; a ratified doc holds a
    human sign-off, so STOP, park the change as an open question, and let the ratifier decide.
    **Released** (either condition false): a doc with `status: implemented` is a
    re-ratification, not fresh authoring: hold a Socratic
@@ -212,6 +212,11 @@ For each slice:
    `--slice-ready` refuses it). A doc written before em 1.14 has no markers; leave it as it is
    unless you are re-creating it (`em slice new … --wire --force`, carrying the prose across).
    A question this version will not answer is deferred with `em slice defer <model> <key> "<question>" --until v<n> --decision "<what this version does>"` — never left `- [ ]`, never deleted, never answered by guessing.
+   When the question lives on the diagram as an `issue "..."` note rather than on the doc, use
+   `em slice defer <model> <key> --from-issue "<text>" --until v<n> --decision "<what this version does>"`
+   instead: it writes the deferred item into the doc's Open Questions and removes the note in one
+   step. A question that is *answered* is an edit to the authored section plus deleting the note —
+   never a deferral.
 2. **First-time authoring:** scaffold the doc mechanically rather than hand-writing the
    frontmatter — `em slice new "<slice name>" --pattern <state-change|state-view|automation|
    translation> --swimlane "<Persona> → <Context>" --wire <model>.em` writes `slices/<slice-name>.md`
@@ -236,23 +241,29 @@ For each slice:
    lineage key(s) by hand (`split-from`/`merged-from`/`superseded-by`, `<slice-key>@v<N>` grammar
    — see `../event-modeling-shared/reference/slice-doc-schema.md` for the full schema; `em validate` catches a malformed one
    after the fact, see the `lineage-*` rules below).
-   **Re-ratification (step 0) — released models only.** Confirm the model is released first
+   **Revision (step 0) — released models only.** Confirm the model is released first
    (`em status <model>.em --json`: the `modelVersion` entry's `design` is not `null`, or
-   `slices.byStatus.implemented > 0`); on a pre-release model never run `reratify`. The doc
+   `slices.byStatus.shipped > 0`); on a pre-release model never run `revise`. The doc
    already exists, so `em slice new` doesn't apply here
    (it refuses to overwrite an existing file without `--force`, and forcing would blow away the
-   doc's authored body) — run `em slice reratify <model>.em <slice-key>` instead: it bumps
-   `version` and flips `status` back to `ready-to-implement` in the existing frontmatter,
-   clearing any stale `ratifiedBy:`/`ratifiedOn:` from the prior version so a follow-up
-   `em slice ratify --by <name>` (if the team records that) applies cleanly. The same command
-   changes a ratified doc that **never shipped** (`ready-to-implement` with `ratifiedBy` set — a
-   gap answered mid-build, MIL-258): it bumps `version` and clears the sign-off but leaves
-   `status` alone. Either way the doc is not ratified until `em slice ratify --by <name>` records
-   the new sign-off. A `ready-to-implement` doc with no `ratifiedBy` is already awaiting that
-   sign-off and refuses a second `reratify`; a `draft`/`reviewed` doc is simply edited, and its
-   `version:` never moves.
+   doc's authored body) — run `em slice revise <model>.em <slice-key>` instead (MIL-283): it
+   opens the next version as a **`draft`** in the existing frontmatter — `version` bumped,
+   `status: draft`, the prior version's review and sign-off cleared — while the shipped version
+   stays shipped in the shipped record (`implementedIn:`/`shippedVersion:`, untouched). If a
+   question was deferred to this version, `em slice mark-implemented` already opened the draft
+   at merge and the question is back on the list; `revise` then refuses ("the next version is
+   already open") and you simply edit. The same command revises a ratified doc that **never
+   shipped** (`ready-to-implement` with `ratifiedBy` set — a gap answered mid-build): the
+   ratification is withdrawn and the draft opens. Either way the new version is a new spec:
+   write the delta into `## Delta`, walk it in a review session (`em slice review --by`), and
+   only then does `em slice ratify --by <name>` sign it. **Commit before ratifying (MIL-284):**
+   `em slice ratify` records the commit and body hash it signs and refuses a doc with uncommitted
+   changes — finish the doc's edits (deferrals included: `em slice defer` rewrites a body line, so
+   a deferral after sign-off trips `slice-ready-body-changed-since-ratification`), commit, then
+   ratify. A `draft`/`reviewed` doc is simply edited, and its `version:` never moves.
    **Public-touching slices (MIL-238).** On a slice that owns a `public` command, event or view,
-   `em slice ratify --by <name>` and `em slice reratify` refuse without one of two flags: pass
+   `em slice ratify --by <name>` refuses without one of two flags (`revise` takes neither — the
+   confirmation belongs to the new version's ratification): pass
    `--meaning-unchanged` when this version does not change what the public contract means, or
    `--contract-change "<why>"` when a consumer must read the change differently. Without
    either, both refuse with `slice "<key>" touches the public surface — pass

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-discover
-em-version: 1.14.1
+em-version: 1.15.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-engagement/SKILL.md

@@ -1,24 +1,32 @@
 ---
 name: event-modeling-engagement
-em-version: 1.14.1
+em-version: 1.15.0
 description: >-
   Use when leading an engagement: building a named set of ratified event-modeling slices
-  (`em engagement`) into a stack of PRs by dispatching the em-implementer, em-validator,
-  em-reviewer and em-critic sub-agents, level by level, and handing the human the stack
-  bottom-first to merge. The lead session orchestrates and never writes slice code itself. To
-  build one slice by hand, use event-modeling-implement instead.
+  (`em engagement`) into one independent PR per slice, each against main, by dispatching the
+  em-implementer, em-validator, em-reviewer and em-critic sub-agents, level by level, and handing
+  the human each PR with its evidence as it passes review. The lead session orchestrates and never
+  writes slice code itself. To build one slice by hand, use event-modeling-implement instead.
 ---
 
 # Event Modeling — engagement (lead session)
 
 Goal: take an engagement (a named chunk of the model, `<model dir>/engagements/<slug>.md`) from
 its plan to merged PRs. You are the **lead**: you cut worktrees, dispatch scoped sub-agents,
-record every step in the Ledger with `em engagement set`, and hand the human a stack of PRs to
-merge bottom-first. You never write slice code, never merge, and never rebase a slice branch.
+record every step in the Ledger with `em engagement set`, and hand the human one PR per slice,
+each cut from and targeting `main`, to merge in any order. You never write slice code, never
+merge, and never rebase a slice branch.
+
+An engagement is a *related set* of isolated slices — a workflow, a lifecycle — built together.
+It is not a stack: no slice branch is ever cut from another slice's branch, and no PR ever
+targets another PR (MIL-280). The foundation PR (implement.md §8) already holds every event, and
+a slice never reaches into a sibling's code (§8 rule 3), so each PR compiles, tests and merges
+on its own. Levels order the work for the human's review and your dispatch; they never gate a
+merge.
 
 **Read `reference/engagement.md` before the first dispatch.** It holds the Ledger state machine,
-the evidence bundle format, the retarget check, the gap protocol and the model-selection rule
-this file uses by name. Each sub-agent runs `event-modeling-implement`'s contract
+the evidence bundle format, the gap protocol and the model-selection rule this file uses by
+name. Each sub-agent runs `event-modeling-implement`'s contract
 (`../event-modeling-implement/reference/implement.md`) for its one slice; that contract is
 theirs, not yours.
 
@@ -42,21 +50,17 @@ Run the shared preconditions first (tool check, bundle currency, locate the mode
 2. **Foundation PR merged.** Ask the human for the foundation PR (implement.md §8) and confirm it
    has merged into `main` (`gh pr view <n> --json state` shows `MERGED`). STOP if there is none
    or it is still open. No slice branch is cut before it lands.
-3. **Merge strategy.** The constitution's "Review and merge norms" must carry the line
-   `- **Merge strategy:** merge-commits-when-stacked`. STOP if the line is absent or names any
-   other value: tell the human the engagement needs that norm and point at the constitution
-   template's "Review and merge norms" prompt
-   (`../event-modeling-shared/templates/constitution.md`). The constitution is the human's to
-   amend and ratify, never yours.
-4. **Agent models.** Read the line `- **Agent models:** implementer=<model>,
+3. **Agent models.** Read the line `- **Agent models:** implementer=<model>,
    validator=<model>, reviewer=<model>, critic=<model|codex>`. If it is absent, say once:
    "no Agent models line — using implementer=sonnet, validator=sonnet, reviewer=sonnet,
    critic=opus", and proceed. Apply the model-selection rule in `reference/engagement.md`
-   (the critic never runs on the implementer's model).
-5. **Worktrees are ignored.** `git check-ignore -q .claude/worktrees/x` must succeed. If it
+   (the critic never runs on the implementer's model). A constitution that still carries a
+   `- **Merge strategy:**` line from em ≤ 1.14.2 is fine: the line is ignored, never a reason to
+   stop — PRs merge with whatever strategy the project uses.
+4. **Worktrees are ignored.** `git check-ignore -q .claude/worktrees/x` must succeed. If it
    fails, STOP and ask the human to add `.claude/worktrees/` to `.gitignore` in its own commit
    on `main`.
-6. **The engagement exists.** `em engagement status <model>.em <slug>`. If there is no such
+5. **The engagement exists.** `em engagement status <model>.em <slug>`. If there is no such
    engagement, ask the human which slices it covers (a list, a context, or "everything
    downstream of X") and run `em engagement new <model>.em <slug> --slices a,b,c` (or
    `--context <C>`, or `--downstream-of <ref>`) `--by "<their name>"`. When `new` warns that the
@@ -66,9 +70,9 @@ Run the shared preconditions first (tool check, bundle currency, locate the mode
 ## 2. Plan and confirm the ceiling once
 
 Run `em engagement plan <model>.em <slug>` (`--json` when you need the fields). Present it in
-plain terms: each level, its width against the ceiling (`parallel`), each slice's branch and
-base, and every held slice with its reason (`not-ready`, `upstream-outside-engagement-unmerged`,
-`multiple-unmerged-upstreams`, or `human`). Then ask exactly one question:
+plain terms: each level, its width against the ceiling (`parallel`), each slice's branch (every
+base is `main`), and every held slice with its reason (`not-ready`,
+`upstream-outside-engagement-unmerged`, or `human`). Then ask exactly one question:
 
 > "Ceiling N from the plan; proceed?"
 
@@ -78,13 +82,14 @@ A held slice is never started; the plan releases it when its hold clears.
 
 ## 3. Per level: cut the worktree, then dispatch the implementer
 
-Work level by level, in order. A slice in level n+1 starts only when its upstream has reached
-`awaiting-merge` or `merged`, so the base it is cut from no longer moves. Within a level, keep up
-to the ceiling of slices in flight (`building`, `validating` or `review`) at once, dispatched in
-parallel. For each slice the plan lists as not held:
+Work level by level, in order: a level's slices are dispatched before the next level's, so the
+human sees upstream slices first. Nothing in level n+1 waits for a merge — every slice is cut
+from `main`. Keep up to the ceiling of slices in flight (`building`, `validating` or `review`)
+at once, dispatched in parallel; when a slot frees, take the next not-held slice in level order.
+For each slice the plan lists as not held:
 
-1. Take `base` from the plan for this slice: `main`, or `impl/<upstream>`. **Never the current
-   HEAD**, and never a branch you picked yourself.
+1. Take `base` from the plan for this slice. It is always `main`. **Never the current HEAD**,
+   never another slice's branch, and never a branch you picked yourself.
 2. If `impl/<key>` already exists (`git rev-parse --verify --quiet impl/<key>`) or
    `.claude/worktrees/<key>` already exists, STOP for that slice and report it. Never delete,
    reuse or reset someone's branch.
@@ -94,17 +99,16 @@ parallel. For each slice the plan lists as not held:
    `em engagement set <model>.em <slug> <key> --state building --branch impl/<key> --base <base>`
 5. Dispatch `em-implementer` (`em:em-implementer` under the plugin) on the implementer model.
    Its prompt is ONLY the slice key and the absolute worktree path. It reads its own spec, the
-   constitution and the implement contract. Give it no plan, no other slice, and no merge or
-   stacking instructions.
+   constitution and the implement contract. Give it no plan, no other slice, and no merge
+   instructions.
 
 ## 4. Validate, review, criticise
 
 When the implementer returns a PR URL (and a per-invariant test map):
 
 1. `em engagement set <model>.em <slug> <key> --state validating --pr <url>`. Check the PR's
-   base: `gh pr view <url> --json baseRefName` must equal the Ledger's base. If not, fix it
-   with `gh pr edit <url> --base <base>`. That is a lead step; the implementer never changes a
-   base.
+   base: `gh pr view <url> --json baseRefName` must be `main`. If not, fix it with
+   `gh pr edit <url> --base main`. That is a lead step; the implementer never changes a base.
 2. Dispatch `em-validator` (`em:em-validator`) with the slice key and the worktree path. It
    returns one PASS/FAIL line per check and `OVERALL: PASS` or a failure.
 3. On `OVERALL: PASS`: `em engagement set <model>.em <slug> <key> --state review`. Dispatch
@@ -125,36 +129,31 @@ When the implementer returns a PR URL (and a per-invariant test map):
    human.
 6. `minor` findings do not loop. They go in the evidence bundle.
 
-## 5. Hand the human the stack, bottom first
+## 5. Hand the human each PR as it passes
 
 When a slice passes review: `em engagement set <model>.em <slug> <key> --state awaiting-merge`.
-Hand the human the PRs bottom-first, lowest level first, each with its evidence bundle
-(`reference/engagement.md`): the validator table, the reviewer's and critic's findings and any
-disagreement, and the per-invariant test map. Tell them, every time:
-
-- merge bottom-first, with a **merge commit** while any PR stacks on this one (implement.md §8
-  rule 2a). Squash is forbidden in that state;
-- delete the head branch on merge, so GitHub retargets the PRs that stacked on it.
+Hand the human the PR with its evidence bundle (`reference/engagement.md`): the validator table,
+the reviewer's and critic's findings and any disagreement, and the per-invariant test map. Every
+PR is independent — against `main`, carrying only its own slice — so the human merges them in
+any order, with the project's usual merge strategy (squash included), and nothing else needs
+retargeting or restacking. Suggest level order (upstream slices first) because it reads better,
+not because anything depends on it.
 
 You never merge.
 
 ## 6. After each human merge
 
 1. Update `main` in your own checkout: `git switch main && git pull --ff-only`.
-2. **Retarget check** (`reference/engagement.md`): `gh pr list --base impl/<key> --state open`
-   must be empty. For each PR still listed (the head branch was not deleted),
-   `gh pr edit <n> --base main`. Then record the new base on each dependent, keeping its state:
-   `em engagement set <model>.em <slug> <dependent> --state <its state> --base main`.
-3. `em engagement set <model>.em <slug> <key> --state merged`, then remove the worktree:
+2. `em engagement set <model>.em <slug> <key> --state merged`, then remove the worktree:
    `git worktree remove .claude/worktrees/<key>`.
-4. When every slice of a level is `merged` or `gap`, open one follow-up PR for that level from
+3. When every slice of a level is `merged` or `gap`, open one follow-up PR for that level from
    `main`: `git switch -c engagement/<slug>-level-<n> main`, run
    `em slice mark-implemented <model>.em <key> <pr-url>` for each slice merged in the level,
    then `em slice index <model>.em`, commit, and `gh pr create --base main`. The human merges it
    like any other PR.
-5. Recompute: `em engagement plan <model>.em <slug>`. Merges release holds
-   (`multiple-unmerged-upstreams` drops to one upstream, a base moves to `main`). Continue with
-   step 3 for anything newly startable.
+4. Recompute: `em engagement plan <model>.em <slug>`. A merge can release an
+   `upstream-outside-engagement-unmerged` hold once that upstream's doc reads `implemented`.
+   Continue with step 3 for anything newly startable.
 
 ## 7. Gaps
 
@@ -182,11 +181,12 @@ constitution), follow the gap protocol (`reference/engagement.md`):
 | Rule | Because |
 |---|---|
 | Never hand-edit `engagements/<slug>.md` | `em engagement set` and `close` are the only write paths; the Ledger table is generated |
-| Never restack or rebase a slice branch | Merge commits make restacking unnecessary; a rebase rewrites history a dependent was cut from |
-| Never squash a PR with an open dependent | It strands the dependent's history (implement.md §8 rule 2a) |
+| Never cut a slice branch from another slice's branch, or make a PR target another PR | Every slice PR is cut from and targets `main` (MIL-280); a stack turns isolated slices into one landing and adds merge ceremony the contract never needed |
+| Never rebase a slice branch | The branch is the implementer's; the lead orchestrates and records, it does not rewrite history |
 | Never run the implementer's work yourself | The lead orchestrates; code comes from a scoped implementer working from its own read of the spec |
 | Never dispatch beyond the ceiling | The ceiling was confirmed once for the engagement; exceeding it breaks that agreement |
-| Never cut a slice branch from the current HEAD | The base comes from the plan; any other base stacks the PR on the wrong history |
-| Never merge a PR | The human merges, bottom-first |
+| Never cut a slice branch from the current HEAD | The base is `main` from the plan; the lead's HEAD may be anything |
+| Never hold a PR back for an upstream merge | Slices do not depend on each other's branches (§8 rules 2 and 3); level order is for reading, not gating |
+| Never merge a PR | The human merges, in any order |
 | Never show the critic the reviewer's findings | The critic's value is an independent view; disagreement is a finding |
 | Never start a held slice, or ask "which slice first" | The plan decides order and holds; the human confirms only the ceiling |

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

@@ -26,17 +26,17 @@ closed engagement refuses every `set`.
 `em engagement close <model>.em <slug>` succeeds only when every slice is `merged` (recorded or
 inferred) or `gap`; `em engagement status` reports this as `closable`.
 
-A dependent's base changes once, when its upstream merges: record it with the dependent's
-current state and `--base main` (step 6.2), so the Ledger matches the PR's real base.
+Every slice's `base` is `main` (MIL-280): recorded once at `building`, never changed. A Ledger
+that still shows an `impl/<upstream>` base came from em ≤ 1.14.2; `plan` reports `main` and the
+next `set` on that slice should record `--base main`.
 
 ## The evidence bundle (step 5)
 
-Hand the human one block per PR, bottom-first, in this shape:
+Hand the human one block per PR as it passes review, in this shape:
 
 ```markdown
 ### <level n> · `<key>` · <PR URL>
-Base: `<base>` · Ledger: awaiting-merge · Stacked on it: <PR URLs of open dependents, or "none">
-Merge with: a merge commit (<a dependent is open | squash allowed: no open dependent>)
+Base: `main` · Ledger: awaiting-merge · Independent: merges in any order with the project's usual strategy
 
 Validator (em-validator, <model>):
 | Check | Result |
@@ -60,20 +60,6 @@ Per-invariant tests (from em-implementer):
 
 Copy the agents' lines verbatim; never summarise a finding away.
 
-## The retarget check (step 6.2)
-
-GitHub retargets every open PR whose base was a merged head branch to the merged PR's base, but
-only when that head branch is deleted. After each merge of `impl/<key>`:
-
-1. `gh pr list --base impl/<key> --state open --json number,headRefName` must return `[]`.
-2. For each PR it does list, run `gh pr edit <number> --base main`. Then record it:
-   `em engagement set <model>.em <slug> <dependent> --state <its current state> --base main`.
-3. Confirm with `gh pr view <number> --json baseRefName`.
-
-Because the lower PR merged with a merge commit, the dependent's diff against `main` shrinks to
-its own commits by itself. Never rebase it. If its diff still shows the upstream's commits, the
-lower PR was squashed: STOP and tell the human. Restacking that PR is their decision.
-
 ## The gap protocol (step 7)
 
 A gap is a question only the model can answer: the doc is wrong, incomplete, or contradicts the

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

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

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

@@ -158,11 +158,15 @@ undocumented ordering, a contradiction with adjacent code. The discipline:
   answered open question or a small ratified delta alongside your fix, so the decision is
   recorded instead of buried in an implementation diff.
 - **How a delta is ratified on a doc that never shipped** (it is `ready-to-implement` with
-  `ratifiedBy` set): once the human has answered, the doc changes by `em slice reratify
-  <model>.em <slice-key>` (bumps `version:`, clears the old sign-off, leaves `status` alone),
-  the answer is written into the doc, and the human re-signs with `em slice ratify <model>.em
-  <slice-key> --by <name>` — on a slice owning a `public` element both commands also need
-  `--meaning-unchanged` or `--contract-change "<why>"` (MIL-238). That is the human's step, not
+  `ratifiedBy` set): once the human has answered, the doc changes by `em slice revise
+  <model>.em <slice-key>` (MIL-283: opens the next version as a `draft` — `version:` bumped,
+  the old sign-off cleared; the ratification of the unshipped version is withdrawn),
+  the answer is written into the doc and committed, the room reviews it (`em slice review
+  --by`), and the human re-signs with `em slice ratify
+  <model>.em <slice-key> --by <name>` (it records the commit it signs and refuses uncommitted
+  changes, MIL-284) — on a slice owning a `public` element that `ratify` also needs
+  `--meaning-unchanged` or `--contract-change "<why>"` (MIL-238; `revise` takes neither — the
+  confirmation belongs to the new version's sign-off). That is the human's step, not
   yours — you never run `ratify`, and
   the doc is not ratified again until they do; resume the build after that.
 - **Never edit the ratified doc to record your own answer**, and never quietly pick a behavior
@@ -228,7 +232,15 @@ a bump here is a ledger defect.
 `em slice mark-implemented <model>.em <slice-key> <pr-url>` does the flip for you (MIL-103) —
 resolves the doc via the same note-binding join `--slice-ready` uses, is idempotent on a re-run
 with the same URL, and refuses (never silently overwrites) if the doc is already `implemented`
-with a different URL. Prefer it over hand-editing the doc's frontmatter.
+with a different URL. It also refuses a doc that isn't `ready-to-implement` (MIL-277): if it
+reports `doc is \`status: draft\``/`reviewed`, the slice was never ratified — stop and surface
+that to the human rather than editing the frontmatter by hand; the §1 gate should have caught it.
+Prefer it over hand-editing the doc's frontmatter. It also writes the **shipped record**
+(`shippedVersion:`/`shippedRef:`/`shippedOn:`, MIL-284) — what every reader decides "has this
+shipped?" on since 1.15.0 — and, when the ratified doc deferred a question to the next version,
+**opens that version as a `draft` on the same write** (MIL-283: `status: draft`, `version` bumped,
+the question back to `- [ ]`; the version you built stays shipped). If it prints `opened draft
+v<N+1>`, say so in your report: the slice has known work, and a design session, not you, decides it.
 
 Then, if the project keeps a model README (from `../../event-modeling-shared/templates/model-readme.md`), run
 `em slice index <model-name>.em` so its generated Slices table reflects the new status and
@@ -308,23 +320,17 @@ sibling slice's package to reuse it — the boundary the constitution drew is go
    contract into a pre-empted slice.
 2. **It merges before any slice PR opens.** Every slice branch is cut *after* the foundation PR
    has landed on `main` — never from a commit that predates it, and never alongside an open,
-   unmerged foundation PR. Within an engagement, cut the slice branch from the base the
-   engagement plan names (`em engagement plan`); outside an engagement, from `main`. 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. The plan's
-   base is either `main` or `impl/<upstream>` (the one unmerged upstream slice this slice builds
-   on); either way it already contains the foundation.
-
-2a. **While a dependent PR is open, the lower PR merges with a merge commit; squash is forbidden
-   in that state (it strands the dependent's history).** A PR is the *lower* one when another
-   open PR targets its branch as its base. Once no open PR depends on it, the project's usual
-   merge strategy applies. Because: a squash rewrites the lower branch's commits into one new
-   commit on `main`, so the dependent branch still carries the originals and its diff against
-   `main` shows them again — it then needs a hand rebase (`git rebase --onto main <old base
-   tip>`). A merge commit keeps the original commits: once the lower branch is merged and
-   deleted, the dependent is retargeted to `main` and its diff shrinks to its own commits with
-   no rebase.
+   unmerged foundation PR. Every slice branch is cut from `main` and every slice PR targets
+   `main` — inside an engagement (`em engagement plan` names `main` as every slice's base) and
+   outside one alike; never from another slice's branch, never targeting another slice's 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.
+   And because the foundation already holds every event and rule 3 keeps a slice out of its
+   siblings' code, no slice needs another slice's branch to compile or test: a PR cut from a
+   sibling's branch (a "stack") carries a dependency this contract forbids, and turns N isolated
+   slices into one landing with merge-commit and retargeting ceremony attached. `main` already
+   contains the foundation; that is all a slice needs.
 
 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,

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-review
-em-version: 1.14.1
+em-version: 1.15.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
@@ -53,10 +53,20 @@ 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:`).
 
-**Per-slice outcome.** A slice whose open questions are all resolved in the room →
+**Per-slice outcome.** Walk the slice's questions — the doc's `## Open Questions` and every
+`issue "..."` note the room added to its elements — and give each one of three endings:
+
+- **Answered in the room** → edit the doc's authored section with the answer and delete the
+  `issue` note by hand. Defer is never used to record an answer.
+- **Raised in the room, not for this version** → `em slice defer <model> <key> --from-issue "<text>" --until v<n> --decision "<what this version does>"`:
+  promotes the captured `issue` into the doc's Open Questions as a deferred item, mirrors it
+  into the state file and removes the red note — one command, no hand edit mid-session.
+- **Already on the doc, not for this version** → the positional form. A question this version will not answer is deferred with `em slice defer <model> <key> "<question>" --until v<n> --decision "<what this version does>"` — never left `- [ ]`, never deleted, never answered by guessing.
+
+Then, and only then: a slice with nothing left `- [ ]` and no open `issue` →
 `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. A question this version will not answer is deferred with `em slice defer <model> <key> "<question>" --until v<n> --decision "<what this version does>"` — never left `- [ ]`, never deleted, never answered by guessing.
+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**