@eventmodelers/cli 2.0.38 → 2.0.39

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@eventmodelers/cli",
-  "version": "2.0.38",
+  "version": "2.0.39",
   "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/stacks/modeling-kit/templates/.claude/skills/prototype/assets/index.template.html

@@ -61,8 +61,8 @@
     .em-ev b { color: #fdba74; font-weight: 600; }
     .em-ev-head { display: flex; align-items: baseline; gap: 8px; flex-wrap: wrap; cursor: pointer; }
     .em-ev-pos { font: 600 11px ui-monospace, SFMono-Regular, Menlo, monospace; color: #8a95a9; background: #0e1522; border-radius: 5px; padding: 1px 6px; }
-    .em-ev-type { font-weight: 600; font-size: 13px; color: #fdba74; }
-    .em-ev-from { color: #8a95a9; font-size: 12px; }
+    .em-ev-type { font-weight: 600; font-size: 13px; color: #1a0f05; background: #f97316; border-radius: 4px; padding: 2px 8px; box-shadow: 0 1px 2px rgba(0,0,0,.35); }
+    .em-ev-from { font-weight: 600; font-size: 12px; color: #fff; background: #3b82f6; border-radius: 4px; padding: 2px 8px; box-shadow: 0 1px 2px rgba(0,0,0,.35); }
     .em-ev-time { margin-left: auto; color: #6b7690; font: 11px ui-monospace, SFMono-Regular, Menlo, monospace; }
     .em-kv { display: grid; grid-template-columns: minmax(70px, max-content) 1fr; gap: 3px 14px; margin: 8px 0 2px; padding-top: 8px; border-top: 1px solid var(--p-line, #232f45); }
     .em-kv dt { color: #8a95a9; margin: 0; } .em-kv dd { margin: 0; word-break: break-word; color: #e7eaf0; } .em-kv dd.em-none { color: #4f5b73; }
@@ -360,7 +360,7 @@ function EventBrowser({ events }) {
             <div className="em-ev-head" onClick={() => setOpen(isOpen ? null : e.id)}>
               <span className="em-ev-pos">#{e.position}</span>
               <span className="em-ev-type">{e.type}</span>
-              {e.metadata.command && <span className="em-ev-from">← {e.metadata.command}</span>}
+              {e.metadata.command && <span className="em-ev-from">{e.metadata.command}</span>}
               {e.metadata.automation && <span className="em-pill">automation</span>}
               {e.metadata.simulated && <span className="em-pill">simulated</span>}
               <span className="em-ev-time">{new Date(e.metadata.at).toLocaleTimeString()}</span>

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

@@ -0,0 +1,53 @@
+---
+name: scenario-coverage
+description: Calculate how much of each slice's business logic its Given/When/Then scenarios cover, for one chapter (or all), and store it on the slice's specification node as `meta.data.coverage` — percentage plus the meaningful scenarios still missing. The canvas shows the percentage on the spec lane (red < 50, orange < 70, green otherwise).
+---
+
+# Scenario Coverage
+
+> **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`.
+
+Prefer `mcp__eventmodelers__*` tools when available. Only the coverage value is written; scenarios, elements and slice status are never changed.
+
+## Step 1 — Arguments
+
+From `$ARGUMENTS`: the **chapter** (timeline title) to work on; none given = every chapter. If a name matches several, ask.
+
+## Step 2 — Read the chapter
+
+```
+mcp__eventmodelers__get_slice_data { "boardId": "$BOARD_ID", "contextName": "<CHAPTER>", "projection": "fields", "format": "toon" }
+mcp__eventmodelers__get_slice_data { "boardId": "$BOARD_ID", "contextName": "<CHAPTER>", "projection": "specs", "format": "toon" }
+```
+
+`fields` gives each slice's elements, fields and dependencies; `specs` gives its scenarios. Find each slice's specification node (the SCENARIO / spec-lane node of its column) with `get_nodes` (`type: "SCENARIO"`) — its id is where the result is written. A slice without one: skip it and say so.
+
+## Step 3 — Derive the real use cases, per slice
+
+Work out what the slice's business logic actually has to do, from its command / read model / automation, fields, dependencies and the events involved:
+
+- the happy path(s) and meaningful variants of them,
+- each business rule and **every way the business would reject or alter the outcome** (validation of a field with a rule behind it, duplicates, state preconditions, limits, authorisation that the model shows),
+- every distinct event outcome of a command; for a read model, each distinct projection behaviour (what appears, changes, disappears).
+
+**Only meaningful scenarios count — both for what exists and for what is missing.** A scenario that is technically possible but means nothing to the business is not a use case: don't invent it, don't list it as missing, and an existing scenario that only restates another one, tests a framework/technical behaviour (null checks, type errors, malformed JSON, "field is empty" with no rule behind it) or can never occur in the process adds nothing to the coverage. Ask of each candidate: *would a domain expert care that this case behaves as specified?* If not, drop it.
+
+## Step 4 — Calculate
+
+`percentage = round(100 × covered meaningful use cases ÷ all meaningful use cases)`. A use case is covered when an existing, meaningful scenario specifies exactly its given / when / then outcome. A slice with no business logic to speak of (a pure pass-through) with one scenario is 100; with no use cases derivable, don't write a value. Be honest — don't round up to look good; the number guides what to model next.
+
+For every uncovered meaningful use case add an entry to `missing`: a short `title` and, where the model lets you say it, `given`, `when`, `then` (one short plain sentence each, in the model's own vocabulary and with concrete values only if the model has them). Leave a part out rather than guess. Max 10 entries, most important first.
+
+## Step 5 — Store it
+
+Read the spec node first (`get_node`) and keep its whole existing `meta`; add only `data.coverage`, preserving anything else already in `data`:
+
+```
+"data": { "coverage": { "percentage": 78, "missing": [ { "title": "Reject a rental of an already rented bike", "given": "bike B-1 is rented", "when": "a customer rents B-1", "then": "the rental is rejected" } ] } }
+```
+
+Send it as a `node:changed` event for the spec node (`changedAttributes: ["data"]`, `meta` = existing meta + `data`) with `mcp__eventmodelers__submit_node_events`, or via `POST <BASE_URL>/api/org/<ORG_ID>/boards/<BOARD_ID>/nodes/events` with the same body. Write coverage again on a rerun — it replaces the old value.
+
+## Step 6 — Report
+
+Post a `table` snippet (columns Slice · Coverage · Missing; slice as a link to its node), plus a one-line summary: slices rated, average, the lowest three. Always include a plain `text`.

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

@@ -75,6 +75,7 @@ Follow `eventmodeling-information-completeness` before writing any field. It def
 | Design or update a single wireframe/sketch screen (explicit request only) | `/storyboard-screen` |
 | Business analysis, gap spotting, posting questions | `/wdyt` |
 | Analyse the existing model structure, slice coverage, element counts | `/analyze-existing-model` |
+| Calculate how much of a slice's business logic its scenarios cover (stored as `meta.data.coverage`, shown on the spec lane) | `/scenario-coverage <chapter>` |
 | Reverse-engineer the business process of an existing code base into the model, as an interview — all chapters first, then one chapter at a time | `/analyze-code-base` |
 | Find what changed in the code since the last analysis (git history from the chapter note's baseline) that the model doesn't reflect, and propose fixes | `/detect-model-drift` |
 | Walk someone through a feature slice by slice, or through every slice a planned feature needs (existing, to adjust, new), as a player in the chat | `/walkthrough` |