@eventmodelers/cli 1.0.150 → 1.0.151

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@eventmodelers/cli",
-  "version": "1.0.150",
+  "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/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/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