@eventmodelers/cli 1.0.37 → 1.0.38

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-orchestrating-event-modeling/SKILL.md

@@ -11,6 +11,8 @@ allowed-tools:
 
 > **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Do not proceed until it has completed. Consult `learn-eventmodelers-api` only if you need to look up a specific endpoint or field this file doesn't cover — don't load it eagerly.
 
+This step applies the shared element rules in **`eventmodeling-core-rules`** — read it once per session if you haven't already; it defines what a COMMAND/EVENT/READMODEL/SCREEN/AUTOMATION is, how each is named, and the anti-patterns to reject, so this step doesn't restate them.
+
 Prefer `mcp__eventmodelers__*` tools when available (registered by the `connect` skill) — the curl blocks below are the fallback for sessions without MCP connected.
 
 Coordinates the 11-step Event Modeling workflow. Each step delegates to a
@@ -183,7 +185,7 @@ scope, and stated output goal (code, design, learning, docs).
 Confirm understanding before proceeding: "So we're modeling [domain], goal is
 [goal], constraints are [constraints]. Starting from [step]. Does that match?"
 
-**Capture findings** — write to `.trogonai/interviews/[project-name]/EVENTMODELING.md`:
+**Capture findings** — create `.trogonai/interviews/[project-name]/EVENTMODELING.md` with this header (this step is what creates the file; every later step appends to it per `eventmodeling-interview-protocol`):
 
 ```markdown
 # Event Modeling: [Project Name]
@@ -197,10 +199,9 @@ Confirm understanding before proceeding: "So we're modeling [domain], goal is
 
 | Step | Skill | Status | Key Output |
 |------|-------|--------|------------|
-| Orchestration | eventmodeling-orchestrating-event-modeling | Done | Domain scoped, starting point confirmed |
 ```
 
-Update this file as each step completes.
+Then follow **`eventmodeling-interview-protocol`** to record this step's own findings and add its Interview Trail row ("Orchestration" / `eventmodeling-orchestrating-event-modeling` / domain scoped, starting point confirmed). Every later step updates the same file as it completes.
 
 ---
 
@@ -377,12 +378,11 @@ Invoke `eventmodeling-validating-event-models`.
 
 If FAIL: address findings and re-invoke `eventmodeling-validating-event-models`.
 
-**Optional — Production Readiness Checklist**: Invoke
-`eventmodeling-validating-event-models-checklist` when the model is destined
-for production. It runs 17 architectural checks across 7 phases and returns a
+**Optional — Structural Checklist**: Invoke
+`eventmodeling-validating-event-models-checklist` for a second, mechanical
+pass. It runs 12 structural checks across 6 phases and returns a
 PASS / PASS WITH WARNINGS / FAIL verdict independently of Step 9. A PASS on
-Step 9 does not substitute for this checklist when production readiness is
-required.
+Step 9 does not substitute for this checklist.
 
 ---
 
@@ -443,7 +443,7 @@ Not delegated to a separate skill — performed directly by this orchestrating s
    The note's body lives in **`meta.description`** as plain markdown source — headings, lists, bold, code fences, tables all render. **Not `meta.content`** — that field is accepted and stored without error but never rendered by the board UI, producing a visibly empty note; this was caught by comparing against a note authored directly in the UI, so treat it as confirmed, not a guess. There is no separate render/sketch call (unlike SCREEN/HTML_SCREEN) and no `fields[]` array on this element type.
 
 **What the note should actually contain** — write for the next person (or next session) who opens this board cold, not for whoever just built it:
-- **Scope**: what business process this chapter covers, and its stream roots (identity keys).
+- **Scope**: what business process this chapter covers, and its entities (identity keys).
 - **Assumptions added beyond the literal brief** — anything invented to fill a gap the requirements left open, and why (e.g. adding a resolution event so a state isn't a one-way trap door).
 - **Business rules deliberately encoded as scenarios, not new events** — so a reader doesn't mistake a missing event for an oversight.
 - **Sequencing or design corrections made mid-workflow** — e.g. a column reorder because an event's original placement implied the wrong causality.
@@ -475,13 +475,12 @@ A complete, sliced event model consisting of:
 These skills are not part of the 11-step main path but extend the model for
 specific needs:
 
-- **`eventmodeling-designing-event-models`** — Use when stream identity,
-  per-command state shapes, or event causality need detailed design work. Can
-  be applied at any step where those decisions arise, most commonly during or
-  after Step 1.
+- **`eventmodeling-designing-event-models`** — Use when the Command/Event/Read-Model
+  structure or event causality need detailed design work. Can be applied at
+  any step where those decisions arise, most commonly during or after Step 1.
 - **`eventmodeling-optimizing-stream-design`** — Use after the model is
-  complete to validate that every stream is anchored on a single business
-  identity, not a disguised collection or event log.
+  complete to validate that every entity's event timeline is anchored on a
+  single business identity, not a disguised collection or event log.
 - **`eventmodeling-translating-external-events`** — Use when external systems
   (webhooks, IoT, third-party APIs) need to feed into the domain model.
 

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-plotting-events/SKILL.md

@@ -10,6 +10,8 @@ allowed-tools:
 
 > **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Do not proceed until it has completed. Consult `learn-eventmodelers-api` only if you need to look up a specific endpoint or field this file doesn't cover — don't load it eagerly.
 
+This step applies the shared element rules in **`eventmodeling-core-rules`** — read it once per session if you haven't already; it defines what a COMMAND/EVENT/READMODEL/SCREEN/AUTOMATION is, how each is named, and the anti-patterns to reject, so this step doesn't restate them.
+
 Prefer `mcp__eventmodelers__*` tools when available (registered by the `connect` skill) — the curl blocks below are the fallback for sessions without MCP connected.
 
 Arrange all brainstormed events chronologically to create a logical sequence that makes sense as a narrative timeline. Show how events flow and depend on each other.
@@ -78,6 +80,8 @@ Path A: Payment succeeds → PaymentProcessed
 Path B: Payment fails → PaymentFailed → OrderCancelled
 ```
 
+**Every path here is a decision point, not a divergent journey** — by the time plotting runs, chapter structure is already fixed (Step 1), so a path in this step is always one trigger resolving to one of several outcomes within *this* timeline's story, shown as branching columns. If a "path" you're documenting actually starts a different story with its own screens/commands rather than just deciding how this one ends, it was mis-grouped in Step 1 — stop and send it back to `eventmodeling-brainstorming-events`'s chapter grouping (see its "Divergent journey vs. a decision point" note) rather than modeling it as a branch here.
+
 ### 4. Create Timeline Diagram
 Visual representation of event flow:
 

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-slicing-event-models/SKILL.md

@@ -11,6 +11,8 @@ allowed-tools:
 
 > **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Do not proceed until it has completed. Consult `learn-eventmodelers-api` (in particular the **Slices** section) only if you need to look up a specific endpoint or field this file doesn't cover — don't load it eagerly.
 
+This step applies the shared element and slice rules in **`eventmodeling-core-rules`** — read it once per session if you haven't already; its "Slices" section defines the state-change/state-view/automation slice types this step derives, so this step doesn't restate them.
+
 > Prefer `mcp__eventmodelers__*` tools when available (registered by the `connect` skill) — the curl blocks below are the fallback for sessions without MCP connected.
 
 **Purpose**: Turn a completed event model's timeline into explicit slice definitions on the board, and note the event dependencies between them.
@@ -24,21 +26,7 @@ allowed-tools:
 
 ## Core Concept: A Slice Is One Command, One Read Model, or One Automation — Never Combined
 
-A **Feature Slice** is the thinnest possible vertical cut through the model — exactly one decision or one query:
-
-```
-state-change slice = SCREEN/Processor → COMMAND → EVENT(s)
-state-view slice   = EVENT(s) → READMODEL → SCREEN/Processor
-automation slice   = EVENT(s) → AUTOMATION → COMMAND → EVENT(s)
-```
-
-A slice never mixes a COMMAND and a READMODEL — the platform models these as two distinct slice types (`state-change` and `state-view`). If a "feature" needs both a command and a read model (e.g. "place an order" needs the `PlaceOrder` command *and* an `OrderDetailView` read model), that's **two slices**, not one.
-
-**Key characteristics**:
-- Exactly one COMMAND (state-change), exactly one READMODEL (state-view), or one AUTOMATION's command — never combined
-- Named after that command, read model, or automation
-- Independently deployable
-- Communicates with other slices via events only
+See `eventmodeling-core-rules`'s "Slices" section for the definition (state-change / state-view / automation, never combined) and why a feature needing both a command and a read model is two slices, not one.
 
 ---
 

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-storyboarding-events/SKILL.md

@@ -11,18 +11,16 @@ allowed-tools:
 
 > **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Do not proceed until it has completed. Consult `learn-eventmodelers-api` only if you need to look up a specific endpoint or field this file doesn't cover — don't load it eagerly.
 
+This step applies the shared element rules in **`eventmodeling-core-rules`** — read it once per session if you haven't already; it defines what a COMMAND/EVENT/READMODEL/SCREEN/AUTOMATION is, how each is named, and the anti-patterns to reject, so this step doesn't restate them.
+
 Prefer `mcp__eventmodelers__*` tools when available (registered by the `connect` skill) — the curl blocks below are the fallback for sessions without MCP connected.
 
 ## Interview Phase (Optional)
 
 **When to Interview**: Skip if the user has already specified: existing UI patterns or mockups to reference, critical data fields, and UI/UX preferences. Interview when these details haven't been discussed or when the user wants guidance on storyboarding depth.
 
-**Interview Strategy**: Clarify UI needs, data priorities, and existing patterns to guide storyboard design. This ensures mockups capture all necessary fields without over-designing.
-
 ### Critical Questions
 
-When UI design guidance is needed:
-
 1. **Current UI State** (Impact: Determines if you're designing from scratch or enhancing existing)
    - Question: "Do you have: (A) Existing UI/wireframes to reference, (B) Rough sketches, (C) Starting from scratch?"
    - Why it matters: Existing UI provides constraints and patterns; starting fresh allows more design freedom
@@ -38,52 +36,7 @@ When UI design guidance is needed:
    - Why it matters: Platform and fidelity affect storyboard detail; mobile has different constraints than web
    - Follow-up triggers: If (C) → ask about prototype tool; if minimal → discuss what level of detail is enough
 
-### Interview Flow
-
-**Conditional Entry**:
-```
-If user has provided:
-  - Existing UI patterns or references
-  - AND identified critical data fields
-  - AND specified storyboard detail level
-
-Then: Skip interview, proceed directly to storyboarding
-
-Else: Conduct interview
-```
-
-**Phase 1: Context Assessment** (Questions 1-2)
-- Understand existing UI context
-- Identify data priorities
-- Establish storyboard scope
-
-**Phase 2: Design Guidance** (Question 3)
-- Determine platform and fidelity
-- Adjust storyboard detail accordingly
-
-### Capturing Interview Findings
-
-Document findings to guide storyboard creation:
-
-```markdown
-## Interview Findings: [Domain Name] UI
-
-**Existing UI Context**: [Starting from scratch / Enhancing / Matching pattern]
-**Most Critical Data**: [List fields in priority order]
-**Platform**: [Web / Mobile / Both]
-**Storyboard Detail**: [Minimal wireframes / Detailed mockups]
-
-**Key UI Interactions**:
-- [Action 1]: [What data triggers it]
-- [Action 2]: [What data triggers it]
-
-**Storyboard Focus**:
-- Prioritize showing [most critical fields]
-- Ensure [specific interactions] are clear
-- Reference [existing patterns] for consistency
-```
-
-Optional: Write to `.trogonai/interviews/[timestamp]-storyboarding-events.interview.internal.trogonai.md`.
+Follow **`eventmodeling-interview-protocol`** to run this interview and record its findings — label this step "**3. Storyboarding** (`eventmodeling-storyboarding-events`)". Findings should cover: existing UI context, most critical data fields (priority order), platform and detail-level preferences, key UI interactions, and storyboard focus.
 
 ---
 

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-translating-external-events/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: eventmodeling-translating-external-events
-description: "Translate external system events (webhooks, APIs, IoT) into domain events. Map technical data to business concepts. Use when integrating with external systems that emit events your domain needs to react to. Do not use for: designing command handlers for the translated events (use eventmodeling-designing-event-models)."
+description: "Translate external system events (webhooks, APIs, IoT) into domain events. Map technical data to business concepts. Use when integrating with external systems that emit events your domain needs to react to. Do not use for: designing the commands/read models for the translated events (use eventmodeling-designing-event-models)."
 allowed-tools:
   - AskUserQuestion
   - Write
@@ -11,12 +11,12 @@ allowed-tools:
 
 > **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Do not proceed until it has completed. Consult `learn-eventmodelers-api` only if you need to look up a specific endpoint or field this file doesn't cover — don't load it eagerly.
 
+This step applies the shared element rules in **`eventmodeling-core-rules`** — read it once per session if you haven't already; it defines what a COMMAND/EVENT/READMODEL/SCREEN/AUTOMATION is, how each is named, and the anti-patterns to reject, so this step doesn't restate them.
+
 ## Interview Phase (Optional)
 
 **When to Interview**: Skip if the user has specified: external systems involved, webhook/API formats, and domain mapping. Interview when external systems haven't been fully cataloged or translation rules are unclear.
 
-**Interview Strategy**: Catalog all external systems and understand their event formats before defining translation rules. Missing correlation strategies — how external IDs map back to domain entities — are the most common source of integration failures, so surface them early.
-
 ### Critical Questions
 
 1. **External System Details** (Impact: Determines what translation rules to create)
@@ -29,59 +29,7 @@ allowed-tools:
    - Why it matters: Simple 1-to-1 mappings vs. complex multi-source translations affect design
    - Follow-up triggers: If (B) or (C) → ask "What data must you look up from your own system to complete the translation? How do you handle arrival before that data exists?"
 
-### Interview Flow
-
-**Conditional Entry**:
-```
-If user has provided:
-  - Full list of external systems with event types
-  - AND sample payload formats for each event type
-  - AND correlation strategy (how to link external IDs to domain entity IDs)
-
-Then: Skip interview, proceed directly to translation rule design
-
-Else: Conduct interview
-```
-
-**Phase 1: External System Catalog** (Question 1)
-- Enumerate all systems that send events into the domain
-- Document event types and payload formats for each
-- Identify authentication and delivery mechanisms (webhook, polling, streaming)
-
-**Phase 2: Mapping Complexity Assessment** (Question 2)
-- Identify which integrations require enrichment from domain data
-- Surface correlation gaps (external ID ≠ domain ID)
-- Flag multi-source aggregations for deeper design attention
-
-### Capturing Interview Findings
-
-Append findings to the project's event modeling file:
-
-**File**: `.trogonai/interviews/[project-name]/EVENTMODELING.md`
-
-Use Write tool to add/update this section:
-
-```markdown
-## Translating External Events (eventmodeling-translating-external-events)
-
-### External Systems Catalog
-[From Q1: System names, event types, formats, auth mechanisms]
-
-### Mapping Complexity
-[From Q2: Direct mappings vs. complex enrichment needs, correlation gaps]
-
-### Correlation Strategies
-- [System A]: correlates via [reference field / lookup table]
-- [System B]: correlates via [metadata in external payload]
-
-### High-Risk Integrations
-- [System needing multi-source data]: [risk description]
-```
-
-Update Interview Trail:
-```markdown
-| Ext. Events | eventmodeling-translating-external-events | Done | External systems cataloged, correlation strategies defined |
-```
+Follow **`eventmodeling-interview-protocol`** to run this interview and record its findings — label this step "**Translating External Events** (`eventmodeling-translating-external-events`)". Findings should cover: the external systems catalog (names, event types, formats, auth), mapping complexity, correlation strategies (how external IDs map to domain entity IDs), and any high-risk integrations needing multi-source data.
 
 ---
 

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-validating-event-models/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: eventmodeling-validating-event-models
-description: "Step 9 of Event Modeling - Validate event-sourced models for completeness, consistency, and event sourcing principles. Ensures events are immutable facts, state projections are deterministic, and commands are pure. Identifies gaps and suggests improvements before code generation. Use when reviewing models before code generation. Do not use for: the structured 17-check production checklist (use eventmodeling-validating-event-models-checklist) or field-level completeness verification (use eventmodeling-checking-completeness)."
+description: "Step 9 of Event Modeling - Validate the model for completeness and consistency. Ensures events are immutable facts, read models are deterministic projections, and commands are traceable decisions. Identifies gaps before the model is declared done. Use when reviewing a model before it's considered final. Do not use for: the structured 12-check checklist (use eventmodeling-validating-event-models-checklist) or field-level completeness verification (use eventmodeling-checking-completeness)."
 allowed-tools:
   - Write
   - Bash
@@ -10,6 +10,8 @@ allowed-tools:
 
 > **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Do not proceed until it has completed. Consult `learn-eventmodelers-api` only if you need to look up a specific endpoint or field this file doesn't cover — don't load it eagerly.
 
+This step applies the shared element rules in **`eventmodeling-core-rules`** — read it once per session if you haven't already; it defines what a COMMAND/EVENT/READMODEL/SCREEN/AUTOMATION is, how each is named, and the anti-patterns to reject, so this step doesn't restate them.
+
 Prefer `mcp__eventmodelers__*` tools when available (registered by the `connect` skill) — the curl blocks below are the fallback for sessions without MCP connected.
 
 For validation you treat the Event Model as read only. The only thing you are allowed to change is comments.
@@ -38,7 +40,8 @@ mcp__eventmodelers__get_nodes { "boardId": "$BOARD_ID", "type": "READMODEL" }
 After validation, use the `handle-comment` skill to post findings on the relevant nodes — `TASK` for critical violations that must be fixed, `QUESTION` for warnings and recommendations. (That skill already handles the `add_comment` MCP-vs-curl choice internally — no separate rewrite needed here.)
 
 ## Purpose
-Ensures event-sourced models are complete, correct, and follow pure event sourcing principles (minimal per-command state).
+
+Ensures the event model is complete, correct, and internally consistent.
 
 ## Workflow
 
@@ -54,12 +57,12 @@ mcp__eventmodelers__validate_model { "boardId": "$BOARD_ID", "chapterId": "<chap
 
 It returns a compact `findings` list (no node dumps) covering: unplaced nodes, backward arrows among the forward-only pairs (with the todo-list `EVENT → READMODEL` exception already applied), COMMANDs with zero or multiple issuers, READMODELs with no inbound EVENT, columns with more than one screen, and COMMAND/READMODEL columns with no SCENARIO. This replaces the per-type `get_nodes` scans and the `get_node` `projection: "edges"` spot-checks those manual checks would otherwise need — start from its `findings`, then use the sections below for the semantic checks it can't make (naming, immutability, field-source traceability, scenario coverage depth). A `verdict` of `PASS` on `validate_model` is necessary but not sufficient — still do the semantic pass.
 
-### 1. Swimlane Completeness Check
+### 1. Entity/Timeline Completeness Check
 
-Verify each swimlane has:
+Verify each entity's timeline has:
 - Clear name (identity)
 - At least one event type
-- Initial event (what creates the stream)
+- An initial event (what starts the entity's story)
 - State transitions documented
 
 **For each event:**
@@ -68,142 +71,115 @@ Verify each swimlane has:
 - All data is **immutable**
 - Unique semantics (no duplicates)
 
-**For each state projection:**
-- Can be deterministically rebuilt from events
-- Replay logic is pure (no side effects)
+**For each read model:**
+- Can be deterministically derived from events
+- No side effects in how it's built
 
 **For each command:**
 - Clear input parameters
-- Validation rules defined in scenarios (against state)
+- Preconditions defined in scenarios
 - Resulting events specified (or rejection reason)
-- Pure logic (no side effects except event appending)
 
 ### 2. Consistency Checks
 
-- [ ] **Event-Stream Mapping**: Every event belongs to exactly one lane
+- [ ] **Event-Entity Mapping**: Every event belongs to exactly one lane/entity
 - [ ] **Single Command Issuer**: Every command is issued by exactly one SCREEN or AUTOMATION — never two. Check each COMMAND node's inbound edges; more than one SCREEN/AUTOMATION wired into the same command is a CRITICAL violation (commonly an auto-connect artifact — see `place-element` Step 7c)
-- [ ] **Command Outcomes**: Every command produces events OR documents rejection
-- [ ] **Deterministic Projections**: State can only be derived one way from events
-- [ ] **No Side Effects in Projections**: Pure state reconstruction logic
+- [ ] **Command Outcomes**: Every command produces events OR documents a rejection
+- [ ] **Deterministic Read Models**: A read model can only be derived one way from its events
 - [ ] **Event Immutability**: No event data is ever modified
 - [ ] **Naming Consistency**: Are naming patterns consistent?
-  - Commands: Verb present (CreateOrder, ConfirmPayment)
-  - Events: Verb past tense (OrderCreated, PaymentConfirmed)
+  - Commands: present-tense verb (CreateOrder, ConfirmPayment)
+  - Events: past-tense verb (OrderCreated, PaymentConfirmed)
 
-### 3. Event Sourcing Principles Compliance
+### 3. Event Modeling Principles Compliance
 
-Check against event sourcing fundamentals:
-
-- [ ] **Events are Facts**: Events describe what happened, not potential futures
+- [ ] **Events are Facts**: describe what happened, not potential futures
   - "OrderMayBeConfirmed" →  "OrderConfirmed"
-  - "PaymentPending" (in events) →  "PaymentInitiated", "PaymentAuthorized"
+  - "PaymentPending" (as an event) →  "PaymentInitiated", "PaymentAuthorized"
 
-- [ ] **Events are Immutable**: No modification of event data
+- [ ] **Events are Immutable**: no modification of event data
   - "Update OrderCreated event with new total" →  "Append OrderTotalCorrected event"
 
-- [ ] **Complete Event Data**: Events contain all facts needed for state rebuild
-  - Event: "OrderConfirmed" (missing paymentId) →  Event includes paymentId
-
-- [ ] **No Computed Fields in Events**: Only raw captured facts
-  - OrderCreated includes "totalTax" (computed) →  Includes items + amounts, tax computed in projection
+- [ ] **Complete Event Data**: events contain all facts a read model needs to project them
+  - Event "OrderConfirmed" missing paymentId →  Event includes paymentId
 
-- [ ] **Deterministic Projections**: Replaying events always produces same state
-  - Projection uses: for each event, do X
-  - Projection uses: external API call during replay
+- [ ] **No Computed Fields in Events**: only raw captured facts
+  - OrderCreated includes "totalTax" (computed) →  Includes items + amounts; tax computed in the read model
 
-- [ ] **State is Derived**: Current state always comes from replaying events
-  - "Load state: replay all events for Order:123"
-  - "Load state: query database Orders table"
+- [ ] **Deterministic Read Models**: replaying the same events always produces the same read model
 
 ### 4. Event Flow Validation
 
-- [ ] **Command → Event Mapping**: Clear what each command produces
-- [ ] **No Zombie Commands**: Commands that never produce events (read-only OK)
+- [ ] **Command → Event Mapping**: clear what each command produces
+- [ ] **No Zombie Commands**: commands that never produce events (read-only commands are fine if documented as such)
 
 ### 5. Role & Actor Attribution Validation
 
 Verify that every command has explicit actor attribution from the Role Catalog:
 
-- [ ] **Role Catalog exists**: A Role Catalog was defined in Step 1 (eventmodeling-brainstorming-events)
-  - CRITICAL: No Role Catalog found — commands have no actor attribution
+- [ ] **Role Catalog exists**: a Role Catalog was defined in Step 1 (eventmodeling-brainstorming-events)
+  - CRITICAL: no Role Catalog found — commands have no actor attribution
   - PASS: Role Catalog with human roles and system actors defined
 
-- [ ] **Every command has actor attribution**: No command uses generic "User"
+- [ ] **Every command has actor attribution**: no command uses generic "User"
   - CRITICAL: `CreateOrder` attributed to "User" (which user? Customer? Admin? Seller?)
   - PASS: `CreateOrder` attributed to "Customer" (specific role from catalog)
 
-### 6. Command State Read Models Validation (CRITICAL)
+### 6. Command Validation
 
- **This is the PRIMARY validation gate. Violations are CRITICAL and must be fixed before approval.** Validate that **command state read models** are **minimal and command-specific**, not bundled like DDD aggregates.
-
-### 7. Command & State Validation
-
-- [ ] **State-Based Decisions**: Commands decide based on current state only
-- [ ] **Valid State Transitions**: Document what state changes are allowed
+- [ ] **Preconditions Clear**: when can each command execute?
+  - "Can only confirm if state is Draft"
+  - "Can sometimes confirm"
+- [ ] **Rejection Handling**: what happens if a precondition fails?
+  - "Reject, no events appended"
+  - "Append a rejection/failure event and continue" (if that's the modeled outcome)
+- [ ] **Valid State Transitions**: document what state changes are allowed
 ```text
 Draft → Confirmed (ConfirmOrder)
 Draft → Cancelled (CancelOrder)
 Confirmed → Shipped (ShipOrder)
 Confirmed ↛ Draft (invalid)
 ```
-- [ ] **Preconditions Clear**: When can each command execute?
-  - "Can only confirm if state is Draft"
-  - "Can sometimes confirm"
-- [ ] **Error Handling**: What happens if validation fails?
-  - "Reject with ValidationError, no events appended"
-  - "Append ErrorEvent and continue"
 
-### 8. Projection Validation
+### 7. Read Model Validation
 
-- [ ] **Read Models**: Read models are rich projections
-- [ ] **Read Models Optional**: Are they needed or just convenience?
-- [ ] **Regenerable**: Can be rebuilt from events at any time
+- [ ] **Read Models**: are rich projections shaped for their query
+- [ ] **Read Models Optional**: are they needed, or just convenience?
+- [ ] **Regenerable**: could be rebuilt from events at any time
 
-### 9. Issues & Recommendations Report
+### 8. Issues & Recommendations Report
 
 Format findings as comments:
 
 ```markdown
-
 ## Validation Summary
 
 **Overall Status**:  Ready with recommendations
 
-**Blockers for Implementation**: 0 critical issues
+**Blockers**: 0 critical issues
 
 **Recommended Fixes**:
 1. Add missing OrderCancelled event
-2. Move PaymentMethod to its own minimal state projection
-3. Document all implicit invariants explicitly
-
-**Ready for Code Generation**: Yes, after implementing recommendations
+2. Document all implicit preconditions explicitly
 
 ## Next Steps
 1. Review recommendations with domain expert
 2. Update model with critical fixes
-3. Proceed to code generation
 ```
 
 ## Common Issues to Flag
 
 | Issue | Pattern | Fix |
 |-------|---------|-----|
-| Missing cancellation flows | No "Cancelled" events | Add compensation paths |
-| Implicit invariants | "Obviously can't do X" | Make invariants explicit |
-| Command state too broad | Shared state used by 2+ commands | Split into per-command minimal state projections |
-| Orphaned events | Events no one listens to | Link to projections or commands |
-| No read models | Commands reading query/read models for validation | Add separate query read models; keep command state minimal |
-| Circular dependencies | Projection A depends on B, B on A | Redesign stream boundaries |
+| Missing cancellation flows | No "Cancelled" events | Add the missing outcome slices |
+| Implicit preconditions | "Obviously can't do X" | Make preconditions explicit |
+| Orphaned events | Events no one reads | Link to a read model or command |
+| No read models | Commands validated against raw event replay with no documented read model | Add a read model documenting what the command actually reads |
 | Command issued by multiple things | COMMAND node has 2+ inbound SCREEN/AUTOMATION edges | Keep the deliberate same-column issuer, remove the rest via `set_connection` (`action: "remove"`) — see `place-element` Step 7c |
 
-## Key Principles for Event Sourcing
+## Key Principles
 
-1. **Events are the source of truth**: Everything else is derived from them
-2. **Immutable event log**: Events never change, only appended
-3. **State is a projection**: Current state is built by replaying events
-4. **Commands are pure decisions**: Validate against state, produce events or reject
-5. **Projections are optional**: Can be rebuilt at any time
-6. **Stream per entity**: Each entity has one append-only event stream
+See `eventmodeling-core-rules` for the element definitions this validation checks against (events as immutable facts, read models as optional projections, commands as decisions against documented preconditions).
 
 ## Success Criteria
 
@@ -211,39 +187,24 @@ Your event model validation is successful when:
 
 - All requirements are captured in events
 - Commands clearly trigger events
-- Stream roots have clear, minimal boundaries
-- Business rules are explicit invariants (not hidden assumptions)
-- Read models serve actual query needs (not used by commands)
-- Command state is minimal and command-specific (not shared across multiple commands)
+- Business rules are explicit preconditions (not hidden assumptions)
+- Read models serve actual query needs
 - Events are immutable facts (past tense, no computed fields)
-- State can be deterministically rebuilt from events
 - All command-to-event mappings are documented
 - Critical issues are resolved or documented as known limitations
-
-A model is **ready for code generation** if:
-- No critical issues remain
-- All command state follows naming convention (e.g., `[CommandName]State`)
-- No state is shared between different commands
-- All events are immutable facts
-- All business rules are explicit
-- A Role Catalog exists with all human roles and system actors
-- Every command has explicit actor attribution from the Role Catalog
+- A Role Catalog exists with all human roles and system actors, and every command has explicit actor attribution
 
 ## Quality Checklist
 
 - [ ] All events are immutable facts (past tense)
 - [ ] No computed fields stored in events
-- [ ] State projection is deterministic from events
-- [ ] Commands validate against current state only
+- [ ] Read models are derived deterministically from events
+- [ ] Commands are checked against documented preconditions
 - [ ] Each command either produces events or rejects (no silent failures)
 - [ ] **No command has more than one inbound SCREEN/AUTOMATION edge (a command is never issued by more than one thing)**
 - [ ] Event causality/command-event mapping is clear
 - [ ] State transitions are documented
-- [ ] No direct references between lanes
-- [ ] Projections serve specific query needs (or are removed)
-- [ ] Everything can be rebuilt from the event stream
-- [ ] No state is shared between different commands
-- [ ] All command state is minimal (only fields needed for validation)
+- [ ] Read models serve specific query needs (or are removed)
 - [ ] **Role Catalog exists with human roles and system actors**
 - [ ] **Every command attributed to a specific role/actor (no generic "User")**
 - [ ] **Every human role has at least one command and one read model**