@milehimikey/em 1.4.0 → 1.5.0

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

@@ -48,11 +48,31 @@ validation rules) before doing real work — they are the source of truth. Templ
   triggers **no** command — the analog of `view → ui`). **Repeat read models** across slices so the
   timeline flows left-to-right — put each repeat **right after the event that feeds it**, sourcing
   only that one adjacent event, so every arrow is short (a read model far from its source events
-  draws long arrows that look like a forbidden read→read link). Repeats render cleanly — em only
-  warns on a duplicate name that's *referenced* by `from`/`arrow`. Slice order matters: a reaction
-  must be directly followed by its command slice, and a read slice must not be immediately
+  draws a long arrow whose head lands columns away, making the *write* slice read as dangling —
+  keep a sub-flow that detours into another context together, not parked at the end of the model).
+  Declare every instance after the first with
+  **`view X again from "..."`** — `again` instances are exempt from the duplicate-name warning even
+  when referenced, and each reference resolves to the right instance. Slice order matters: a
+  reaction must be directly followed by its command slice, and a read slice must not be immediately
   followed by a command slice (see `em-dsl.md`).
   See `reference/methodology.md` (State View) and `reference/em-dsl.md`.
+- **Never connect two instances of one read model.** The repeat is a timeline device, not a flow:
+  continuity is implied by the shared name, and the events arriving at each instance are what show
+  it changing. An arrow between instances says the read model feeds itself, and is an error.
+- **Every slice is a COMPLETE pattern, never a half-slice.** A State Change is
+  `ui → command → event`; a State View is `event → read model → ui` (or `→ reaction`). So: a
+  command needs something that **triggers** it (the `ui` it's issued from, or the reaction in the
+  slice before it), its event needs a **reader**, and that read model needs a **consumer** of its
+  own. A command nothing points at is a write nobody can start; an event nothing projects is a
+  write nobody can see; a read model nothing displays is information dropped on the floor. Write
+  the whole chain together rather than sweeping up dangling ends later. Reactions don't count as
+  readers of *events* — they read views. **Every instance** of a repeated read model needs its own
+  consumer: if you repeat a view next to an event just to keep the arrow short, bring its screen
+  along, or don't add the instance.
+- **Only six connections are legal:** `ui → command`, `command → event`, `event → read model`,
+  `read model → ui`, `read model → reaction`, `reaction → command`. Reaching for anything else —
+  above all `command → read model` (the CQRS violation) or `read model → command` — means the model
+  is missing an **element**, not an arrow.
 - **Validate continuously.** Run `em validate` and fix errors/warnings as you go (see DSL ref).
 - **Save state at the end of every session** so work resumes cleanly.
 
@@ -117,12 +137,20 @@ phase applies to field tables, below.
    **callers** at each step instead; they become the inbound write translations and read
    translations (see `reference/methodology.md`).
 3. **Inputs (step 3).** For each event, find the **command** that causes it (imperative name).
-   Form `command → event` slices (State Change pattern).
+   Form `command → event` slices (State Change pattern). Every command needs a **trigger** in the
+   same breath: the screen the user issues it from (a `ui` in the slice), or — for the Automation
+   and Translation patterns — the reaction in the slice before it. A command nothing points at is
+   a write nobody can start. *"Who does this, and where are they when they do it?"*
 4. **Outputs (step 4).** Identify the **read models / views** consumers need and wire them with
-   `from "Event"` (State View pattern). In a **headless/API** model there is no UI — a read model is
+   `from "Event"` (State View pattern), each with the screen (or reaction) that consumes it — a
+   read model nothing displays is information dropped on the floor. In a **headless/API** model there is no UI — a read model is
    consumed by an **external read translation** (the API query, triggers no command), and read
-   models are **repeated** in each slice where they're read so the timeline flows (see
-   `reference/methodology.md`).
+   models are **repeated** in each slice where they're read (use `view X again` after the first) so
+   the timeline flows (see `reference/methodology.md`).
+   **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.
 
 End of phase: write/refresh the `.em`, render it, update `.event-modeling.md` (steps done,
 decisions, open questions) and `README.md`'s slice index. Tell the user they can stop here and
@@ -164,12 +192,17 @@ Goal: a structurally complete, **validated** model with correct patterns and swi
    event).
 2. **Elaborate scenarios — first pass (step 6).** For each slice, capture the happy-path
    Given/When/Then and the obvious invariants as short notes. (The full spec is the `slice` phase.)
-3. **Evaluate completeness (step 7).** Walk the model: every command emits an event, every view
-   has a source, no orphan events, every UI is reachable, automations **and translations** split
-   correctly (each reaction triggers a command — none wired straight to an event). Run
-   `em validate` and resolve all errors and warnings — but check the reaction→command→event split
-   by hand, since `em validate` does **not** flag a translation/automation that emits an event
-   directly (see `reference/em-dsl.md`).
+3. **Evaluate completeness (step 7).** Walk the model: every slice is a **complete** pattern, not a
+   half-slice — **every command has something that triggers it**, every command emits an event,
+   **every event is read by a read model**, **every read model has a consumer**, every view has a
+   source, every UI is reachable, every connection is
+   one of the six legal pairs, and automations **and translations** split correctly (each reaction
+   triggers a command — none wired straight to an event). Run `em validate` and resolve all errors
+   and warnings — but check the reaction→command→event split by hand, since `em validate` does
+   **not** flag a translation/automation that emits an event directly (see `reference/em-dsl.md`).
+   For an unread event, don't just bolt on a view to silence the warning: ask the user who looks at
+   this fact and what they do with it. The honest answers are "here's the read model we missed" or
+   "nobody — so why are we recording it", and both improve the model.
 
 End of phase: render, update state, suggest `/event-modeling slice` to write implementation specs.
 
@@ -181,7 +214,9 @@ timeline). Check `README.md`'s slice index for what's already done.
 This is also where **branch / unhappy-path events** are discovered and added to the model — as a
 slice's alternate/error flows surface (a rejection, removal, cancellation, decline, expiry), add
 the corresponding event/slice to the `.em` and re-render. The happy-path spine from earlier
-phases is the starting point, not the finished event set.
+phases is the starting point, not the finished event set. **Every new event needs its reader too**
+— a rejection or cancellation that nothing projects will warn, and usually the missing piece is
+real (someone has to see that the request was declined).
 
 For each slice:
 1. Hold a Socratic deep-dive to fill every section of `templates/slice.md`: intent, trigger/actor,
@@ -241,8 +276,19 @@ editing of `live.html` is needed — the `?svg=` query picks the model.
 ## Phase: `validate`
 
 Run `em validate <model-name>.em` and walk through each diagnostic with the user, explaining the
-rule (see `reference/em-dsl.md`) and proposing the fix (e.g. split an automation's command into
-the next slice, add a missing `from`, give a command its event). Apply fixes on agreement.
+rule (see `reference/em-dsl.md`) and proposing the fix. Apply fixes on agreement. Common ones:
+
+| Diagnostic | Fix |
+|---|---|
+| automation/translation shares a slice with a command | Split the command into the next slice |
+| **command has nothing that triggers it** | Add the `ui` it's issued from — or, if the system issues it, the reaction in the slice before it. Ask *"who does this, and where are they when they do it?"* |
+| **read model has no consumer** | Add the screen that displays it, or the reaction that watches it. If it's a repeat added only to shorten an arrow and nothing looks at it there, drop the instance |
+| read model has no source | Add the missing `from "Event"` |
+| command produces no event | Give the command its event, or drop the command |
+| **event is not read by any read model** | Add the read slice that projects it — but ask *who looks at this and what do they do with it* first. "Nobody" is a real answer, and then the question is why it's recorded at all |
+| **illegal `arrow` kind pair** | Don't reroute it — the model is missing an element. `command → view` needs the event between them; `view → command` needs a reaction. Between two instances of one read model, just delete the arrow: the repeat needs no connection |
+| `view X again` with no earlier declaration | Declare the view plainly the first time it appears |
+| event feeding an earlier view instance | Add a `view X again` where the event lands and move the source there |
 
 For anything genuinely unresolved rather than a rule violation, prefer `issue "text"` on the
 relevant element over a `# TBD` comment — it shows up as a red marker on the rendered diagram and

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

@@ -135,7 +135,9 @@ what every finding in the report will cite — file paths, not vibes.
 First `em validate <model-name>-asis.em`. `em diff` refuses when either side has validation
 *errors* (warnings are fine), so a scratch model that doesn't compile stops the run cold. The
 usual cause is a slice that depends on one you rewrote incompletely — a `view X again` whose
-first declaration you dropped, or an automation `from` a read model that no longer exists.
+first declaration you dropped, an automation `from` a read model that no longer exists, or an
+`arrow` you wrote joining kinds the patterns don't connect. (An unread event is only a *warning*,
+so it never blocks the diff — and in an as-is scratch model it's expected.)
 Seeding from the canonical model (step 2) prevents this; if it still fails, **fix the scratch
 model and report the failure as a tooling problem in the run metadata — never as drift.** A
 model you couldn't compile is an uncertainty about your own scratch file, not a finding

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

@@ -64,9 +64,10 @@ arrow From Element -> To Element    # explicit cross-slice edge (overrides infer
 - **`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
-  instance's `from` lists only the NEW events landing at that point (not cumulative); instances are
-  linked left-to-right with a continuity arrow; a reaction (`from "View"`) reads the nearest
-  instance at-or-before its own slice. `again` with no earlier declaration is a validation error.
+  instance's `from` lists only the NEW events landing at that point (not cumulative); a reaction
+  (`from "View"`) reads the nearest instance at-or-before its own slice. Instances are NEVER
+  connected to one another — continuity is implied by the shared name, and the events reaching each
+  instance are what show the view changing. `again` with no earlier declaration is a validation error.
   Use `again` (not a plain repeated `view` name) whenever the view is referenced by a
   `from`/`arrow` — plain repeats are only warning-free while unreferenced.
 - **`note "path.md"`** on ANY element links a markdown doc. Relative to the `.em` file. Renders as
@@ -106,7 +107,7 @@ slice "Open Orders" {
   ui Order List @Customer
 }
 
-# 3. Automation: split across TWO slices
+# 3. Automation: split across TWO slices (plus the read slice that consumes the event)
 slice "Orders To Fulfill" {
   view Orders To Fulfill from "Order Placed"
   processor Fulfillment Service
@@ -115,6 +116,10 @@ slice "Ship Order" {            # the triggered command goes in the NEXT slice
   command Ship Order
   event Order Shipped @Shipping
 }
+slice "Open Orders — shipped" {
+  view Open Orders again from "Order Shipped"   # every event needs a reader
+  ui Order List @Customer                       # ...and every read model needs a consumer
+}
 
 # 4a. Translation (external trigger): external input -> translation -> command -> event
 slice "Carrier Webhook" {
@@ -124,8 +129,17 @@ slice "Confirm Delivery" {            # the triggered command goes in the NEXT s
   command Confirm Delivery
   event Delivery Confirmed @Shipping
 }
+slice "Open Orders — delivered" {
+  view Open Orders again from "Delivery Confirmed"
+  ui Order List @Customer
+}
 
 # 4b. Translation (internal trigger): read model -> translation -> command -> event
+slice "Accept Quote" {
+  ui Quote Screen @Customer     # every command needs a trigger: a ui, or a reaction before it
+  command Accept Quote
+  event Quote Accepted @Quote
+}
 slice "Quotes To Sync" {
   view Accepted Quotes from "Quote Accepted"
   translation CRM Sync                # reacts to our own state via the read model in this slice
@@ -134,40 +148,66 @@ slice "Record Sync" {
   command Record Crm Sync
   event Quote Synced @Quote
 }
+slice "Accepted Quotes — synced" {
+  view Accepted Quotes again from "Quote Synced"
+  ui Sync Status @Customer
+}
 ```
 
 A `translation` (like a `processor`) is a **reaction**: it triggers a command and never carries an
 `event` in its own slice. Same two-slice split as the Automation pattern above.
 
+Note the read slice closing each pattern: **every event must be read by some read model**
+(warning 4 below). A command slice is not finished until the slice that projects its event
+exists. Reactions don't count — they read *views*, not events.
+
 ### Headless / API systems (no UI) & repeated read models
 
 When the system is headless (no UI — clients call an API), drop `ui`/`persona` entirely:
 
+A slice body is always multi-line — there is **no one-line `slice "X" { … }` form**, and writing
+one is a parse error (`'slice' is not valid inside a slice`).
+
 ```em
 # Write: external translation -> command -> event (name the inbound adapter for the caller/role)
-slice "Create Quote (request)" { translation SalesRep BU Create Quote }
-slice "Create Quote"           { command Create Quote  event QuoteCreated @Quote }
+slice "Create Quote (request)" {
+  translation SalesRep BU Create Quote
+}
+slice "Create Quote" {
+  command Create Quote
+  event QuoteCreated @Quote
+}
 
-# Read: event(s) -> read model -> READ translation (the external caller's API query, replaces UI)
-slice "Read Quote — created"   { view Quote from "QuoteCreated"  translation SalesRep BU Read Quote }
+# Read: event(s) -> read model -> READ translation (the external caller's API query, replaces UI).
+# This slice is also what makes QuoteCreated a *read* event — without it the model warns.
+slice "Read Quote — created" {
+  view Quote from "QuoteCreated"
+  translation SalesRep BU Read Quote
+}
 ```
 
 - A **read translation triggers no command** (it returns data outbound) — it is the headless analog
   of `view → ui`, *not* a reaction. Only *reaction* translations/processors trigger commands. A read
   slice has no `command` and no `event`, so `em validate` stays quiet about it.
-- **Repeat the read model** in every slice where it's read so the timeline flows left-to-right.
-  Recurring `view`/`translation` names **render cleanly and stay warning-free** as long as nothing
-  references the repeated name via `from`/`arrow` (the duplicate-name warning fires only for a
-  *referenced* duplicate, resolving to the first). **Wire each event to a read model exactly once:**
-  a repeated instance's `from` lists only the **new** events since the previous instance (not
-  cumulative), or the event draws a duplicate arrow to the same read model at every repeat. (An
-  event may still feed several *different* read models, once each.) When a repeated view **must be
-  referenced** — e.g. a reaction reads it via `from` — declare its later instances with
-  `view X again` instead (see Clauses); instances resolve properly and draw continuity arrows.
+- **Repeat the read model** in every slice where it's read so the timeline flows left-to-right, and
+  **prefer `view X again`** for every instance after the first (see Clauses). `again` instances are
+  exempt from the duplicate-name warning even when referenced, and each reference resolves to the
+  right instance — a plain repeat only stays warning-free while nothing references it by name, and
+  resolves to the *first* declaration when something does. **Wire each event to a read model exactly
+  once:** a repeated instance's `from` lists only the **new** events since the previous instance
+  (not cumulative), or the event draws a duplicate arrow to the same read model at every repeat. (An
+  event may still feed several *different* read models, once each.)
+- **Instances are never joined to one another.** No arrow between two instances of one read model,
+  ever — an explicit one is a validation error. The repeat is a timeline device: continuity is
+  implied by the shared name, and the events arriving at each instance are what show it changing.
 - **Keep arrows span-1: put each repeat right after its feeding event.** Place a read-model instance
-  immediately after the event that updates it, sourcing only that single adjacent event. A read
-  model far from its source events draws long arrows that cross the read-model row and read as
-  read→read (an Event Modeling violation) — repeat the read model next to each event instead.
+  immediately after the event that updates it, sourcing only that single adjacent event. The
+  renderer routes a long arrow *around* intervening boxes rather than through them, so it no longer
+  reads as a forbidden read→read link — but distance is still a real problem: the arrowhead lands
+  columns away from the event that produced it, so **the write slice reads as dangling**, as if
+  nothing consumed its event. You have to trace a line across the diagram to see the connection.
+  Keep the read model adjacent to its event, and keep a sub-flow that detours into another context
+  together rather than parking it at the end of the model.
 
 ### Slice-ordering gotchas (edge inference)
 
@@ -197,20 +237,33 @@ slice "Read Quote — created"   { view Quote from "QuoteCreated"  translation S
    there), a reaction reading a view before any instance of it exists, or an explicit backward
    `arrow`.
 6. **`again` without an earlier declaration** — declare the view plainly the first time it appears.
+7. **Illegal connection** — an `arrow` joining kinds the patterns don't connect. Only
+   `ui -> command`, `command -> event`, `event -> view`, `view -> ui`, `view -> reaction`, and
+   `reaction -> command` are allowed. A command straight to a view is the CQRS violation (an event
+   has to sit between them); a view straight to a command needs a reaction between them; and two
+   instances of one view are never connected at all. Inferred edges are always legal, so this only
+   ever fires on a hand-written `arrow`.
 
 **Warnings (should fix):**
 1. **Automation/translation shares slice with its command** — both `automation`/`processor` and
    `translation` are reactions; put the triggered command in the *next* slice.
-2. **Command without event** — every command should record at least one event.
-3. **Read model without source** — add `from "Event"` or place the view in a slice with an event.
-4. **Duplicate name** — the same name defined N times; references resolve to the first. Rename.
-5. **Open issue** — an element carries `issue "text"`; resolve the question, then remove the
+2. **Command with no trigger** — nothing issues it. A command needs a `ui` in its slice, or a
+   reaction (automation/processor/saga/translation) in the slice *before* it. The input-side mirror
+   of (4): a command nothing points at is a write nobody can start.
+3. **Command without event** — every command should record at least one event.
+4. **Event nobody reads** — the mirror of (3): recording an event no read model projects is a
+   write with no reader. Follow every write slice with the read slice that consumes its event.
+   Counts as read when a `view` names it in `from` (any `again` instance will do), when a
+   fieldless-`from` view sits in its slice, or via an explicit `event -> view` arrow.
+5. **Read model without source** — add `from "Event"` or place the view in a slice with an event.
+6. **Duplicate name** — the same name defined N times; references resolve to the first. Rename.
+7. **Open issue** — an element carries `issue "text"`; resolve the question, then remove the
    clause. `em validate --list-issues` prints just these; `--fail-on-issues` (opt-in) makes CI
    fail while any remain open.
-6. **View field with no source** — a `view` field whose name matches no field on any instance
+8. **View field with no source** — a `view` field whose name matches no field on any instance
    of its source events. Only checked once BOTH the view and at least one source event declare
    `{ fields }`.
-7. **Event field not from a command** — an `event` field whose name matches no field on any
+9. **Event field not from a command** — an `event` field whose name matches no field on any
    command in the same slice. Only checked once BOTH the event and at least one same-slice
    command declare `{ fields }`. This is the payoff of the fields feature for slicing rigor:
    once fields are written down, `em validate` checks that data flows forward consistently.
@@ -218,6 +271,20 @@ slice "Read Quote — created"   { view Quote from "QuoteCreated"  translation S
 **Design rules that keep models valid:**
 - One element per band per slice (multiple personas/contexts are fine — they're different rows).
 - Every `command` slice includes its `event`. Every `view` has a `from` source.
+- **Every `command` has a trigger.** A `ui` in its slice, or a reaction in the slice *before* it.
+  A command nothing points at is a write nobody can start.
+- **Every `event` has a reader.** A command slice isn't finished until the read slice that projects
+  its event exists. Reactions don't count — they read views, not events. Pair each write slice with
+  its read slice as you go rather than sweeping up dangling events at the end.
+- **Every `view` has a consumer.** A `ui` in its slice, a reaction watching it, or (headless) a read
+  translation. Every *instance* of a repeat, not just the last — a bare `view X again` slice is a
+  half-slice, not a State View.
+- **Only six connections are legal**, and only these are ever inferred:
+  `ui → command`, `command → event`, `event → view`, `view → ui`, `view → reaction`,
+  `reaction → command`. Anything else in an explicit `arrow` is an error — above all
+  `command → view` (the CQRS violation: an event has to sit between them) and `view → command`
+  (a reaction has to sit between them). If you reach for an arrow the patterns don't allow, the
+  model is missing an element, not an arrow.
 - Automations **and translations** are always two slices: the reaction (plus its read model, if
   internally triggered) in one slice, the triggered `command` + its `event` in the next. A
   translation/automation slice **never contains an `event`** — reactions trigger commands, not

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

@@ -70,10 +70,16 @@ it is fine to finish a round with `# TBD`s still parked.
   *actual* actors/callers and the *real* UI or API surfaces (headless systems: no
   `ui`/`persona` — use write/read translations per `em-dsl.md`). **First `em render` here.**
 - **R3 — Commands / inputs.** For each event, the request that actually produces it today
-  (imperative name). Unclear trigger → `# TBD`, not a plausible guess.
+  (imperative name), *and what triggers it* — the real screen, or the scheduler/listener that
+  fires it (model that as a reaction in the preceding slice, per R5). Unclear trigger → `# TBD`,
+  not a plausible guess; expect a *command has nothing that triggers it* warning until R5 fills
+  it in, and don't invent a screen to silence it.
 - **R4 — Read models / outputs.** The projections/queries the system actually serves; wire
-  `from "Event"` (repeat read models span-1 per `em-dsl.md`). **Start running `em validate`**
-  each round from here.
+  `from "Event"` (repeat read models span-1 per `em-dsl.md`, using `view X again` after the
+  first). **Start running `em validate`** each round from here. Expect *event is not read by any
+  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.
 - **R5 — Boundaries & reactions.** Current automations and integrations as-is: schedulers,
   listeners, outbound syncs, inbound webhooks. Model each as a reaction with the two-slice
   `reaction → command → event` split and the slice-ordering rules in `em-dsl.md` — even when
@@ -103,8 +109,9 @@ one for a sprawling one. Record any deviation in the Decisions log.
 ## Completion & handoff
 
 Extraction is complete when: the model renders; `em validate` is clean (or remaining warnings
-are consciously accepted in the Decisions log); every unknown is a parked `# TBD`; and the
-user has confirmed the model reflects today's behavior. Then:
+are consciously accepted in the Decisions log — unread events in an as-is model are the usual
+accepted case, and each one is worth naming explicitly as a finding); every unknown is a parked
+`# TBD`; and the user has confirmed the model reflects today's behavior. Then:
 
 1. State file: set phase progress (extraction rounds checked), log the completion decision.
    Seed `README.md`'s **slice index** (every slice, pattern, status `none`).

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

@@ -16,6 +16,20 @@ three ways:
 3. There is **no other way** for information to flow. Every box on the diagram is one of:
    UI screen, command, event, read model, or automation/processor.
 
+Concretely, that leaves exactly six legal connections, and `em` infers only these:
+`ui → command`, `command → event`, `event → read model`, `read model → ui`,
+`read model → reaction`, `reaction → command`. Every other pair is a rule violation, and an
+explicit `arrow` writing one is a validation error. The two worth naming, because they are the
+tempting shortcuts:
+
+- **`command → read model`** — the CQRS violation. A write is only ever visible to a reader
+  through the event it recorded. Put the event between them.
+- **`read model → command`** — reads never drive a write directly. A processor or translation
+  watches the read model and issues the command, across two slices.
+
+If you find yourself wanting an arrow the patterns don't allow, the model is missing an
+**element**, not an arrow.
+
 **Automations and translations are not exceptions to rule 1.** They are *reactions* — a processor
 or an adapter that wakes up, decides something must change, and **issues a command** to do it. They
 never record an event themselves. A reaction box always points at a **command** (in the next
@@ -37,7 +51,24 @@ Every slice is exactly one of these. In `em`, each maps to a specific shape (see
 ### 1. State Change (Command pattern)
 **UI → Command → Event.** A user (or automation) submits a command; the system validates it
 against invariants and records one or more events.
-- `em` shape: `slice { ui X @Persona  command Y  event Z @Context }`
+- **A State Change never travels alone, and it's joined at both ends.** Something must *trigger*
+  the command — the `ui` it's issued from, or (patterns 3 and 4) the reaction in the slice before
+  it — and its event needs a read model that projects it. So the unit of work is a State Change
+  slice *plus* the State View slice that reads its event. Write them together; a command nothing
+  points at is a write nobody can start, an unread event is a write nobody can see, and
+  `em validate` warns on each.
+- `em` shape (one element per line — there is no one-line slice form):
+  ```em
+  slice "Do The Thing" {
+    ui X @Persona
+    command Y
+    event Z @Context
+  }
+  slice "See The Result" {   # the State View slice that reads Z — pattern 2, but required here
+    view V from "Z"
+    ui Screen @Persona
+  }
+  ```
 - This is where **invariants** live — the command is rejected if a rule is violated.
 - Socratic prompts: *"What does the user do here? What request are they making? What must be
   true for it to succeed? What fact gets recorded when it does? What gets rejected and why?"*
@@ -55,19 +86,30 @@ displays. Read-only; changes no state.
 - **Repeat read models across the timeline.** A read model is drawn fresh in **every** slice where
   it is read — after the events that update it, before the actions that consume it — so the diagram
   shows state flowing left-to-right (the information-completeness staircase). The same read-model
-  name recurring is intentional and **renders cleanly**: `em validate` only warns about a duplicate
-  name that is *also referenced* by a `from`/`arrow` (it resolves to the first), so a repeated read
-  model that nothing references by name produces **no warning**. **Wire each event to a read model
+  name recurring is intentional and **renders cleanly**. Declare every instance after the first with
+  **`view V again from "..."`**: `again` instances are exempt from the duplicate-name warning even
+  when something references them, and each reference resolves to the right instance. (A plain repeat
+  only stays warning-free while nothing references it by name, and resolves to the *first*
+  declaration when something does.) **Wire each event to a read model
   exactly once:** a repeated instance's `from` lists only the **new** events since the previous
   instance (not cumulative) — otherwise an event draws a duplicate arrow to the same read model at
   every repeat. (An event may still feed several *different* read models, once each.)
+- **Instances are never connected to one another.** There is no arrow between two appearances of one
+  read model, and an explicit one is a validation error. The repeat is an ergonomic device for
+  showing the same read model at successive points in time — continuity is implied by the shared
+  name, and the events arriving at each instance are what show it changing. An arrow between them
+  would say the read model feeds itself.
 - **Place each repeat immediately after its feeding event (span-1).** The cleanest staircase puts a
   read-model instance right after each event that updates it, sourcing **only that one adjacent
   event** — every `event → read model` arrow is then short and forward-flowing. A read model sitting
   far from its source events (e.g. a "list/queue" read placed early but fed by late events) draws
-  long arrows that cross the read-model row and *look* like read→read connections — which Event
-  Modeling forbids. The fix is never a `view → view` edge; it's to repeat the read model next to each
-  event that feeds it.
+  long arrows that sweep across the diagram. The renderer routes them *around* intervening boxes
+  rather than through them, so they no longer *look* like a forbidden read→read link — but the
+  distance itself is the problem: the arrowhead lands columns away from the event that produced it,
+  so **the write slice reads as dangling**, as if nothing consumed its event. A reader has to trace
+  the line across the diagram to see otherwise. The fix is never a `view → view` edge; it's to
+  repeat the read model next to each event that feeds it, and to keep a sub-flow that detours into
+  another context together rather than parking it at the end of the model.
 - Socratic prompts: *"What does the consumer need to see to make their next decision? Which past
   events provide that information? Is this a screen or an API read? What's the freshness/consistency
   expectation?"*
@@ -76,10 +118,24 @@ displays. Read-only; changes no state.
 **Read Model → Processor → (next slice) Command → Event.** The system reacts on its own: a
 processor watches a read model (a "to-do list" of work) and **issues a command** — it never
 records an event directly.
-- `em` shape: **two slices.** First `slice { view "Todo" from "..."  processor P }`, then the
-  **next** `slice { command C  event E @Context }`. The processor band holds no event; the command
-  in the next slice produces it. Keeping the triggered command in the same slice as the processor
-  is a validation warning — always split it.
+- `em` shape: **two slices**, then the read slice that consumes the event — three in all:
+  ```em
+  slice "Todo" {
+    view Todo from "..."
+    processor P
+  }
+  slice "Do It" {           # the triggered command goes in the NEXT slice
+    command C
+    event E @Context
+  }
+  slice "Todo — done" {
+    view Todo again from "E"   # every event needs a reader; here it clears the to-do list
+    ui Work Board @Persona     # ...and every read model needs a consumer
+  }
+  ```
+  The processor band holds no event; the command in the next slice produces it. Keeping the
+  triggered command in the same slice as the processor is a validation warning — always split it.
+  Forgetting the third slice leaves `E` unread, which is also a warning.
 - Socratic prompts: *"What should happen without a human? What condition triggers it? What work
   list does the processor watch? What command does it fire? What if it fails or retries?"*
 
@@ -92,9 +148,22 @@ trigger forms:
   from outside the model, so the translation has no internal `from`.
 - **Internally triggered** (reacting to the modeled system's own state, e.g. pushing data out):
   `read model → translation → command → event`. The translation reads a **view** via `from`.
-- `em` shape: **two slices**, exactly like an automation. First
-  `slice { [view "Source" from "..."]  translation T [from "Source"] }`, then the **next**
-  `slice { command C  event E @Context }`. The translation band never carries an event.
+- `em` shape: **two slices**, exactly like an automation, plus the read slice for the event:
+  ```em
+  slice "Boundary" {
+    view Source from "..."     # internally triggered only; omit for an external trigger
+    translation T from "Source"
+  }
+  slice "Record It" {
+    command C
+    event E @Context
+  }
+  slice "Source — recorded" {
+    view Source again from "E"   # every event needs a reader
+    ui Status Screen @Persona    # ...and every read model needs a consumer
+  }
+  ```
+  The translation band never carries an event.
 - Socratic prompts: *"What boundary are we crossing, and which way? What outside system or context
   feeds us (or do we feed)? In what format? How do we know its data is trustworthy/complete? What
   internal **command** does it trigger, and what event does that command record?"*
@@ -170,17 +239,30 @@ dedicated `slice` phase writes the full rich spec (see `templates/slice.md`).
 
 ### Step 7 — Evaluate Completeness  *(model)*
 Walk the whole model with stakeholders and check for loose ends:
+- Every **command** has something that **triggers** it — a `ui` in its slice, or a reaction in the
+  slice before it. A command nothing points at is a write nobody can start. `em validate` warns.
 - Every **command** produces at least one **event**.
-- Every **view** has at least one source event.
-- Every **event** is shown somewhere or consumed by something (no orphan facts).
+- Every **view** has at least one source event, **and a consumer** — a `ui`, a reaction watching it,
+  or (headless) a read translation. Every *instance* of a repeated view, not just the last one.
+  A read model nothing displays is information projected out and then dropped. `em validate` warns.
+- Every **event** is **read by a read model** — a `view` naming it in `from` (any `again` instance
+  counts), or a `view` with no `from` sitting in its slice. A reaction consuming it does **not**
+  count: reactions read views, not events. An event nothing projects is a write nobody can see, so
+  there was no point recording it. `em validate` warns on each one.
 - Every **UI** is reachable and leads somewhere.
+- Every connection is one of the six legal pairs (`ui → command`, `command → event`,
+  `event → read model`, `read model → ui`, `read model → reaction`, `reaction → command`). No
+  arrow between two instances of one read model.
 - Automations **and** translations are split correctly (reaction → command → event, never a
   reaction wired straight to an event); translations cover every external input.
-- Run `em validate` and resolve all errors and warnings. Note: `em validate` does **not** catch a
-  translation/automation that emits an event directly — verify the two-slice split by hand.
-- Prompts: *"Is there any event nobody sees? Any screen with no way in or out? Any command that
-  records nothing? Any external system we haven't translated? Any translation or automation that
-  records an event instead of triggering a command?"*
+- Run `em validate` and resolve all errors and warnings. It now catches illegal `arrow` kind pairs
+  (error) and unread events (warning), but it still does **not** catch a translation/automation that
+  emits an event directly — verify the two-slice split by hand.
+- Prompts: *"Is there any event nobody reads — and if the business genuinely never looks at it, why
+  are we recording it? Any command that just happens, with nobody and nothing asking for it? Any
+  screen with no way in or out? Any command that records nothing? Any
+  external system we haven't translated? Any translation or automation that records an event instead
+  of triggering a command?"*
 
 ---
 

package/.claude/skills/event-modeling/templates/model-readme.md

@@ -21,6 +21,15 @@ Static render: `em render {{model-name}}.em -o {{model-name}}.svg`
 - **Automation** — Read Model → Processor → (next slice) Command → Event
 - **Translation** — External input (or Read Model) → Translation → (next slice) Command → Event
 
+Between them these are the only legal connections: `ui → command`, `command → event`,
+`event → read model`, `read model → ui`, `read model → reaction`, `reaction → command`. A command
+never reaches a read model directly — the event goes between them. Every slice is joined up at
+both ends: something triggers each command (the screen it's issued from, or the reaction in the
+slice before it), and every event a command records is read by some read model — so each State
+Change slice is paired with the State View slice that projects its event. A read model repeated
+along the timeline (`view X again`) shows the same projection at a later point; the instances are
+never connected to one another.
+
 ## Slices
 <!-- The canonical slice index — the ONE place slices are enumerated (the state file
      points here rather than keeping its own copy). Keep it in sync as slice docs are

package/.claude/skills/event-modeling/templates/slice.md

@@ -32,9 +32,20 @@ an event directly.}}
 |-------|------|----------|--------------------|
 | {{field}} | {{Type}} | {{yes/no}} | {{constraints, formats, ranges}} |
 
+## Trigger
+<!-- What issues this slice's command. Required: a command nothing points at is a write nobody
+     can start. Either the screen the user acts on (a `ui` in this slice), or the reaction that
+     issues it (an automation/processor/translation in the PREVIOUS slice). -->
+**Triggered by:** {{screen `X` @Persona | processor `Y` in slice "Z"}}
+
 ## Event(s) Emitted
 <!-- The immutable facts recorded. List each event and its payload. -->
 **Event:** `{{Event Name}}` → context `{{Context}}`
+**Read by:** {{which read model projects this event, and in which slice}}
+<!-- Required, not optional. Every event must be read by a read model — an event nothing
+     projects is a write nobody can see, and `em validate` warns on it. A reaction consuming
+     it does NOT count: reactions read views, not events. If the honest answer is "nothing
+     reads it", that's a question for the business, not a field to leave blank. -->
 
 | Field | Type | Immutable Fact? | Source / Notes |
 |-------|------|-----------------|----------------|
@@ -43,7 +54,10 @@ an event directly.}}
 ## Read Model / View
 <!-- For State View slices, and any read model this slice produces or feeds. -->
 - **View:** `{{View Name}}` built from events: {{"Event A", "Event B"}}
-- **Consumed by:** {{which UI screen or automation}}
+- **Consumed by:** {{which UI screen, reaction, or read translation}}
+<!-- "Consumed by" is required, not optional. A read model nothing displays or watches is
+     information projected out of the system and then dropped, and `em validate` warns. Every
+     instance of a repeated view needs its own consumer, not just the last one. -->
 - **Freshness / consistency expectation:** {{real-time | eventual | on-demand}}
 
 ## Invariants / Business Rules