@eventmodelers/cli 1.0.149 → 1.0.151

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@eventmodelers/cli",
-  "version": "1.0.149",
+  "version": "1.0.151",
   "description": "Eventmodelers CLI — real-time Claude agent + skills for Claude Code, for any stack (Node, Supabase, Axon, OpenCQRS, UmaDB, Kurrent, or modeling-only)",
   "type": "module",
   "bin": {

package/shared/skills/learn-eventmodelers-api/SKILL.md

@@ -696,6 +696,8 @@ Append Given-When-Then scenario(s) to a column's spec node — the node is creat
   title: string
   vertical?: boolean
   examples?: unknown[]
+  context?: SpecStep[]  // READMODELs the command decides against
+  contextNote?: string  // markdown background — ONLY what events, commands and read models can't express
   given?: SpecStep[]  // EVENTs from this timeline
   when?: SpecStep[]   // at most one COMMAND, or one inline QUERY object; empty if then has a READMODEL
   then?: SpecStep[]   // EVENTs only OR exactly one READMODEL (not mixed)
@@ -711,6 +713,7 @@ A step given as `{title, type}` is resolved server-side, so the names you alread
 
 **Validation rules**:
 - `context`: only READMODELs (the state the command decides against)
+- `contextNote`: free markdown, last resort. State belongs in `given` events (or `context` read models), inputs in the `when` command's fields, outcomes in `then` — a note never replaces or repeats any of them. Use it only for background no element can carry: an external condition ("the payment provider is in maintenance"), a business assumption, the reason a case matters. Blank notes are dropped. Exported as `contextNote` on the scenario in slice data
 - `given`: only EVENTs from same timeline
 - `when`: max one COMMAND; must be empty when `then` contains a READMODEL (use an inline QUERY item for a state-view)
 - `then`: all EVENTs OR exactly one READMODEL — never mixed
@@ -765,8 +768,13 @@ Append one or more storylines to a column's spec node. The spec node is auto-cre
     examples?: unknown[]
   }>
 }
+
+// A note beat — free markdown anywhere in the sequence, referencing no element:
+{ instanceId: 'uuid', refId: '', type: 'STORYLINE_NOTE', title: 'Note', note: 'markdown' }
 ```
 
+A note beat is the storyline's `contextNote`: only for what the beats themselves can't express (an external condition, an assumption, a time gap like "two weeks later"). Never use one to stand in for an event, command or read model that should be a beat — model the element instead. It is exported as an element `{id: instanceId, type: 'STORYLINE_NOTE', description: note}`; an empty note is rejected (`STORYLINE_NOTE_EMPTY`).
+
 A beat is addressed either way, like a scenario step:
 ```typescript
 { refId: 'node-uuid' }                           // a board node — always wins, never re-resolved

package/stacks/axon/templates/.claude/skills/build-automation/SKILL.md

@@ -396,6 +396,8 @@ class {AutomationName}ProcessorTest {
 
 ### Storyline-Derived Tests (Optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 `slice.json` may also carry a `storylines[]` array — narrated walkthroughs with an ordered
 `elements[]` "beats" sequence (EVENT/COMMAND/READMODEL/...). This is a secondary, supplementary
 source; `specifications[]` above stays the primary and default source of test cases. Most slices

package/stacks/axon/templates/.claude/skills/build-state-change/SKILL.md

@@ -405,6 +405,8 @@ see [references/axon-test-fixture-patterns.md](references/axon-test-fixture-patt
 
 ## Step 7b: Storyline-Derived Tests (Optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 `slice.json` may carry a `storylines[]` array alongside `specifications[]` — narrated walkthroughs
 where an ordered sequence of `elements[]` "beats" (EVENT/COMMAND/READMODEL/...) shows one use case
 end to end. This is a secondary, supplementary source — `specifications[]` (Step 7) stays the

package/stacks/axon/templates/.claude/skills/build-state-view/SKILL.md

@@ -210,6 +210,8 @@ Do not design your own test cases unless specifically instructed to do so.
 
 ## Step 4b: Storyline-Derived Tests (Optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 `slice.json` may also carry a `storylines[]` array — narrated walkthroughs where the *same* read
 model appears as multiple ordered "beats" across one flow (see `elements[]` on each storyline).
 This is a secondary, supplementary source: `specifications[]` (Step 4) remains the primary and

package/stacks/classic/templates/.claude/skills/build-automation/SKILL.md

@@ -39,6 +39,8 @@ Follow `/build-state-change` for this slice's command and events — all of its
 
 ### Storyline-derived tests
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 If `storylines[]` includes a beat sequence running through this automation's trigger → this slice's command, the command test for that segment is already covered by build-state-change's own "Storyline-derived tests" step.
 
 ## Step 3 — Find the trigger point

package/stacks/classic/templates/.claude/skills/build-state-change/SKILL.md

@@ -77,6 +77,8 @@ Name each test after the specification title so it can be traced back to the boa
 
 ### Storyline-derived tests (optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 `storylines[]` in slice.json (optional — only present when the board author built an explicit walkthrough) can supply additional tests. A storyline embedded in this slice's slice.json already belongs entirely to this slice — no need to match beats against `commands[]` by id/title. Scan each storyline's ordered `elements` for a `type: COMMAND` beat followed by its EVENT beat(s):
 
 - `given` — the cumulative ordered events from the start of the storyline up to (not including) the command beat, set up as state as above

package/stacks/classic/templates/.claude/skills/build-state-view/SKILL.md

@@ -80,6 +80,8 @@ Name each test after the specification title.
 
 ### Storyline-derived tests (optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 `storylines[]` in slice.json is optional — present only when the board author explicitly built a walkthrough for this flow. When present, mine it for **additional** tests, on top of (never instead of) the specification tests.
 
 A storyline is `{ id, title, elements: [...] }`, where `elements` is an ordered list of beats — the same element can repeat to show its state at different points in the flow. A storyline embedded in this slice's slice.json already belongs entirely to this slice — no need to match beats against `readmodels[]` by id/title. Scan for a pair of adjacent beats that are both `type: READMODEL`, with only EVENT beat(s) between them and no COMMAND beat in that run. That pair is one self-contained test:

package/stacks/kurrent/templates/.claude/skills/build-automation/SKILL.md

@@ -384,6 +384,8 @@ class {AutomationName}HandlingTest {
 
 ### Storyline-Derived Tests (Optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 `slice.json` may also carry a `storylines[]` array — narrated walkthroughs with an ordered
 `elements[]` "beats" sequence (EVENT/COMMAND/READMODEL/...). This is a secondary, supplementary
 source; `specifications[]` above stays the primary and default source of test cases. Most slices

package/stacks/kurrent/templates/.claude/skills/build-state-change/SKILL.md

@@ -376,6 +376,8 @@ the same reconstruction path production uses.
 
 ## Step 6b: Storyline-Derived Tests (Optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 `slice.json` may carry a `storylines[]` array alongside `specifications[]` — narrated walkthroughs
 where an ordered sequence of `elements[]` "beats" (EVENT/COMMAND/READMODEL/...) shows one use case
 end to end. This is a secondary, supplementary source — `specifications[]` (Step 7) stays the

package/stacks/kurrent/templates/.claude/skills/build-state-view/SKILL.md

@@ -341,6 +341,8 @@ package — which it already does, following this stack's convention (`{SliceNam
 
 ## Step 5b: Storyline-Derived Tests (Optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 `slice.json` may also carry a `storylines[]` array — narrated walkthroughs where the *same* read
 model appears as multiple ordered "beats" across one flow (see `elements[]` on each storyline).
 This is a secondary, supplementary source: `specifications[]` (Step 4) remains the primary and

package/stacks/modeling-kit/templates/.claude/skills/attributes/SKILL.md

@@ -138,7 +138,7 @@ For each node, compute (don't write yet):
 
 ### If operation is `add`:
 - Check if a field with that name already exists in `meta.fields` — if so, skip this node (log it).
-- Otherwise append a new field:
+- Otherwise append a new field, with its source set per `eventmodeling-information-completeness`. Along the chain, the same name carries the value from hop to hop. The **source element** is where it starts (`generated: true`), unless one of its own inbound neighbours already carries it, in which case the chain stops too early: extend it to the real origin.
 ```json
 {
   "name": "<attributeName>",
@@ -157,6 +157,7 @@ For each node, compute (don't write yet):
 ### If operation is `rename`:
 - Find the field where `name === oldName` (case-insensitive). If not found in this node, skip it (log it).
 - Update only the `name` property to `newName`. Leave all other field properties unchanged.
+- Then fix the downstream fields outside the chain that lost their source through the rename (see `eventmodeling-information-completeness` → "Renames move the lineage too"), in the same batch.
 
 Collect one `node:changed` event per affected node, then send them together.
 
@@ -196,6 +197,7 @@ Tell the user:
 - **Chain**: list each element in order (type + title + cell)
 - **Updated**: which nodes were changed
 - **Skipped**: which nodes were skipped and why (field already exists / field not found / slice not `Created` — asked to confirm)
+- **Lineage**: where the attribute starts (`generated` on which element) and any `mapping` you set for a renamed hop
 
 Example output:
 ```

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-checking-completeness/SKILL.md

@@ -127,7 +127,7 @@ Older versions of this skill wrote the completeness check as a markdown report r
 ## Completeness Criteria
 
 The model is **complete** when:
- Every event field has a source (command or system or is marked as  generated)
+ Every field on every element has a source per `eventmodeling-information-completeness`
  Every command input becomes event/state data
  Every read model field has event source
  All state transitions are covered

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-core-rules/SKILL.md

@@ -56,6 +56,7 @@ Slices are not placed directly — they're **derived** from a completed model. E
 ### COMMAND
 - Represents business intent — what an actor wants to do.
 - Can be rejected; only succeeds if its documented preconditions hold.
+- Carries every piece of information its validation needs that isn't in the stream's prior events. That includes context such as the current time or date, the acting user and the tenant. The decision never reads a clock or a session on its own. See `eventmodeling-identifying-inputs` → "Command input is self-contained".
 - Naming: imperative, business language.
   - Valid: `PlaceOrder`, `ConfirmPayment`, `CancelSubscription`
   - Invalid: `LoadOrders`, `FetchData`, `OpenDialog` — these are queries or UI-only actions, not business intent
@@ -100,11 +101,9 @@ Every event model needs one, established before brainstorming events (it's the f
 
 See `eventmodeling-brainstorming-events` for how the catalog is built, `eventmodeling-identifying-inputs` for attributing commands to it, and `eventmodeling-validating-event-models` for re-checking it holds once the model is complete.
 
-## Field Lineage
+## Field Lineage (Information Completeness)
 
-Every field on a COMMAND or READMODEL must carry a `mapping` that traces it back to where its value actually comes from — user input, the session, a prior event's field, a derived/computed value, or an external webhook payload. **A field with no mapping is a gap, not a detail to fill in later.**
-
-See `eventmodeling-identifying-inputs` for the full COMMAND mapping vocabulary and `eventmodeling-identifying-outputs` for the READMODEL equivalent — this rule only states that every field must have one, not the mapping syntax itself.
+Every field on every element has a known source: a same-named field on a connected upstream element, a `mapping` to a differently named field or a connected event, or `generated: true` where the information starts. Check it each time you add or rename a field. **A field with no source is a gap, not a detail to fill in later.** The full rule, per element type, is in `eventmodeling-information-completeness`.
 
 ## Connections Read Forward
 

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-designing-automation-chains/SKILL.md

@@ -69,7 +69,7 @@ When a worker automation *is* warranted, wire the todo lists differently for eac
 
 A todo-list read model's fields describe the pending item — the identity it's about (e.g. `customerId`) plus enough context to act on it (e.g. `email`, `notificationType`). Do not add a `status` field to mark items done — a todo list's "open" state is *membership in the list itself* (the row exists at all), not a status flag on a row that never leaves. If the same underlying data is also useful with an explicit status column for a different consumer, that is a different read model, not this one.
 
-Every field must set a `mapping` per `eventmodeling-identifying-outputs`'s field data lineage rules (`"<EventTitle>.<fieldName>"`, `"latest:..."`, `"aggregate:..."`, `"derived:..."`), and `"cardinality"` (`"Single"` unless the field genuinely holds a list).
+Every field needs a known source per `eventmodeling-information-completeness`, and `"cardinality"` (`"Single"` unless the field genuinely holds a list).
 
 A todo-list read model is always list-shaped — it's a queue of pending items, never a single record — so it always gets **`meta.listElement: true`** on the node itself (see `eventmodeling-core-rules`'s READMODEL section). This is a node-level flag separate from any field's own `cardinality`.
 

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-elaborating-scenarios/SKILL.md

@@ -50,6 +50,21 @@ narrated lifecycle, GWT covers everything else about that read model.
 A storyline threads all three beats into one walkthrough; three separate GWTs could each assert one
 transition but not the lifecycle.
 
+## Notes — Last Resort Only
+
+A scenario can carry a `contextNote` (markdown), and a storyline can hold note beats
+(`{type: "STORYLINE_NOTE", refId: "", note: "…"}`). **Notes are only for what cannot be expressed
+with events and the other elements.** Before writing one, ask: could this be a `given` event, a
+`context` read model, a field example on the command, or a `then` outcome? If yes, model it that
+way — a scenario that tells its story in a note instead of in events is incomplete, and code
+generated from it can't test what's only in prose.
+
+Legit uses: a condition outside the system ("the payment provider is in maintenance"), a business
+assumption or regulation behind the case, why the case matters, a time gap between storyline beats
+("14 days later"). Not legit: "the customer has already ordered twice" (→ `given` events), "the
+cart total is 120 €" (→ field examples), "an email is sent" (→ a `then` event), restating the
+title. Most scenarios need no note; keep any note to a few lines.
+
 ### Storyline data shape
 
 ```json
@@ -77,6 +92,8 @@ transition but not the lifecycle.
   READMODEL. Beats are only READMODEL or EVENT — no COMMAND, SCREEN or other types. Every `refId`
   must be on the same timeline.
 - `isError` marks a beat as an alternate/error branch off the previous beat.
+- A note beat (`type: "STORYLINE_NOTE"`, `refId: ""`, markdown in `note`) may sit anywhere and is
+  skipped by the order rules — see "Notes — Last Resort Only" above before adding one.
 - `fields`, `expectEmptyList`, `exampleMode`, `examples` mirror the same fields GWT scenario steps
   use, letting a beat show concrete example data the same way a "then" readmodel step does.
 
@@ -494,6 +511,7 @@ After posting, tell the user:
 **No command has only 2 scenarios unless all other types were reviewed and found inapplicable.**
 
 **Per read model — this is a separate, equally mandatory pass, not an afterthought of the command pass above:**
+- [ ] **Notes carry nothing an element could** — every `contextNote` and note beat holds only background no event, command field or read model can express; anything else is moved into `given`/`when`/`then`/`context` and the note removed
 - [ ] **Every READMODEL on the board has at least one view scenario** — GWT (`given`: source EVENTs, `when`: empty, `then`: the READMODEL) or a storyline. A model with dozens of command scenarios and 0 read-model scenarios is not a complete Step 7 — it's easy to walk away thinking coverage is thorough because the command side looks exhaustive, so check the read-model side explicitly before reporting this step done.
 - [ ] **Population scenario** — the view shows correct data after its source event(s)
 - [ ] **Removal/update scenario, where applicable** — a row disappears or changes (`expectEmptyList: true` for list-type views) after an event that supersedes it (expiry, return, archival, withdrawal, status change, etc.). `EVENT → READMODEL` is exempt from column ordering **only when the read model already feeds an AUTOMATION** (`READMODEL → AUTOMATION` edge; see `learn-eventmodelers-api` §3 and `eventmodeling-orchestrating-event-modeling`'s "No backward arrows") — a later event connecting back to an earlier-placed todo-list read model is normal for that accumulator shape, so add the connection if it's missing rather than assuming the scenario is impossible. If the read model has no automation to feed, the backward connection is rejected — by Step 5 this should already have been modeled the forward way (see `eventmodeling-identifying-outputs` Step 5g's copy pattern: a new read model + screen copy in the later event's column, never a link back). If it wasn't, write the scenario against that forward-placed copy rather than the original. Only skip this scenario, with a documented gap (TASK comment), when the superseding event genuinely lives in a different chapter.

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

@@ -67,6 +67,21 @@ Show which commands come from automation vs. user actions: catalog every command
 ### 3. Document Command Specifics
 For each command, define structure: its source, its typed input fields, the validation rules it enforces, the preconditions it checks against stream state, the success event it produces, and each distinct failure outcome. A full worked example (ConfirmOrder) is in `references/examples.md`.
 
+### 3b. Command input is self-contained
+
+A command must carry **everything needed to validate it**. For each validation rule and precondition, list every value the rule reads. Each value is either:
+- **a field on the command**, or
+- **stream state**: data from prior events of this entity (step 6).
+
+Nothing else. Watch for **contextual information** that is easy to overlook because "the system just knows it":
+- the current time or date (`now`, `today`), for deadlines, expiry, "must be in the future", opening hours, cut-off dates
+- the acting user, their role, and the tenant or organization, for "only the owner may…", limits per customer
+- the timezone or locale, when a rule depends on the local date ("before midnight", "on a business day")
+
+Each one becomes a command field, `generated: true` (it enters the model at the command, supplied when the command is issued, per `eventmodeling-information-completeness`). The decision then never reads a clock or session on its own, and the same command always gets the same outcome. That is also what lets a GWT scenario state it: *when `ReserveBike` with `requestedAt = 09:00`, then rejected, because `startTime` is in the past*.
+
+A timestamp the event records (`reservedAt`) comes from that command field, not from a clock read when the event is stored.
+
 ### 4. Create Command Catalog
 List all commands the system accepts, grouped into UI-issued and processor-issued sections, each with its source, input fields, and the event it produces. A full worked example is in `references/examples.md`.
 
@@ -80,60 +95,39 @@ Document what comes from stream state beyond the command's explicit input: the p
 
 Instead of writing a markdown document, **place each COMMAND on the board** using the `node:created` API.
 
-> **CRITICAL: Every COMMAND node MUST include `meta.fields` with a `mapping` on every field.** A command without fields — or with fields that lack `mapping` — is an incomplete model that cannot be traced, validated, or turned into code.
-
-### Field data lineage — the `mapping` attribute
+> **CRITICAL: Every COMMAND node MUST include `meta.fields`, and every field must have a known source.** A command without fields — or with fields whose origin is unknown — is an incomplete model that cannot be traced, validated, or turned into code.
 
-Every field on a COMMAND must carry a `mapping` that says exactly where its value comes from. Use one of these forms:
+### Field data lineage — `mapping` and `generated`
 
- | `mapping` format | Meaning | `generated` | Example |
-|---|---|---|---|
-| `"user-input"` | User types or selects this value directly | `false` | `startTime` picked from a date picker |
-| `"session:<fieldName>"` | Read from the authenticated session | `false` | `session:customerId` |
-| `"<EventTitle>.<fieldName>"` | Taken from a previously emitted event | `false` | `BikeReserved.bikeId` |
-| `"derived:<expression>"` | Computed by the system | `true` | `derived:uuid4()`, `derived:now()` |
-| `"webhook:<payloadField>"` | Comes from an external webhook payload | `false` | `webhook:gateway_transaction_id` |
-
-Set the field's `generated` property according to this table. Fields typed by the user (typically from a screen form) are never generated — the user supplies the value. Fields with a `derived:` mapping are always generated — the system produces the value automatically.
-
-The `mapping` traces the value all the way back to its origin. **If you cannot write a mapping for a field, that field has an unknown origin — treat it as a gap and resolve it.**
+Apply `eventmodeling-information-completeness` to every COMMAND field and every EVENT field as you add it. A command's upstream is the SCREEN or AUTOMATION issuing it. An event's upstream is the COMMAND producing it. User input is `generated` on the screen that captures it, not on the command. Contextual values the validation reads (current time, acting user, tenant) are `generated` on the command (see 3b). Only an id the system creates when recording the fact is `generated` on the event. **A field whose source you can't name is a gap. Resolve it before you place the field.**
 
 Every field must also set `"cardinality"` — use `"Single"` unless the field genuinely holds a list of values (e.g. multi-select), in which case use `"List"`. Default to `"Single"` when unsure. Only add fields the command actually needs to do its job — do not add speculative fields; enrich later via `/attributes`.
 
 ### Field traceability rule for events
 
-Every field in the resulting EVENT must either:
-- Appear in the command's `fields` (direct mapping — same name or documented rename), or
-- Be derivable from command fields + system state
-
-Example: `BikeReserved.reservedAt` is not in `ReserveBike` but derives from `derived:now()`. That is acceptable — document it. `BikeReserved.reservationId` is not in `ReserveBike` but derives from `derived:uuid4()`. Also acceptable.
-
-If an event field has **no** corresponding command field and **no** derivation rule, that is a gap — add it to the command or note it as a system-generated field.
-
-> **Connected-element rule**: A field `mapping` may only reference elements that are connected to this COMMAND via board arrows (`SCREEN → COMMAND`). If a field's value would come from something not yet connected, flag it as a gap. **If a mapping cannot be defined at all, it hints at missing data in the model or a modeling error** — a missing event field, a missing screen field, or a broken connection. Investigate before proceeding.
+Every EVENT field comes from its COMMAND (same name, or `mapping` for a rename) or is created by the system when the event is recorded (`generated: true`). Anything else means the command, or the screen behind it, is missing that field.
 
 ```json
 {
   "type": "COMMAND",
   "title": "ReserveBike",
   "fields": [
-    {"name": "customerId",  "type": "String",   "example": "cust-42",               "mapping": "session:customerId", "generated": false},
-    {"name": "bikeId",      "type": "String",   "example": "bike-17",               "mapping": "user-input",         "generated": false},
-    {"name": "stationId",   "type": "String",   "example": "stn-03",                "mapping": "user-input",         "generated": false},
-    {"name": "startTime",   "type": "DateTime", "example": "2026-06-01T09:00:00Z",  "mapping": "user-input",         "generated": false},
-    {"name": "endTime",     "type": "DateTime", "example": "2026-06-01T17:00:00Z",  "mapping": "user-input",         "generated": false}
+    {"name": "customerId",  "type": "String",   "example": "cust-42",               "generated": true},
+    {"name": "bikeId",      "type": "String",   "example": "bike-17"},
+    {"name": "stationId",   "type": "String",   "example": "stn-03"},
+    {"name": "startTime",   "type": "DateTime", "example": "2026-06-01T09:00:00Z"},
+    {"name": "endTime",     "type": "DateTime", "example": "2026-06-01T17:00:00Z",  "mapping": "returnTime"},
+    {"name": "requestedAt", "type": "DateTime", "example": "2026-06-01T08:45:00Z",  "generated": true}
   ]
 }
 ```
 
+`customerId` (from the session) and `requestedAt` (the current time) are contextual: the rules "a customer may hold one active reservation" and "`startTime` must be after `requestedAt`" read them, so they are on the command, `generated: true`. `bikeId`, `stationId` and `startTime` come from same-named fields on the `Reserve a Bike` screen. `endTime` is called `returnTime` on that screen.
+
 Event fields produced by this command:
-- `reservationId` → `derived:uuid4()` → `generated: true`
-- `customerId` → `ReserveBike.customerId` → `generated: false`
-- `bikeId` → `ReserveBike.bikeId` → `generated: false`
-- `stationId` → `ReserveBike.stationId` → `generated: false`
-- `startTime` → `ReserveBike.startTime` → `generated: false`
-- `endTime` → `ReserveBike.endTime` → `generated: false`
-- `reservedAt` → `derived:now()` → `generated: true`
+- `reservationId` → created by the system → `generated: true`
+- `customerId`, `bikeId`, `stationId`, `startTime`, `endTime` → same name on `ReserveBike` → no mapping
+- `reservedAt` → `mapping: "requestedAt"`, the command's current time, never a clock read when the event is stored
 
 Commands go in the `interaction` lane — same column as their resulting event.
 
@@ -167,9 +161,9 @@ mcp__eventmodelers__submit_node_events {
       "type": "COMMAND",
       "title": "ReserveBike",
       "fields": [
-        {"name": "customerId", "type": "String",   "example": "cust-42",             "mapping": "session:customerId"},
-        {"name": "bikeId",     "type": "String",   "example": "bike-17",             "mapping": "user-input"},
-        {"name": "startTime",  "type": "DateTime", "example": "2026-06-01T09:00:00Z","mapping": "user-input"}
+        {"name": "customerId", "type": "String",   "example": "cust-42",             "generated": true},
+        {"name": "bikeId",     "type": "String",   "example": "bike-17"},
+        {"name": "startTime",  "type": "DateTime", "example": "2026-06-01T09:00:00Z"}
       ]
     }
   }],
@@ -251,6 +245,7 @@ Older versions of this skill wrote the command catalog as a markdown document ra
 - [ ] Preconditions from stream state are explicit
 - [ ] Success and failure outcomes documented
 - [ ] Implicit context from stream state is identified
+- [ ] **Every value a validation rule reads is a command field or stream state, including contextual information (current time/date, acting user, tenant)**
 - [ ] No undocumented commands exist
 - [ ] Command naming is consistent and clear
 - [ ] Processor triggers are explicit
@@ -262,7 +257,7 @@ Older versions of this skill wrote the command catalog as a markdown document ra
 ## Key Principles
 
 1. **Source Clarity**: Every command comes from UI or Processor
-2. **Input Completeness**: All needed data captured
+2. **Input Completeness**: All data needed to validate is on the command, including contextual information like the current time
 3. **Validation Explicit**: All rules documented
 4. **State Awareness**: Preconditions from stream state clear
 5. **Event Mapping**: Every input becomes event data

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-identifying-inputs/references/api-fallback.md

@@ -40,9 +40,9 @@ curl -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/events" \
       "type": "COMMAND",
       "title": "ReserveBike",
       "fields": [
-        {"name": "customerId", "type": "String",   "example": "cust-42",             "mapping": "session:customerId"},
-        {"name": "bikeId",     "type": "String",   "example": "bike-17",             "mapping": "user-input"},
-        {"name": "startTime",  "type": "DateTime", "example": "2026-06-01T09:00:00Z","mapping": "user-input"}
+        {"name": "customerId", "type": "String",   "example": "cust-42",             "generated": true},
+        {"name": "bikeId",     "type": "String",   "example": "bike-17"},
+        {"name": "startTime",  "type": "DateTime", "example": "2026-06-01T09:00:00Z"}
       ]
     }
   }]'

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

@@ -131,7 +131,7 @@ Instead of writing a markdown document, **place each READMODEL (and any missing
 
 This step proceeds as a sequence of lettered sub-steps: identify each screen's components (5a), break multi-component screens apart into copies (5c), then design and place one read model per component (5d onward). Every automation's todo-list read model and any translation chain is designed in **Step 4b** (`eventmodeling-designing-automation-chains`), immediately after Step 4 — not here. This step only ever designs screen-facing read models; Step 5i below re-checks automations defensively, not as this step's primary job.
 
-> **CRITICAL: Every READMODEL node MUST include `meta.fields` with a `mapping` on every field.** A read model without fields — or with fields that lack `mapping` — has no data lineage and cannot be traced back to its source events.
+> **CRITICAL: Every READMODEL node MUST include `meta.fields`, and every field must trace back to a connected source event (or be `generated`).** A read model without fields, or with fields of unknown origin, has no data lineage and cannot be traced back to its source events.
 
 ### The typical slice pattern
 
@@ -195,30 +195,15 @@ Before finalizing any read model, ask: "does this screen contain more than one c
 
 **Do not re-derive read model needs from a screen's title or description alone, and do not rely on the orchestrator's phase-summary handoff for this** — if you arrived here via `eventmodeling-orchestrating-event-modeling`, the handoff after Step 3 is a short hand-written prose summary (`.eventmodelers/interviews/.../EVENTMODELING.md`), not the actual field data. It will not reliably carry the per-field mappings forward. Go back to the board itself:
 
-For every SCREEN node, fetch it directly (`get_node`/`get_nodes`, never from memory) and read its `meta.fields` — a full read on purpose (`projection: "line"` carries field names only, not the `mapping` this step groups by); scope it to the chapter, e.g. `get_nodes { "boardId": "<BOARD_ID>", "type": "SCREEN", "chapterId": "<CHAPTER_ID>" }`, rather than board-wide. Step 3 already required every field to carry a `mapping`, and for view fields that mapping is already in the exact form `"<ReadModelTitle>.<fieldName>"` — recorded specifically so this step doesn't have to re-guess it.
+For every SCREEN node, fetch it directly (`get_node`/`get_nodes`, never from memory) and read its `meta.fields` — a full read on purpose (`projection: "line"` carries field names only, not the `mapping` this step groups by); scope it to the chapter, e.g. `get_nodes { "boardId": "<BOARD_ID>", "type": "SCREEN", "chapterId": "<CHAPTER_ID>" }`, rather than board-wide. Step 3 already required every view field to name its read model, as `mapping: "<ReadModelTitle>"`. It was recorded so this step doesn't have to guess it again.
 
 - **Group the screen's fields by the `<ReadModelTitle>` already named in their `mapping`.** That grouping — not a fresh read of the screen's visuals — is the read model's title and field list. Build the READMODEL node from it directly.
-- If a field's `mapping` names a read model that isn't `"<CommandTitle>.<fieldName>"` or `"session:..."` or `"derived:..."`, it is a read-model reference — treat it as a requirement, not a suggestion.
+- A field whose `mapping` is a title that isn't on the board yet is a read-model reference. Treat it as a requirement, not a suggestion. (Fields marked `generated: true` are input or display-only values. They need no read model.)
 - A screen with no fields, or with fields that carry no read-model-shaped mapping, is **not** evidence that it needs no read model. Re-check it against the three rules above (view screen / automation / command screen showing prior state) before concluding it's the rare blank-form exception — and say explicitly why it qualifies.
 
 ### Step 5e — Field data lineage — the `mapping` attribute on READMODEL fields
 
-Every field on a READMODEL must carry a `mapping` that says exactly which event (or command) field it is projected from. Use one of these forms:
-
-| `mapping` format | Meaning | `generated` | Example |
-|---|---|---|---|
-| `"<EventTitle>.<fieldName>"` | Projected directly from an event field | `false` | `"BikeReserved.customerId"` |
-| `"latest:<EventTitle>.<fieldName>"` | Latest value from the most recent event of this type | `false` | `"latest:BikeStatusChanged.toStatus"` |
-| `"aggregate:<EventTitle>.<fieldName>"` | Aggregated across multiple events of this type | `true` | `"aggregate:RentalEnded.durationMinutes"` |
-| `"derived:<expression>"` | Calculated from other read model fields | `true` | `"derived:sum(lineItems.amount)"` |
-
-Set the field's `generated` property according to this table. Fields projected directly from events are not generated — they carry a real domain value. Fields that are aggregated or calculated by the system are generated.
-
-**Field traceability rule**: Every field in a read model must trace back to at least one source event. If a field cannot be mapped to any event in the timeline, it is either:
-- A calculated/derived field — document the derivation expression, or
-- A missing event field — add it to the source event before proceeding.
-
-> **Connected-element rule**: A read model's field `mapping` may only reference EVENTs that are connected to this READMODEL via a board `EVENT → READMODEL` arrow. If a field needs data from an event that is not connected, either add the connection or flag it as a gap. **If a mapping cannot be defined for a field, it signals missing data in the model, a missing event, or a modeling error.** Do not leave unmapped fields without a note.
+Apply `eventmodeling-information-completeness` to every READMODEL field as you add it. A read model's upstream is the EVENTs connected to it by `EVENT → READMODEL` arrows. A value the projection calculates itself (a count, a sum, a duration) is `generated: true`. A field no connected event supplies is a missing event field or a missing connection: add it before proceeding.
 
 Every field must also set `"cardinality"` — use `"Single"` unless the field genuinely holds a list of values (e.g. line items, a collection projected from multiple events), in which case use `"List"`. Default to `"Single"` when unsure. Include only the fields the consuming SCREEN or AUTOMATION actually displays or needs — do not add speculative fields; enrich later via `/attributes`.
 
@@ -229,12 +214,13 @@ If the READMODEL itself represents a set of rows rather than a single record —
   "type": "READMODEL",
   "title": "ActiveReservationView",
   "fields": [
-    {"name": "reservationId",  "type": "String",   "example": "res-001",               "mapping": "BikeReserved.reservationId",          "generated": false},
-    {"name": "customerId",     "type": "String",   "example": "cust-42",               "mapping": "BikeReserved.customerId",              "generated": false},
-    {"name": "bikeId",         "type": "String",   "example": "bike-17",               "mapping": "BikeReserved.bikeId",                  "generated": false},
-    {"name": "stationId",      "type": "String",   "example": "stn-03",                "mapping": "BikeReserved.stationId",               "generated": false},
-    {"name": "expiresAt",      "type": "DateTime", "example": "2026-06-01T09:30:00Z",  "mapping": "ReservationConfirmed.expiresAt",       "generated": false},
-    {"name": "status",         "type": "String",   "example": "confirmed",             "mapping": "latest:ReservationConfirmed.status",   "generated": false}
+    {"name": "reservationId",  "type": "String",   "example": "res-001"},
+    {"name": "customerId",     "type": "String",   "example": "cust-42"},
+    {"name": "bikeId",         "type": "String",   "example": "bike-17"},
+    {"name": "stationId",      "type": "String",   "example": "stn-03"},
+    {"name": "expiresAt",      "type": "DateTime", "example": "2026-06-01T09:30:00Z",  "mapping": "ReservationConfirmed"},
+    {"name": "status",         "type": "String",   "example": "confirmed",             "mapping": "toStatus"},
+    {"name": "minutesLeft",    "type": "Integer",  "example": "25",                    "generated": true}
   ]
 }
 ```

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-information-completeness/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: eventmodeling-information-completeness
+description: The rule for where every field's value comes from. Use it whenever a field is added, renamed or reviewed on any element (SCREEN, HTML_SCREEN, COMMAND, EVENT, READMODEL, AUTOMATION), whether in a full modeling run, a one-off /attributes or /place-element call, or a fix. Each field either matches a same-named field on a connected upstream element, maps to a differently named field or a connected event, or is marked generated where the information starts. Anything else is a gap to close. Not a step of its own. Other skills reference it instead of restating it.
+---
+
+# Information Completeness
+
+Information doesn't appear out of nowhere. Every field on every element either comes from an element **connected upstream** of it, or starts at this element. Check this **each time you add or rename a field**, before you write it. Don't leave it for a later completeness pass.
+
+## The four valid states of a field
+
+| Where the value comes from | What to write | Example |
+|---|---|---|
+| A connected upstream element has a field **with the same name** | nothing: no `mapping`, the same name *is* the mapping | `BikeReserved.bikeId` ← `ReserveBike.bikeId` |
+| A connected upstream element has it **under a different name** | `mapping: "<sourceFieldName>"` (a sub-field as `"<field>.<subfield>"`) | `ReserveBike.endTime` with `mapping: "returnTime"` |
+| It comes from one specific connected **event** (or other connected element), e.g. because several upstream elements carry the field | `mapping: "<EventTitle>"`, the element's title on its own | `ReservationView.expiresAt` with `mapping: "ReservationConfirmed"` |
+| **Nothing upstream** supplies it: manual input typed into a screen, a session value, a generated id or timestamp, a value computed at this element | `generated: true` | `HTML_SCREEN "Reserve a Bike".startTime`, `BikeReserved.reservationId` |
+
+These are the forms the board resolves. The field picker offers the connected fields and the event titles, and the Data Trail follows them. Write the field name or the element title **bare**. Combined forms like `"BikeReserved.bikeId"`, `"user-input"`, `"session:x"` or `"derived:..."` resolve to nothing.
+
+## Upstream means inbound, per element type
+
+Lineage always points to where the value comes **from**. It never points downstream.
+
+| Element | Its upstream (where its fields can come from) |
+|---|---|
+| SCREEN / HTML_SCREEN | the READMODEL it displays. The COMMAND it submits is **downstream**: never map a screen field to it. |
+| COMMAND | the SCREEN or AUTOMATION issuing it |
+| EVENT | the COMMAND producing it |
+| READMODEL | the EVENTs connected to it (`EVENT → READMODEL`) |
+| AUTOMATION | the READMODEL (todo list) it reads |
+
+So information typed into a form is `generated: true` **on the screen**. The command, event and read model then pick it up by the same name, or by a `mapping` where it's renamed. Contextual values a command's validation reads (current time or date, acting user, tenant) are `generated: true` on the **command**. Commands carry everything they need to validate (`eventmodeling-identifying-inputs` → "Command input is self-contained"), and the event takes a recorded time from there. Only an id the system creates when recording the fact is `generated: true` on the event. A count, sum or duration the projection calculates is `generated: true` on the read model.
+
+## How to check a field
+
+1. Look at the element's inbound neighbours, from the edges (`get_connected_nodes` `direction: "inbound"`, `includeFields: true`), or from the layout when the chapter is unwired.
+2. Pick the row above that matches. One neighbour with the same name, and nothing to write, is the common case.
+3. **No row fits → it's a gap.** The field is missing upstream, the connection is missing, or the element is missing. Close it: add the field upstream (and carry it through the chain the same way), add the connection, or add the element. Only when the source genuinely can't be decided from the model, apply the questioning rule.
+
+`generated: true` means "this information starts here". It is never a way to say "I don't know where this comes from". Don't mark a field `generated` to make a gap go away, and don't invent a `generated` origin in the middle of a flow.
+
+## Planned sources that aren't on the board yet
+
+While storyboarding, a displayed screen field is often meant to come from a read model that hasn't been designed yet. Write `mapping: "<ReadModelTitle>"` anyway and flag it as a gap. `eventmodeling-identifying-outputs` groups screen fields by that title to design the read model. Once the read model is connected, a same-named field needs no mapping, and a differently named one gets `mapping: "<readModelFieldName>"`. A displayed field is never marked `generated` just because its read model is missing.
+
+## Renames move the lineage too
+
+Renaming a field breaks every downstream field that matched it by name, or that has `mapping: "<oldName>"`. In the same write, either rename those too or set their `mapping` to the new name. `/attributes` does this for a chain.
+
+## Worked example — reserving a bike
+
+```
+HTML_SCREEN "Reserve a Bike"   bikeId (generated), startTime (generated), returnTime (generated),
+                               customerId (generated, from session), bikeCategory (mapping "AvailableBikeView")
+COMMAND     ReserveBike        bikeId, startTime, customerId (same names, no mapping), endTime (mapping "returnTime"),
+                               requestedAt (generated: current time, read by "startTime must be in the future")
+EVENT       BikeReserved       bikeId, startTime, endTime, customerId (same names), reservationId (generated),
+                               reservedAt (mapping "requestedAt")
+READMODEL   ActiveReservation  reservationId, bikeId, startTime (same names), expiresAt (mapping "ReservationConfirmed"),
+                               minutesLeft (generated)
+HTML_SCREEN "Reservation"      reservationId, startTime, expiresAt (same names, read model connected)
+```
+
+Every field on the way traces back to a `generated` origin. Nothing appears without a source.

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

@@ -135,30 +135,9 @@ The result is a `{ roleName: actorRowId }` map, covering human roles only, used
 
 ## Mandatory Field Definitions on Screen Nodes
 
-> **CRITICAL: Every screen node MUST include `meta.fields` with a `mapping` on every field.** A screen without fields cannot show data lineage — it becomes impossible to verify that all displayed data has a source event or command. This applies regardless of which content type the screen renders as (HTML_SCREEN by default, or SCREEN when a sketch was explicitly requested).
+> **CRITICAL: Every screen node MUST include `meta.fields`, and every field must have a known source.** A screen without fields cannot show data lineage — it becomes impossible to verify that all displayed data has a source event or command. This applies regardless of which content type the screen renders as (HTML_SCREEN by default, or SCREEN when a sketch was explicitly requested).
 
-There are two types of screens, and each type has a different `mapping` source:
-
-### Command screen (input/action screen)
-
-An **input screen** captures data that will be sent as a command. Its fields map to the command they feed into.
-
-| Field type | `mapping` | `generated` | Example |
-|---|---|---|---|
-| User types a value | `"<CommandTitle>.<fieldName>"` | `false` | `"ReserveBike.bikeId"` |
-| Read from session | `"session:<fieldName>"` | `false` | `"session:customerId"` |
-| Pre-populated from a previous event | `"<EventTitle>.<fieldName>"` | `false` | `"BikeReserved.stationId"` |
-| Calculated for display only (not sent to command) | `"derived:<expression>"` | `true` | `"derived:sum(items.price)"` |
-
-### View screen (output/read model screen)
-
-A **view screen** displays data read from a Read Model. Its fields map to the read model that serves the data. View screens are placed adjacent to their read model in Step 5 (Identifying Outputs) — during storyboarding, record the intended read model name as the source even if the read model hasn't been designed yet.
-
-| Field type | `mapping` | `generated` | Example |
-|---|---|---|---|
-| Displayed from a read model | `"<ReadModelTitle>.<fieldName>"` | `false` | `"ActiveReservationView.status"` |
-| Displayed from a direct event (no read model yet) | `"<EventTitle>.<fieldName>"` | `false` | `"BikeReserved.startTime"` |
-| Calculated/formatted on the client | `"derived:<expression>"` | `true` | `"derived:formatDuration(durationMinutes)"` |
+Apply `eventmodeling-information-completeness` to every screen field as you add it. In short: input the user enters, session values and display-only calculations are `generated: true`. Displayed data names its read model (`mapping: "<ReadModelTitle>"`), even when that read model isn't designed yet, which Step 5 then groups by. A screen field never maps to the command it submits.
 
 ### Example: command screen fields
 
@@ -167,12 +146,12 @@ A **view screen** displays data read from a Read Model. Its fields map to the re
   "type": "HTML_SCREEN",
   "title": "Reserve a Bike",
   "fields": [
-    {"name": "bikeId",      "type": "String",   "example": "bike-17",               "mapping": "ReserveBike.bikeId"},
-    {"name": "stationId",   "type": "String",   "example": "stn-03",                "mapping": "ReserveBike.stationId"},
-    {"name": "startTime",   "type": "DateTime", "example": "2026-06-01T09:00:00Z",  "mapping": "ReserveBike.startTime"},
-    {"name": "endTime",     "type": "DateTime", "example": "2026-06-01T17:00:00Z",  "mapping": "ReserveBike.endTime"},
-    {"name": "bikeCategory","type": "String",   "example": "City Bike",             "mapping": "AvailableBikeView.category"},
-    {"name": "dailyRate",   "type": "Decimal",  "example": "0.10",                  "mapping": "AvailableBikeView.ratePerMinute"}
+    {"name": "bikeId",      "type": "String",   "example": "bike-17",               "generated": true},
+    {"name": "stationId",   "type": "String",   "example": "stn-03",                "generated": true},
+    {"name": "startTime",   "type": "DateTime", "example": "2026-06-01T09:00:00Z",  "generated": true},
+    {"name": "returnTime",  "type": "DateTime", "example": "2026-06-01T17:00:00Z",  "generated": true},
+    {"name": "bikeCategory","type": "String",   "example": "City Bike",             "mapping": "AvailableBikeView"},
+    {"name": "dailyRate",   "type": "Decimal",  "example": "0.10",                  "mapping": "ratePerMinute"}
   ]
 }
 ```
@@ -184,27 +163,17 @@ A **view screen** displays data read from a Read Model. Its fields map to the re
   "type": "HTML_SCREEN",
   "title": "Reservation Confirmed",
   "fields": [
-    {"name": "reservationId",  "type": "String",   "example": "res-001",               "mapping": "ActiveReservationView.reservationId"},
-    {"name": "bikeName",       "type": "String",   "example": "City Bike — Gazelle",   "mapping": "ActiveReservationView.bikeName"},
-    {"name": "stationName",    "type": "String",   "example": "Central Park East",     "mapping": "ActiveReservationView.stationName"},
-    {"name": "startTime",      "type": "DateTime", "example": "2026-06-01T09:00:00Z",  "mapping": "ActiveReservationView.startTime"},
-    {"name": "expiresAt",      "type": "DateTime", "example": "2026-06-01T09:30:00Z",  "mapping": "ActiveReservationView.expiresAt"},
-    {"name": "estimatedCost",  "type": "Decimal",  "example": "48.00",                 "mapping": "derived:durationHours × AvailableBikeView.ratePerMinute × 60"}
+    {"name": "reservationId",  "type": "String",   "example": "res-001",               "mapping": "ActiveReservationView"},
+    {"name": "bikeName",       "type": "String",   "example": "City Bike — Gazelle",   "mapping": "ActiveReservationView"},
+    {"name": "stationName",    "type": "String",   "example": "Central Park East",     "mapping": "ActiveReservationView"},
+    {"name": "startTime",      "type": "DateTime", "example": "2026-06-01T09:00:00Z",  "mapping": "ActiveReservationView"},
+    {"name": "expiresAt",      "type": "DateTime", "example": "2026-06-01T09:30:00Z",  "mapping": "ActiveReservationView"},
+    {"name": "estimatedCost",  "type": "Decimal",  "example": "48.00",                 "generated": true}
   ]
 }
 ```
 
-### Connected-element rule (critical constraint)
-
-> **A field `mapping` may only reference an element that is connected to this SCREEN via a board connection arrow.**
->
-> - A command screen may only map to: the COMMAND it submits, the SCREEN's own input (user-input), or a READ MODEL whose `READMODEL → SCREEN` arrow points to this screen.
-> - A view screen may only map to: the READ MODEL connected to it via a `READMODEL → SCREEN` arrow, or derived expressions.
-> - If a mapping references an element that is not yet connected — for example, `AvailableBikeView.category` when no such read model exists on the board — that is a **gap**. It signals either:
->   1. A read model is missing and must be created in Step 5 (Identifying Outputs), or
->   2. The connection arrow is missing and must be added.
->
-> **When you encounter a mapping that cannot resolve to a connected element, write the mapping as-is but flag it as a gap in the completeness notes.** Do not invent connections that don't exist.
+A read model named in a `mapping` but not on the board (or not connected to this screen) is a **gap** for Step 5 (Identifying Outputs) to close. Flag it in the completeness notes, and don't invent connections that don't exist.
 
 Every field must also set `"cardinality"` — use `"Single"` unless the field genuinely displays/collects a list of values (e.g. a repeated line-item row), in which case use `"List"`. Default to `"Single"` when unsure. Only add the fields the screen actually shows or captures — do not add speculative fields; enrich later via `/attributes`.
 

package/stacks/modeling-kit/templates/.claude/skills/html-screen/SKILL.md

@@ -161,19 +161,10 @@ Expect `204 No Content` on success from either curl call. A `HTML_SCREEN_PAGE_TO
 
 ## Step 5 — Define field data lineage (mandatory)
 
-Every screen — new or updated — needs `meta.fields`: one entry per piece of data the screen displays or captures, each with a `mapping` naming where that data comes from. A screen with only a title and no fields is an empty placeholder from a data-lineage standpoint, even if the mockup itself looks complete.
+Every screen, new or updated, needs `meta.fields`: one entry per piece of data the screen displays or captures, each with a known source per `eventmodeling-information-completeness`. Input, session values and display-only calculations are `generated: true`. Displayed data names its read model (`mapping: "<ReadModelTitle>"`), even if that read model isn't on the board yet. This skill doesn't create read models or connections, but naming the source is not optional. A screen with only a title and no fields is an empty placeholder from a data-lineage standpoint, even if the mockup itself looks complete.
 
 **For a brand-new screen** (Step 4's `create_screen` call), pass `fields` directly on that call instead of a separate `node:changed` here — one round trip instead of two. This step's separate `submit_node_events` call is still how you set/update fields on an **existing** screen (`render_screen` doesn't take `fields` either).
 
-| Field type | `mapping` | Example |
-|---|---|---|
-| User types a value, sent as a command | `"<CommandTitle>.<fieldName>"` | `"ReserveBike.bikeId"` |
-| Read from session | `"session:<fieldName>"` | `"session:customerId"` |
-| Displayed data, sourced from a read model | `"<ReadModelTitle>.<fieldName>"` | `"ActiveReservationView.status"` |
-| Calculated/formatted only for display | `"derived:<expression>"` | `"derived:formatDuration(durationMinutes)"` |
-
-Name the read model even if it doesn't exist as a board node yet — this skill only renders the screen, it does not create READMODEL nodes or connections (that's `eventmodeling-identifying-outputs` or `place-element`, if the model is taken that far). But naming the source is **not optional**: a screen displaying data should almost never have a field with no mapping. If you can't say which read model a displayed field comes from, that's a sign the model is missing something — not a reason to skip the field.
-
 If this node is one of several sharing the same visual base with different marks/highlights (see "Marked screens and field scoping" above), only list the fields that fall inside *this* node's highlighted area — not every field the shared screen shows.
 
 Set `cardinality` too (`"Single"` unless the field is a repeated/list value), then push the fields onto the node:
@@ -186,7 +177,7 @@ mcp__eventmodelers__submit_node_events {
     "id": "<event-uuid>", "eventType": "node:changed", "nodeId": "<NODE_ID>",
     "changedAttributes": ["meta.fields"],
     "meta": { "type": "HTML_SCREEN", "fields": [
-      {"name": "status", "type": "String", "example": "confirmed", "mapping": "ActiveReservationView.status", "cardinality": "Single"}
+      {"name": "status", "type": "String", "example": "confirmed", "mapping": "ActiveReservationView", "cardinality": "Single"}
     ] }
   }],
   "compact": true

package/stacks/modeling-kit/templates/.claude/skills/html-screen/references/api-fallback.md

@@ -43,7 +43,7 @@ curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/events" \
     "id": "<event-uuid>", "eventType": "node:changed", "nodeId": "<NODE_ID>",
     "changedAttributes": ["meta.fields"],
     "meta": { "type": "HTML_SCREEN", "fields": [
-      {"name": "status", "type": "String", "example": "confirmed", "mapping": "ActiveReservationView.status", "cardinality": "Single"}
+      {"name": "status", "type": "String", "example": "confirmed", "mapping": "ActiveReservationView", "cardinality": "Single"}
     ] }
   }]'
 ```

package/stacks/modeling-kit/templates/.claude/skills/place-element/SKILL.md

@@ -55,7 +55,7 @@ mcp__eventmodelers__place_element {
 }
 ```
 
-Pass `fields` whenever the element's attributes are already known — they are written by this same call, so don't follow a placement with a `submit_node_events` just to set them. Placing **more than one** element is more entries in the same `elements` array, applied in order so each entry sees the columns the previous one added — one call for a whole slice's or column run's worth instead of one per element. **Order the array by narrative, left to right, one slice after another** (screen → command → event → the read model/view screen that event feeds → next slice) — never grouped by `elementType` (all commands, then all read models): by-type order makes every read model land in an inserted column after the fact and breaks the visual story.
+Pass `fields` whenever the element's attributes are already known — they are written by this same call, so don't follow a placement with a `submit_node_events` just to set them. Every field you pass needs a known source per `eventmodeling-information-completeness`. A field without one is a gap to close upstream, not a field to place as is. Placing **more than one** element is more entries in the same `elements` array, applied in order so each entry sees the columns the previous one added — one call for a whole slice's or column run's worth instead of one per element. **Order the array by narrative, left to right, one slice after another** (screen → command → event → the read model/view screen that event feeds → next slice) — never grouped by `elementType` (all commands, then all read models): by-type order makes every read model land in an inserted column after the fact and breaks the visual story.
 
 This tool finds or creates an empty cell in the correct lane and places the node in one call — it collapses the "resolve timeline → fetch columns → determine lane → check occupancy → create node" sequence (Steps 2–3, 4, 6, 7b below) into a single round trip. A `columnIndex` past the timeline's current column count is handled automatically (columns are added to reach it) — no need to pre-check the column count or catch an out-of-range error yourself. If `timelineId` is unknown, resolve it first via Step 2's MCP call. Pass `compact: true` for a smaller `{nodeId, cellName, columnIndex}` response (plus `connectedCount` if auto-connect wired an edge) when you don't need the full `lane`/`elementType`/`title`/`autoConnected` detail back. Go straight to Step 8 once it returns.
 

package/stacks/modeling-kit/templates/.claude/skills/storyboard-screen/SKILL.md

@@ -110,7 +110,7 @@ mcp__eventmodelers__render_screen {
 
 ## Step 5 — Define field data lineage (mandatory)
 
-Every screen — new or updated — needs `meta.fields`: one entry per piece of data the screen displays or captures, each with a `mapping` naming where that data comes from. A screen with only a title and no fields is an empty placeholder from a data-lineage standpoint, even once the wireframe is rendered. See the `html-screen` skill's "Step 5 — Define field data lineage" for the full `mapping`-format table (command/session/read-model/derived forms).
+Every screen — new or updated — needs `meta.fields`: one entry per piece of data the screen displays or captures, each with a known source per `eventmodeling-information-completeness`. A screen with only a title and no fields is an empty placeholder from a data-lineage standpoint, even once the wireframe is rendered.
 
 Name the read model even if it doesn't exist as a board node yet — this skill only renders the screen, it does not create READMODEL nodes or connections. But naming the source is **not optional**: a screen displaying data should almost never have a field with no mapping. If you can't say which read model a displayed field comes from, that's a sign the model is missing something — not a reason to skip the field.
 
@@ -124,7 +124,7 @@ mcp__eventmodelers__submit_node_events {
     "id": "<event-uuid>", "eventType": "node:changed", "nodeId": "<NODE_ID>",
     "changedAttributes": ["meta.fields"],
     "meta": { "type": "SCREEN", "fields": [
-      {"name": "status", "type": "String", "example": "confirmed", "mapping": "ActiveReservationView.status", "cardinality": "Single"}
+      {"name": "status", "type": "String", "example": "confirmed", "mapping": "ActiveReservationView", "cardinality": "Single"}
     ] }
   }],
   "compact": true

package/stacks/modeling-kit/templates/.claude/skills/storyboard-screen/references/api-fallback.md

@@ -35,7 +35,7 @@ curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/events" \
     "id": "<event-uuid>", "eventType": "node:changed", "nodeId": "<NODE_ID>",
     "changedAttributes": ["meta.fields"],
     "meta": { "type": "SCREEN", "fields": [
-      {"name": "status", "type": "String", "example": "confirmed", "mapping": "ActiveReservationView.status", "cardinality": "Single"}
+      {"name": "status", "type": "String", "example": "confirmed", "mapping": "ActiveReservationView", "cardinality": "Single"}
     ] }
   }]'
 ```

package/stacks/modeling-kit/templates/kit/CLAUDE.md

@@ -100,6 +100,9 @@ exactly those elements — nothing else about the rule loosens. **No skill overr
 when there is no chat to ask in (a prompt that did not come from one, a standalone turn): then change
 nothing and comment which status blocked it. Where there is a chat, never comment — ask with the snippet.
 
+**Every field you add or rename must have a known source. This holds in every skill and every turn, not only in a full modeling run.**
+Follow `eventmodeling-information-completeness` before writing any field. It defines the three valid sources: a same-named upstream field, a `mapping`, or `generated: true`. A field with none of these is a gap to close upstream, never one to place unmapped.
+
 **One board read, shared by the whole turn.** Orientation first — `get_board_outline`, or `get_nodes` with
 `projection: "line"` — to establish where the work actually is, and only for the chapter this turn is about.
 In a `standalone=on` session the `SESSION_START` warm-up gave you the chapter list but no chapter's contents,

package/stacks/node/templates/.claude/skills/build-automation/SKILL.md

@@ -64,6 +64,8 @@ Refer to the build-state-change skill for the full command handler structure.
 
 ### Storyline-derived tests
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 If `storylines[]` includes a beat sequence running through this automation's trigger event → this slice's command, the command-handler test for that segment is already covered by build-state-change's own "Storyline-derived tests" step — it runs as part of following that skill above. This skill has no separate reactor-test format: the processor's event-to-command field mapping is exercised only indirectly, through that command-handler test, never by a dedicated `processor.test.ts`.
 
 ---

package/stacks/node/templates/.claude/skills/build-state-change/SKILL.md

@@ -230,6 +230,8 @@ Add one test per specification in the slice.json. If the spec has no preconditio
 
 ### Storyline-derived tests (optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 `storylines[]` in slice.json (optional — only present when the board author built an explicit walkthrough) can also supply command-handler tests, in addition to the specifications-derived ones above. A storyline embedded in this slice's slice.json already belongs entirely to this slice — no need to match beats against `commands[]` by id/title. Just scan each storyline's ordered `elements` for a `type: COMMAND` beat, followed by its emitted EVENT beat(s):
 
 - `given` — the cumulative ordered events from the start of the storyline up to (not including) the command beat

package/stacks/node/templates/.claude/skills/build-state-view/SKILL.md

@@ -327,6 +327,8 @@ Write one `it` block per specification in the slice.json. Use `given([events]).w
 
 ### Storyline-derived tests (optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 `storylines[]` in slice.json is optional — present only when the board author explicitly built a walkthrough for this flow; most slices have none. When present, mine it for **additional** read-model-chain tests, on top of (never instead of) the specifications-derived tests above.
 
 A storyline is `{ id, title, elements: [...] }`, where `elements` is an ordered list of beats — the same element can repeat to show its state at different points in the flow. A storyline embedded in this slice's slice.json already belongs entirely to this slice — no need to match beats against `readmodels[]` by id/title. Just scan for a pair of adjacent beats that are both `type: READMODEL`, with only EVENT beat(s) between them and no COMMAND beat in that run. That pair is one self-contained projection test:

package/stacks/opencqrs/templates/.claude/skills/build-automation/SKILL.md

@@ -394,6 +394,8 @@ class {AutomationName}ProcessorTest {
 
 ### Storyline-Derived Tests (Optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 `slice.json` may also carry a `storylines[]` array — narrated walkthroughs with an ordered
 `elements[]` "beats" sequence (EVENT/COMMAND/READMODEL/...). This is a secondary, supplementary
 source; `specifications[]` above stays the primary and default source of test cases. Most slices

package/stacks/opencqrs/templates/.claude/skills/build-state-change/SKILL.md

@@ -368,6 +368,8 @@ Full fluent-API cheat sheet: see
 
 ## Step 7b: Storyline-Derived Tests (Optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 `slice.json` may carry a `storylines[]` array alongside `specifications[]` — narrated walkthroughs
 where an ordered sequence of `elements[]` "beats" (EVENT/COMMAND/READMODEL/...) shows one use case
 end to end. This is a secondary, supplementary source — `specifications[]` (Step 7) stays the

package/stacks/opencqrs/templates/.claude/skills/build-state-view/SKILL.md

@@ -300,6 +300,8 @@ class {SliceName}ProjectorTest {
 
 ## Step 4b: Storyline-Derived Tests (Optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 `slice.json` may also carry a `storylines[]` array — narrated walkthroughs where the *same* read
 model appears as multiple ordered "beats" across one flow (see `elements[]` on each storyline).
 This is a secondary, supplementary source: `specifications[]` (Step 3) remains the primary and

package/stacks/supabase/templates/.claude/skills/build-state-change/SKILL.md

@@ -232,6 +232,8 @@ Add one test per specification in the slice.json. If the spec has no preconditio
 
 ## Step 4b — Storyline-derived tests (optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 Some slices also have a `storylines[]` array in slice.json — narrated walkthroughs of one use case as an ordered sequence of beats (`elements[]`). Most slices have no storylines; skip this step silently when `storylines[]` is empty or absent.
 
 A storyline embedded in this slice's slice.json already belongs entirely to this slice — no need to match beats against `commands[]` by id/title. For each storyline, find a `type: COMMAND` beat directly followed by its EVENT beat(s). That pair is a command-handler test — the same shape as the specifications-derived tests above:

package/stacks/supabase/templates/.claude/skills/build-state-view/SKILL.md

@@ -309,6 +309,8 @@ Write one `it` block per specification in the slice.json. Use `given([events]).w
 
 ## Step 5b — Storyline-derived tests (optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 Some slices also have a `storylines[]` array in slice.json — narrated walkthroughs where the *same* read model repeats across several beats in one ordered `elements[]` list, showing its state at different points in a single flow. Most slices have no storylines; skip this step silently when `storylines[]` is empty or absent.
 
 A storyline embedded in this slice's slice.json already belongs entirely to this slice — no need to match beats against `readmodels[]` by id/title. For each storyline, scan `elements[]` for pairs of adjacent `type: 'READMODEL'` beats with only EVENT beat(s) in between. Each such pair is a clean, self-contained projection test — the same shape as the specifications-derived tests above:

package/stacks/umadb/templates/.claude/skills/build-automation/SKILL.md

@@ -282,6 +282,8 @@ verifyNoMoreInteractions(targetCommandHandler);
 
 ### Storyline-Derived Tests (Optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 `slice.json` may also carry a `storylines[]` array — narrated walkthroughs with an ordered
 `elements[]` "beats" sequence (EVENT/COMMAND/READMODEL/...). This is a secondary, supplementary
 source; `specifications[]` above stays the primary and default source of test cases. Most slices

package/stacks/umadb/templates/.claude/skills/build-state-change/SKILL.md

@@ -344,6 +344,8 @@ behaviour, why `subscribe()` isn't faked: see
 
 ## Step 7b: Storyline-Derived Tests (Optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 `slice.json` may carry a `storylines[]` array alongside `specifications[]` — narrated walkthroughs
 where an ordered sequence of `elements[]` "beats" (EVENT/COMMAND/READMODEL/...) shows one use case
 end to end. This is a secondary, supplementary source — `specifications[]` (Step 7) stays the

package/stacks/umadb/templates/.claude/skills/build-state-view/SKILL.md

@@ -286,6 +286,8 @@ Add a `com.h2database:h2` test-scope dependency once, project-wide, if it isn't
 
 ## Step 4b: Storyline-Derived Tests (Optional)
 
+> **Note beats**: an entry with `type: STORYLINE_NOTE` is a note the board author placed in the walkthrough — its `description` is markdown context (an assumption, an external condition, a time gap), and its `id` is not a board node. Read it as background for the beats around it, but it is never a step: skip it when looking for COMMAND/EVENT/READMODEL beats or judging which beats are adjacent, and never turn it into test setup or an assertion on its own.
+
 `slice.json` may also carry a `storylines[]` array — narrated walkthroughs where the *same* read
 model appears as multiple ordered "beats" across one flow. This is a secondary, supplementary
 source: `specifications[]` (Step 4) remains the primary and default source of test cases. Most