@milehimikey/em 1.14.2 → 1.16.0

package/.claude/agents/em-implementer.md

@@ -1,6 +1,6 @@
 ---
 name: em-implementer
-description: Implements exactly one ratified event-modeling slice in an assigned worktree and branch and opens its pull request; the engagement skill dispatches it once per slice with only the slice key and the worktree path.
+description: Implements exactly one ratified event-modeling slice in an assigned worktree and branch and opens its pull request; the engagement skill dispatches it once per slice with only the slice key, the worktree path and, when there is one, a tracking key.
 tools: Read, Write, Edit, Bash, Grep, Glob, Skill
 ---
 <!-- managed by em — `em skill sync` overwrites; `Bash` cannot be partially allowed, so read-only agents rely on their instructions for Bash -->
@@ -18,6 +18,16 @@ You are the em implementer. You build one slice, in one worktree, on one branch,
 - Write code and tests inside that slice's package, as the constitution's layout rule describes it.
 - Every invariant and scenario in the slice doc gets a test that cites its `INV-*` id.
 
+## Tracking key
+
+If your prompt carries a tracking key (an issue-tracker key such as `PROJ-123`, or a URL), the lead has already resolved it for this slice: the slice doc's own `tracking:` wins over the engagement's. Use it as given:
+
+- Title the pull request `<key>: <slice name>`.
+- Cite it in the pull request body.
+- Put it in a commit message only when the constitution's commit convention asks for a ticket key.
+
+With no tracking key, title the pull request as you would without one and invent none.
+
 ## Hard lines
 
 - Never edit the slice doc, the `.em` model, another slice's package, shared infrastructure, or the engagement file.
@@ -29,6 +39,6 @@ You are the em implementer. You build one slice, in one worktree, on one branch,
 
 Reply with:
 
-- The pull request URL.
+- The pull request URL (its title carries the tracking key when you were given one).
 - A per-invariant test map: one line per `INV-*` id, `INV-<id> -> <test file>::<test name>`.
 - Any gap you stopped on, stated as the doc line and the question.

package/.claude/agents/em-validator.md

@@ -9,7 +9,7 @@ You are the em validator. You run checks and report what they say. You make no j
 
 ## Scope
 
-You were given a slice key and the worktree path of its pull request. You read output; you never change anything. Use Bash only to run the checks below and read-only git or `gh` commands. Do not write, edit, create, delete, commit, or push anything.
+You were given a slice key and the worktree path of its pull request, and, when the slice has one, a tracking key. You read output; you never change anything. Use Bash only to run the checks below and read-only git or `gh` commands. Do not write, edit, create, delete, commit, or push anything.
 
 ## Checks
 
@@ -21,6 +21,7 @@ Run each one and record pass or fail:
 4. Diff footprint: every changed path sits inside the slice's package, as the constitution's layout rule describes it. This is a judgment against that rule; quote the rule and list any path outside it.
 5. No diff under `slices/**`, `*.em`, `constitution.md`, or `engagements/`. Use `git diff --name-only <base>...HEAD`.
 6. The pull request body cites the slice doc.
+7. Only when a tracking key was given: the pull request title carries it (`gh pr view <pr> --json title`; the title starts with `<key>:`). Without a tracking key, skip this check and say so.
 
 ## Output
 

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

@@ -1,13 +1,13 @@
 ---
 name: event-modeling
-em-version: 1.14.2
+em-version: 1.16.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.2
+em-version: 1.16.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.2
+em-version: 1.16.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.2
+em-version: 1.16.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.2
+em-version: 1.16.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.
@@ -93,19 +98,22 @@ parallel. For each slice the plan lists as not held:
 4. Record it:
    `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.
+   Its prompt is ONLY the slice key, the absolute worktree path and, when the plan's slice
+   carries one, its tracking key (`tracking` in `em engagement plan --json` — GH #241). That
+   field is already resolved: the slice doc's own `tracking:` wins over the engagement's
+   `--tracking`, and it is `null` when neither is set (then say nothing about tracking). It reads
+   its own spec, the 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.
-2. Dispatch `em-validator` (`em:em-validator`) with the slice key and the worktree path. It
+   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, the worktree path and the same
+   tracking key (when the slice has one). 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
    `em-reviewer` (`em:em-reviewer`) with the slice key and the PR URL. Dispatch `em-critic`
@@ -125,36 +133,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 +185,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
@@ -88,6 +74,14 @@ constitution. The implementer stops and reports it as the doc line plus the ques
 4. Carry on with every other startable slice. Never answer the question yourself, never edit the
    doc, and never let the implementer guess.
 
+A question the build can finish without (it does not block the slice) is not a gap: queue it with
+`em slice defer <model>.em <key> "<question>" --until v<n> --decision "<what this version does>"`
+(GH #236). On a ratified doc that never edits the body — `ratifiedHash` and `--slice-ready` stay
+green — and records the question in `.event-modeling.md` for `<key>@v<N+1>`; `mark-implemented`
+at merge opens v<N+1> as a draft with it in Open Questions. Never write the `- [ ]` into the
+ratified doc, and do not run `em slice revise` for it (an unshipped ratified doc refuses
+`revise` without `--withdraw`).
+
 The question is answered in a design session (`event-modeling-design`), which re-ratifies the
 doc. The slice is then built in a later engagement.
 

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-implement
-em-version: 1.14.2
+em-version: 1.16.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
@@ -34,8 +34,8 @@ 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:`
+`.specify/memory/constitution.md` in a spec-kit project (when that file exists), 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.

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

@@ -48,12 +48,14 @@ facilitated session, not in an implementation branch.
 
 **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:
+code style, testing norms, NFR baselines, review and merge norms). It lives in one place, found by
+one lookup (shared by `em status` and `em upgrade`):
 
 - **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.
+  `.specify/memory/constitution.md` — spec-kit's own slot, which em defers to — wins whenever it
+  exists.
+- **otherwise, or while that slot is empty**: `constitution.md` beside the model, where
+  `em scaffold` writes it (a symlink to a repo-root file counts).
 
 `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.
@@ -157,12 +159,23 @@ undocumented ordering, a contradiction with adjacent code. The discipline:
   your recommendation. The human resolves it — at the model, where the resolution lands as an
   answered open question or a small ratified delta alongside your fix, so the decision is
   recorded instead of buried in an implementation diff.
+- **A question this build will not wait on is queued, never written into the doc** (GH #236). On a
+  ratified doc the body is the signed spec: `em slice defer <model>.em <slice-key> "<question>"
+  --until v<n> --decision "<what this version does>"` records it in `.event-modeling.md` as queued
+  for `<key>@v<N+1>` and leaves the doc — and `ratifiedHash`, and `--slice-ready` — untouched. When
+  the slice merges (`mark-implemented`) or is revised, the queued question is injected into the
+  v<N+1> draft's Open Questions. Never add the `- [ ]` item to the ratified doc yourself.
 - **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) when the spec itself must change: once the human has answered, the doc changes
+  by `em slice revise <model>.em <slice-key> --withdraw` (MIL-283: opens the next version as a
+  `draft` — `version:` bumped, the old sign-off cleared; the ratification of the unshipped version
+  is withdrawn, which is why GH #236 makes you pass `--withdraw` — plain `revise` refuses),
+  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
@@ -231,7 +244,13 @@ with the same URL, and refuses (never silently overwrites) if the doc is already
 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.
+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) — questions queued with `em slice
+defer` while the doc was ratified (GH #236) are injected into that draft too. 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
@@ -311,23 +330,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.2
+em-version: 1.16.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**