@eventmodelers/cli 1.0.128 → 1.0.129

package/package.json

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

@@ -1152,7 +1152,8 @@ Rule of thumb: if you are about to write "Shall I…?", "Want me to…?", "A or
                  nodeId?: string,                                                 // the slice's SLICE_BORDER — drawn in its lanes, selecting the step zooms to it; none for a new slice
                  status?: 'existing' | 'changed' | 'new',                         // planned feature: used as is / needs adjustment / built from scratch
                  elements?: Array<{ type: 'SCREEN' | 'COMMAND' | 'EVENT' | 'READMODEL' | 'AUTOMATION',
-                                    title: string, fields?: string[] }>,          // a new slice only: its sketch, drawn in lanes
+                                    title: string, fields?: string[],
+                                    html?: string }>,                              // a new slice only: its sketch, drawn in lanes; html = the SCREEN as a small HTML page (≤ 16000 chars)
                  screenId?: string,                                               // a SCREEN / HTML_SCREEN outside the slice the person sees in this step
                  rules?: string[],                                                // business rules of this slice
                  changes?: string[] }> }                                          // planned feature: what has to change or be built here
@@ -1166,7 +1167,7 @@ Rule of thumb: if you are about to write "Shall I…?", "Want me to…?", "A or
 - **Answers are text.** For a `tasks` answer, match the titles (or ids) back to your list; an element the person left unticked was declined, not forgotten. A `poll` option with a `message` of your own makes the answer unambiguous.
 - `get_chat_session` shows your snippet on the message as `snippet`, and the person's answer is the user message after it, carrying `context.snippetReply.messageId` (your message's id) — useful to tell an answer to a snippet from a new message.
 - **`report`** draws the numbers you send — it computes nothing, so aggregate first. A series whose length differs from `labels`, or a non-number, makes the whole snippet invisible. Keep `text` as a one-line summary of what the diagram shows. Add `confirm` when the diagram leads to a follow-up question ("Want me to look into the backward arrows?"): the answer comes back like a `confirm` answer, and without it the report is display only.
-- **`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`; 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.
+- **`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.
 - 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/walkthrough/SKILL.md

@@ -107,11 +107,13 @@ Per step:
 | `description` | 1–3 sentences: what happens in this slice and why it matters, in the board's language. No ids, no cell addresses. |
 | `nodeId` | the slice's `SLICE_BORDER` id from `list_slices` — the player draws the slice from it and zooms the canvas to it. Left out for a `new` slice |
 | `status` | **impact mode: required on every step** — `existing`, `changed` or `new` (table above). Omitted in explain mode |
-| `elements` | **`new` slices only**: the sketch — `[{ "type": "SCREEN" \| "COMMAND" \| "EVENT" \| "READMODEL" \| "AUTOMATION", "title": "…", "fields": ["…"] }]`, the elements the slice will have (a state change: screen → command → event; a state view: event(s) → read model → screen; an automation: read model → automation → command → event). Titles and fields in the board's style; reuse the names of existing events the slice reads from |
+| `elements` | **`new` slices only**: the sketch — `[{ "type": "SCREEN" \| "COMMAND" \| "EVENT" \| "READMODEL" \| "AUTOMATION", "title": "…", "fields": ["…"] }]`, the elements the slice will have (a state change: screen → command → event; a state view: event(s) → read model → screen; an automation: read model → automation → command → event). Titles and fields in the board's style; reuse the names of existing events the slice reads from. **Give the SCREEN an `html`** — see *Screen HTML* below |
 | `screenId` | only when the screen a person sees in this step is not part of the slice itself |
 | `rules` | the business rules of this slice, taken from its scenarios (and the context note); one line each, thresholds verbatim. Empty when there are none — never invent one |
 | `changes` | **impact mode only**: what has to change or be built in this slice, one line each — "add field `email` (String) to Register Customer", "new scenario: duplicate email is rejected" |
 
+**Screen HTML.** A new slice's SCREEN is shown as a real screen, so write it: `html` is a small HTML page of what the person sees there — a form for a state change (an input per command field, labelled in business words, a button named after the command), a list or table for a state view (columns from the read model's fields, 2–3 rows of plausible example data), whatever fits the screen otherwise (a checklist, a confirmation page). Keep it rough and simple: a heading and the content, no navigation, header or footer. Body content only (no `<html>`/`<head>` needed), inline `style` attributes or one `<style>` block, at most 16000 characters. It renders sandboxed: scripts, external images, fonts and stylesheets are blocked, so no `<script>`, no CDN, no `https://` images. Without `html` the player generates a plain form/table from the fields.
+
 **Faithfulness.** Existing slices come from the board. A rule nobody modelled is not a rule — if the walkthrough reveals a gap ("nothing says what happens when confirmation never arrives"), mention it in the step's `description` as an open question, not as a rule. A sketched new slice is a proposal, and the `description` should read like one.
 
 ---
@@ -152,7 +154,8 @@ Impact mode, same shape with `status` (and `changes`, or `elements` for a new sl
   { "title": "Confirm Email", "status": "new",
     "description": "Proposed: the customer opens the link and the email is marked as confirmed.",
     "elements": [
-      { "type": "SCREEN",  "title": "Confirm Email Page" },
+      { "type": "SCREEN",  "title": "Confirm Email Page",
+        "html": "<h3>Confirm your email</h3><p>We sent a link to <b>jane@example.com</b>.</p><label>Code<br><input value=\"8F3K-21\"></label><br><br><button>Confirm Email</button>" },
       { "type": "COMMAND", "title": "Confirm Email",   "fields": ["customerId", "token"] },
       { "type": "EVENT",   "title": "Email Confirmed", "fields": ["customerId", "confirmedAt"] }
     ],
@@ -163,7 +166,7 @@ Impact mode, same shape with `status` (and `changes`, or `elements` for a new sl
 ```
 
 - `text` is one line: the subject and the number of slices — in impact mode with the split ("Startup license in 8 slices: 3 new, 2 to adjust"). It is the fallback, so it must make sense alone.
-- Impact mode: before posting, check that every step has a `status`, every `changed` step has `changes` and every `new` step has `elements` and no `nodeId`.
+- Impact mode: before posting, check that every step has a `status`, every `changed` step has `changes` and every `new` step has `elements` (its SCREEN with `html`) and no `nodeId`.
 - `summary` is always there — the first page shows it under the slice count.
 - Every `nodeId` / `screenId` is an id you read in Steps 2–3 — never a guessed or remembered one. A `new` slice has no `nodeId`.
 - The snippet is at most 64 KB; keep descriptions short rather than dropping steps.