@milehimikey/em 1.20.0 → 1.21.0

package/dist/templates.js

@@ -93,14 +93,22 @@ Change slice is paired with the State View slice that projects its event. A read
 along the timeline (\`view X again\`) shows the same projection at a later point; the instances are
 never connected to one another.
 
+## Storylines
+<!-- Generated — \`em slice index {{model-name}}.em\` writes one row per storyline between the
+     markers (count, implemented, diagram); the canvas is \`em render {{model-name}}.em --map\`. -->
+<!-- GENERATED:storylines:start -->
+| Storyline | Slices | Implemented | Diagram |
+|-----------|--------|-------------|---------|
+<!-- GENERATED:storylines:end -->
+
 ## Slices
 <!-- The canonical slice index — the ONE place slices are enumerated (the state file
      points here rather than keeping its own copy). Generated — run
      \`em slice index {{model-name}}.em\` to (re)write the table below from the model and its
      slice docs; never hand-edit between the markers. -->
 <!-- GENERATED:slices:start -->
-| # | Slice | Pattern | Status | Reviewed by | Ratified by | Owner | Tracking | Implemented in | Design doc |
-|---|-------|---------|--------|-------------|-------------|-------|----------|----------------|------------|
+| # | Slice | Pattern | Status | Design doc |
+|---|-------|---------|--------|------------|
 <!-- GENERATED:slices:end -->
 
 ## Status

package/dist/templates.js.map

@@ -1 +1 @@
-{"version":3,"file":"templates.js","sourceRoot":"","sources":["../src/templates.ts"],"names":[],"mappings":"AAAA,+BAA+B;AAC/B,mCAAmC;AAEnC,MAAM,CAAC,MAAM,UAAU,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiDzB,CAAC;AAEF,wDAAwD;AACxD,EAAE;AACF,2FAA2F;AAC3F,0FAA0F;AAC1F,2FAA2F;AAC3F,2FAA2F;AAC3F,+FAA+F;AAC/F,2FAA2F;AAC3F,2CAA2C;AAE3C,qGAAqG;AACrG,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6CpC,CAAC;AAEF,iGAAiG;AACjG,MAAM,CAAC,MAAM,cAAc,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA4E7B,CAAC;AAEF;8BAC8B;AAC9B,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAqIpC,CAAC;AAEF;oFACoF;AACpF,MAAM,UAAU,YAAY,CAAC,KAAa;IACxC,0FAA0F;IAC1F,yFAAyF;IACzF,6FAA6F;IAC7F,OAAO,UAAU,CAAC,OAAO,CAAC,2BAA2B,EAAE,GAAG,EAAE,CAAC,UAAU,KAAK,GAAG,CAAC,CAAC;AACnF,CAAC;AAED;;;;4DAI4D;AAC5D,MAAM,UAAU,cAAc,CAAC,WAAmB,EAAE,QAAgB;IAClE,6FAA6F;IAC7F,4EAA4E;IAC5E,OAAO,qBAAqB,CAAC,OAAO,CAAC,qBAAqB,EAAE,GAAG,EAAE,CAAC,WAAW,CAAC;SAC3E,OAAO,CAAC,qBAAqB,EAAE,GAAG,EAAE,CAAC,QAAQ,CAAC;SAC9C,OAAO,CACN,oFAAoF,EACpF,yFAAyF,CAC1F,CAAC;AACN,CAAC;AAED;;;;8FAI8F;AAC9F,MAAM,UAAU,iBAAiB,CAAC,WAAmB,EAAE,QAAgB,EAAE,KAAa,EAAE,SAAiB;IACvG,qFAAqF;IACrF,wFAAwF;IACxF,4BAA4B;IAC5B,MAAM,MAAM,GAAG,cAAc,CAAC,OAAO,CAAC,gBAAgB,EAAE,GAAG,EAAE,CAAC,WAAW,CAAC;SACvE,OAAO,CAAC,gBAAgB,EAAE,GAAG,EAAE,CAAC,QAAQ,CAAC;SACzC,OAAO,CAAC,WAAW,EAAE,GAAG,EAAE,CAAC,SAAS,CAAC,CAAC,8DAA8D;SACpG,OAAO,CAAC,kFAAkF,EAAE,UAAU,CAAC;SACvG,OAAO,CAAC,+DAA+D,EAAE,GAAG,CAAC;SAC7E,OAAO,CAAC,gBAAgB,EAAE,KAAK,CAAC,CAAC,8DAA8D;QAChG,oEAAoE;SACnE,OAAO,CAAC,6FAA6F,EAAE,OAAO,CAAC;SAC/G,OAAO,CAAC,cAAc,EAAE,MAAM,CAAC,CAAC,qDAAqD;SACrF,OAAO,CAAC,wDAAwD,EAAE,OAAO,CAAC,CAAC,yBAAyB;SACpG,OAAO,CAAC,2DAA2D,EAAE,OAAO,CAAC,CAAC;IAEjF,OAAO,MAAM;SACV,KAAK,CAAC,IAAI,CAAC;SACX,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC;SACtC,IAAI,CAAC,IAAI,CAAC,CAAC;AAChB,CAAC;AAED;;;;;;;;4CAQ4C;AAC5C,MAAM,UAAU,oBAAoB,CAAC,WAAmB;IACtD,6FAA6F;IAC7F,0FAA0F;IAC1F,wCAAwC;IACxC,OAAO,qBAAqB,CAAC,OAAO,CAAC,kBAAkB,EAAE,GAAG,EAAE,CAAC,WAAW,CAAC,CAAC;AAC9E,CAAC"}
+{"version":3,"file":"templates.js","sourceRoot":"","sources":["../src/templates.ts"],"names":[],"mappings":"AAAA,+BAA+B;AAC/B,mCAAmC;AAEnC,MAAM,CAAC,MAAM,UAAU,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiDzB,CAAC;AAEF,wDAAwD;AACxD,EAAE;AACF,2FAA2F;AAC3F,0FAA0F;AAC1F,2FAA2F;AAC3F,2FAA2F;AAC3F,+FAA+F;AAC/F,2FAA2F;AAC3F,2CAA2C;AAE3C,qGAAqG;AACrG,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAqDpC,CAAC;AAEF,iGAAiG;AACjG,MAAM,CAAC,MAAM,cAAc,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA4E7B,CAAC;AAEF;8BAC8B;AAC9B,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAqIpC,CAAC;AAEF;oFACoF;AACpF,MAAM,UAAU,YAAY,CAAC,KAAa;IACxC,0FAA0F;IAC1F,yFAAyF;IACzF,6FAA6F;IAC7F,OAAO,UAAU,CAAC,OAAO,CAAC,2BAA2B,EAAE,GAAG,EAAE,CAAC,UAAU,KAAK,GAAG,CAAC,CAAC;AACnF,CAAC;AAED;;;;4DAI4D;AAC5D,MAAM,UAAU,cAAc,CAAC,WAAmB,EAAE,QAAgB;IAClE,6FAA6F;IAC7F,4EAA4E;IAC5E,OAAO,qBAAqB,CAAC,OAAO,CAAC,qBAAqB,EAAE,GAAG,EAAE,CAAC,WAAW,CAAC;SAC3E,OAAO,CAAC,qBAAqB,EAAE,GAAG,EAAE,CAAC,QAAQ,CAAC;SAC9C,OAAO,CACN,oFAAoF,EACpF,yFAAyF,CAC1F,CAAC;AACN,CAAC;AAED;;;;8FAI8F;AAC9F,MAAM,UAAU,iBAAiB,CAAC,WAAmB,EAAE,QAAgB,EAAE,KAAa,EAAE,SAAiB;IACvG,qFAAqF;IACrF,wFAAwF;IACxF,4BAA4B;IAC5B,MAAM,MAAM,GAAG,cAAc,CAAC,OAAO,CAAC,gBAAgB,EAAE,GAAG,EAAE,CAAC,WAAW,CAAC;SACvE,OAAO,CAAC,gBAAgB,EAAE,GAAG,EAAE,CAAC,QAAQ,CAAC;SACzC,OAAO,CAAC,WAAW,EAAE,GAAG,EAAE,CAAC,SAAS,CAAC,CAAC,8DAA8D;SACpG,OAAO,CAAC,kFAAkF,EAAE,UAAU,CAAC;SACvG,OAAO,CAAC,+DAA+D,EAAE,GAAG,CAAC;SAC7E,OAAO,CAAC,gBAAgB,EAAE,KAAK,CAAC,CAAC,8DAA8D;QAChG,oEAAoE;SACnE,OAAO,CAAC,6FAA6F,EAAE,OAAO,CAAC;SAC/G,OAAO,CAAC,cAAc,EAAE,MAAM,CAAC,CAAC,qDAAqD;SACrF,OAAO,CAAC,wDAAwD,EAAE,OAAO,CAAC,CAAC,yBAAyB;SACpG,OAAO,CAAC,2DAA2D,EAAE,OAAO,CAAC,CAAC;IAEjF,OAAO,MAAM;SACV,KAAK,CAAC,IAAI,CAAC;SACX,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC;SACtC,IAAI,CAAC,IAAI,CAAC,CAAC;AAChB,CAAC;AAED;;;;;;;;4CAQ4C;AAC5C,MAAM,UAAU,oBAAoB,CAAC,WAAmB;IACtD,6FAA6F;IAC7F,0FAA0F;IAC1F,wCAAwC;IACxC,OAAO,qBAAqB,CAAC,OAAO,CAAC,kBAAkB,EAAE,GAAG,EAAE,CAAC,WAAW,CAAC,CAAC;AAC9E,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@milehimikey/em",
-  "version": "1.20.0",
+  "version": "1.21.0",
   "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.20.0",
+  "version": "1.21.0",
   "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.20.0",
+        "@milehimikey/em@1.21.0",
         "mcp"
       ]
     }

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

@@ -23,7 +23,8 @@ em render <file>                                                    # transpile
 em render <file> -o, --out <path>                                   # output path (extension picks the format)
 em render <file> -T, --format <fmt>                                 # output format (svg, png, pdf, ...)
 em render <file> --slice <name>                                     # render only this slice, redrawn in its own canonical pattern shape (default out: slices/<kebab-slug>.svg)
-em render <file> --storyline <name>                                 # render only this storyline: its slices in order, preceded by dimmed stub columns for what they read from outside it (and the end state of a storyline it comes `after`) (default out: storylines/<kebab-slug>.svg)
+em render <file> --storyline <name>                                 # render only this storyline: its own slices in order, nothing from outside it (default out: storylines/<kebab-slug>.svg)
+em render <file> --map                                              # render every storyline to storylines/<kebab-slug>.svg plus a draggable canvas of them all, with the flow between storylines, at storylines/map.html (-o picks the html path)
 em render <file> --emit-dot                                         # print the generated DOT instead of rendering
 em render <file> --keep-empty-lanes                                 # keep the API lane even when empty
 em export <file>                                                    # export a versioned JSON snapshot of the normalized model
@@ -71,6 +72,7 @@ em slice stub-all <file> --implemented-in <url>                     # PR/commit
 em slice stub-all <file> --dry-run                                  # list what would be stubbed/wired without writing anything
 em slice index <file>                                               # rewrite the model's sibling README.md's GENERATED Slices table from `em export`'s slice facts (key, pattern, doc status/implementedIn) — the hand-maintained table is deprecated
 em slice index <file> --check                                       # verify the table is current; exit non-zero on drift without writing (CI)
+em slice index <file> --full                                        # every lifecycle column (reviewed/ratified/owner/tracking/implemented/conformed) instead of the reader's five
 em slice mark-implemented <file> <slice-key> <pr-url>               # flip a slice doc's frontmatter to `status: implemented` / `implementedIn: <pr-url>` — the one edit an implementing agent makes to a ratified doc at merge (MIL-103, replaces the em-sdd-bridge `em-sdd-mark-implemented` script; see reference/implement.md §6). Applies only to a `ready-to-implement` doc (MIL-277: a `draft`/`reviewed` doc refuses — ratify first). Also records the shipped version beside the link (MIL-284): `shippedVersion:`, `shippedRef:` (the doc's `ratifiedRef:`, when it has one) and `shippedOn:`, and opens the next version as a `draft` when an Open Question was deferred to it (MIL-283). Idempotent on the same URL — also after that draft opened; refuses to overwrite a different one; never touches the doc body except to re-open those deferred questions
 em slice mark-implemented <file> <slice-key> <pr-url> --on <date>   # merge date recorded as `shippedOn:`, YYYY-MM-DD (default: today, local date; MIL-284)
 em slice mark-implemented <file> <slice-key> <pr-url> --json        # print a JSON document instead of text: { path, changed, implementedIn, nextDraft: { version, reopened[] } | null } (GH #285)
@@ -276,15 +278,25 @@ em mcp                                                              # start an M
 em skill install                                                    # copy the event-modeling skill bundle into .claude/skills/ (event-modeling, event-modeling-discover/-design/-implement/-conform/-review, event-modeling-shared); across a structural bundle change (e.g. the MIL-157 split of the old single event-modeling/ directory into this six-directory bundle), `em skill sync` is the migration path — --force now performs the same reconcile (MIL-180)
 em skill install -f, --force                                        # overwrite an existing installation, reconciling added/updated/removed files within the bundle's own managed directories the same way `em skill sync` does — never touching an unrelated sibling skill (MIL-180)
 em skill install --no-agents-md                                     # skip writing/updating the AGENTS.md agent-contract section (on by default, MIL-129)
+em skill install --skills-dir <dir>                                 # where the vendored skill bundle lives, relative to the repo root (default .claude/skills; .agents/skills when that exists and .claude/skills does not — GH #412)
+em skill install --agents-dir <dir>                                 # where the four em sub-agent definitions live, relative to the repo root (default .claude/agents, or .agents/agents beside an .agents/skills bundle — GH #412)
 em skill sync [path]                                                # update the vendored .claude/skills/ event-modeling skill bundle in [path] to match the installed em package (overwrites unconditionally; local edits are never merged, MIL-93)
 em skill sync [path] --no-agents-md                                 # skip writing/updating the AGENTS.md agent-contract section (on by default, MIL-129)
+em skill sync [path] --skills-dir <dir>                             # where the vendored skill bundle lives, relative to the repo root (default .claude/skills; .agents/skills when that exists and .claude/skills does not — GH #412)
+em skill sync [path] --agents-dir <dir>                             # where the four em sub-agent definitions live, relative to the repo root (default .claude/agents, or .agents/agents beside an .agents/skills bundle — GH #412)
 em skill check [path]                                               # check [path]'s em skills for drift against the installed em package: the em Claude Code plugin's pin (settings + this machine's marketplace registry) when the repo declares it, and the vendored .claude/skills/ bundle when present; exits non-zero on any mismatch (CI-ready, MIL-93, MIL-231)
 em skill check [path] --json                                        # print a JSON document instead of the text report (see docs/cli.md)
 em skill check [path] --ci                                          # also fail (exit 1) when the declared plugin is not registered on this machine (implied by CI=true in the environment); without it that finding prints the install commands on stderr and exits 0
+em skill check [path] --skills-dir <dir>                            # where the vendored skill bundle lives, relative to the repo root (default .claude/skills; .agents/skills when that exists and .claude/skills does not — GH #412)
+em skill check [path] --agents-dir <dir>                            # where the four em sub-agent definitions live, relative to the repo root (default .claude/agents, or .agents/agents beside an .agents/skills bundle — GH #412)
 em ci init <model>                                                  # install .github/workflows/em-ci.yml (PR gates: em validate, em slice index --check, em coverage --strict, em ledger, em skill check, em glossary --fail-on-conflicts, plus a push-triggered status-badge rebuild) and em-conform.yml (scheduled, advisory-only conformance cadence) — same install discipline as `em skill install`: marker-delimited, idempotent, --check for CI self-verification (MIL-166, see docs/ci.md). Give it a system.yaml (or its directory) instead of a model to cover every model in the system: one workflow, per-model jobs, a conform matrix (MIL-233)
 em ci init <model> --tests <dir>                                    # test directory the coverage/status steps scan for INV-* citations
 em ci init <model> -f, --force                                      # replace an existing workflow file that has no GENERATED markers, or a managed block generated for a different set of models
 em ci init <model> --check                                          # verify both files match the current preset; exit non-zero on drift without writing (CI)
+em storyline split <file>                                           # move each inline `storyline "X" { … }` block into its own storyline model file <slug>/<slug>.em (a `storyline "X" [source]` header, then the block's slices) and leave the one-line declaration `storyline "X" [after "Y"]` in the root (GH #421). Slice docs stay under the root's slices/. A storyline declared in several blocks is left alone (merge them first)
+em storyline split <file> --storyline <name>                        # split only this storyline
+em storyline split <file> --dry-run                                 # print what would be written without touching anything
+em storyline split <file> -f, --force                               # overwrite a storyline model file that already exists
 em storyline suggest <file>                                         # advisory (GH #290): propose `storyline` blocks for a model that has none — one per distinct slice `source "url"`, the remaining slices grouped by the view-instance chains (`again`) they feed — printed as a unified diff on stdout (apply with `patch -p1` or `git apply`); never writes the model
 em upgrade <file>                                                   # bring a model repo authored under an older em (1.6 forward) up to the installed version: an ordered list of mechanical steps (skill bundle, reaction shape, state-file bullets, generated CI blocks, constitution scaffold) plus a human list of things no command can safely decide by itself (MIL-219, see docs/upgrading.md). Dry-run by default; --apply makes one git commit per applicable step, refusing on a dirty working tree
 em upgrade <file> --apply                                           # apply every applicable mechanical step, one git commit each, then a final `Em version:` commit
@@ -311,12 +323,14 @@ context Name                     # an event swimlane row (bounded context / aggr
 storyline "Name" [source "url"] [after "Other"] {   # optional chapter grouping slices (see Storylines)
   slice "Name" { ... }
 }
+storyline "Name" [after "Other"] [in "path.em"]      # a storyline MODEL: its slices live in <slug>/<slug>.em (see Storylines)
 
 slice "Name" [source "url"] {    # one vertical time step (a column); source is optional
   ui   Free Text @Persona        # screen; @Persona picks its row (defaults to first/"User")
   command Free Text              # state-changing request (API band)
   invariant INV-ORD-1 "Rule"     # rule guarding the command/event just above (see Clauses)
   view Free Text from "Event A", "Event B"   # read model fed by event(s)
+  view Free Text from "Event A" updates from "Event B", "Event C"   # B, C keep rows current: read, never drawn (see Clauses)
   view Free Text again from "Event C"        # later instance of an evolving read model (see Clauses)
   event Free Text @Context       # recorded fact; @Context picks its row (defaults to "Domain")
   processor Free Text from "View"   # automation; aliases: automation | saga | translation
@@ -360,6 +374,14 @@ type Name { field: Type, ... }      # named structured type, reusable from any f
   previous instance of V that also reads E), and EVERY site needs a reader at or after it (add `view V again from "E"`
   after the last site, or `event-unread` warns for that site). The same name in a different context
   is still a `duplicate-name` warning.
+- **`updates from "Event", …`** (views only, GH #414): the subset of a view's sources that only keep a
+  row current or remove it (a due date moved, an address changed, a loan returned). They are folded
+  into the view's `from` for every check — `derived from`, completeness, the generated built-from
+  list — but never drawn as arrows: the diagram shows the line from the event that puts work on the
+  list, and lists the rest under "Kept current by". The author chooses the triggers: `view Holds To
+  Fulfill from "Hold Placed", "Tool Returned" updates from "Hold Collected", "Hold Cancelled"`.
+  Valid on an `again` instance too. A to-do view with more than one or two inbound arrows is missing
+  this split.
 - **`again`** (views only): `view <Name> again [from "Event", …]` declares a later instance of an
   already-declared read model — the forward-only device for a view that evolves as later events
   land. Instances are ONE logical view: the first declaration owns the `note` binding; each
@@ -550,8 +572,15 @@ type Name { field: Type, ... }      # named structured type, reusable from any f
   Slices keep their file-order timeline position; a slice outside any storyline is allowed;
   storylines don't nest and a repeated name continues that storyline (its slices join it; a continuation may not add or change
   `source`/`after` — parse error). The full render draws a
-  labelled band above the slice headers; `em render --storyline "Name"` draws one story alone, with the
-  elements it reads from outside as dimmed stub columns. `em export` carries `slice.storyline` and
+  labelled band above the slice headers; `em render --storyline "Name"` draws one story alone — its own
+  slices only, nothing from outside it — and `em render <root>.em --map` puts every story's real
+  diagram on one draggable canvas with the flow between stories (`after` thick, reads dashed and
+  labelled). **Storyline models (GH #421):** `storyline "Name" [after "Other"] [in "path.em"]` with no
+  body declares a storyline whose slices live in `<slug>/<slug>.em` — a file that starts with
+  `storyline "Name" [source "url"]` and holds slice blocks only — with its docs in `<slug>/slices/`;
+  the root is the compile unit (always give em the root), and `em storyline split <root>.em` turns
+  inline blocks into files, moving each story's docs. A storyline that reads another declares `after`
+  it (`storyline-reads-without-after`). `em export` carries `slice.storyline` and
   `model.storylines[]`; `em query slices --storyline`; `em slice index` adds a Storyline column. Once
   any storyline exists a slice outside every one is the advisory warning `slice-outside-storyline`.
   `after "<other>"` reads the storyline as if its slices followed the referenced storyline's last
@@ -877,6 +906,7 @@ not the prose above has caught up yet. `--slice-ready <key>`-only codes are excl
 <!-- GENERATED:validate-rules:start -- run `npm run docs:generate` to refresh, do not hand-edit -->
 | Code | Severity | Title | Fix |
 |---|---|---|---|
+| `again-restates-sources` | warning | Continuation restates sources an earlier instance already read | Name only the events that changed the view since the previous instance on the `again` line; the view's field sources are the union across instances, so nothing is lost (docs/dsl.md#view--again). |
 | `alternative-events-no-command` | error | Alternative events without a command | Add the command whose decision records one of the alternatives, in the same slice. |
 | `arrow-backward` | error | Backward arrow | Restructure so the target comes later. |
 | `arrow-unresolved-source` | error | Arrow source unresolved | Fix the arrow's source name. |
@@ -917,6 +947,7 @@ not the prose above has caught up yet. `--slice-ready <key>`-only codes are excl
 | `fields-completeness/view-field-no-source` | warning | View field with no source | Add the field to a source event, or remove it from the view. |
 | `frontmatter-coherence-implemented-without-link` | warning | Implemented without a link | Add `implementedIn` once the slice ships. |
 | `frontmatter-invalid` | warning | Invalid or missing frontmatter | Add the required frontmatter keys, or add a frontmatter block. |
+| `frontmatter-status-unrecognized` | warning | Unrecognized slice status | Set `status:` to one of draft, reviewed, ready-to-implement, implemented. |
 | `grid-collision` | error | Band collision | Split the colliding elements into separate slices. |
 | `invariant-without-scenario` | warning | Invariant cited by no scenario | Cite the INV id in the Given/When/Then (or title) of the scenario that exercises it, or add one. |
 | `invariants/declared-in-both` | warning | Invariant declared in the model and in a slice doc | Keep the model's `invariant` line; in the doc, cite the ID and elaborate instead of restating it as a `**INV-…:**` rule. |
@@ -960,6 +991,7 @@ not the prose above has caught up yet. `--slice-ready <key>`-only codes are excl
 | `storyline-after-cycle` | error | Storyline `after` cycle | Remove an `after` clause so no storyline comes after itself. |
 | `storyline-after-out-of-order` | error | Backward timeline (storyline declared above the one it comes after) | Move the storyline block below the storyline it comes `after`, or restructure the feed. |
 | `storyline-after-unknown` | error | `after` names an unknown storyline | Name a storyline declared in this model, or drop the `after` clause. |
+| `storyline-reads-without-after` | warning | Storyline reads another without declaring `after` it | Add `after "<the storyline it reads>"` to the reading storyline (or to one between them); if the two stories are parallel on purpose, accept it on the shape exit gate (docs/storyline.md). |
 | `system-manifest-invalid` | error | Seam manifest invalid | Fix the manifest: `systemSchemaVersion: "2.0"`, `models:` with a readable `source` per model, and nothing else (`seams:`/`owner:` moved into the models — run `em upgrade`). |
 | `system-manifest-outdated` | warning | Seam manifest is schema 1.0 | Run `em upgrade <model>.em --apply` once: it moves `seams:` into `consumes` clauses and `owner:` onto each model header, and rewrites the manifest to 2.0. |
 | `system-model-key-mismatch` | error | Manifest model key differs from the export's `model.key` | Rename the manifest's `models:` key to the computed key the message prints. |

package/plugin/shared/reference/methodology.md

@@ -219,7 +219,11 @@ drift into **CRUD laid on a timeline**; these rules stop that. Quoted lines are
   reorganize are **secondary storylines** (chapters; Dilger: "one linear flow from left to right. No
   exceptions… Linearize it!", "Model one process at a time, each with its own clear ending"). Never one
   lifecycle block per entity. Name the main and every secondary storyline; a `storyline "Name" { … }`
-  block groups the slices (`dsl.md`, Storylines).
+  block groups the slices (`dsl.md`, Storylines). **A storyline is the unit a reader consumes, so it
+  is the unit an author edits too (GH #421):** the root model lists the storylines and their flow
+  (`storyline "Name" [after "Other"]`), and each story's slices live in `<slug>/<slug>.em` with its
+  docs in `<slug>/slices/`. Draft with inline blocks if that is faster, then `em storyline split
+  <root>.em` once the storylines are named — before docs are wired, so nothing moves twice.
 - **Build from walkthroughs first.** The story already lives in the spec's walkthroughs, use cases and
   user journeys. Build the timeline from those; the resource/API reference (OpenAPI, endpoint tables,
   migrations) fills only the operations no walkthrough touches, and is read last. Headless: a persona
@@ -333,12 +337,41 @@ drift into **CRUD laid on a timeline**; these rules stop that. Quoted lines are
   `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.
+  **Then split what is left into trigger and housekeeping** (Dilger: show the line from the event
+  that triggers the automation, not every event that touches its read model; GH #414). Of the
+  events a view legitimately reads, only the ones that **put work on the list** are the story — they
+  go in `from` and are drawn. Every event that merely **keeps a row current or removes it** (a due
+  date moved, an address changed, a loan returned) goes in `updates from`: still a source for
+  `derived from`, completeness and the generated built-from list, never an arrow. Write the to-do
+  list as `view Overdue Loans To Notify from "Tool Checked Out" updates from "Loan Extended",
+  "Neighbor Email Changed", "Tool Returned"`. The author chooses the triggers — `Holds To Fulfill`
+  keeps two (`from "Hold Placed", "Tool Returned"`) because both put a fulfillable hold on the
+  list. **Per-view check:** *which of these events is the reason this row appears? That is `from`;
+  everything else is `updates from`.* The render's "Kept current by" legend is the readback: if a
+  to-do view shows more than one or two inbound arrows, the split is missing. A State View that is
+  not a to-do list gets the same treatment — its screen's story is the event that creates the row.
 - **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
   two slices record the same fact, repeat the event bare (same name, same context). *(em ruling)*
 - **Repeat the view after every command that changes it** (`again`, span-1 — see State View above), so
-  the reader sees the information arrive rather than a view at the end.
+  the reader sees the information arrive rather than a view at the end. **A continuation names only
+  what changed:** `view X again from "E"` lists the event(s) that changed the view since the previous
+  instance — never the originating instance's whole source list again. Field sources are the union
+  across instances, so restating loses nothing and only draws the same arrows twice;
+  `again-restates-sources` (GH #424) is the mechanical half.
+- **Storylines read as stories** (owner rulings 2026-11-03, after Dilger). (1) **A storyline that reads
+  another declares `after` it:** an event of story A feeding a view of story B means B comes after A
+  in the telling — write `storyline "B" after "A"` (or on a storyline between them); two stories that
+  really run in parallel read nothing from each other. `storyline-reads-without-after` (GH #420) is
+  the mechanical half. (2) **Review each story on its own render and on the canvas, never on the
+  full timeline:** `em render <root>.em --map` draws every storyline's real diagram as a frame with
+  the flow between stories (`after` thick, reads dashed and labelled by event); the full timeline is
+  for `em diff` and ordering checks, not for reading. A storyline render shows only the storyline —
+  nothing from outside it is drawn, so an inbound arrow you miss there is a connector on the canvas.
+  (3) **Housekeeping is not drawn** (`updates from`, above) and **continuations name only what
+  changed** (above): together these are what keeps a story's render to one line per cause. *(em
+  ruling, built on Dilger's "the line from the event that triggers it")*
 - **Outcomes are events of one slice** (Dilger: "One decision. One event. One state change."; one
   action with two outcomes is the legitimate exception): alternative events on one context in one slice
   (`event A | B @Ctx`, GH #278), failure as a scenario first, a chapter only when core (it changes what the user does next, or has

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

@@ -57,7 +57,7 @@ to decide `frontmatter-invalid` without re-deriving frontmatter-shape rules of i
 | `schemaVersion` | integer | `1` (current dialect version) | its *value* is not read back by any `em` command today (reserved) — but its *presence* is required by `hasUsableFrontmatter()`: a doc omitting it is `frontmatter-invalid` (see below) |
 | `pattern` | string | `state-change` \| `state-view` \| `automation` \| `translation` | authored/informational only — `em catalog` and `em export` both derive pattern from the `.em` AST instead (`em export`'s `slice.pattern`, schema `1.4`) |
 | `swimlane` | string | free text, `<Persona> → <Context>` | display-only |
-| `status` | string, case-insensitive | `draft` \| `reviewed` \| `ready-to-implement` \| `implemented` | written by `em slice review` (→ `reviewed`, MIL-201), `em slice ratify`/`em slice reratify` (→ `ready-to-implement`) and `em slice mark-implemented` (→ `implemented`); read by `em catalog`, `em render`/`em watch` header coloring; joined into `em export`'s `slice.doc.status` (schema `1.4`); paired with `implementedIn` to compute `slice.doc.driftSignal` (schema `1.5`, MIL-85) and `em validate`'s frontmatter-coherence check (MIL-85 — see [validation.md#frontmatter-coherence](https://github.com/milehimikey/em/blob/main/docs/validation.md#frontmatter-coherence)) |
+| `status` | string, case-insensitive | `draft` \| `reviewed` \| `ready-to-implement` \| `implemented` | written by `em slice review` (→ `reviewed`, MIL-201), `em slice ratify`/`em slice reratify` (→ `ready-to-implement`) and `em slice mark-implemented` (→ `implemented`); read by `em catalog`, `em render`/`em watch` header coloring; joined into `em export`'s `slice.doc.status` (schema `1.4`); paired with `implementedIn` to compute `slice.doc.driftSignal` (schema `1.5`, MIL-85) and `em validate`'s frontmatter-coherence check (MIL-85 — see [validation.md#frontmatter-coherence](https://github.com/milehimikey/em/blob/main/docs/validation.md#frontmatter-coherence)); any other value is read as written but `em validate` warns `frontmatter-status-unrecognized` (GH #411) |
 | `version` | integer | positive integer, starts at `1` | joined into `em export`'s `slice.doc.version` (schema `1.4`, MIL-91) |
 | `implementedIn` | string | free text (PR/commit link) | joined into `em export`'s `slice.doc.implementedIn` (schema `1.4`, MIL-91); paired with `status` to compute `slice.doc.driftSignal` (schema `1.5`, MIL-85) and `em validate`'s frontmatter-coherence check (MIL-85 — see [validation.md#frontmatter-coherence](https://github.com/milehimikey/em/blob/main/docs/validation.md#frontmatter-coherence)) |
 | `split-from` | single ref | `<slice-key>@v<N>` | joined into `em export`'s `slice.doc.splitFrom` (schema `1.4`, MIL-91) and `em diff`'s `slice-added` entries (schema `1.6`, MIL-84); current-tree referential checks by `em validate` (MIL-84 — see [validation.md#lineage](https://github.com/milehimikey/em/blob/main/docs/validation.md#lineage)) |
@@ -473,6 +473,7 @@ re-run `em slice sync`.
 
 | Region | Section | Body |
 |---|---|---|
+| `em-slice-story` | right under `![Diagram](…)` | one line: `Step N of M in **<Storyline>** · after <Prev> · before <Next> · <Pattern>` (Prev and Next link to the neighbouring slices' docs; a continuation neighbour is named, not linked) — where the slice sits in its story; the one region `em slice sync` inserts when missing on an unsigned doc (see `em slice sync` in the CLI reference) |
 | `em-slice-command` | `## Command / Input` | `**Command:** \`Name\`` + `\| Field \| Type \| Required \| Rules / Validation \|` (Required is `no` for a `name?: Type` field) |
 | `em-slice-event` | `## Event(s) Emitted` | `**Event:** \`Name\` → context \`Ctx\`` + `\| Field \| Type \| Immutable Fact? \| Source / Notes \|` (Source: the same-slice command field it is copied from; failing that, the command from another slice that also records the event, written `not supplied by this command (from \`A\`, slice "Create")` (GH #344 / #362, the same union `fields-completeness/event-field-no-source` checks; worded as a statement about this slice, since the repeat's own command does not take the field); `assigned` for a system-assigned field, else `{{ }}`) |
 | `em-slice-view` | `## Read Model / View` | `- **View:** \`Name\` built from events: …` (the union across the originating and every `again` instance; each later event is annotated `(via "<slice>")` with the slice of the instance that adds it) + `\| Field \| Type \| Source / Notes \|` (Source: the source event, from that union, carrying the field, `Derived` for a `derived` field, `Collection of \`T\`, fed by …` for a `T[] derived from …` field — followed by one neutral Given/Then scenario stub per named event under the table, to copy into `## Scenarios` and complete there (the region itself stays read-only); `em slice sync` retires a stub once an authored scenario covers that field and event, by the stub's `<field> after <Event>` title or by a Given naming the event with the field named in the block (GH #368), and drops the `Scenario stubs for` line when none is left — else `{{ }}`) |

package/plugin/shared/templates/model-readme.md

@@ -32,14 +32,22 @@ Change slice is paired with the State View slice that projects its event. A read
 along the timeline (`view X again`) shows the same projection at a later point; the instances are
 never connected to one another.
 
+## Storylines
+<!-- Generated — `em slice index {{model-name}}.em` writes one row per storyline between the
+     markers (count, implemented, diagram); the canvas is `em render {{model-name}}.em --map`. -->
+<!-- GENERATED:storylines:start -->
+| Storyline | Slices | Implemented | Diagram |
+|-----------|--------|-------------|---------|
+<!-- GENERATED:storylines:end -->
+
 ## Slices
 <!-- The canonical slice index — the ONE place slices are enumerated (the state file
      points here rather than keeping its own copy). Generated — run
      `em slice index {{model-name}}.em` to (re)write the table below from the model and its
      slice docs; never hand-edit between the markers. -->
 <!-- GENERATED:slices:start -->
-| # | Slice | Pattern | Status | Reviewed by | Ratified by | Owner | Tracking | Implemented in | Design doc |
-|---|-------|---------|--------|-------------|-------------|-------|----------|----------------|------------|
+| # | Slice | Pattern | Status | Design doc |
+|---|-------|---------|--------|------------|
 <!-- GENERATED:slices:end -->
 
 ## Status

package/plugin/shared/templates/slice.md

@@ -80,6 +80,10 @@ implementedIn: {{PR/commit link — fill in once status is `implemented`}}
 
 ![Diagram](./{{slice-name}}.svg)
 
+<!-- GENERATED:em-slice-story:start — generated from the model by `em slice sync`; do not hand-edit -->
+_Run `em slice sync` to place this slice in its story._
+<!-- GENERATED:em-slice-story:end -->
+
 <!-- Only on re-ratification of an already-`implemented` slice — omit this whole section on a
      slice's first version (v1 has no delta yet). The heading is always the literal `## Delta`,
      never `## Delta: vX → vY` — hop metadata is a display line inside the section instead (see
@@ -170,7 +174,9 @@ an event directly.}}
      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. -->
+     reads to enforce its own invariants. Fix the `.em`, not the prose. The built-from list names
+     every source, trigger and housekeeping alike; in the `.em` only the triggering event(s) sit in
+     `from`, the rest in `updates from` (methodology reference, "trigger and housekeeping"). -->
 <!-- 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/plugin/skills/conform/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: conform
-em-version: 1.20.0
+em-version: 1.21.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/plugin/skills/design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: design
-em-version: 1.20.0
+em-version: 1.21.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
@@ -72,7 +72,13 @@ Goal: a structurally complete, **validated** model with correct patterns and swi
    optional `after "<storyline>"` timeline clause: `em-dsl.md`) so the diagram gets a band per
    story and `em render --storyline "Name"` can show one alone; slices keep their file order, and
    a model can adopt storylines incrementally (`slice-outside-storyline` is only an advisory
-   warning) — but name them before you slice, not after. Then group events into **contexts** (bounded contexts /
+   warning) — but name them before you slice, not after. **Once the storylines are named, give
+   each its own file** (GH #421): run `em storyline split <root>.em` so the root keeps the
+   vocabulary and the storyline list with its flow (`storyline "Name" [after "Other"]`) and each
+   story's slices live in `<slug>/<slug>.em` with its docs in `<slug>/slices/` — do this before any
+   doc is wired, so nothing moves twice. **A storyline that reads another story's events declares
+   `after` it** (`storyline-reads-without-after` flags the ones you miss); two stories that run in
+   parallel read nothing from each other. Then group events into **contexts** (bounded contexts /
    aggregates) — ask which events share a consistency boundary and who owns them. Classify each
    slice as one of the 4 patterns. **Share the slice between every automation or translation and
    the command it triggers** (the reaction — processor/translation — together with the command
@@ -92,17 +98,26 @@ Goal: a structurally complete, **validated** model with correct patterns and swi
    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
-   `${CLAUDE_PLUGIN_ROOT}/shared/reference/methodology.md`, "Views as lookups"), and the
+   `${CLAUDE_PLUGIN_ROOT}/shared/reference/methodology.md`, "Views as lookups"), then the
+   **trigger / housekeeping split** on what is left (*which event is the reason this row appears?*
+   that one stays in `from`; every event that only keeps a row current or removes it moves to
+   `updates from` — the view still reads it, the diagram no longer draws it; a to-do list with more
+   than one or two inbound arrows is missing this split), the **continuation check** per `view X
+   again` (it names only the events that changed the view since the previous instance, never the
+   first instance's list again), 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`, `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,
+   mean two intents in one command: split it). Read each story on its own render and on the canvas
+   (`em render <root>.em --map`), not on the full timeline. The `timeline-entity-clustered`,
+   `command-second-intent`, `automation-split-by-outcome`, `view-lookup-source`,
+   `again-restates-sources` and `storyline-reads-without-after` lints are the
+   mechanical half (the lookup one only catches the cross-context cases — do the check by eye too); the
+   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
    slice, none skipped: `em slice new "<slice name>" --pattern <state-change|state-view|
    automation|translation> --swimlane "<Persona> → <Context>" --wire <model>.em` writes
-   `slices/<slice-name>.md` at `status: draft` (the same command, flags, and `--wire`
+   `slices/<slice-name>.md` at `status: draft` (into the slice's own storyline folder when the model
+   is split — pass the ROOT model to `--wire`) (the same command, flags, and `--wire`
    note-binding the `slice` phase's step 2 below documents in full). A slice whose only element
    is a `view X again` instance is a **continuation** (MIL-208), not a slice to scaffold —
    `--wire` refuses it and names the originating slice holding `X`'s first declaration; its

package/plugin/skills/discover/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: discover
-em-version: 1.20.0
+em-version: 1.21.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
@@ -69,7 +69,7 @@ Goal: a draft model of events, storyboard, commands, and views. Loose is OK; str
    **Close the loop before leaving this step:** every event from step 3 must be read by at least one
    read model. Walk the event list and ask, for each one, *"who looks at this, and what do they do
    with it?"* An event with no answer is either missing its read model or shouldn't be recorded —
-   both are worth raising with the user rather than leaving dangling.
+   both are worth raising with the user rather than leaving dangling. Keep the draft in one file with inline `storyline` blocks; the design phase splits it into one file per story (`em storyline split`) once the names are settled.
 
 End of phase: write/refresh the `.em`, render it, update `.event-modeling.md` (steps done,
 decisions, open questions — run `em state set-phase model` rather than hand-editing `Current

package/plugin/skills/discover/reference/extract.md

@@ -104,7 +104,11 @@ it is fine to finish a round with `# TBD`s still parked.
   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
   (`../../../shared/reference/methodology.md`, "Views as lookups") once the as-is
-  model is agreed.
+  model is agreed. **Housekeeping handlers are `updates from`, as-is:** when the projection code
+  handles an event only to update or delete a row it already holds (a status flip, a due date
+  moved, an address changed, a row removed), write that event in `updates from "…"`, not `from` —
+  that is what the code does today, it keeps the field tracing complete, and the as-is render then
+  shows the one line that puts work on the list instead of every handler.
 - **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/plugin/skills/engagement/SKILL.md

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

@@ -1,6 +1,6 @@
 ---
 name: event-modeling
-em-version: 1.20.0
+em-version: 1.21.0
 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.20.0
+em-version: 1.21.0
 description: >-
   Use when building a single ratified event-modeling slice (status: ready-to-implement) into
   merged, tested code — the one phase where the agent builds rather than facilitates. Gates on

package/plugin/skills/review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: review
-em-version: 1.20.0
+em-version: 1.21.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
@@ -16,8 +16,16 @@ description: >-
 Start the watcher with `--serve` in the background:
 `em watch <model-name>.em -o <model-name>.svg --serve` (run_in_background). It re-renders on every
 save and pushes an instant reload to the browser over Server-Sent Events. Tell the user to open the
-URL it prints (e.g. `http://localhost:5173/?svg=<model-name>.svg`) and share their screen — updates
-appear the moment you save, with no polling and no idle churn between edits.
+URL it prints and share their screen — updates appear the moment you save, with no polling and no
+idle churn between edits.
+
+What that URL opens depends on the model. A model that declares storylines opens on the
+**storyline canvas** (`http://localhost:5173/map`): every storyline's own diagram in a draggable
+frame, the flow between storylines drawn between frames, reloaded live on every save with the
+layout kept. A frame's **open ›** drills into that storyline — the viewer on its own slices and
+nothing from outside it — and **‹ Storylines** in the header returns to the canvas. A model
+without storylines opens on the timeline (`http://localhost:5173/?svg=<model-name>.svg`). Never
+send a room to the full timeline of a storyline model; the storyline is the unit people read.
 
 The viewer navigates like a map — drag to pan, scroll/pinch to zoom, **Fit** to reset — and its
 **Review mode** steps through slices one at a time (see the `review` phase below). A save that
@@ -35,10 +43,14 @@ speculation.** Don't propose this phase proactively; it exists for facilitated r
 non-engineer stakeholders in the room, not routine model editing.
 
 Start the same live server as `watch`: `em watch <model-name>.em -o <model-name>.svg --serve`
-(run_in_background). Open the printed URL, click **Review mode** in the header, and share the
-screen. Use Prev/Next (or the left/right arrow keys) to step through slices in declaration
-order — each one pans/zooms into view with everything else dimmed, so the room's attention
-tracks one slice at a time.
+(run_in_background). Open the printed URL and share the screen. With storylines, review one
+storyline at a time: open it from the canvas (or start inside it with `--storyline "<name>"`),
+then click **Review mode** in the header — Prev/Next walk that storyline's slices only. Between
+storylines, **‹ Storylines** returns to the canvas, where the arrows between frames are the
+order to take them in. Without storylines, click **Review mode** on the timeline. Use Prev/Next
+(or the left/right arrow keys) to step through slices in declaration order — each one
+pans/zooms into view with everything else dimmed, so the room's attention tracks one slice at
+a time.
 
 **When a State View slice is on screen, ask who reads it (MIL-215):** a person or client in the
 room → the `ui` should draw it; another system → `public`; only an automation → nothing, it's