@milehimikey/em 1.15.0 → 1.16.1

package/plugin/skills/design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: design
-em-version: 1.15.0
+em-version: 1.16.1
 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

package/plugin/skills/discover/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: discover
-em-version: 1.15.0
+em-version: 1.16.1
 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/plugin/skills/engagement/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: engagement
-em-version: 1.15.0
+em-version: 1.16.1
 description: >-
   Use when leading an engagement: building a named set of ratified event-modeling slices
   (`em engagement`) into one independent PR per slice, each against main, by dispatching the
@@ -99,9 +99,12 @@ 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
-   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
 
@@ -110,7 +113,8 @@ 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 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
+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`

package/plugin/skills/engagement/reference/engagement.md

@@ -75,6 +75,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 (`em:design`), which re-ratifies the
 doc. The slice is then built in a later engagement.
 

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling
-em-version: 1.15.0
+em-version: 1.16.1
 description: >-
   Use when the user runs `/em: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/plugin/skills/implement/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: implement
-em-version: 1.15.0
+em-version: 1.16.1
 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
@@ -35,8 +35,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/plugin/skills/implement/reference/implement.md

@@ -49,12 +49,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.
@@ -158,10 +160,17 @@ 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 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),
+  `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
@@ -240,7 +249,8 @@ Prefer it over hand-editing the doc's frontmatter. It also writes the **shipped
 (`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
+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 `../../../shared/templates/model-readme.md`), run

package/plugin/skills/review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: review
-em-version: 1.15.0
+em-version: 1.16.1
 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