@eventmodelers/cli 1.0.112 → 1.0.113

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@eventmodelers/cli",
-  "version": "1.0.112",
+  "version": "1.0.113",
   "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/{analyze-legacy-system → analyze-code-base}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: analyze-legacy-system
-description: Uncover the business process behind a legacy code base and build it on the board as an interview, iteratively — all chapters at high level first, then one chapter per pass, the person choosing which. Reads the code for hypotheses, asks one question at a time, draws as answers land. Use for "analyze this existing system", "reverse-engineer the model from the code", "model the legacy app".
+name: analyze-code-base
+description: Uncover the business process behind an existing code base and build it on the board as an interview, iteratively — all chapters at high level first, then one chapter per pass, the person choosing which. Reads the code for hypotheses, asks one question at a time, draws as answers land. Use for "analyze this code base", "analyze this existing system", "reverse-engineer the model from the code", "model the legacy app".
 ---
 
-# Analyze a Legacy System
+# Analyze a Code Base
 
 You are a facilitator running an interview, not a batch analyser. The code gives you a hypothesis; the person gives you the truth. **The board is the deliverable** — never hand over a JSON model, `config.json` or `high-level-analysis.json`. Everything you derive is created on the board as you go.
 
@@ -44,24 +44,24 @@ Therefore: never trade one reader for the other. No cryptic titles to save space
 
 ## How to interview
 
-- **Propose, then ask.** "From `VisitController` I see the owner picks a pet and then books a visit — does that match, and what happens after?" — never an empty question.
+- **Build what the code shows; ask only what it can't tell you.** Elements, fields, edges and scenarios that follow from the API, persistence, tests and UI go onto the board directly — no confirmation round, no tick-boxes for things you can see. Ask only about **order** and **unclear business requirements** (what the code leaves open or contradicts). When you ask, propose first: "From `VisitController` I see the owner picks a pet and then books a visit — is that the real sequence?" — never an empty question.
 - **One question at a time**, answerable in a sentence or two. Never a wall of questions.
 - The recurring question is **"what happens next?"** — walk the flow forward until the person says it ends, then backwards once: "what has to have happened before this?"
-- **Order before placement.** Confirm the order, then place; the timeline is only as right as its sequence.
-- **Draw as you go.** Every confirmed answer goes onto the board immediately (in a chat: every *ticked* answer — see Chat mode) — the person watches the model grow. Never disappear for ten tool calls.
+- **Order before placement.** Place where the code or UI make the order clear; where they don't, ask first. The timeline is only as right as its sequence.
+- **Draw as you go.** Everything you derived or were told goes onto the board immediately — the person watches the model grow. Never disappear for ten tool calls.
 - **Ask before every descent.** Which flow next and how much deeper — never decide alone.
 
 ### Be proactive — and ask about order above all
 
 The code almost never says in which order the business does things: persistence writes have no sequence, controllers are independent, tests run in isolation. **Order is the person's knowledge, so ask for it — every round, unprompted.** Don't settle for the sequence the code happens to suggest.
 
-**Order is what the timeline is made of.** An event model is a left-to-right sequence: a column's position *is* the business order, and a wrong order is a wrong model, not a cosmetic flaw. So never place an element at a position you guessed — place it where the person confirmed it goes, and if the order is still open, hold the element back (or leave a QUESTION comment) rather than put it somewhere plausible. Chapters get their order the same way.
+**Order is what the timeline is made of.** An event model is a left-to-right sequence: a column's position *is* the business order, and a wrong order is a wrong model, not a cosmetic flaw. So never place an element at a position you guessed — place it where the code or UI make the order clear or the person confirmed it, and if the order is still open, hold the element back (or leave a QUESTION comment) rather than put it somewhere plausible. Chapters get their order the same way.
 
 - Whenever you have two or more elements (events, chapters, milestones), propose an order *and* ask: "I'd put *Owner Registered* before *Pet Added* — does the clinic ever add a pet first, or can it happen in either order?"
 - Ask what must have happened **before** each step (preconditions) and what **can run in parallel** or in any order.
 - Ask where the **ordering of chapters** comes from: which flow starts the story, which depends on another, which repeat.
 - Ask when a step can happen **again** (a second visit, a re-booking) and what it means then.
-- Put an order question into every snippet round (in chat: a `poll` with the candidate orders, or a `confirm` on your proposal).
+- In a chat, put an order question as a `poll` with the candidate orders, or a `confirm` on your proposal (see Chat mode).
 - Don't wait for gaps to surface: whenever the code leaves you guessing — what triggers an automation, who is allowed to act, what happens on failure, whether a step is optional — ask, with your best hypothesis attached. Still one question at a time: pick the one that unblocks the most.
 
 Questions to keep in rotation: *What happens next? · Which comes first — and can it be the other way round? · What must be true before this can happen? · Who triggers this? · What do they see before they decide? · Can this fail — and what does the business do then? · Is that the word the business uses? · Which flow now? · Deeper, or enough?*
@@ -79,10 +79,14 @@ Every pass reads the code through the same four lenses; each produces *hypothese
 
    **With a URL, play with it using Playwright.** Prefer the Playwright MCP tools (`browser_navigate`, `browser_snapshot`, `browser_click`, `browser_type`, …) when they are available; otherwise drive it with a small Playwright script (`npx playwright`) kept in the scratchpad, not in the repository.
    - Walk it like a user: start at the entry page, follow the navigation, and note each page, form, button and list. Record, per step, what the person sees, what they can do, and what changed afterwards — that is a screen, a command and the event or read model behind it.
-   - Take snapshots/screenshots as evidence for what you propose ("the *Add Visit* form asks for date and description") and, where a person decides, as input for `/html-screen`.
+   - **The UI is the best source for what is possible and in which order.** Menus, buttons, wizard steps and enabled/disabled states show which actions exist and which come first; use the click path as the *proposed* order and put it to the person ("after *Add Pet* the app leads to *Book Visit* — is that the real sequence?"). The person still confirms the order before anything is placed.
+   - **Screenshot every step and paste it onto the board as an image.** Save each screenshot (`browser_take_screenshot`, or `page.screenshot()` in the script) to the scratchpad, then place it as a SCREEN in the chapter, at the column of the step it belongs to, in walk order:
+     `mcp__eventmodelers__create_screen { boardId, screens: [{ contentType: "image", chapterId, cellName, title: "<business name of the step>", imageBase64: "<base64 PNG, no data: URI prefix>", mimeType: "image/png", description: "Shows X. Arrived via: Y. Actions: A, B. Legacy: <URL / template>" }] }`
+     The image is the real legacy screen kept as evidence. Where a person decides, `/html-screen` may add a clean wireframe later, but never replaces the screenshot unasked. Screenshot only what you walked, never invent screens. Mask personal data (names, emails) in the shots, or use test data.
    - Trigger a write (submit a form) only against a test or local system, or after the person agrees — it changes real data. Never on anything that looks like production without asking first. Create test data with a clear marker so it can be found again.
    - Confirm what you observed against the code: the UI shows the flow, the API/persistence lenses show what really happens behind it.
    - Not reachable, login missing or the page needs something you don't have: tell the person and carry on with the other lenses; never invent screens.
+   - **No UI, and the code doesn't make the flow or order clear: ask the business expert (the human in the loop).** Don't guess from the code. Put your best hypothesis to them, one question at a time ("without a UI I can't see the sequence — does the clinic register the owner before adding a pet?"), and ask them to describe or sketch what people see and do. Their answer is the source for order and screens; if it stays open, leave a QUESTION comment instead of placing the element.
 
 Where the lenses disagree (a route nobody calls, a table never written, a test for removed behaviour, a screen with no backend), that is a question for the person — not something to model.
 
@@ -120,14 +124,14 @@ Before proposing elements for a chapter, apply the rules of the skills that own
 
 ### Pass 0 — all chapters, high level
 1. Read the sources broadly through the four lenses (API, tests, persistence, UI) to spot the end-to-end business flows, and ask whether a running UI exists.
-2. Interview the person to confirm the list: which flows does the business actually run, what starts each, where does each end? Name them in business words (*Register an Owner*, *Book a Visit*).
-3. Create **one chapter per high-level flow** (`/timeline`), in business order. Inside each chapter sketch only the coarse milestones as slices — titles only (*Visit Booked*, *Pet Registered*; not operations on entities). Connect the chapters' order, not their internals.
+2. Derive the flows yourself and name them in business words (*Register an Owner*, *Book a Visit*). Ask only what the code can't tell you: the **order** of the flows, and what starts or ends one when that is unclear.
+3. Create **one chapter per high-level flow** (`/timeline`) straight away — no confirmation round — in the best-known business order (ask where it is unclear). Inside each chapter sketch only the coarse milestones as slices — titles only (*Visit Booked*, *Pet Registered*; not operations on entities). Connect the chapters' order, not their internals.
 4. Report the chapters back and **ask which chapter to start with**. Never pick for them.
 
 ### Pass N — detail the chosen chapter
 1. The person picks one existing chapter. Work **in that chapter** — do not create a new one. Replace/expand its milestones into the real command / event / read model sequence (`/timeline`, `/place-element`), reusing what is already there.
-2. Interview forward — what happens next, who does it, what do they see, what can go wrong — while reading the code that backs each step (all four lenses).
-3. Add this layer's detail (budget below) as answers land.
+2. Read the code behind each step (all four lenses) and build it directly. Interview only where the code stops: what happens next when the order is unclear, who is allowed to act, what the business does on failure.
+3. Add this layer's detail (budget below) as you derive it, and as answers land.
 4. Report what you uncovered, name the sub-flows found *inside* this chapter (offer them as new chapters if the person wants them), list the chapters still at high level, and ask: which chapter next, go deeper here, or stop?
 
 Repeat until the person says stop. Each pass leaves the chapters not yet chosen untouched at high level.
@@ -144,15 +148,17 @@ Never add detail that belongs to a deeper layer. Every element must trace to sou
 
 ---
 
-## Chat mode — snippets instead of prose
+## Chat mode — snippets only for real questions
 
-**When this run has a chat** (`CHAT_SESSION_ID` is set — the request came from the board's chat), questions the person answers with a pick are **snippets** (`post_chat_message` with `snippet`; shapes in `/learn-eventmodelers-api` § 16 *Chat snippets*), and nothing goes on the board until they tick it. Open questions ("what happens after the visit is booked?") stay text. Without a chat (terminal) everything works as written — ask in prose, draw immediately.
+**When this run has a chat** (`CHAT_SESSION_ID` is set — the request came from the board's chat), a question the person answers with a pick is a **snippet** (`post_chat_message` with `snippet`; shapes in `/learn-eventmodelers-api` § 16 *Chat snippets*); an open question stays text. Without a chat, ask in prose.
 
-1. **Pass 0 — the chapters.** Post **one** `tasks` snippet with every candidate chapter you found, one tickable line each (`title` = business name of the flow, `description` = the milestones you saw and the code it came from). End the turn. The ticked ones become chapters, in the order listed.
-2. **Which chapter next** (end of every pass): a **`poll` snippet** — one option per chapter still at high level, plus *"Stop here"*. End the turn. The pick arrives as the next chat message.
-3. **Pass N — the detail.** Offer the elements, edges, fields and scenarios you found for the chosen chapter as **one** `tasks` snippet per round (one line per slice or rule, `description` = where it goes and the code reference), then one follow-up question in the same message — a pick (*"Can this fail?"* → `confirm`, *"Which comes first?"* → `poll`) is a snippet, an open question stays text. Put **every** finding of the round in the one snippet (it pages itself at 5). Nothing found: one line of text, no snippet.
-4. **A code-vs-user conflict** is not worth a snippet on its own — fold it into the tasks snippet as a line *"Comment: code does X instead"* the person can tick.
-5. **Applying the answer.** It arrives as a `CHAT` turn (`Please do these:` + the ticked titles, or ids when the list was long). Read your snippet back (`get_chat_session`), match the ticked tasks, and create **one prompt**: *"Apply these /analyze-legacy-system changes in chapter `<CHAPTER_ID>`: `<id> | <title>` per line"*. Unticked ones were declined — drop them. A prompt starting with **"Apply these /analyze-legacy-system changes"** is the applying run: skip the code reading and the offering, create what is listed through the delegated skills, then post one short chat message — what went on the board and the next question (item 2 or 3). This is how the model grows: *a snippet to tick → applied → the next snippet.*
+**Snippets are not a confirmation gate.** Never post a `tasks` snippet to let the person tick what you derived from the code — you build that directly (see *How to interview*). Use a snippet only when you genuinely need the person:
+
+1. **Order** — *"Which comes first?"* → a `poll` with the candidate orders; *"I'd put A before B — right?"* → a `confirm`.
+2. **Unclear business requirement** — the code leaves it open or contradicts itself (*"Can a visit be cancelled?"*, *"Is the specialty optional?"*) → a `confirm` or `poll` with your hypothesis; an open answer stays text.
+3. **Which chapter next** (end of every pass) → a `poll` with one option per chapter still at high level, plus *"Stop here"*. The pick arrives as the next chat message.
+
+One question per message, with the best hypothesis attached. The answer arrives as a normal chat message: apply it to the board right away and continue with the next derivation or question. If nothing is unclear, don't ask — post a short note of what went on the board and the poll for the next chapter.
 
 ---
 

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

@@ -203,7 +203,7 @@ for it. Instead:
      and posts nothing to the board until they answer (`/wdyt` Step 4.0). Your reply here is one line —
      *"On it — looking at Registration."*
    - **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-legacy-system`, `/detect-architecture-drift`, `/add-next-slice`, `/examples`, `/timeline …`,
+     writes these: `/analyze-existing-model`, `/analyze-code-base`, `/detect-architecture-drift`, `/add-next-slice`, `/examples`, `/timeline …`,
      `/html-screen …`, `/storyboard …`): 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
@@ -356,7 +356,7 @@ nothing to sanitize either, since a board change is not user text.
 | 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` |
-| Reverse-engineer the business process of a legacy code base into the model, as an interview, one layer at a time | `/analyze-legacy-system` |
+| 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 where the model and the code have drifted apart (fields, specs, screens, edges, missing/extra slices) and propose fixes | `/detect-architecture-drift` |
 | Turn a document or image (e.g. a tender/RFP) into a chaptered event model with screens, scenarios and a written blueprint summary | `/summarize` |
 | Look up any API endpoint or element type not already covered by the skill you're executing | `/learn-eventmodelers-api` |