@milehimikey/em 1.7.0 → 1.7.2

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

@@ -1,19 +1,13 @@
 ---
 name: event-modeling
-em-version: 1.7.0
+em-version: 1.7.2
 description: >-
-  Guide a user and their team through building rigorous Event Models with the `em` CLI, using
-  the 7 steps of Event Modeling and the 4 patterns (State Change, State View, Automation,
-  Translation), and produce implementation-ready slice docs. Use when the user wants
-  to event-model a business process or system, do event modeling / event storming, design slices,
-  build or edit an `.em` model, run the em tool, extract / reverse-engineer a current-state
-  event model from an existing system or codebase (event-driven or legacy/procedural), or check
-  a ratified model for drift against the codebase that implements it. Works in resumable phases
-  via an argument: `discover` (steps 1-4, greenfield), `extract` (current-state model of an
-  existing system), `model` (steps 5-7), `slice` (deep slice specs), `implement` (build one
-  ratified slice into code, following the bundled agent guide), `conform` (drift check
-  against the codebase), plus `watch`, `review` (stakeholder walkthrough), and `validate`.
-  With no argument it resumes from the saved state file.
+  Use when the user wants to event-model a business process or system: building, editing,
+  updating, or maintaining a model — extending or detailing an existing one into slices,
+  extracting a current-state model from an existing codebase, implementing a ratified slice, or
+  checking a model for drift against the code. Drives the `em` CLI through resumable phases —
+  discover, extract, model, slice, implement, conform, watch, review, validate — or resumes
+  automatically with no argument.
 ---
 
 # Event Modeling with `em`
@@ -59,23 +53,24 @@ vendored alongside this skill.
   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`).
+  when referenced, and each reference resolves to the right instance. A reaction's command is
+  wired by same-slice presence, exactly like `ui → command` — no positional/adjacency rule to get
+  right (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.
+  command needs something that **triggers** it (the `ui` it's issued from, or the reaction that
+  triggers it, also in this slice), 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; a reaction
+  that triggers no command is a decision the system never acts on; 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
@@ -150,8 +145,9 @@ phase applies to field tables, below.
 3. **Inputs (step 3).** For each event, find the **command** that causes it (imperative name).
    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?"*
+   and Translation patterns — the reaction that triggers it, also in this slice. 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), 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
@@ -194,23 +190,23 @@ Goal: a structurally complete, **validated** model with correct patterns and swi
 
 1. **Swimlanes & patterns (step 5).** 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. **Split every automation _and every translation_ across two
-   slices** (the reaction — processor/translation — plus its read model in one slice; the
-   triggered command + its event in the *next* slice). A translation or automation is a reaction:
-   it **triggers a command and never records an event directly**. Add `translation` slices for
-   external inputs (externally triggered: external → translation → command → event) and for the
-   system reacting to its own state (internally triggered: read model → translation → command →
-   event).
+   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
+   and event it produces; the read model it watches, if any, stays in the slice before). A
+   translation or automation is a reaction: it **triggers a command and never records an event
+   directly**. Add `translation` slices for external inputs (externally triggered: external →
+   translation → command → event, no slice before) and for the system reacting to its own state
+   (internally triggered: read model in the slice before → translation → command → 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 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`).
+   one of the six legal pairs, and every automation **and** translation triggers a command (none
+   wired straight to an event, none with no command at all). Run `em validate` and resolve all
+   errors and warnings — it catches a reaction wired straight to an event too now (see
+   `reference/em-dsl.md`), so a clean run covers this case.
    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.
@@ -368,8 +364,8 @@ rule (see `reference/em-dsl.md`) and proposing the fix. Apply fixes on agreement
 
 | 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?"* |
+| reaction triggers no command | Add the command it issues, in this same slice, or an explicit `arrow` to one elsewhere |
+| **command has nothing that triggers it** | Add the `ui` it's issued from — or, if the system issues it, the reaction that triggers it, also in this slice. 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 |
@@ -383,10 +379,11 @@ relevant element over a `# TBD` comment — it shows up as a red marker on the r
 `em validate` tracks it as an open-issue warning, so it isn't lost once rendered. `em validate
 --list-issues` gives a quick sweep of everything still open.
 
-Then do one check `em validate` can't: scan every `translation`/`processor`/`automation` slice and
-confirm none contains an `event` — each reaction must trigger a `command` in the next slice
-(`reaction → command → event`). If you find a reaction wired straight to an event, split it into
-two slices and route it through a command.
+`em validate` now catches a reaction wired straight to an event too — any reaction with no
+`command` in its own slice, and no explicit arrow to one, warns "triggers no command". A
+`translation`/`processor`/`automation` should always trigger a `command` in its own slice
+(`reaction → command → event`); if one instead records an event directly, route it through a
+command instead.
 
 ---
 

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

@@ -153,6 +153,11 @@ type Name { field: Type, ... }      # named structured type, reusable from any f
   declared `type` (see Named types below), in which case it resolves to a structured
   reference. Keep these light; full field specs with rules live in the slice doc.
 - **Comments:** `# ...` anywhere outside quotes (full-line or trailing).
+- **Quoted strings:** everything between a `"` and its matching `"` is literal — `{`, `}`, `#`
+  included, never re-interpreted as a field block or comment — so REST path-template
+  placeholders are safe as-is: `issue "PUT v3/widgets/{widgetId}/suspend"`. Escape a literal
+  `"` or `\` inside a string with `\"`/`\\`; no other backslash sequence is special. An
+  unterminated string (missing closing `"`) is a parse error naming the clause it broke in.
 - **`source "url"` on a slice header** (the only slice-level clause — everything above is
   per-element) links the slice back to the ticket/conversation it traces to, e.g.
   `slice "Checkout" source "https://linear.app/team/issue/MIL-60" { ... }`. Exports as
@@ -203,12 +208,12 @@ slice "Open Orders" {
   ui Order List @Customer
 }
 
-# 3. Automation: split across TWO slices (plus the read slice that consumes the event)
+# 3. Automation: read model in the slice before, reaction + command + event together
 slice "Orders To Fulfill" {
   view Orders To Fulfill from "Order Placed"
-  processor Fulfillment Service
 }
-slice "Ship Order" {            # the triggered command goes in the NEXT slice
+slice "Ship Order" {            # reaction, command, and event all share this one slice
+  processor Fulfillment Service from "Orders To Fulfill"
   command Ship Order
   event Order Shipped @Shipping
 }
@@ -218,10 +223,8 @@ slice "Open Orders — shipped" {
 }
 
 # 4a. Translation (external trigger, no durable artifact): external call -> translation -> command -> event
-slice "Carrier Webhook" {
+slice "Confirm Delivery" {
   translation Carrier Adapter         # inbound from outside the model; no internal `from`
-}
-slice "Confirm Delivery" {            # the triggered command goes in the NEXT slice
   command Confirm Delivery
   event Delivery Confirmed @Shipping
 }
@@ -238,9 +241,9 @@ slice "Receive Carrier Event" {           # ingest: persist the raw webhook befo
 }
 slice "Inbound Carrier Events" {
   view Inbound Carrier Events from "Carrier Event Received"   # the persisted inbound queue
-  translation Carrier Adapter
 }
 slice "Acknowledge Carrier Event" {
+  translation Carrier Queue Adapter from "Inbound Carrier Events"   # different producer than 4a's Carrier Adapter, so a distinct name
   command Acknowledge Carrier Event
   event Carrier Event Acknowledged @Shipping
 }
@@ -251,15 +254,15 @@ slice "Inbound Carrier Events — processed" {
 
 # 4c. Translation (internal trigger, durable artifact): read model -> translation -> command -> event
 slice "Accept Quote" {
-  ui Quote Screen @Customer     # every command needs a trigger: a ui, or a reaction before it
+  ui Quote Screen @Customer     # every command needs a trigger: a ui, or a reaction, in this slice
   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
 }
 slice "Record Sync" {
+  translation CRM Sync from "Accepted Quotes"   # reacts to our own state via the read model
   command Record Crm Sync
   event Quote Synced @Quote
 }
@@ -278,8 +281,11 @@ the context/lane whose fact it represents (e.g. `Carrier Event Received @Shippin
 Anti-Corruption-Layer event in DDD) instead of a technical artifact leaking foreign vocabulary
 into the model.
 
-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.
+A `translation` (like a `processor`) is a **reaction**: it triggers a command in the same slice —
+same shape as the Automation pattern above, and the same shape `ui` already uses in State Change.
+The reaction never records the event directly (there's no `reaction -> event` edge); the command
+it triggers is what records it, and that event happens to live in the reaction's own slice now
+because the command does.
 
 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
@@ -314,8 +320,9 @@ slice "Read Quote — created" {
   request/response API call — that's Pattern 1 (State Change) with an API persona, exactly like the
   `Create Quote` slice above.
 - **Internal-only commands and views (no public route) carry no `ui` at all.** They follow the
-  ordinary Automation pattern already documented: the reaction sits in the previous slice, and an
-  internal-only read model is consumed by that reaction, not by a screen or an API query.
+  ordinary Automation pattern already documented: the reaction shares the command's slice, and an
+  internal-only read model is consumed by that reaction (from the slice before), not by a screen
+  or an API query.
 - **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) — **each instance
   carries its own consumer** (the `ui` that reads it, or a reaction), not just the last one. `again`
@@ -337,23 +344,19 @@ slice "Read Quote — created" {
   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)
-
-`em` infers cross-slice arrows positionally, so **slice order matters**:
-- A **reaction** (`processor`/`translation` that triggers a command) wires to the command in the
-  **immediately next** slice. So a reaction slice must be *directly* followed by its command slice —
-  don't insert a read slice between them.
-- A read slice whose consumer is a **reaction** (`view` + `processor`/`translation`, no command in
-  the same slice) must **not** be immediately followed by a `command` slice, or the reaction will be
-  mis-wired to that command. Put it after a command+event slice, or before another read/reaction
-  slice instead. (A `ui`-consumed read slice has no such risk — `ui` never wires as a reaction.)
-- A read model fed by an early event (e.g. a queue or to-do view) can't always sit directly after
-  its source event when a reaction must immediately precede its command slice — placing the read
-  later, in narrative order with a longer arrow, is the correct trade-off, not something to force-fix.
-- A `ui` never triggers a reaction — no pattern has a `ui` wired to `processor`/`automation`/
-  `saga`/`translation`, only to `command`. A `ui` left in the reaction's own slice (instead of the
-  read-model or command slice) renders with no outgoing edge, disconnected, and `em validate` now
-  warns on it.
+### Reaction wiring — no positional gotcha
+
+A reaction's command is inferred from **same-slice presence**, exactly like `ui -> command`: put
+`processor`/`translation` in the same slice as the command it triggers, in either order, and `em`
+wires it correctly regardless of what any other slice contains or where it sits in the file. There's
+no adjacency to get right and no reordering hazard — the read model it watches (if any) is named
+explicitly via `from "View"`, resolved by name to the nearest instance at or before its own slice,
+not by position either.
+
+The one thing that still doesn't wire on its own: a `ui` never triggers a reaction — no pattern has
+a `ui` wired to `processor`/`automation`/`saga`/`translation`, only to `command`. A `ui` left in a
+reaction's slice renders with no outgoing edge, disconnected, and `em validate` warns on it — move
+it to the slice that displays the read model, or drop it.
 
 ---
 
@@ -388,15 +391,16 @@ slice "Read Quote — created" {
    real split/merge (see the four `lineage-*` codes in the table below).
 
 **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. **`ui` shares slice with a reaction, no command** — a `ui` only ever wires to a `command`; no
+1. **Reaction with no command** — a `processor`/`automation`/`saga`/`translation` that triggers
+   nothing. It never records an event itself; add the command it issues in this same slice, or an
+   explicit `arrow` to one elsewhere.
+2. **`ui` shares slice with a reaction** — a `ui` only ever wires to a `command` a person issues; no
    pattern has a `ui` triggering an automation/processor/saga/translation. Left in the reaction's
-   own slice it renders disconnected, with no edge. Move it to the read-model slice, or to the
-   slice with the command this eventually triggers.
-3. **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 (5): a command nothing points at is a write nobody can start.
+   own slice it renders disconnected, with no edge, whether or not that slice also has the
+   reaction's own command. Move it to the slice that displays the read model, or drop it.
+3. **Command with no trigger** — nothing issues it. A command needs a `ui` in its slice, or the
+   reaction (automation/processor/saga/translation) that triggers it, *also* in this slice. The
+   input-side mirror of (5): a command nothing points at is a write nobody can start.
 4. **Command without event** — every command should record at least one event.
 5. **Event nobody reads** — the mirror of (4): 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.
@@ -450,12 +454,12 @@ not the prose above has caught up yet. `--slice-ready <key>`-only codes are excl
 | `arrow-backward` | error | Backward arrow | Restructure so the target comes later. |
 | `arrow-unresolved-source` | error | Arrow source unresolved | Fix the arrow's source name. |
 | `arrow-unresolved-target` | error | Arrow target unresolved | Fix the arrow's target name. |
-| `automation-shares-slice-with-command` | warning | Automation shares slice with its command | Put the triggered command in the next slice. |
 | `binding-missing-file` | warning | Doc binding points at a missing file | Create the slice doc, or fix the `note` path. |
 | `both-ends-of-a-flow/command-no-event` | warning | Command without event | Add the event this command records. |
-| `both-ends-of-a-flow/command-untriggered` | warning | Command with no trigger | Add a `ui` in this slice, or a reaction in the previous slice. |
+| `both-ends-of-a-flow/command-untriggered` | warning | Command with no trigger | Add a `ui` or the reaction that issues it, both in this slice. |
 | `both-ends-of-a-flow/event-unproduced` | warning | Event with no producing command | Add the command that records it, or an explicit arrow from one. |
 | `both-ends-of-a-flow/event-unread` | warning | Event nobody reads | Project it into a view, or reconsider recording it. |
+| `both-ends-of-a-flow/reaction-no-command` | warning | Reaction with no command | Add the command it triggers, in this slice, or an explicit arrow to one. |
 | `both-ends-of-a-flow/ui-unbacked` | warning | `ui` with no read model or command | Add a `view` it displays, or the command it triggers. |
 | `both-ends-of-a-flow/view-unconsumed` | warning | Read model with no consumer | Add a `ui` or reaction that consumes it, or drop this instance. |
 | `connection-legality/illegal-pair` | error | Illegal connection | Only ui→command→event→view→ui and view→reaction→command are legal — the message names the missing step. |
@@ -478,7 +482,7 @@ not the prose above has caught up yet. `--slice-ready <key>`-only codes are excl
 | `reaction-from-unresolved` | error | Unknown read-model source | Project the event into a view first, or fix the `from` reference. |
 | `translation-name-collision` | warning | Translation name reused for different producers | Use a distinct name per producer to avoid confusion. |
 | `type-cycle` | error | Cyclic type reference | Break the cycle, or route the self/mutual reference through an array. |
-| `ui-shares-slice-with-automation` | warning | `ui` shares slice with a reaction, no command | Move the `ui` to the read-model slice, or to the slice with the command this triggers. |
+| `ui-shares-slice-with-automation` | warning | `ui` shares slice with a reaction | Move the `ui` to the slice that displays the read model, or drop it. |
 | `view-again-without-earlier` | error | `again` without an earlier declaration | Declare the view plainly the first time it appears. |
 | `view-from-future-event` | error | Backward timeline (view reads a future event) | Move the source to a later `view X again` instance. |
 | `view-from-unresolved` | error | Unknown event source | Fix the `from` reference to name an existing event. |
@@ -488,8 +492,8 @@ not the prose above has caught up yet. `--slice-ready <key>`-only codes are excl
 **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 `command` has a trigger.** A `ui` in its slice, or the reaction that triggers it, also in
+  its slice. 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.
@@ -502,16 +506,17 @@ not the prose above has caught up yet. `--slice-ready <key>`-only codes are excl
   `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
-  events. Externally-triggered reactions start from outside the model (no `from`);
-  internally-triggered ones read a **view** (read model) — `from "X"` must resolve to a view.
+- A reaction (`processor`/`automation`/`saga`/`translation`) shares its slice with the `command` it
+  triggers and that command's `event` — the same shape `ui` already uses in State Change. If it's
+  internally triggered, the **view** (read model) it watches lives in the slice before, named via
+  `from "X"` (which must resolve to a view, never an event directly). Externally-triggered reactions
+  start from outside the model — no `from` at all, and no slice before them.
 - Name everything uniquely and consistently.
 - Events are past tense; commands are imperative; views name the thing shown.
 
-> ⚠️ **Validator blind spot:** `em validate` does **not** flag a translation/automation that emits
-> an event directly (e.g. `translation T` and `event E` in the same slice with no command). It only
-> warns when a reaction shares a slice with a *command*. So enforce the two-slice
-> `reaction → command → event` split **by construction** — never rely on `em validate` to catch a
-> reaction wired straight to an event.
+A reaction that emits an event with no command anywhere between them — `translation T` and
+`event E` in the same slice, nothing issuing it — is exactly what
+`both-ends-of-a-flow/reaction-no-command` (above) catches: any reaction with no `command` in its
+own slice, and no explicit arrow to one, warns. Still route every reaction through a real command
+by construction (`reaction → command → event`) rather than an explicit `arrow "Reaction" -> "Event"`
+— that shape is its own `connection-legality` error (a reaction never records an event itself).

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

@@ -3,8 +3,8 @@
 Read this **before doing any extract work**. It governs the `extract` phase and **overrides
 `methodology.md` step 1's stance** for the duration of extraction: you are capturing how the
 system behaves **today**, not modeling what the business needs. Everything else in the
-methodology — the 4 patterns, the "is it an event?" test, the Socratic stance, the two-slice
-reaction split — still applies.
+methodology — the 4 patterns, the "is it an event?" test, the Socratic stance, the
+reaction-shares-a-slice-with-its-command shape — still applies.
 
 ## Stance override — current-state-only
 
@@ -81,7 +81,7 @@ it is fine to finish a round with `# TBD`s still parked.
   `em render` here.**
 - **R3 — Commands / inputs.** For each event, the request that actually produces it today
   (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`,
+  fires it (model that as a reaction sharing this same 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
@@ -91,16 +91,18 @@ it is fine to finish a round with `# TBD`s still parked.
   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
-  the current code wires it as one procedural step (note the as-built shape in the slice's
-  `# TBD`/Decisions if it differs).
+  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
+  read model it watches, if any, lives in the slice before, named via the reaction's own
+  `from`. This matches how the current code usually already reads (scheduler/listener → one
+  procedural step); note any real as-built difference in the slice's `# TBD`/Decisions.
 - **R6 — Gap & TBD reconciliation.** Walk every parked `# TBD` with the user. Resolve only
   what they can confirm **as a current-state fact**; everything else stays parked. Explicitly
   refuse to resolve a TBD by inventing desired behavior.
-- **R7 — Convergence.** Final `em render` + `em validate` (fix errors and warnings; remember
-  the validator's blind spot — check the reaction split by hand). User confirms the model is a
-  faithful picture of today. Mark extraction complete in the state file and hand off.
+- **R7 — Convergence.** Final `em render` + `em validate` (fix errors and warnings — this now
+  catches a reaction wired straight to an event too, via *reaction triggers no command*). User
+  confirms the model is a faithful picture of today. Mark extraction complete in the state file
+  and hand off.
 
 Seven rounds is the default shape, not a quota — collapse rounds for a small system, repeat
 one for a sprawling one. Record any deviation in the Decisions log.

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

@@ -25,16 +25,16 @@ 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.
+  watches the read model and issues the command that sits in the same slice.
 
 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
-slice), and that command produces the event. If you ever see a translation or automation wired
-straight to an event, the model is wrong.
+never record an event themselves. A reaction box always points at a **command in its own slice** —
+the same shape a `ui` already uses in State Change — and that command produces the event. If you
+ever see a translation or automation wired straight to an event, the model is wrong.
 
 Events are **immutable past-tense facts** ("Order Placed", "Payment Captured"). They are the
 spine of the model. Everything else hangs off the events.
@@ -52,8 +52,8 @@ Every slice is exactly one of these. In `em`, each maps to a specific shape (see
 **UI → Command → Event.** A user (or automation) submits a command; the system validates it
 against invariants and records one or more events.
 - **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
+  the command — the `ui` it's issued from, or (patterns 3 and 4) the reaction that triggers it,
+  also in this slice — 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.
@@ -114,16 +114,17 @@ displays. Read-only; changes no state.
   expectation?"*
 
 ### 3. Automation (Processor pattern)
-**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**, then the read slice that consumes the event — three in all:
+**Read Model → Processor → Command → Event, the last three together in one slice.** 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: the read model in the slice before, then the reaction with its command and event —
+  plus the read slice that consumes the event — three slices in all:
   ```em
   slice "Todo" {
     view Todo from "..."
-    processor P
   }
-  slice "Do It" {           # the triggered command goes in the NEXT slice
+  slice "Do It" {           # processor, command, and event all share this slice
+    processor P from "Todo"
     command C
     event E @Context
   }
@@ -132,9 +133,10 @@ records an event directly.
     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.
+  The processor never records the event directly — the command it triggers does, and that event
+  happens to live in the processor's own slice now because the command does. A processor with no
+  command in its slice (and no explicit arrow to one) is a validation warning: a decision the
+  system never acts on. Forgetting the third slice leaves `E` unread, which is also a warning.
 - **Naming:** name the read model after the pending work — `Payments To Process`,
   `Orders To Fulfill`, `Pending Approvals` — never after the triggering event. The event is what
   happened; the view is what's left to do. Reusing the event's name also collides in the shared
@@ -144,10 +146,11 @@ records an event directly.
   list does the processor watch? What command does it fire? What if it fails or retries?"*
 
 ### 4. Translation
-**Boundary crossing → command → event.** An adapter translates data across a boundary (an external
-system, or another bounded context) into the model's own language. Like an automation, a
-translation is a *reaction*: it **triggers a command**, never records an event directly. Two
-independent questions shape which form it takes — don't conflate them:
+**Boundary crossing → command → event, the reaction and what it triggers together in one slice.**
+An adapter translates data across a boundary (an external system, or another bounded context) into
+the model's own language. Like an automation, a translation is a *reaction*: it **triggers a
+command**, never records an event directly. Two independent questions shape which form it takes —
+don't conflate them:
 - **Trigger source:** does the input come from outside the model, or from the model's own state
   pushed back out?
 - **Durable artifact:** is there a queryable, persisted thing behind the trigger (a queue, topic,
@@ -167,13 +170,14 @@ The `em` shape only tracks the second question — trigger source doesn't change
   it's scoped to the context/lane whose fact it represents, not by who committed it — the same
   move as an Anti-Corruption-Layer boundary event in DDD — and stays legitimate as long as it
   doesn't leak into the model's own domain vocabulary.
-- `em` shape: **two slices**, exactly like an automation, plus the read slice for the event:
+- `em` shape: exactly like an automation — the read model (durable-artifact form only) in the
+  slice before, then the reaction with its command and event, plus the read slice for the event:
   ```em
   slice "Boundary" {
     view Source from "..."     # durable-artifact form only; omit if there's nothing persisted
-    translation T from "Source"
   }
-  slice "Record It" {
+  slice "Record It" {          # translation, command, and event all share this slice
+    translation T from "Source"   # omit `from` entirely for the no-durable-artifact form
     command C
     event E @Context
   }
@@ -182,7 +186,7 @@ The `em` shape only tracks the second question — trigger source doesn't change
     ui Status Screen @Persona    # ...and every read model needs a consumer
   }
   ```
-  The translation band never carries an event.
+  The translation never records the event directly — the command it triggers does.
 - 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?"*
@@ -237,9 +241,9 @@ each view to the events that feed it.
 ### Step 5 — Swimlanes & Apply the Patterns  *(model)*
 Organize elements into swimlanes: one **persona** row per actor, one **context** (bounded
 context / aggregate) row per event family. Classify every slice as one of the **4 patterns** and
-wire them correctly — especially **split both automations and translations across two slices**
-(the reaction in one, the command + event in the next). A translation or automation never records
-an event directly; it triggers a command.
+wire them correctly — especially **share the slice between every automation or translation and the
+command it triggers** (the read model it watches, if any, stays in the slice before). A translation
+or automation never records an event directly; it triggers a command.
 - Prompts: *"Which events belong together as one consistency boundary (aggregate)? Who owns this
   data? Is this slice a state change, a view, an automation, or a translation?"*
 - Output: a structurally complete model with swimlanes and pattern-correct slices.
@@ -258,8 +262,9 @@ 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** has something that **triggers** it — a `ui` in its slice, or the reaction that
+  triggers it, also in its slice. 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, **and a consumer** — a `ui` (headless: the `ui`
   tagged to the API-caller persona), or a reaction watching it. Every *instance* of a repeated
@@ -273,11 +278,13 @@ Walk the whole model with stakeholders and check for loose ends:
 - 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. 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.
+- Automations **and** translations are wired correctly (reaction → command → event, all in one
+  slice — never a reaction wired straight to an event, and never a reaction with no command at
+  all); translations cover every external input.
+- Run `em validate` and resolve all errors and warnings. It catches illegal `arrow` kind pairs
+  (error), unread events (warning), and a reaction with no command in its slice (warning) — a
+  reaction wired straight to an event with no command anywhere is exactly what that last check
+  catches, so a clean `em validate` run does cover this case.
 - 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