@eventmodelers/cli 1.0.132 → 1.0.134

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@eventmodelers/cli",
-  "version": "1.0.132",
+  "version": "1.0.134",
   "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/stressor-analysis/SKILL.md

@@ -9,7 +9,7 @@ description: Residuality-theory stressor analysis of one chapter, run as a chat
 
 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.
+The analysis runs over several chat turns: each step ends with **one** `post_chat_message` carrying one snippet (except Step 1b), 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`.
 
@@ -17,7 +17,7 @@ The analysis runs over several chat turns: each step ends with **one** `post_cha
 
 ## 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.
+- **Stressor**: anything that can happen to the system or its environment: technical, business, legal, market, people, nature. Deliberately WIDE, far-fetched ones included. Not a risk list, not a prediction — the theory holds that *which* stressors you pick barely matters, what matters is that they come from many directions. So most must come from **outside** the model: a power outage, a pandemic, a new law, the company being acquired, the key admin quitting, a competitor going free. Only loosely related to the chapter is fine.
 - **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.
@@ -28,32 +28,41 @@ The analysis runs over several chat turns: each step ends with **one** `post_cha
 
 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.
+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. Residues name the real slices and elements they hit (field names only in the matrix step, never in a residue); 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"*.
+About **15** wide stressors, mixed:
+
+- **at least 5 external** — things that happen to the business or the world, not to the model: power outage, office flooded, pandemic, new privacy law, company acquired, key person leaves, a competitor goes free, the main customer goes bankrupt, the cloud region is gone for a week;
+- the rest from the chapter's own business (a customer changes their mind, prices change, a partner stops delivering) — still at business level.
+
+Write them the way a business person would say them, short — **no** field names, attribute values, concurrency races, token or API mechanics. One stressor per task, no "(e.g. X, Y)" sub-lists. Order the list so external and internal stressors alternate, not grouped.
+
+Per task: `title` = the stressor (≤ 8 words), `description` = `Residue: <what still works / what is lost>` — **one short sentence** in plain language, naming slices or elements but not fields, `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>" }, … ] }
+  "tasks": [ { "id": "S1", "title": "Payment provider is down for a day", "description": "Residue: orders still come in, but nothing ships until payments return", "nodeId": "<Order Paid id>" },
+             { "id": "S2", "title": "Power outage in the warehouse", "description": "Residue: orders are paid, nobody can pick them — customers aren't told", "nodeId": "<Shipping List id>" }, … ] }
 ```
 
-### Step 1b — Add more? (`poll`), until done
+### Step 1b — "More" right after the list (`confirm`)
 
-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`:
+Every `tasks` list of stressors is followed **in the same turn** by its own `post_chat_message` (same `replyTo` / `sessionId`) carrying this `confirm`. Order matters: post the **full list first**, then the confirm — the person sees every stressor and residue before being asked whether they want more. Never post the confirm on its own or ahead of the list, and never describe the list in the confirm's text as something still to come ("15 stressors come next") — it is already above. The confirm's text is one short line, e.g. *"Tick the unacceptable ones above — or ask for more stressors first."*
 
 ```
-"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" } ] }
+"snippet": { "kind": "confirm", "headline": "Need more stressors?", "yesLabel": "More", "noLabel": "Done — 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.
+This is the one exception to "one snippet per step". The lists stay open, so ticks are submitted per list whenever the person is ready:
+
+- **A `tasks` list is submitted**: note which stressors were ticked, reply in one line, **no** snippet — the open confirm still decides what comes next.
+- **More**: a new `tasks` list (same `headline`/`submitLabel`) of about 10 **fresh** stressors: none already offered, same external/internal mix as Step 1, aimed at elements and categories (nature, legal, people, market, data, …) the earlier lists hit least. Ids continue the numbering (`S16`, `S17`, …). Post the new list first, then this confirm again after it.
+- **Done**: go to Step 2 with every stressor ticked across all lists (read the session to collect them).
+- Fewer than **5** ticked in total at Done: explain in the text that the matrix can't show coupling yet and send this confirm again.
 
 ---
 

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

@@ -214,7 +214,7 @@ for it. Instead:
      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
+     for its steps. It is a loop over several turns (stressors as `tasks` with a "More" `confirm` posted after each list, 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`, `/timeline …`,