@eventmodelers/cli 1.0.130 → 1.0.132

package/README.md

@@ -108,6 +108,7 @@ Use skills in Claude Code with `/skill-name`:
 | `/wdyt` | Business analyst review of your event model |
 | `/walkthrough` | Slice-by-slice player through a feature, or through every slice a planned feature needs (existing, to adjust, new) |
 | `/data-journey` | Where one piece of information (e.g. the customer email) originates, is stored, transformed, used and sent out — as a table in the chat |
+| `/stressor-analysis` | Residuality-theory stress test of one chapter: wide stressors and their residues, a stressor × element matrix that exposes hidden coupling, redesigns proposed as new slices |
 | `/storyboard` | Build a full visual storyboard |
 | `/html-screen` | Design individual real HTML/CSS screens (default) |
 | `/storyboard-screen` | Design individual wireframe/sketch screens (explicit request only) |

package/package.json

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

@@ -1124,8 +1124,9 @@ Rule of thumb: if you are about to write "Shall I…?", "Want me to…?", "A or
 | to explain how a feature works, or walk through what a planned feature takes, slice by slice ("how does registration work?", "we need to add an email — walk me through it") | `walkthrough` | nothing — selecting a step pans the canvas |
 | to show what a screen could look like, without putting it on the board | `screen` | nothing |
 | to answer where one piece of information comes from and where it ends up ("where is the customer email used?") | `dataJourney` | nothing — element names pan the canvas |
+| to lay out rows and columns — a comparison, a matrix (stressors × elements), a short list with a few attributes | `table` | nothing — linked cells pan the canvas |
 
-`confirm`, `poll`, `tasks` and `changes` are questions: a person answers once, then they show as answered. `link`, `image`, `code`, `report`, `walkthrough`, `screen` and `dataJourney` are display only and never wait for anything.
+`confirm`, `poll`, `tasks` and `changes` are questions: a person answers once, then they show as answered. `link`, `image`, `code`, `report`, `walkthrough`, `screen`, `dataJourney` and `table` are display only and never wait for anything.
 
 ### Shapes
 ```typescript
@@ -1170,6 +1171,11 @@ Rule of thumb: if you are about to write "Shall I…?", "Want me to…?", "A or
                  field?: string,                                                  // the field holding it here — names change along the way (email → customerEmail)
                  slice?: string,
                  note?: string }> }                                               // how it is used or changed here, a few words
+{ kind: 'table', title?: string, caption?: string,
+  columns: Array<string | { label: string, nodeId?: string,                      // 1–12; nodeId makes the header a link (a matrix with one column per element)
+                            align?: 'left' | 'center' | 'right' }>,
+  rows: Array<Array<string | number | true | null                                // 1–200, one cell per column; true = check mark, null = empty
+                    | { text: string, nodeId?: string }>> }                      // a cell linking to an element; shown 5 rows per page
 ```
 
 ### How to use them
@@ -1183,6 +1189,7 @@ Rule of thumb: if you are about to write "Shall I…?", "Want me to…?", "A or
 - **`walkthrough`** answers "how does X work?" and "walk me through what changes for Y", **one step per slice**. It opens with a summary page — the slice count (with `status`: how many exist, need adjustment, are new) above your `summary` — then shows each slice in its lanes like Slice View (screen, command / read model, events), a `new` slice sketched from its `elements` (its SCREEN rendered from the `html` you write: a real, simple page — a form, a list, a table — with inline styles only; scripts and external resources are blocked; without `html` a plain form/table is generated from the fields); each step zooms the canvas to its slice, and **Play** opens it full-screen with description, changes and rules underneath. Build it from the board, never from memory — the `walkthrough` skill (modeling kit) has the procedure. Every `nodeId`/`screenId` must be a real id from this board. Keep `text` to one line naming the feature and the number of slices.
 - **`screen`** shows a mock-up in the chat — "what could the registration screen look like?", a variant to compare — without creating anything on the board (that is the `html-screen` skill's job). `html` follows the walkthrough's screen rules: body content, inline styles or one `<style>` block, no scripts, no external images, fonts or stylesheets (they are blocked), at most 16000 characters.
 - **`dataJourney`** answers "where does X come from / where is X used?" for **one piece of information**, as a table: one stop per element it passes through, in flow order, each with its `role`, the field name there and the slice. A headline counts the roles ("Originates in 1 place, stored in 2 elements and used in 3 places"). Build it from the board — the `data-journey` skill (modeling kit) has the procedure; every `nodeId` must be a real id from this board, and a field the board doesn't carry is not a stop. Keep `text` to one line naming the data and where it originates.
+- **`table`** is for anything that is rows and columns and not a chart: a comparison of options, an incidence matrix (rows = stressors, columns = elements, `true` where it hits), a short list with a few attributes per item. It computes nothing — totals are a row you add. Put element ids in `nodeId` (header or cell) so names are links; a row longer than the columns is cut, a shorter one padded, an empty one dropped. Prefer `report` for numbers you want *seen* as a trend or share, `dataJourney` for one piece of data's path.
 - A snippet is shown exactly as you send it — keep secrets and tokens out of `code` and `image`.
 
 ---

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

@@ -0,0 +1,101 @@
+---
+name: stressor-analysis
+description: Residuality-theory stressor analysis of one chapter, run as a chat loop. Finds wide stressors, describes the residue of each, builds a stressor x element incidence matrix to expose hidden coupling, and proposes redesigns as new slices. Read-only until the person confirms.
+---
+
+# Stressor analysis — what is left of the model when things go wrong
+
+> **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Do not proceed until it has completed.
+
+Prefer `mcp__eventmodelers__*` tools. See `learn-eventmodelers-api` for the curl fallback and §16 *Chat snippets* for the `tasks`, `table`, `poll` and `confirm` shapes.
+
+The analysis runs over several chat turns: each step ends with **one** `post_chat_message` carrying one snippet, and the person's click is the next turn. In a `CHAT` turn `replyTo` = this turn's `message_id`; in a prompt turn that came from a chat, `sessionId` = `CHAT_SESSION_ID` and no `replyTo`. Find where you are from the session (`get_chat_session`): the answer to your last snippet says which step comes next.
+
+**This skill never writes to the board** until the person says yes in Step 3 — and then only through `create_prompt`.
+
+---
+
+## Concepts (get these right)
+
+- **Stressor**: anything that can happen to the system or its environment: technical, business, legal, market, people. Deliberately WIDE, far-fetched ones included. Not a risk list, not a prediction.
+- **Residue**: what is LEFT of the system after the stressor hits: which slices still work, which state or data survives or is lost. You observe a residue; you don't build it. The fix is NOT the residue.
+- **Goal**: change the model until every residue is acceptable. The architecture becomes the sum of those residues, so it also survives stressors nobody listed.
+- **Incidence matrix**: stressors × elements. Elements hit by the SAME stressors are hidden-coupled.
+
+---
+
+## Step 0 — Read once
+
+The chapter comes from `$ARGUMENTS` / the message, else the turn's `context=` (`timelineId`, selection). None and more than one chapter on the board: ask with a `poll` of the chapters (each option's `message` a complete `/stressor-analysis <chapter>` request) and end the turn.
+
+Read once and reuse for the whole round: `get_board_outline` (gives `sliceStatus` per slice) and `get_slice_data { boardId, contextName, projection: "fields", format: "toon" }` for the chapter. Ground every statement in real element and field names; every `nodeId` you send is an id you read here.
+
+---
+
+## Step 1 — Stressors and their residues (`tasks`)
+
+About **15** wide stressors. Per task: `title` = the stressor, `description` = `Residue: <what still works / what is lost>`, `nodeId` = the element most affected, `id` = `S1`, `S2`, …. `headline`: *"Tick the ones whose residue is unacceptable"*, `submitLabel`: *"These are unacceptable"*.
+
+```
+"snippet": { "kind": "tasks", "headline": "Tick the ones whose residue is unacceptable", "submitLabel": "These are unacceptable",
+  "tasks": [ { "id": "S1", "title": "Payment provider is down for a day", "description": "Residue: orders are placed, Order Paid never arrives — Shipping waits forever", "nodeId": "<Order Paid id>" }, … ] }
+```
+
+### Step 1b — Add more? (`poll`), until done
+
+When the ticks come back, don't jump to the matrix. Acknowledge the ticks in one line and ask whether to add more stressors with a `poll`:
+
+```
+"snippet": { "kind": "poll", "question": "Should I add more stressors?",
+  "options": [ { "label": "Add more", "message": "Add more stressors" },
+               { "label": "Done — build the matrix", "message": "Done with stressors, build the matrix" } ] }
+```
+
+- **Add more**: a new `tasks` list (same `headline`/`submitLabel`) of about 10 **fresh** stressors: none already offered, aimed at elements and categories (legal, people, market, data, …) the earlier rounds hit least. Ids continue the numbering (`S16`, `S17`, …). Then this poll again.
+- **Done**: go to Step 2 with every stressor ticked across all rounds.
+- Fewer than **5** ticked in total and the person picks Done: explain in the text that the matrix can't show coupling yet and send this poll again.
+
+---
+
+## Step 2 — Incidence matrix (`table`)
+
+For each ticked stressor, list every element it hits (not just the most affected one) — from the read in Step 0, never guessed. Then one `table` snippet:
+
+- one row per element hit at least once, sorted by hits (most first) — the hotspots on top;
+- columns: `Element` (the cell `{text, nodeId}` as a link), `Hits` (`align: "center"`), then one column per ticked stressor, labelled `S1`, `S2` … (`align: "center"`), `true` where it hits, `null` where not;
+- more than 10 ticked stressors: replace the stressor columns with one `Hit by` column (`"S1, S4, S9"`);
+- `caption`: the legend, `S1 = <stressor>; S4 = …`.
+
+```
+"snippet": { "kind": "table", "title": "Stressors × elements", "caption": "S1 = Payment provider down; S4 = Price changes mid-checkout; …",
+  "columns": ["Element", {"label": "Hits", "align": "center"}, {"label": "S1", "align": "center"}, {"label": "S4", "align": "center"}],
+  "rows": [ [{"text": "Order Paid", "nodeId": "<id>"}, 2, true, true], [{"text": "Shipping List", "nodeId": "<id>"}, 1, true, null] ] }
+```
+
+In the text, name the **clusters** (elements hit by the same stressor pair), the shared cause behind each cluster, and the hotspots (most hits). Ask which cluster to redesign first — the matrix is this message's snippet, so the question is in the text; when the person answers in words, go on with that cluster.
+
+---
+
+## Step 3 — Redesign one cluster (`confirm`)
+
+Propose new slices (translations, reconciliation todo lists, grace periods, second entry paths …) and state the **new residue** for each stressor that hit the cluster. A `confirm` snippet: `headline` = *"Add these N slices for <cluster>?"*; the slices and their new residues go in the text, kept short.
+
+Never touch elements in non-`Created` slices without an explicit yes; name them instead ("Order Paid sits in a Done slice — I'd leave it and add a translation next to it").
+
+## Step 4 — On yes
+
+One `create_prompt` per new slice (`originMessageId` = the yes), phrased so the prompt turn can do it on its own (chapter, slice name, its elements and fields). Reply in one line. A no: acknowledge it and offer the next cluster.
+
+## Step 5 — Validate
+
+Generate a **fresh** set of stressors not used in rounds 1–3, and compare how many have an acceptable residue before vs after the redesign (the residual index) — a `tasks` list again, the person ticks the unacceptable ones, and the text states the index ("before: 6 of 12 acceptable, after: 10 of 12"). Repeat rounds until new stressors stop hitting new elements.
+
+---
+
+## Chat style
+
+- Explain a residue with a before/after example if asked (same stressor, different leftover).
+- Text ≤ 1000 characters; the detail goes in the snippet.
+- No ids or cell addresses in the text — element names are enough.
+
+**No chat** (run from a terminal): print the stressors with residues, ask which are unacceptable, then whether to add more (repeat until done), and print the matrix as a table instead of posting.

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

@@ -212,9 +212,13 @@ for it. Instead:
      **one piece of information** (a field, "the customer email"): run the `/data-journey` skill **in this turn** — it only reads
      the board, so no prompt is needed. Its `dataJourney` snippet (a table: origin, stored, transformed, used, sent — per element,
      with the field name there) is your one reply. Without a clear subject it asks first which information.
+   - **stressor analysis** — "what breaks if …?", "stress-test this chapter", or `/stressor-analysis …`: run the
+     `/stressor-analysis` skill **in this turn** — it only reads the board until the person says yes, so no prompt is needed
+     for its steps. It is a loop over several turns (stressors as `tasks`, the incidence matrix as a `table`, a redesign as
+     `confirm`); an answer to one of its snippets continues it at the next step. Only the confirmed new slices become prompts.
    - **a skill by name** — the message starts with `/<name>` of one of your skills (the chat panel's menu
-     writes these: `/analyze-existing-model`, `/analyze-code-base`, `/detect-model-drift`, `/add-next-slice`, `/examples`, `/timeline …`,
-     `/html-screen …`, `/storyboard …`): the person chose that skill, so it **is** the work — create one prompt,
+     writes these: `/analyze-existing-model`, `/analyze-code-base`, `/detect-model-drift`, `/timeline …`,
+     `/storyboard …`; `/add-next-slice`, `/examples`, `/html-screen …` can still be typed): the person chose that skill, so it **is** the work — create one prompt,
      *"Run /<name> <the rest of the message>"*, with the target resolved from `context=` like any other
      (selected elements, chapter), and say so in one line. Don't re-interpret it as a question. A skill that
      needs something the message lacks (which attribute? which screen?) is a **clarify**: ask, with a
@@ -279,7 +283,8 @@ for it. Instead:
    - a **list of things for the person to pick from** (findings, candidates, drifts, "which of these?") → `tasks`;
    - a **pointer to an element, a picture or a command** → `link` / `image` / `code`, instead of describing it.
    - a **screen idea** in the conversation ("what could that screen look like?") → `screen`, a sandboxed HTML mock-up in the chat; putting a screen on the board is `/html-screen` work;
-   - **where one piece of information comes from and where it is used** → `dataJourney` (the `/data-journey` skill).
+   - **where one piece of information comes from and where it is used** → `dataJourney` (the `/data-journey` skill);
+   - **rows and columns** — a comparison, a matrix, a short list with a few attributes per item → `table`.
    Plain text stays for answers, explanations and open questions that need words. `text` is still
    required and stays short — it is the lead-in, the snippet carries the detail. A snippet changes
    nothing on the board: the click comes back as the next `CHAT` turn, and only then do you