@milehimikey/em 1.19.6 → 1.19.7

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@milehimikey/em",
-  "version": "1.19.6",
+  "version": "1.19.7",
   "description": "AI-friendly Event Modeling — a slice-first text DSL rendered to a strict, self-contained Graphviz grid (SVG/PNG)",
   "type": "module",
   "bin": {

package/plugin/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "em",
-  "version": "1.19.6",
+  "version": "1.19.7",
   "description": "Event Modeling with em: discover, design, implement, conform, review and engagement skills over a slice-first text DSL, plus the em MCP server.",
   "author": {
     "name": "Mike Key"
@@ -10,7 +10,7 @@
       "command": "npx",
       "args": [
         "-y",
-        "@milehimikey/em@1.19.6",
+        "@milehimikey/em@1.19.7",
         "mcp"
       ]
     }

package/plugin/shared/reference/em-dsl.md

@@ -110,7 +110,7 @@ em changelog <file> -o, --out <path>                                # write to a
 em state read [dir]                                                 # print the state file's mechanical fields as JSON
 em state set-phase <phase> [dir]                                    # rewrite Current phase: (and Last updated:); --step also rewrites Current step:
 em state set-phase <phase> [dir] --step <n>                         # also set Current step: to this value
-em state set-conformance <revision> [dir]                           # rewrite Last conformance: (and Last updated:) in the exact format reference/conform.md parses. Refuses (MIL-214) while any `implemented` slice has an unruled conformance finding in the findings JSON beside --report (a `slice: null` finding blocks every slice); --partial records the marker with a ` (partial)` suffix instead, with a loud notice. Without a findings JSON beside --report: warns once and records the marker as given (migration path for a report predating `em conform-findings`)
+em state set-conformance <revision> [dir]                           # rewrite Last conformance: (and Last updated:) in the exact format reference/conform.md parses. Refuses (MIL-214) while any `implemented` slice has an unruled conformance finding in the findings JSON beside --report, or, when that is absent, in every findings file at the report's own revision (a `slice: null` finding blocks every slice); --partial records the marker with a ` (partial)` suffix instead, with a loud notice. Without a findings JSON beside --report and none at the report's revision: warns once and records the marker as given (migration path for a report predating `em conform-findings`)
 em state set-conformance <revision> [dir] --report <path>           # path to the conformance report just written
 em state set-conformance <revision> [dir] --partial                 # record the marker as PARTIAL even though some in-scope findings are still unruled
 em state set-review <date> [dir]                                    # rewrite Last stakeholder review: (and Last updated:)
@@ -128,7 +128,7 @@ em conform-scope <file>                                             # mechanize
 em conform-scope <file> --repo <path>                               # path to (or inside) the target codebase's git repository
 em conform-scope <file> --full                                      # ignore Last conformance:/changed paths; scope every implemented slice
 em conform-scope <file> --seed-asis                                 # write <model>-asis.em as a byte copy of the canonical model and ensure it's gitignored
-em conform-supersede <file> <report-path>                           # stamp a conformance report with a "superseded as of <rev>" banner once its findings have been ruled on (MIL-164, docs/process.md#what-ratified-means) — the companion step to run at ratification time so a reader following the report's file:line citations knows they describe an ancestor of the current model. Additive-only splice, never a rewrite of the report; idempotent on the same --as-of/--findings/--on stamp; refuses if the report doesn't exist. --locus/--by (MIL-214, both required together) additionally record the ruling itself — locus/resolvedBy/resolvedOn — on the findings named by --findings in the sibling conformance/<date>-findings.json, when one exists (warns once and stamps the banner only when it doesn't — the migration path for a report predating em conform-findings)
+em conform-supersede <file> <report-path>                           # stamp a conformance report with a "superseded as of <rev>" banner once its findings have been ruled on (MIL-164, docs/process.md#what-ratified-means) — the companion step to run at ratification time so a reader following the report's file:line citations knows they describe an ancestor of the current model. Additive-only splice, never a rewrite of the report; idempotent on the same --as-of/--findings/--on stamp; refuses if the report doesn't exist. --locus/--by (MIL-214, both required together) additionally record the ruling itself — locus/resolvedBy/resolvedOn — on the findings named by --findings in the sibling conformance/<date>-findings.json, when one exists (refuses, naming them, when only other findings files exist at the report's revision; warns once and stamps the banner only when it doesn't — the migration path for a report predating em conform-findings)
 em conform-supersede <file> <report-path> --as-of <rev>             # the revision this ruling was made against — same value passed to `em state set-conformance`
 em conform-supersede <file> <report-path> --findings <spec>         # which finding number(s) this stamps as ruled, e.g. "1-3" or "1,2,4"
 em conform-supersede <file> <report-path> --on <date>               # ruling date, YYYY-MM-DD (default: today, local date)

package/plugin/shared/reference/slice-doc-schema.md

@@ -71,7 +71,7 @@ to decide `frontmatter-invalid` without re-deriving frontmatter-shape rules of i
 | `ratifiedRef` | string | full commit sha | written only by `em slice ratify` (MIL-284 — see [cli.md](https://github.com/milehimikey/em/blob/main/docs/cli.md#em-slice-ratify-file-slice-key---by-name)) when the model directory is inside a git repository: `HEAD` at ratification, the commit whose tree holds the body that was signed (ratify refuses a doc with uncommitted changes so this holds). Absent when ratified before 1.15, outside git, or with `em slice ratify --no-ref` (GH #255 — for a repo whose squash/rebase merges would leave the commit unreachable from the target branch; `--no-ref` also removes a line already present). **An address, not the identity:** valid only while the commit stays reachable; `ratifiedHash` is what identifies the signed content. Cleared by `em slice revise`. Joined into `em export`'s `slice.doc.ratifiedRef` (schema `1.16`). Not a target-repo revision: `em slice conform --at` still names that itself |
 | `ratifiedHash` | string | `sha256:<64 hex>` | written only by `em slice ratify` (MIL-284): `sha256` over the **authored text** of the doc body (everything after the frontmatter fence, EOLs normalised). Since 1.19.0 (GH #347) the text strictly between each [generated region](#generated-regions-and-authored-sections)'s two marker lines is left out (the marker lines themselves stay in), so `em slice sync` can refresh a ratified or shipped doc's regions without moving the hash — the regions restate the model, whose contract changes surface through model validation and its pin (`model-versions/v<N>.json`); a doc whose markers don't balance has nothing left out. Since 1.17.0 (GH #253) the doc also leaves out **what describes a later version**: inside `## Open Questions` the heading line, blank lines and every `deferred to v<n>` item, then trailing whitespace is trimmed — so `em slice defer` can record a question on a ratified or shipped doc without moving the hash. Answered `- [x]` history, any `- [ ]`, the region marker lines and every other section stay signed. The signed content's identity without git. A hash in an older scope whose body is intact is still read as intact — recorded by 1.17.0–1.18.x (generated regions inside) or before 1.17.0 (whole body); `em upgrade`'s `ratified-hash-scope` step re-stamps it, and so do `em slice sync` and `em slice defer` when they first write to the doc. Cleared by `em slice revise`. Read by `em validate --slice-ready` (`slice-ready-body-changed-since-ratification`) and by `ratify`'s same-sign-off re-run; joined into `em export`'s `slice.doc.ratifiedHash` (schema `1.16`) |
 | `shippedVersion` | integer | positive integer | written only by `em slice mark-implemented` (MIL-284): the doc's `version:` when the merge was recorded. With `shippedRef`/`shippedOn`/`implementedIn`, joined into `em export`'s `slice.doc.shipped` (schema `1.16`). Additive in 1.15 — `status`/`implementedIn` still carry the lifecycle for every reader |
-| `shippedRef` | string | full commit sha | written only by `em slice mark-implemented` (MIL-284): the doc's `ratifiedRef` at merge time, i.e. the ref the shipped version was signed at; absent when the doc had none (ratified before 1.15, outside git, or with `--no-ref`, GH #255). Same caveat as `ratifiedRef`: an address, valid while reachable — `ratifiedHash` identifies the content |
+| `shippedRef` | string | full commit sha | written only by `em slice mark-implemented` (MIL-284): the doc's `ratifiedRef` at merge time, i.e. the ref the shipped version was signed at; absent when the doc had none (ratified before 1.15, outside git, or with `--no-ref`, GH #255) — a `shippedRef:` line left by the previous version's ship is removed on the flip (GH #392). Same caveat as `ratifiedRef`: an address, valid while reachable — `ratifiedHash` identifies the content |
 | `shippedOn` | string | `YYYY-MM-DD` | written only by `em slice mark-implemented` (MIL-284): the local date of the merge record, or `--on <date>` |
 | `meaningConfirmed` | boolean | `true` | written only by `em slice ratify --meaning-unchanged` (MIL-238 — see [cli.md](https://github.com/milehimikey/em/blob/main/docs/cli.md#em-slice-ratify-file-slice-key---by-name)): the API-first sign-off on a public-touching slice — this version does not change what the public contract means. Joined into `em export`'s `slice.doc.meaningConfirmed` (schema `1.15`; `false` when absent) |
 | `contractChange` | string | quoted free text (`contractChange: "<why>"`) | written only by `em slice ratify --contract-change "<why>"` (MIL-238): the API-first sign-off on a public-touching slice — why a consumer must read this change differently. Joined into `em export`'s `slice.doc.contractChange` (schema `1.15`, quotes stripped; `null` when absent) |

package/plugin/skills/conform/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: conform
-em-version: 1.19.6
+em-version: 1.19.7
 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/plugin/skills/conform/reference/conform.md

@@ -343,7 +343,7 @@ em state set-conformance <target-repo revision> --report conformance/YYYY-MM-DD-
 ```
 
 — the revision is the one you just diffed against, so the next run's scope starts from here.
-The command writes the exact format step 1 parses back out; never hand-edit the bullet.
+The command writes the exact format step 1 parses back out; never hand-edit the bullet. Gates read every same-revision findings file (the report's own `-findings.json` first, else every file whose `revision` matches). The same-revision lookup uses the report's OWN revision (its `Target repo: … @ <rev>` header line; the caller's `<rev>` / `--as-of` only when the report has none).
 **Refuses (MIL-214) while any `implemented` slice still has an unruled finding** in the findings
 JSON beside the report — rule on every finding first (or certify what's already ruled via `em
 slice conform` above), or pass `--partial` to record the marker with a loud notice instead
@@ -364,7 +364,7 @@ a ruling you're only banner-stamping after the fact), run the same command witho
 em conform-supersede <model-name>.em conformance/YYYY-MM-DD-report.md --as-of <target-repo revision> --findings <spec>
 ```
 
-— stamping the report with a "superseded as of `<rev>`" banner so a later reader who finds it
+— a ruling is written to the file the report names (`<x>-report.md` <-> `<x>-findings.json`; with only per-slice files at that revision, pass the per-slice report or it refuses; `--as-of` is NOT the lookup key — the report's own `Target repo: … @ <rev>` header revision is, and `--as-of` only when the report has none) — stamping the report with a "superseded as of `<rev>`" banner so a later reader who finds it
 (a search hit, a bookmark, a link from an old PR description) sees immediately that its
 file:line citations describe an ancestor of the current model, not its current state. This is
 what keeps a superseded report an honest piece of history rather than a silently-misleading
@@ -380,7 +380,7 @@ each call adds its own stamp rather than overwriting the last.
   the gitignoring (`*-asis.em`, idempotent) mechanically, never built up from nothing and never
   hand-maintained. It's regenerated every conform run.
 - **Report location:** `conformance/<YYYY-MM-DD>-report.md` in the model directory. One file
-  per run; don't overwrite a prior date's report.
+  per run; don't overwrite a prior date's report. Its findings go in the same-stem `-findings.json`; gates read every same-revision findings file, so per-slice runs may write `<date>-<name>-findings.json`, and a ruling is written to the file the report names. The same-revision lookup uses the report's OWN revision (its `Target repo: … @ <rev>` header line; the caller's `<rev>` / `--as-of` only when the report has none).
 - **Red note wording:** `issue "conformance: <what's wrong, plainly>"` — plain enough that
   whoever ratifies it later understands the claim without re-reading the report.
 - **Naming/matching rules:** same past-tense-event / imperative-command / thing-shown-view

package/plugin/skills/design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: design
-em-version: 1.19.6
+em-version: 1.19.7
 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.19.6
+em-version: 1.19.7
 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.19.6
+em-version: 1.19.7
 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

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling
-em-version: 1.19.6
+em-version: 1.19.7
 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.19.6
+em-version: 1.19.7
 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/plugin/skills/review/SKILL.md

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