@milehimikey/em 1.19.6 → 1.20.0

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling
-em-version: 1.19.6
+em-version: 1.20.0
 description: >-
   Use when the user runs `/event-modeling` (with or without a phase name), or wants to resume an
   event-modeling session without specifying which part of the process applies. Reads the model's

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-conform
-em-version: 1.19.6
+em-version: 1.20.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-conform/reference/conform.md

@@ -39,7 +39,9 @@ difference is what you do with what you find: extract *builds* a model from the
    (or the status the user says corresponds to shipped code) for whichever slices are in scope.
    Checking a `draft` or `ready-to-implement` slice against code is a wasted walk — ratified or
    not, nobody has built to it yet; tell the user and skip it rather than reporting "drift"
-   against it.
+   against it. (GH #400: the ONE exception is a deliberate pre-ship advisory run — see
+   `--preview` under step 5 below — not a reason to treat this precondition as optional for an
+   ordinary post-ship sweep.)
 3. The codebase to check: the state file's **Existing system refs** (populated during
    `extract`, if this model came from one) or ask the user for the repo path if not set. Record
    it if missing. In a headless/scheduled run with no user to ask, default to the repository
@@ -335,6 +337,32 @@ been through this) instead of just trusting `implementedIn`. Legal only for `sta
 with a link, and itself refuses if an unruled finding for that slice still exists at this
 revision — the mechanical proof this step comes only after rulings, not before.
 
+**Pre-ship advisory mode: `--preview` (GH #400).** The certify step above is legal only for a
+**shipped** slice (`status: implemented`/`shippedVersion:` + `implementedIn:`) — precondition 2
+reflects that this phase ordinarily walks shipped code. `--preview` is the deliberate exception:
+the SAME doc-resolution and findings-check read, legal for a slice that hasn't shipped yet
+(the shipped/`implementedIn:` preconditions are waived), and it **never writes anything** —
+no `conformedVersion`/`conformedAt`/`conformedOn`, ever, regardless of outcome:
+
+```
+em slice conform <model-name>.em <slice-key> --at <target-repo revision> --preview
+```
+
+Use this to run a conform sweep against your OWN implementing branch before it merges — catching
+spec/code drift while you can still fix it on the same branch, rather than after shipping. The
+walk itself (steps 1-4 above) is unchanged; only the certify step's preconditions differ. Output
+is ephemeral by default (nothing is written, not even to `conformance/`); pass
+`--write-findings` to persist the run's own unruled findings as a normal
+`conformance/<date>-<slice-key>-preview-findings.json` (this is deliberate — `docs/cli.md`'s
+`em slice conform --preview` section documents the exact shape and naming). Know before opting
+in: the written file has no sibling report (`report` is synthetic), so `em conform-supersede`
+refuses to rule on it — unruled entries in it gate certify/`set-conformance` at that revision
+until you rule them in the file by hand, delete the snapshot, or author the sibling report.
+`em state set-conformance` and the unruled-findings gates are unaffected by
+this mode either way: a default preview run writes nothing for them to read, so it can never
+block a later certify or `set-conformance` call. There is no `--slice-ready` integration for this
+mode yet.
+
 End of run: update the state file's `Last conformance:` marker with
 
 ```
@@ -342,7 +370,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
@@ -363,7 +391,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
@@ -379,7 +407,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/.claude/skills/event-modeling-design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-design
-em-version: 1.19.6
+em-version: 1.20.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
@@ -88,10 +88,14 @@ Goal: a structurally complete, **validated** model with correct patterns and swi
    shape — reshape it with the "Reshaping an existing model" checklist. Then the **intent test**
    per command (would a business person say this name at this step in the story? an endpoint-shaped
    name fails), the **question test** per view (write the question it answers; no question, no
-   read model; a child view only when its query needs what the parent view lacks), and the
+   read model; a child view only when its query needs what the parent view lacks), the
+   **views-as-lookups check** per `from "E"` on a view (does E add, change or remove a row here? if
+   it only fills a column, put the column on the event that creates the row and drop E — see
+   `../event-modeling-shared/reference/methodology.md`, "Views as lookups"), and the
    **conditional-invariant signal** (invariants or fields that apply only "if `<field>` is set"
    mean two intents in one command: split it). The `timeline-entity-clustered`,
-   `command-second-intent` and `automation-split-by-outcome` lints are the mechanical half; the
+   `command-second-intent`, `automation-split-by-outcome` and `view-lookup-source` lints are the
+   mechanical half (the last one only catches the cross-context cases — do the check by eye too); the
    1.18.0 design exit gate is `em validate --shape`. Shape the model first, scaffold docs after: a rename,
    split or merge from the reshape would orphan docs already wired with `--wire`. The `slice` phase is unchanged (timeline order).
 3. **Elaborate scenarios — first pass (step 6).** Scaffold every slice's doc now, one per
@@ -130,6 +134,13 @@ Goal: a structurally complete, **validated** model with correct patterns and swi
    that reads it; another model/system reads it → mark it `public`; only an automation reads
    it → nothing, it's internal by design. No new keyword — reachability is already what `ui` and
    `public` mean.
+   **Per `view`, also ask whether each of its sources earns its place (GH #398):** for every
+   `from "E"` on the view, does E add, change or remove a row here — or only fill a column on a
+   row some other event already created? The latter is the views-as-lookups smell (methodology
+   reference, "Views as lookups"): drop E as a source and have the event that creates the row
+   carry the field instead. `view-lookup-source` flags the cross-context instances of this
+   mechanically; a lookup from the view's own context (no `@Context` mismatch to key on) only
+   this by-eye check catches.
    **Per translation fed from another model, declare what it consumes (MIL-235):** write
    `translation Order Intake consumes checkout:event.order-submitted`. The ref is
    `<modelKey>:<kind>.<slug>`, where kind is `event` or `view` and the target is marked `public`

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-discover
-em-version: 1.19.6
+em-version: 1.20.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-discover/reference/extract.md

@@ -96,6 +96,14 @@ it is fine to finish a round with `# TBD`s still parked.
   read model* warnings: real systems do record fire-and-forget events. In an as-is model that is
   a **finding about the system**, not a modelling mistake — never invent a reader to silence it
   (that would be desired state). Park it in the Decisions log and carry the warning.
+  **Expect lookup-style sources too.** A lifted model will faithfully reproduce the projection's
+  lookup joins — a view wired to `from "Order Created"` only because the current query joins the
+  orders table to get `customerName`, not because this view owns any row that event changes. Wire
+  it as-is (current-state-only stance: that join is how the system behaves today); don't fix it
+  here, that would be inventing desired state. Note it as a finding in the Decisions log the same
+  way as an unread event, and leave it for `model`/`slice` to apply the views-as-lookups rule
+  (`../../event-modeling-shared/reference/methodology.md`, "Views as lookups") once the as-is
+  model is agreed.
 - **R5 — Boundaries & reactions.** Current automations and integrations as-is: schedulers,
   listeners, outbound syncs, inbound webhooks. Model each as a reaction sharing its slice with
   the `command` + `event` it triggers (`reaction → command → event`, per `em-dsl.md`) — the

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-engagement
-em-version: 1.19.6
+em-version: 1.20.0
 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/.claude/skills/event-modeling-implement/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-implement
-em-version: 1.19.6
+em-version: 1.20.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
@@ -52,7 +52,12 @@ routing table (§7) is what names the skill set for each pattern.
 Preconditions (tool check, model location) are the same as every other phase — see
 `../event-modeling-shared/reference/operating-principles.md` — but this phase additionally
 requires the target slice to already be ratified; if it isn't, stop and say so rather than
-starting on unratified work.
+starting on unratified work. The one documented exception is **inline ratification** (GH #399,
+`reference/implement.md` §1a): for an internal (non-public-touching, non-engagement) slice whose
+doc is already `reviewed`, drafting code on the same branch ahead of the human's `em slice
+ratify` is sanctioned — provided you never flip the gate yourself and re-confirm
+`--slice-ready` reads `true` before treating the slice as done. `event-modeling-engagement` is
+unchanged by this: it still requires every dispatched slice ratified before its branch is cut.
 
 End of phase: PR merged, slice doc flipped to `status: implemented` with `implementedIn`
 filled, `em slice index <model-name>.em` run to refresh `README.md`'s Slices table. Implement

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

@@ -46,15 +46,82 @@ A warning whose code is in this list blocks; any other warning never does — `c
 
 Because of that list, `ready` can be `false` with every `gates` entry `true` (a `both-ends-of-a-flow/*` warning on one of the slice's own elements, say). Don't work it out from `gates`: read **`blockedBy`** (schema `1.5`, GH #377), the codes that flipped `ready`, `[]` exactly when it is `true`, and report those codes with the `false` gates when you hand the slice back.
 
-**`ready: false` means stop** — with one named exception: a slice already `status: implemented`
-with `driftSignal: in-sync` or `uncertified` (MIL-214) also reads `ready: false` (its
-`statusReady` gate fails because nothing is newly ratified), and that specific case is
-re-implementation/repair, not a blocker — see §3's third mode before treating it as one. For
+**`ready: false` means stop** — with two named exceptions. First: a slice already `status:
+implemented` with `driftSignal: in-sync` or `uncertified` (MIL-214) also reads `ready: false`
+(its `statusReady` gate fails because nothing is newly ratified), and that specific case is
+re-implementation/repair, not a blocker — see §3's third mode before treating it as one. Second:
+under **inline ratification** (§1a) a slice doc that's only `status: reviewed` — not yet
+`ready-to-implement` — is a sanctioned starting point for drafting code on the SAME branch, with
+the explicit, non-negotiable condition that you treat nothing as actually ratified, and open
+nothing for merge, until a human has run `em slice ratify` and `--slice-ready` reads `true` for
+real; §1a names exactly which slices qualify and what that condition requires in practice. For
 every other `false`, report which `gates`
 entries are `false` and what `blockedBy` names (and any `diagnostics` entries concerning this
 slice) and hand the slice back to the humans. Never make the gate pass yourself — checking an open-question box, flipping
-`status`, or editing frontmatter are ratification decisions, and ratification happens in a
-facilitated session, not in an implementation branch.
+`status`, or editing frontmatter are ratification decisions, made by a human in a ratification
+session, never by you running `em slice ratify` on their behalf. That session is usually a
+separate doc-only PR, merged before an implementation branch is even cut — but it doesn't have
+to be: **inline ratification** (GH #399, §1a below) lets the session be the PR review of the
+very branch you're implementing on, for internal slices. Either shape, the rule here is the
+same: you never flip the gate yourself, whatever branch you're on.
+
+### 1a. The inline variant: ratifying on the implementation branch
+
+Most of this document assumes the ordinary shape — a slice is already `ready-to-implement` when
+you start, ratified in its own prior PR, and §1's gate reads `true` before you write a line of
+code. **Inline ratification** is the documented alternative
+(`docs/process.md`'s
+["Inline ratification" section](https://github.com/milehimikey/em/blob/main/docs/process.md#inline-ratification-approval-as-the-ratification-session)):
+draft the slice doc *and* build it on the same branch, spec commits first, and let the human's
+review of that one PR be the ratification session — which means you are, deliberately and
+sanctioned, building for most of that branch's life against a doc that reads `ready: false`.
+What doesn't change: you still never flip `status` yourself, never run `em slice ratify` on the
+human's behalf, and never write a word of the ratification record — see §1's second named
+exception for the precise condition this depends on. What's different is sequencing and tiering:
+
+- **Draft the doc first, then build on the same branch.** Commit the slice doc (through the
+  normal `slice` phase), get it reviewed (`em slice review --by`, flipping it to `status:
+  reviewed` — a human has to do this part too, same as always) before any implementation code,
+  even though doc and code will both live on one branch and merge in one PR. Writing code before
+  the doc exists, or before a human has looked at it, is retrofit — the exact failure mode inline
+  mode is named after avoiding — whether or not anyone ever checks for it.
+- **You may keep building past a `reviewed`-but-not-yet-`ready-to-implement` doc, but nothing is
+  ratified until `em slice ratify` actually runs.** `--slice-ready` keeps reading `false` the
+  whole time you're building — that's expected, not a signal to stop, as long as the doc's
+  `status` is `reviewed` (not `draft`: an un-reviewed doc is never a valid base, inline or not).
+  On an inline branch the human typically runs `em slice ratify --no-ref` as part of approving
+  the PR (`--no-ref` because the branch is headed for a squash/rebase merge) — not something you
+  do for them, and not something you should expect to have happened before the PR is up for
+  review. Before you report the slice done, or treat §6's merge-time flip as legitimate,
+  re-check `--slice-ready` yourself and confirm it now reads `true` with `ratifiedBy:` set — if
+  it still doesn't, the slice isn't ratified yet and you say so instead of proceeding.
+- **A post-signature doc edit still trips the hash check.** `ratifiedHash` doesn't know or care
+  which branch it was computed on — if something changes the doc's body after the human has
+  signed it (a gap surfaces, §4), `--slice-ready` and `em slice ratify` both refuse the stale
+  signature exactly as they would across two PRs. Route it through `em slice revise --withdraw`,
+  review, re-ratify (§4) — inline doesn't shortcut that loop, it just means the re-sign happens
+  on the branch you're already on instead of a fresh one.
+- **Not every slice is a candidate.** A slice owning a `public` command, event or view
+  (`isPublicTouchingSlice`) keeps the separate doc PR — the contract is a promise to consumers
+  who never see your implementation diff, and `em slice ratify` already refuses a public-touching
+  slice without `--meaning-unchanged`/`--contract-change` regardless of which branch it runs on.
+  An engagement-dispatched slice is never inline either — engagements structurally need every
+  contract frozen before any implementer branch is cut, so the engagement skill never offers you
+  this shape (it is explicitly unchanged by GH #399 — this is a note for your own judgment
+  outside an engagement, not something to apply inside one).
+- **Pre-ship advisory conform is the loop's natural checkpoint.** Before the PR merges, a human
+  (or you, if asked) can run `em slice conform <model>.em <key> --at <rev> --preview` — the
+  pre-ship, non-certifying mode (GH #400): same doc-resolution and findings-check read as a real
+  certification, legal before the slice has shipped, never writes `conformedVersion:`/
+  `conformedAt:`/`conformedOn:`. It's advisory and ephemeral by default (nothing written unless
+  `--write-findings` is passed) — a cheap "did I just drift from the doc I signed" look before
+  asking for the PR review that will also be the ratification.
+- **The ordering advisory is informational, not yours to act on.** `em refs --check-order`
+  (GH #399) can report whether a commit on this branch touched code before the doc's
+  `ratifiedRef` — a retrofit smoke signal for the human reviewing the PR. It's advisory, never a
+  gate, and nothing in this skill asks you to run it or react to its output; if a human shows you
+  a `code-before-ratification` result, treat it the same as any other gap raised against your
+  work (§4), not as something to silence.
 
 ## 2. Read the spec
 

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling-review
-em-version: 1.19.6
+em-version: 1.20.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

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

@@ -28,6 +28,8 @@ em render <file> --keep-empty-lanes                                 # keep the A
 em export <file>                                                    # export a versioned JSON snapshot of the normalized model
 em export <file> -o, --out <path>                                   # write to a file instead of stdout
 em export <file> --slice <key>                                      # export only this slice's object (pattern/fields/doc) instead of the whole model (export key, MIL-128) — refuses only if THIS slice has an error; an unrelated slice's breakage elsewhere in the model doesn't block it (see docs/cli.md)
+em export <file> --doc-json                                         # emit the structured slice-doc export (GH #401) instead of the model snapshot: per slice the frontmatter join plus the parsed sections as data (fields, invariants, scenarios, error flows, open questions) and a model-level invariant catalog. Own schema version; whole model only (does not combine with --slice)
+em export <file> --include-html                                     # with --doc-json, include each slice doc's rendered HTML body (excluded by default; the authored body never appears in a plain export)
 em api generate <file>                                              # write the TypeSpec contract for the model's public commands, events and views to <model dir>/contracts/<model key>.tsp
 em api generate <file> -o, --out <path>                             # write to this path instead of <model dir>/contracts/<model key>.tsp
 em api generate <file> --stdout                                     # print the contract instead of writing it
@@ -98,10 +100,13 @@ em slice defer <file> <slice-key> [question] --decision <text>      # what this
 em slice defer <file> <slice-key> [question] --from-issue <text>    # defer a captured `issue "..."` on this slice instead of a doc Open Question (case-sensitive substring of its text)
 em slice defer <file> <slice-key> [question] --by <name>            # who deferred it
 em slice defer <file> <slice-key> [question] --on <date>            # deferral date, YYYY-MM-DD (default: today, local date)
-em slice conform <file> <slice-key>                                 # record per-slice-per-version conformance certification: sets `conformedVersion:`/`conformedAt:`/`conformedOn:` on a slice doc (MIL-214) — the fact `driftSignal: in-sync` now depends on. Legal only for a shipped slice (`status: implemented`, or any status with a `shippedVersion:` — MIL-283) with an `implementedIn:` link; `conformedVersion:` is the shipped version. Idempotent on the same (version, --at) pair; a different --at simply overwrites (a later re-certification is normal — there's no way for em to tell 'later' from 'earlier' for an arbitrary revision string, so there's no --force to reach for). Refuses when the conformance/<date>[-<name>]-findings.json file matching --at still has an unruled finding in scope for this slice; --skip-findings-check overrides with a loud notice.
+em slice conform <file> <slice-key>                                 # record per-slice-per-version conformance certification: sets `conformedVersion:`/`conformedAt:`/`conformedOn:` on a slice doc (MIL-214) — the fact `driftSignal: in-sync` now depends on. Legal only for a shipped slice (`status: implemented`, or any status with a `shippedVersion:` — MIL-283) with an `implementedIn:` link; `conformedVersion:` is the shipped version. Idempotent on the same (version, --at) pair; a different --at simply overwrites (a later re-certification is normal — there's no way for em to tell 'later' from 'earlier' for an arbitrary revision string, so there's no --force to reach for). Refuses when the conformance/<date>[-<name>]-findings.json file matching --at still has an unruled finding in scope for this slice; --skip-findings-check overrides with a loud notice. GH #400: --preview runs the same doc-resolution and findings-check read for a slice that hasn't shipped yet — the shipped/implementedIn gates are waived and NOTHING is ever written to the doc; output is ephemeral (text or --json) unless --write-findings opts into persisting a normal findings file.
 em slice conform <file> <slice-key> --at <rev>                      # the target-repo revision this certification sweep diffed against — or, when what was exercised is not a commit that stays reachable (a per-PR environment under squash/rebase merges, a build or image), an opaque `<kind>:<id>` such as build:1234 or deploy:eu-1-2026-10-15 (GH #261); recorded verbatim, skipped by git-reachability checks
 em slice conform <file> <slice-key> --on <date>                     # certification date, YYYY-MM-DD (default: today, local date)
 em slice conform <file> <slice-key> --skip-findings-check           # certify even with unruled findings in scope — prints a loud notice on stderr
+em slice conform <file> <slice-key> --preview                       # GH #400: pre-ship advisory mode — waives the shipped-status/`implementedIn:` gates, writes NOTHING to the doc (no conformedVersion/conformedAt/conformedOn, ever); ephemeral by default, --write-findings opts into persisting a normal findings file. --skip-findings-check has no effect in this mode (preview never refuses on findings)
+em slice conform <file> <slice-key> --write-findings                # with --preview: persist the preview's own unruled findings as conformance/<on>-<slice-key>-preview-findings.json
+em slice conform <file> <slice-key> --json                          # with --preview: print a JSON document instead of the text report
 em changelog <file>                                                 # render a model's git history as a business-readable ledger (see docs/cli.md)
 em changelog <file> --from <rev>                                    # start the walk at this revision (inclusive)
 em changelog <file> --to <rev>                                      # end the walk at this revision (inclusive; default HEAD)
@@ -109,7 +114,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:)
@@ -127,7 +132,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)
@@ -145,6 +150,7 @@ em watch <file> -T, --format <fmt>                                  # output for
 em watch <file> --keep-empty-lanes                                  # keep the API lane even when empty
 em watch <file> --serve                                             # serve a live viewer with instant push-reload (no polling)
 em watch <file> --port <n>                                          # port for --serve (default 5173)
+em watch <file> --storyline <name>                                  # GH #309 (deferred from #277): filter the live view to one storyline's subset — the same subset `em render --storyline` draws (its own slices in order, plus dimmed stub columns for what they read from outside it and the `after` end state). Whenever the model declares any storylines the viewer also offers a picker to switch to the full model or another declared storyline, live, without restarting. An unknown name errors, listing the declared storylines; requires --serve
 em validate <file>                                                  # check a model against event-modeling rules
 em validate <file> --list-issues                                    # print only open `issue` diagnostics (slice, element, line, text)
 em validate <file> --list-divergences                               # print only accepted-divergence annotations (slice, element, line, text) — never fails the build
@@ -164,6 +170,7 @@ em refs <file>                                                      # check that
 em refs <file> --reachable-from <rev>                               # the branch or commit every ref must be an ancestor of (e.g. origin/main)
 em refs <file> --waive <slice-key>                                  # excuse this slice's non-ancestor/unresolved/undecidable results from the exit code (repeatable); still reported
 em refs <file> --waive-file <path>                                  # a baseline file of slice keys to waive, one per line (`#` comments allowed); missing file = no waivers
+em refs <file> --check-order                                        # advisory-only (GH #399): for every slice doc with a ratifiedRef, report whether a commit between the branch's fork point and ratifiedRef already touched code other than the doc itself — a retrofit signal for inline ratification (spec written to describe code that already exists). History is rewritable, so this NEVER affects the exit code or `ok`, and is never a validate gate — see docs/process.md's inline-ratification section
 em refs <file> --json                                               # print a JSON document instead of the text report (see docs/cli.md)
 em ledger <file>                                                    # check slice docs' version: field agrees with their content across two git revisions (opt-in CI check, MIL-89 — never part of `em validate`, see docs/ci.md)
 em ledger <file> --from <rev>                                       # baseline revision
@@ -489,7 +496,19 @@ type Name { field: Type, ... }      # named structured type, reusable from any f
   declared `type T`, with `derived from "Child Created", "Child Deleted"`, embeds a child entity:
   each field of `T` must trace to a named event (`fields-completeness/view-field-no-source`
   otherwise); a field also traces one level through the declared element type of an array field
-  on the event (`optionValues: VariantOptionValue[]`), no deeper and with no path syntax. An
+  on the event (`optionValues: VariantOptionValue[]`), no deeper by same name. When the event
+  renamed or flattened the field, declare the element field's source by **path** into the named
+  event, as the unquoted form of the same clause (GH #383): `attributeValueIds: string[] derived
+  from values[].attributeValueId` — a `.`-joined chain of identifiers, each `[]`-suffixed exactly
+  when it steps through an array field (the marker is enforced against the event field's actual
+  arrayness). The path must resolve on a named event — every named event is tried; non-leaf
+  segments must be `type`-valued fields — and the leaf field's type must match the element
+  field's (array markers stripped); an unresolved path or leaf-type mismatch is
+  `fields-completeness/view-field-no-source` (implicit same-name nested tracing matches names
+  only; the explicit path form earns the stronger leaf-type check). The quoted event-list form
+  and the unquoted path form are mutually exclusive on one field — both at once is a parse error.
+  A plain (non-collection) view field may carry the same path form, checked the same way against
+  the view's source events — never silently exempt like a bare `derived` field. An
   element field the projection computes rather than copies (an audit stamp from event metadata,
   say) is marked `derived` on the `type` field itself — bare or `derived from "<events>"`, same
   syntax as a view field (GH #382): it is then skipped by `view-field-no-source`, and a traced
@@ -954,6 +973,7 @@ not the prose above has caught up yet. `--slice-ready <key>`-only codes are excl
 | `view-again-without-earlier` | error | `again` without an earlier declaration | Declare the view plainly the first time it appears. |
 | `view-from-future-event` | error | Backward timeline (view reads a future event) | Move the source to a later `view X again` instance. |
 | `view-from-unresolved` | error | Unknown event source | Fix the `from` reference to name an existing event. |
+| `view-lookup-source` | warning | View reads an event only as a lookup | Carry the field on the event that creates this view's own row instead; if this is a genuine cross-context row change, accept it on the shape exit gate (docs/validation.md#the-shape-exit-gate) rather than fixing it (docs/patterns.md#state-view). |
 | `view-no-source` | warning | Read model without source | Add `from "Event"`, or place the view in a slice with an event. |
 <!-- GENERATED:validate-rules:end -->
 

package/.claude/skills/event-modeling-shared/reference/methodology.md

@@ -316,6 +316,22 @@ drift into **CRUD laid on a timeline**; these rules stop that. Quoted lines are
   view carries ids; child with its own data → embedded in the parent view; child queried without the
   parent id → its own view. Aggregate rules decide write-side consistency, never read models. *(em
   ruling)*
+- **Views as lookups: an event that creates a row carries what the row shows.** A view reads another
+  event only when that event adds, changes or removes a row the view already owns — never merely to
+  fill a column on a row some *other* event created. **Per-view check:** for each `from "E"` on a view,
+  ask *does E add, change or remove a row here? If it only fills a column, put the column on the event
+  that creates the row and drop E.* Generated models routinely come out wrong here — a wide fan-out of
+  "reference" events into every view that shows a name, and views keeping a lookup table ("every
+  neighbor's name and current email, every tool's name") beside their own rows. Fix: the decider
+  already read what it needed to enforce its own invariants (e.g. a checkout decider that reads Tool
+  Added and Neighbor Registered to validate the request already has `toolName`/`neighborName` in hand),
+  so have it assign those fields onto the event it records — the view then needs nothing beyond that
+  one event. A slice doc that needs a "Bookkeeping" paragraph (the view keeps, beyond its own rows, a
+  lookup of some other entity's fields) has this smell; see `docs/patterns.md#state-view` for the
+  worked overdue-notice example.
+  `view-lookup-source` is the mechanical, advisory half — it catches the cross-context cases with a few
+  false positives; a within-context lookup (`Tool Checked Out` read only to learn whose loan a later
+  event concerns) is invisible to it, so this check still has to be done by eye.
 - **Write side: children belong in the parent's context** when the child's invariants are checks against
   the parent. A sub-resource schema shared across parent types is one event per parent on the parent's
   context, not a shared aggregate — check the spec's event reference, not its resource section. Where

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

@@ -70,7 +70,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/.claude/skills/event-modeling-shared/templates/slice.md

@@ -164,7 +164,12 @@ an event directly.}}
      line and field table are a GENERATED region (one per read model; `em-slice-view-<view-slug>`
      when there are several): Source / Notes names the source event a field is copied from, or
      `Derived` for a field marked `derived` in the `.em` (docs/dsl.md#derived-fields) — say how
-     it is derived in prose below the region. `{{ }}` marks a field the model cannot trace. -->
+     it is derived in prose below the region. `{{ }}` marks a field the model cannot trace.
+     If describing a field here needs a "Bookkeeping" paragraph — this view also keeps, beyond its
+     own rows, a lookup of some other entity's name/email/etc. so it can display it — that is the
+     views-as-lookups smell (methodology reference, "Views as lookups"): the field belongs on the
+     event that creates this view's row instead, copied from state the command/decider already
+     reads to enforce its own invariants. Fix the `.em`, not the prose. -->
 <!-- GENERATED:em-slice-view:start — generated from the model by `em slice sync`; do not hand-edit -->
 - **View:** `{{View Name}}` built from events: {{"Event A", "Event B"}}
 

package/.claude-plugin/marketplace.json

@@ -1,9 +1,9 @@
 {
-  "name": "em-1-19-6",
+  "name": "em-1-20-0",
   "owner": {
     "name": "Mike Key"
   },
-  "description": "em v1.19.6: the Event Modeling skill bundle and MCP server as a Claude Code plugin.",
+  "description": "em v1.20.0: the Event Modeling skill bundle and MCP server as a Claude Code plugin.",
   "plugins": [
     {
       "name": "em",

package/README.md

@@ -109,7 +109,7 @@ flowchart LR
 
 ## Model with AI
 
-`em` ships a Claude Code skill bundle — one router skill plus six focused, SDLC-stage skills
+`em` ships a plugin skill bundle for Claude Code and Codex — one router skill plus six focused, SDLC-stage skills
 (discover/extract, model/slice, implement, conform/validate, watch/review) — that runs a
 facilitated Event Modeling session: the AI asks the questions, you supply the domain, and the
 model renders live as it grows.
@@ -122,6 +122,16 @@ claude plugin marketplace add milehimikey/em@v1.14.0 --scope project
 claude plugin install em@em-1-14-0 --scope project
 ```
 
+Codex uses the same marketplace and plugin bundle:
+
+```bash
+codex plugin marketplace add milehimikey/em --ref v1.14.0
+codex plugin add em@em-1-14-0
+```
+
+Start a new Codex session after installation. The same skills and MCP server are available; Codex
+does not use Claude's `/em:` slash-command syntax.
+
 Then run `/em:event-modeling` in Claude Code. The older vendored route (`em skill install`,
 which copies the bundle into `.claude/skills/`) still works but is deprecated since 1.14;
 `em upgrade --apply` moves a vendored repo to the pinned plugin in one commit. The same bundle

package/dist/catalog/docBadge.d.ts

@@ -0,0 +1,16 @@
+export interface FrontmatterBadgeInput {
+    /** `SliceDoc.pattern` — kebab-case or null. */
+    pattern: string | null;
+    /** `SliceDoc.version` or null. */
+    version: number | null;
+    /** `SliceDoc.status`, lowercase, or null. */
+    status: string | null;
+    /** `classifyImplementationDrift(doc)`'s result, as its string value. */
+    driftSignal: string;
+}
+/** GH #402: a compact badge row — pattern, version, lifecycle status, implementation-drift
+ *  signal — built from a slice doc's own frontmatter facts. Callers gate this on
+ *  `doc.frontmatterPresent` themselves (catalog/pages.ts, render/sliceOverlay.ts): a legacy
+ *  freeform doc with no frontmatter at all renders with no badge row, exactly as it did before
+ *  this feature. */
+export declare function renderFrontmatterBadgeRow(input: FrontmatterBadgeInput): string;

package/dist/catalog/docBadge.js

@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: MIT
+// GH #402: the compact frontmatter badge row shown above a slice doc's body wherever
+// `SliceDoc.html` is rendered — `em catalog`'s per-slice page (catalog/pages.ts) and the live
+// viewer's doc flyout (render/sliceOverlay.ts). Both callers already hold a resolved `SliceDoc`
+// and can compute its `classifyImplementationDrift()` (catalog/driftSignal.ts) themselves; this
+// module takes the four already-resolved primitives rather than either type, so it carries no
+// dependency on catalog/sliceDoc.ts or catalog/driftSignal.ts and can't become part of a cycle
+// with either. Pure: primitives in, an HTML string out.
+function escapeHtml(s) {
+    return s.replace(/&/g, "&amp;").replace(/</g, "&lt;").replace(/>/g, "&gt;").replace(/"/g, "&quot;");
+}
+/** `"state-change"` -> `"State Change"`, `"ready-to-implement"` -> `"Ready To Implement"` — the
+ *  frontmatter's kebab-case machine values, in the display label shape the skill prose already
+ *  uses for `pattern` (sliceDoc.ts's own comment: "the frontmatter value is a machine key, not a
+ *  display label"). */
+function titleCase(kebab) {
+    return kebab
+        .split("-")
+        .map((w) => (w.length > 0 ? w[0].toUpperCase() + w.slice(1) : w))
+        .join(" ");
+}
+/** Readable labels for `classifyImplementationDrift`'s `DriftSignalKind` — duplicated here as
+ *  strings rather than importing the union type, so this module stays free of any dependency on
+ *  catalog/driftSignal.ts (see file header). An unrecognized value (there shouldn't be one) falls
+ *  back to showing itself verbatim rather than disappearing. */
+const DRIFT_LABELS = {
+    "in-sync": "In sync",
+    "never-implemented": "Not implemented",
+    "unpropagated-delta": "Delta pending",
+    "implemented-without-link": "Implemented, no link",
+    uncertified: "Uncertified",
+};
+/** GH #402: a compact badge row — pattern, version, lifecycle status, implementation-drift
+ *  signal — built from a slice doc's own frontmatter facts. Callers gate this on
+ *  `doc.frontmatterPresent` themselves (catalog/pages.ts, render/sliceOverlay.ts): a legacy
+ *  freeform doc with no frontmatter at all renders with no badge row, exactly as it did before
+ *  this feature. */
+export function renderFrontmatterBadgeRow(input) {
+    const badges = [];
+    if (input.pattern)
+        badges.push(`<span class="doc-badge doc-badge--pattern">${escapeHtml(titleCase(input.pattern))}</span>`);
+    if (input.version !== null)
+        badges.push(`<span class="doc-badge doc-badge--version">v${input.version}</span>`);
+    if (input.status)
+        badges.push(`<span class="doc-badge doc-badge--status">${escapeHtml(titleCase(input.status))}</span>`);
+    const driftLabel = DRIFT_LABELS[input.driftSignal] ?? input.driftSignal;
+    badges.push(`<span class="doc-badge doc-badge--drift doc-badge--drift-${escapeHtml(input.driftSignal)}">${escapeHtml(driftLabel)}</span>`);
+    return `<div class="doc-badge-row">${badges.join("")}</div>`;
+}
+//# sourceMappingURL=docBadge.js.map

package/dist/catalog/docBadge.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"docBadge.js","sourceRoot":"","sources":["../../src/catalog/docBadge.ts"],"names":[],"mappings":"AAAA,+BAA+B;AAC/B,qFAAqF;AACrF,8FAA8F;AAC9F,gGAAgG;AAChG,gGAAgG;AAChG,8FAA8F;AAC9F,+FAA+F;AAC/F,wDAAwD;AAExD,SAAS,UAAU,CAAC,CAAS;IAC3B,OAAO,CAAC,CAAC,OAAO,CAAC,IAAI,EAAE,OAAO,CAAC,CAAC,OAAO,CAAC,IAAI,EAAE,MAAM,CAAC,CAAC,OAAO,CAAC,IAAI,EAAE,MAAM,CAAC,CAAC,OAAO,CAAC,IAAI,EAAE,QAAQ,CAAC,CAAC;AACtG,CAAC;AAED;;;uBAGuB;AACvB,SAAS,SAAS,CAAC,KAAa;IAC9B,OAAO,KAAK;SACT,KAAK,CAAC,GAAG,CAAC;SACV,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC;SAChE,IAAI,CAAC,GAAG,CAAC,CAAC;AACf,CAAC;AAED;;;gEAGgE;AAChE,MAAM,YAAY,GAA2B;IAC3C,SAAS,EAAE,SAAS;IACpB,mBAAmB,EAAE,iBAAiB;IACtC,oBAAoB,EAAE,eAAe;IACrC,0BAA0B,EAAE,sBAAsB;IAClD,WAAW,EAAE,aAAa;CAC3B,CAAC;AAaF;;;;oBAIoB;AACpB,MAAM,UAAU,yBAAyB,CAAC,KAA4B;IACpE,MAAM,MAAM,GAAa,EAAE,CAAC;IAC5B,IAAI,KAAK,CAAC,OAAO;QAAE,MAAM,CAAC,IAAI,CAAC,8CAA8C,UAAU,CAAC,SAAS,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC,SAAS,CAAC,CAAC;IAC5H,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI;QAAE,MAAM,CAAC,IAAI,CAAC,+CAA+C,KAAK,CAAC,OAAO,SAAS,CAAC,CAAC;IAC/G,IAAI,KAAK,CAAC,MAAM;QAAE,MAAM,CAAC,IAAI,CAAC,6CAA6C,UAAU,CAAC,SAAS,CAAC,KAAK,CAAC,MAAM,CAAC,CAAC,SAAS,CAAC,CAAC;IACzH,MAAM,UAAU,GAAG,YAAY,CAAC,KAAK,CAAC,WAAW,CAAC,IAAI,KAAK,CAAC,WAAW,CAAC;IACxE,MAAM,CAAC,IAAI,CACT,4DAA4D,UAAU,CAAC,KAAK,CAAC,WAAW,CAAC,KAAK,UAAU,CAAC,UAAU,CAAC,SAAS,CAC9H,CAAC;IACF,OAAO,8BAA8B,MAAM,CAAC,IAAI,CAAC,EAAE,CAAC,QAAQ,CAAC;AAC/D,CAAC"}

package/dist/catalog/docModelConsistencyValidate.js

@@ -66,7 +66,7 @@ import { isSignedSliceDoc } from "./sliceDoc.js";
 import { checkScenarioQuality } from "./scenarioQualityValidate.js";
 import { authoredTextOf, findStructuredSectionProblems, generatedRegionPlaceholders, splitCells } from "./sliceSections.js";
 import { duplicateScenarioTitles, parseScenariosLenient } from "./scenarios.js";
-import { viewSourceNames } from "../model/continuation.js";
+import { viewLoopedEventNames, viewSourceNames } from "../model/continuation.js";
 const COMMAND_MARKER = /^\*\*Command:\*\*\s*`([^`]+)`\s*$/;
 const EVENT_MARKER = /^\*\*Event:\*\*\s*`([^`]+)`(?:\s*→\s*context\s*`[^`]+`\s*)?$/;
 const VIEW_MARKER = /^-\s*\*\*View:\*\*\s*`([^`]+)`/;
@@ -405,6 +405,9 @@ function checkFields(diags, kind, docPath, docByName, modelByName, model, refs)
 //   doc-names-unfed-event — the doc's field-table Source column (or, when the doc has exactly one
 //     view, a scenario Given/Then item) names an event that exists in the model but is not among
 //     the view's sources (the toolshed case: prose anticipated an edge the model never drew).
+//     An event reaching the view via a resolved `loops-to "<View>"` edge (MIL-199) counts as a
+//     source too (GH #397) — the DSL reference already says so, and `em export`'s `model.edges`
+//     carries the edge with `source: "loops-to"`.
 //   doc-omits-fed-event — the model feeds the view an event the doc body never mentions.
 // Event names are found by scanning text for the model's own event names (longest first, word-
 // bounded, case-insensitive), so a name embedded in a longer event name is not double-counted.
@@ -505,7 +508,11 @@ function checkViewFeeds(diags, doc, docPath, markers, sliceIndices, ownerSlice,
     for (const marker of matched) {
         const view = modelViews.get(normalizeName(marker.name));
         const sources = viewSourceNames(model, view);
-        const fed = new Set(sources.map(normalizeName));
+        // GH #397: a `loops-to "<View>"` edge re-feeds this view just like an ordinary `from` —
+        // an event naming only a loop-back is still read by the view, so the doc isn't wrong to
+        // list it under the view's sources.
+        const looped = viewLoopedEventNames(model, view);
+        const fed = new Set([...sources, ...looped].map(normalizeName));
         const refsOut = [refs.sliceKeys[view.sliceIndex], refs.refById.get(view.id)];
         let end = lines.length;
         for (let j = marker.bodyLine + 1; j < lines.length; j++) {