@eventmodelers/cli 1.0.37 → 1.0.38

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-identifying-inputs/SKILL.md

@@ -11,14 +11,14 @@ 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 identified UI actions/commands and processor triggers. Interview when it's unclear which actions are user-initiated vs. processor-automated.
 
-**Interview Strategy**: Separate UI-driven commands from processor-driven commands before cataloging inputs. Mixing them leads to incorrect role attribution, which breaks the Role Catalog traceability that downstream steps depend on.
-
 ### Critical Questions
 
 1. **Automation Level** (Impact: Determines which commands are UI-triggered vs. processor-triggered)
@@ -31,54 +31,7 @@ Prefer `mcp__eventmodelers__*` tools when available (registered by the `connect`
    - Why it matters: External triggers are processor commands, not UI commands
    - Follow-up triggers: If (B) or (D) → ask which external systems send webhooks and what data they include
 
-### Interview Flow
-
-**Conditional Entry**:
-```
-If user has provided:
-  - UI actions already listed per storyboard screen
-  - AND processor triggers identified with source systems named
-  - AND it's clear which role/actor initiates each action
-
-Then: Skip interview, proceed directly to command identification
-
-Else: Conduct interview
-```
-
-**Phase 1: Trigger Classification** (Question 1)
-- Establish which commands come from human actors vs. automated processors
-- Confirm Role Catalog from Step 1 is available for attribution
-
-**Phase 2: External Triggers** (Question 2)
-- Identify all external system integrations that issue commands
-- Confirm whether scheduled jobs or event-driven processors exist
-
-### 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
-## 4. Identifying Inputs (eventmodeling-identifying-inputs)
-
-### Automation Classification
-[From Q1: Which actions are user-initiated vs. processor-automated?]
-
-### External System Triggers
-[From Q2: Which external systems trigger commands? Webhook formats?]
-
-### Command Attribution Summary
-- UI-issued commands: [list with role from Role Catalog]
-- Processor-issued commands: [list with source system]
-```
-
-Update Interview Trail:
-```markdown
-| 4 | eventmodeling-identifying-inputs | Done | UI commands, processor commands, role attribution |
-```
+Follow **`eventmodeling-interview-protocol`** to run this interview and record its findings — label this step "**4. Identifying Inputs** (`eventmodeling-identifying-inputs`)". Findings should cover: automation classification (user-initiated vs. processor-automated), external system triggers, and a command attribution summary (UI-issued vs. processor-issued, each with its role/source).
 
 ---
 

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-identifying-outputs/SKILL.md

@@ -11,14 +11,14 @@ 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 clearly identified: read model queries needed by UI, processor needs, and refresh patterns. Interview when unclear which data queries are critical or how frequently they're accessed.
 
-**Interview Strategy**: Establish query patterns and identify any calculations before designing read models. The most common architecture error at this step is modeling recalculated state as an event — identifying calculated fields upfront prevents that anti-pattern.
-
 ### Critical Questions
 
 1. **Query Patterns** (Impact: Determines which read models are needed and their update frequency)
@@ -31,58 +31,7 @@ Prefer `mcp__eventmodelers__*` tools when available (registered by the `connect`
    - Why it matters: Common mistake to model calculations as events; identifying them upfront prevents architecture errors
    - Follow-up triggers: For each calculated field mentioned → confirm "This recalculates as source data changes, so it belongs in a read model projection — does that match your expectation?"
 
-### Interview Flow
-
-**Conditional Entry**:
-```
-If user has provided:
-  - UI screens with data needs mapped to event sources
-  - AND processor query needs documented
-  - AND calculated/aggregated fields identified as read models (not events)
-
-Then: Skip interview, proceed directly to read model design
-
-Else: Conduct interview
-```
-
-**Phase 1: Query Pattern Mapping** (Question 1)
-- Identify which UI screens and processors need which data
-- Typically every screen needs some kind of data, same for automations.
-- Establish freshness requirements per consumer
-- Determine if any queries require real-time consistency
-
-**Phase 2: Calculation Detection** (Question 2)
-- Surface any aggregated or computed values
-- Confirm they are projections, not events
-- Prevent the calculation-as-event anti-pattern before design begins
-
-### 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
-## 5. Identifying Outputs (eventmodeling-identifying-outputs)
-
-### Query Patterns
-[From Q1: Which consumers need what freshness? Real-time vs. periodic?]
-
-### Calculated Fields Identified
-[From Q2: Which fields are aggregated/calculated? Confirmed as read models?]
-
-### Read Model Summary
-- Real-time read models: [list]
-- Near-real-time read models: [list]
-- Calculation-as-event anti-patterns caught: [list or "None"]
-```
-
-Update Interview Trail:
-```markdown
-| 5 | eventmodeling-identifying-outputs | Done | Read model catalog, query patterns, calculation classification |
-```
+Follow **`eventmodeling-interview-protocol`** to run this interview and record its findings — label this step "**5. Identifying Outputs** (`eventmodeling-identifying-outputs`)". Findings should cover: query patterns (which consumers need what freshness), calculated/aggregated fields identified (and confirmed as read models, not events), and a read model summary by freshness tier.
 
 ---
 

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-interview-protocol/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: eventmodeling-interview-protocol
+description: Shared procedure for deciding whether to ask the user clarifying questions before an event-modeling step proceeds, and how to record what was decided. Not a step of its own — referenced by other eventmodeling-* skills' Interview Phase section. Do not use standalone.
+---
+
+# Interview Protocol
+
+Shared by every event-modeling step that has an "Interview Phase" section. A step's own SKILL.md defines only what's specific to it — when to interview and its Critical Questions. Everything below is common to all of them.
+
+## When to ask
+
+Missing information, or something ambiguous that this step needs? Ask the user — using the step's own Critical Questions as a guide, via `AskUserQuestion` where appropriate. Follow any listed follow-up trigger based on the answer.
+
+Already have everything the step needs? Skip straight to the step's own workflow — don't ask questions whose answers you already have.
+
+**Unless told not to ask** (an autonomous/unattended run, or the user has said not to stop for questions): don't block. Proceed with the most reasonable assumption for anything missing, and say so plainly in this step's findings below — visibly, so it can be corrected later. Never silently guess.
+
+## Recording the outcome
+
+Append to the project's event modeling file: `.trogonai/interviews/[project-name]/EVENTMODELING.md`, under a section for this step:
+
+```markdown
+## <Step Number>. <Step Name> (<skill-name>)
+[What was asked and decided — or, if nothing was asked, what was assumed and why]
+```
+
+Then add or update this step's row in the `## Interview Trail` table (create it if this is the first step to run):
+
+```markdown
+| <Step Number> | <skill-name> | Done | <one-line summary of key outputs> |
+```

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-optimizing-stream-design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: eventmodeling-optimizing-stream-design
-description: "Validate and fix event stream boundaries — is each stream anchored on a single business identity, or is it secretly a collection/log that will grow unbounded? Use when concerned about stream length, reviewing stream design before implementation, or when a stream feels like it's absorbing unrelated events. Do not use for: designing the initial event model structure (use eventmodeling-designing-event-models) or general architectural validation (use eventmodeling-validating-event-models)."
+description: "Validate and fix an entity's event timeline boundary — is it anchored on a single business identity, or is it secretly a collection/log that will grow unbounded? Use when concerned about a timeline mixing concerns, reviewing timeline boundaries, or when a timeline feels like it's absorbing unrelated events. Do not use for: designing the initial event model structure (use eventmodeling-designing-event-models) or general model validation (use eventmodeling-validating-event-models)."
 allowed-tools:
   - AskUserQuestion
   - Write
@@ -8,102 +8,64 @@ allowed-tools:
 
 # Optimizing Stream Design
 
-## Interview Phase (Optional)
+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.
 
-**When to Interview**: Skip if the user has already named the entity each stream is anchored on and confirmed every event in it belongs to that entity's own lifecycle. Interview when a stream's boundary feels unclear or it seems to be absorbing events from more than one concern.
+## Timeline Boundary Optimization
 
-**Interview Strategy**: This is a boundary question, not a performance question — establish what single business identity a stream is supposed to represent before judging whether it's well-designed.
-
-### Critical Question
-
-**Stream Identity** (Impact: Determines whether the stream is a real aggregate or a disguised collection/log)
-- Question: "What one business entity does this stream represent the history of? Does every event in it belong to that entity's own lifecycle, or does it also pick up events from a broader category?"
-- Why it matters: A stream with no single identity, or one that mixes in events belonging to other entities, is the root cause behind almost every stream-design complaint — not stream length itself.
-- Follow-up triggers: If the answer names a category ("all orders", "system events") rather than one entity → that's Pattern 3/4 in `references/patterns.md` (Collection/Event Log anti-patterns) — walk through the fix directly.
-
-### 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
-## Optimizing Stream Design (eventmodeling-optimizing-stream-design)
-
-### Stream Identity Review
-[Which streams were reviewed? What entity does each represent? Any that turned out to be a disguised collection/log?]
-
-### Boundary Decisions
-- Streams requiring redesign: [list or "None"]
-- Streams confirmed well-bounded: [list]
-```
-
-Update Interview Trail:
-```markdown
-| Optimization | eventmodeling-optimizing-stream-design | Done | Stream identity review, boundary decisions |
-```
-
----
-
-## Stream Design Optimization
-
-**Purpose**: Validate stream boundaries — confirm each stream is anchored on a single business entity's own lifecycle, and catch the two common anti-patterns (an unbounded collection, or an unrelated event log) before they get built.
+**Purpose**: Validate timeline boundaries — confirm each entity's event timeline is anchored on a single business entity's own lifecycle, and catch the two common anti-patterns (an unbounded collection, or an unrelated event log) before they get modeled further.
 
 **Applies To**: Any domain — e-commerce, banking, SaaS, marketplace, healthcare, etc.
 
 **When to Use**:
-- After defining event streams in domain analysis
-- Before implementing, to validate stream design
-- When a stream feels like it's growing for reasons unrelated to one entity's own story
-- When redesigning a stream whose boundary turned out to be wrong
+- After defining events in domain analysis
+- When a timeline feels like it's growing for reasons unrelated to one entity's own story
+- When redesigning a timeline whose boundary turned out to be wrong
 
 **What It Does**:
-1. Checks that each stream has a single, natural business identity
-2. Identifies streams that are actually collections or logs in disguise
-3. Recommends the correct stream boundary when one is wrong
-4. Distinguishes "this stream is long because the entity has a long history" (fine) from "this stream is long because it's absorbing events that don't belong to it" (a boundary bug)
+1. Checks that each timeline has a single, natural business identity
+2. Identifies timelines that are actually collections or logs in disguise
+3. Recommends the correct boundary when one is wrong
+4. Distinguishes "this timeline is long because the entity has a long history" (fine) from "this timeline is long because it's absorbing events that don't belong to it" (a boundary bug)
 
 ---
 
 ## Core Principle: Get the Identity Right
 
 **Golden Rule**:
-> If a stream feels like it's growing for the wrong reasons, first ask: "Does this stream actually have one business identity, or is it a collection/log wearing an aggregate's name?"
+> If a timeline feels like it's growing for the wrong reasons, first ask: "Does this timeline actually have one business identity, or is it a collection/log wearing an entity's name?"
 
-A long stream is not, by itself, evidence of a design problem — an account open for thirty years is correctly one long stream. What *is* always a design problem is a stream whose events don't all belong to the same entity's own lifecycle.
+A long timeline is not, by itself, evidence of a design problem — an account open for thirty years is correctly one long timeline. What *is* always a design problem is a timeline whose events don't all belong to the same entity's own lifecycle.
 
 ---
 
-## Stream Boundary Review
+## Timeline Boundary Review
 
-For each stream in scope, work through:
+For each entity's timeline in scope, work through:
 
 ### 1. Name the identity
 
-What single business entity does this stream represent the history of? Write it down explicitly (e.g. `orderId`, not "orders").
+What single business entity does this timeline represent the history of? Write it down explicitly (e.g. `orderId`, not "orders").
 
 ### 2. Check every event against that identity
 
-Does each event in the stream describe something that happened to *this* entity — not to a category of entities, not to the system in general? If any event fails this test, the boundary is wrong (see `references/patterns.md`'s Red Flags).
+Does each event on the timeline describe something that happened to *this* entity — not to a category of entities, not to the system in general? If any event fails this test, the boundary is wrong (see `references/patterns.md`'s Red Flags).
 
 ### 3. Classify the result
 
 | Result | Meaning | Action |
 |---|---|---|
 | Every event belongs to one clear entity | Boundary is correct | Keep as-is, regardless of how long the history gets |
-| Events span a category or "all X" | Pattern 3 (Collection) anti-pattern | Re-scope to the real per-entity identity; the category becomes a read model/query, not a stream |
-| Events span unrelated concerns (users, orders, payments mixed) | Pattern 4 (Event Log) anti-pattern | Split into one stream per concern |
-| Stream conflates an entity's active life with its historical record | Missing the Pattern 5 split | Separate active vs. archived/historical streams |
+| Events span a category or "all X" | Pattern 3 (Collection) anti-pattern | Re-scope to the real per-entity identity; the category becomes a read model/query, not an event timeline |
+| Events span unrelated concerns (users, orders, payments mixed) | Pattern 4 (Event Log) anti-pattern | Split into one timeline per concern |
+| Timeline conflates an entity's active life with its historical record | Missing the Pattern 5 split | Separate active vs. archived/historical timelines |
 
 ---
 
 ## Reference Files
 
-**Aggregate Boundary Design**: See [patterns.md](references/patterns.md) for:
-- 5 aggregate boundary patterns (single entity, composite, collection anti-pattern, event-log anti-pattern, historical)
-- The stream boundary decision tree
+**Timeline Boundary Design**: See [patterns.md](references/patterns.md) for:
+- 5 boundary patterns (single entity, composite, collection anti-pattern, event-log anti-pattern, historical)
+- The timeline boundary decision tree
 - Red flags that indicate the boundary — not the volume — is wrong
 - Tips for finding the right boundary
 
@@ -116,9 +78,7 @@ Does each event in the stream describe something that happened to *this* entity
 
 ## Quality Checklist
 
-- [ ] Each stream is identified by a business entity identity (e.g., `orderId`), not a category or type
-- [ ] Every event in a stream belongs to that one entity's own lifecycle — none of them describe a different entity or an unrelated system concern
-- [ ] No stream is secretly a collection ("all X") or a log ("everything that happened") wearing an aggregate's name
-- [ ] Command handler state is reconstructed from stream events — no persistent state stored outside the stream
-- [ ] Each stream can be independently versioned and replayed without affecting other streams
-- [ ] A stream that conflates an entity's active life with its historical record has been split (active vs. archived)
+- [ ] Each timeline is identified by a business entity identity (e.g., `orderId`), not a category or type
+- [ ] Every event on a timeline belongs to that one entity's own lifecycle — none of them describe a different entity or an unrelated system concern
+- [ ] No timeline is secretly a collection ("all X") or a log ("everything that happened") wearing an entity's name
+- [ ] A timeline that conflates an entity's active life with its historical record has been split (active vs. archived)

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-optimizing-stream-design/references/domain-patterns.md

@@ -1,4 +1,4 @@
-# Domain-Specific Stream Boundary Patterns
+# Domain-Specific Timeline Boundary Patterns
 
 ## Contents
 - E-commerce patterns
@@ -11,7 +11,7 @@ Each entry shows a well-scoped boundary for that domain: what identity it's anch
 
 ## E-commerce Domain
 
-**Order Aggregate**:
+**Order Entity**:
 ```
 Identity: orderId
 Lifetime: 1-3 years
@@ -20,17 +20,17 @@ Reason for this boundary: the order has a clear owner (one customer,
 one checkout) and a natural end (delivered, cancelled, refunded)
 ```
 
-**Shopping Cart Aggregate**:
+**Shopping Cart Entity**:
 ```
 Identity: cartId (or customerId, if a customer has exactly one active cart)
 Lifetime: 30 minutes to 2 years (varies widely by product)
 Boundary: Items added/removed for this one cart
 Watch for: an "abandoned" cart and an "active" cart are different
-lifecycles — split into separate streams if their behavior diverges
+lifecycles — split into separate timelines if their behavior diverges
 (e.g. abandoned-cart recovery vs. active checkout flow)
 ```
 
-**User Account Aggregate**:
+**User Account Entity**:
 ```
 Identity: userId
 Lifetime: 5-10+ years
@@ -44,26 +44,26 @@ different concerns with different change frequency — split them
 
 ## Banking Domain
 
-**Account Aggregate**:
+**Account Entity**:
 ```
 Identity: accountId
 Lifetime: 10-50+ years
 Boundary: Deposits, withdrawals, and fees for this one account
 Watch for: an account spanning decades is still one identity — the
-boundary is correct even though the stream is long-lived; don't
+boundary is correct even though the timeline is long-lived; don't
 split it just because it accumulates many events over a long life
 ```
 
-**Transaction Aggregate**:
+**Transaction Entity**:
 ```
 Identity: transactionId
 Lifetime: 1-2 months (then archived)
 Boundary: Requested → Processing → Settled, for this one transaction
 Reason for this boundary: a transaction is a short, self-contained
-lifecycle — treat it as its own stream, not folded into the account
+lifecycle — treat it as its own timeline, not folded into the account
 ```
 
-**Loan Aggregate**:
+**Loan Entity**:
 ```
 Identity: loanId
 Lifetime: 5-30 years
@@ -77,7 +77,7 @@ ActiveLoan vs. CompletedLoan if their consumers genuinely differ
 
 ## SaaS Domain
 
-**Subscription Aggregate**:
+**Subscription Entity**:
 ```
 Identity: subscriptionId
 Lifetime: 1-5+ years
@@ -86,17 +86,17 @@ Reason for this boundary: a subscription has one clear owner and a
 well-defined lifecycle
 ```
 
-**User Workspace Aggregate**:
+**User Workspace Entity**:
 ```
 Identity: workspaceId
 Lifetime: 2-5+ years
 Boundary: Members added, roles changed, settings updated — for this one workspace
 Watch for: workspace-level settings and individual member activity
-are different concerns — keep member activity in its own stream if
+are different concerns — keep member activity in its own timeline if
 it needs independent access patterns
 ```
 
-**Data Collection Aggregate**:
+**Data Collection Entity**:
 ```
 Identity: depends on what's actually being tracked as one thing
 Watch for: this is the domain most likely to hide a Pattern 3
@@ -104,6 +104,6 @@ Watch for: this is the domain most likely to hide a Pattern 3
 points about the same business entity?"
   → If NO, the boundary is wrong: split by whatever entity each
     data point actually belongs to.
-  → If YES, the boundary is fine even if the stream accumulates a
+  → If YES, the boundary is fine even if the timeline accumulates a
     lot of events — that's a volume question, not a boundary one.
 ```

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-optimizing-stream-design/references/patterns.md

@@ -1,25 +1,24 @@
-# Stream Boundary Design Patterns
+# Timeline Boundary Design Patterns
 
 ## Contents
-- Aggregate Boundary Design Patterns (5 patterns with examples)
-- Stream Boundary Decision Tree
+- Entity Boundary Design Patterns (5 patterns with examples)
+- Timeline Boundary Decision Tree
 - Red Flags: Boundary Is Wrong
 - Tips for Finding the Right Boundary
 
 ---
 
-## Aggregate Boundary Design Patterns
+## Entity Boundary Design Patterns
 
 ### Pattern 1: Single Entity (Most Common)
 
-CORRECT: One aggregate per entity
+CORRECT: One timeline boundary per business entity
 ```
-Aggregate: Order
+Entity: Order
 Root Identity: orderId (e.g., 'order-123')
-Entity: The specific order
 Lifetime: 1-2 years
 
-Events in stream:
+Events in timeline:
   1. OrderCreated (2024-01-15)
   2. OrderLineAdded (2024-01-15)
   3. OrderLineAdded (2024-01-15)
@@ -30,16 +29,15 @@ Events in stream:
 
 Identity Principle: orderId is the natural business key
 Boundary: Everything about THIS specific order, nothing else
-Consistency: Only one order being modified at a time
 ```
 
 ---
 
 ### Pattern 2: Composite Entity (Proper Composition)
 
-CORRECT: Aggregate contains related child entities
+CORRECT: Entity contains related child entities
 ```
-Aggregate: Order
+Entity: Order
 Root Identity: orderId (e.g., 'order-456')
 
 Contains related children (same lifetime):
@@ -54,7 +52,7 @@ Contains related children (same lifetime):
   - PaymentInfo:
     method: credit_card, amount: $400
 
-Events in stream:
+Events in timeline:
   1. OrderCreated (customer-789, 3 items)
   2. OrderLineAdded (item 1)
   3. OrderLineAdded (item 2)
@@ -65,16 +63,16 @@ Events in stream:
 
 Pattern: Small, bounded number of children per parent
 Lifetime: Parent and all children created/destroyed together
-Consistency: All modified as a unit (can't ship without payment, etc.)
+Together: they change as a unit (can't ship without payment, etc.)
 ```
 
 ---
 
 ### Pattern 3: Collection (ANTI-PATTERN - DO NOT USE)
 
-WRONG: Treating a collection as an aggregate
+WRONG: Treating a collection as an entity
 ```
-Bad Aggregate: AllOrders
+Bad Entity: AllOrders
 Root Identity: "all-orders-collection" (artificial, meaningless)
 
 Contains: Every order ever created
@@ -87,23 +85,21 @@ Events:
 
 Problems with this approach:
   - No single business identity (it's a collection, not an entity)
-  - Stream grows unbounded — no natural end to its lifetime
-  - Can't split or scale
-  - Every write goes to the same stream (contention)
+  - Timeline grows unbounded — no natural end to its lifetime
 
-Solution: Use a projection/read model query instead, not an aggregate
+Solution: Use a projection/read model query instead, not an entity
   - Query: "GetAllOrdersByCustomer(customer-id)"
   - Query: "GetOrdersByStatus(status)"
-  - Rebuild from individual Order streams on-demand
+  - Rebuild from individual Order timelines on-demand
 ```
 
 ---
 
 ### Pattern 4: Event Log (ANTI-PATTERN - DO NOT USE)
 
-WRONG: Using an aggregate as an event log
+WRONG: Using an entity as an event log
 ```
-Bad Aggregate: SystemLog
+Bad Entity: SystemLog
 Root Identity: "system-log" (meaningless placeholder)
 
 Contains: Every system event imaginable
@@ -119,23 +115,19 @@ Events:
 Problems with this approach:
   - No business identity (log of everything)
   - Events unrelated to each other (mixing user, order, payment, inventory)
-  - No consistency boundary (user login != order creation)
   - Can't answer "what's the state of X?" (too mixed)
-  - Contention: every subsystem writing to the same stream
-  - Can't replay meaningfully (mixed concerns)
 
-Solution: Use separate event streams per business entity
-  - Keep dedicated event streams: Order, Payment, Inventory, User
-  - Use a time-series database for metrics/logs, not a domain stream
+Solution: Use separate event timelines per business entity
+  - Keep dedicated event timelines: Order, Payment, Inventory, User
 ```
 
 ---
 
-### Pattern 5: Historical Aggregate (GOOD - When Needed)
+### Pattern 5: Historical Entity (GOOD - When Needed)
 
 CORRECT: Keep historical data for audit/compliance as its own boundary
 ```
-Aggregate: ArchivedOrder
+Entity: ArchivedOrder
 Root Identity: archivedOrderId (e.g., 'archived-order-001')
 Purpose: Regulatory compliance (7-year retention)
 
@@ -157,8 +149,8 @@ Events:
 
 Lifetime: 7 years (regulatory requirement)
 
-Key architectural principles:
-  - Completely separate from the active Order aggregate
+Key principles:
+  - Completely separate from the active Order entity
   - Active Order is for current business operations
   - Archived Order is an immutable historical record
   - Different access patterns, different lifecycles
@@ -166,16 +158,16 @@ Key architectural principles:
 
 ---
 
-## Stream Boundary Decision Tree
+## Timeline Boundary Decision Tree
 
-Use this to decide whether a stream is bounded around the right business identity:
+Use this to decide whether a timeline is bounded around the right business identity:
 
 ```
-Does your stream have a natural business identity?
- NO → This is not an aggregate, it's a log/report
-    SOLUTION: Use a read model/projection, not an aggregate
+Does your timeline have a natural business identity?
+ NO → This is not an entity, it's a log/report
+    SOLUTION: Use a read model/projection, not an entity
 
- YES → Does every event in the stream belong to that one entity's lifecycle?
+ YES → Does every event in the timeline belong to that one entity's lifecycle?
    
     YES → GOOD: Boundary is correctly scoped to one identity
    
@@ -191,28 +183,28 @@ Does your stream have a natural business identity?
 
 ## Red Flags: Boundary Is Wrong
 
-If your stream exhibits ANY of these, the fix is a narrower or different identity — not a technical workaround:
+If your timeline exhibits ANY of these, the fix is a narrower or different identity — not a technical workaround:
 
 ```
-Red Flag 1: Stream growing continuously with no natural end
-   Cause: The stream identity spans an unbounded population, not one entity
+Red Flag 1: Timeline growing continuously with no natural end
+   Cause: The timeline identity spans an unbounded population, not one entity
    Solution: Re-scope to a single business entity's lifecycle
-   Example: "AllOrders" stream → "Order" per customer order
+   Example: "AllOrders" timeline → "Order" per customer order
 
 Red Flag 2: Events with no shared business meaning
-   Cause: Treating a log as an aggregate
-   Solution: Use a read model/query instead of an aggregate
+   Cause: Treating a log as an entity
+   Solution: Use a read model/query instead of an entity
    Example: "SystemMetricRecorded" → use a metrics/observability system
 
-Red Flag 3: Stream contains unrelated entities
-   Cause: Aggregate boundary is wrong
-   Solution: Split into separate aggregates
+Red Flag 3: Timeline contains unrelated entities
+   Cause: Entity boundary is wrong
+   Solution: Split into separate entities
    Example: "AllOrders" → "Order" per customer
 
-Red Flag 4: Can't explain what single business question the stream answers
-   Cause: Not a real aggregate — probably a collection or log
+Red Flag 4: Can't explain what single business question the timeline answers
+   Cause: Not a real entity — probably a collection or log
    Solution: Convert to a read model/projection
-   Example: "SystemEvents" → query specific per-entity streams instead
+   Example: "SystemEvents" → query specific per-entity timelines instead
 ```
 
 ---
@@ -221,7 +213,7 @@ Red Flag 4: Can't explain what single business question the stream answers
 
 ### 1. Anchor on a Single Business Identity
 ```
-Every stream should answer: "the history of exactly which entity?"
+Every timeline should answer: "the history of exactly which entity?"
 If the answer is "a category of things" or "everything," the
 boundary is wrong — it's describing a collection, not an entity.
 ```
@@ -248,7 +240,7 @@ UserAccount (everything about a user, several unrelated concerns)
 
 ### 4. Separate Active From Historical Concerns
 ```
-Keeping everything in one aggregate forever conflates two different
+Keeping everything in one entity forever conflates two different
 lifecycles: the entity while it's active, and its record afterward.
 Example:
   - ActiveSubscription (current state)