@eventmodelers/cli 1.0.116 → 1.0.118

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@eventmodelers/cli",
-  "version": "1.0.116",
+  "version": "1.0.118",
   "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-code-base/SKILL.md

@@ -69,6 +69,8 @@ Every pass reads the code through the same four lenses; each produces *hypothese
 
    **With a URL, walk it via `discover-storyboard`** (URL already known — don't ask again; pass the flow as guidance and ask for screenshots). Its click path is the *proposed* order and its screens go into the chapter as evidence; confirm both against the API and persistence lenses. Submit forms only against a local or test system, or after the person agrees.
 
+If the code is a generic engine (templates, schemas, configurable entities), model one real case it handles, not the engine (see *Concrete Over Generic* in `eventmodeling-core-rules`).
+
 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.
 
 ---
@@ -93,7 +95,7 @@ Rules of thumb: every API call is either a screen-driven command/read or an auto
 
 ### Pass 0 — all chapters, high level
 1. Read the sources broadly through the four lenses to spot the business workflows — walking the running UI from Step 1 via `discover-storyboard` if there is one.
-2. Group them into chapters and create them as `eventmodeling-brainstorming-events` (§ *Group events by workflow* / *Create one chapter per group*) does — a chapter is a workflow, never one endpoint or CRUD operation. Order the chapters per `eventmodeling-plotting-events`; ask where it is unclear. Add the **Decisions** lane, put the `Legacy Sources` note into **column 0** (see *The analysis log*), then sketch only the milestones (titles only) **from column 1 on**.
+2. Group them into chapters and create them as `eventmodeling-brainstorming-events` (§ *Group events by workflow* / *Create one chapter per group*) does — a chapter is a user journey, never one endpoint, controller or CRUD operation. Code is split by operation (`OwnerController#initCreationForm`, `#processFindForm`, `#showOwner`, `#processUpdateOwnerForm`); the story is not — registering, finding, viewing and updating an owner are **one** chapter. Order the chapters per `eventmodeling-plotting-events`; ask where it is unclear. Add the **Decisions** lane, put the `Legacy Sources` note into **column 0** (see *The analysis log*), then sketch only the milestones (titles only) **from column 1 on**.
 3. Report the chapters and **ask which chapter to start with**. Never pick for them.
 
 ### Pass N — detail the chosen chapter

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-brainstorming-events/SKILL.md

@@ -78,6 +78,14 @@ After completing the analysis, partition the full event list into groups where e
 
 If all events belong to a single flow, one timeline is correct — do not split artificially.
 
+**A chapter tells a story — a user journey, not an operation.** Read the chapter titles aloud in order: each should be a journey someone lives through from start to outcome (*Owner & Pet Care*, *Visit Booking*), never a single action or screen (*Register Owner*, *Find Owner*, *Update Owner*, *View Owner*). Creating, finding, viewing and updating the same thing is **one** story — registering an owner, looking them up and correcting their address belong in one chapter. Signs a chapter is too fine-grained:
+
+- its title is one verb + one noun, or names one form/page;
+- it holds one or two slices;
+- the next chapter starts with the read model or entity this one just produced (*Owner Registered* → *Find and View an Owner*) — that is the same story continuing; merge them.
+
+When in doubt, merge: a chapter with a dozen slices that reads as one journey is right; five chapters of two slices each is not.
+
 **Divergent journey vs. a decision point — do not confuse the two.** A group of events sometimes contains a branch, and the branch's nature decides whether it gets its own chapter or stays inside this one:
 
 - **Divergent journey → its own chapter.** The actor makes a different choice *before* the process even starts, and everything downstream differs as a result (e.g. "Checkout with saved card" vs. "Checkout as guest" — different screens, different commands, arguably a different Role Catalog entry). Group these as separate workflows in Step 1, not as one group with a fork in it.

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-core-rules/SKILL.md

@@ -165,6 +165,14 @@ Model the business process as it would work without any software first, then tra
 
 Question any step that exists only because of the system — a loading spinner, a cache refresh, a session check is not a business step and does not belong on the timeline. This is the discipline behind the Anti-Patterns below; the anti-patterns are what it looks like when this principle is skipped.
 
+## Concrete Over Generic
+
+Looking at the model, a reader must understand how the business works. Model one real flow with real examples and real data, not a generic model that covers every case. This applies to generic platforms too: model one real case the platform handles, not the platform's own structure.
+
+Example (a template-driven health record system):
+- ❌ `Commit Composition` with fields `content`, or `name`/`category`/`entries` — still says nothing about the business.
+- ✅ `Record Blood Pressure` → `Blood Pressure Recorded` with `systolic: 132`, `diastolic: 92`, `pulse: 113`, `composer: Dr. Marcus Johnson`.
+
 ## Anti-Patterns
 
 - **Data-loading commands**: `LoadOrders`/`FetchData` are queries, not business intent — model as a READMODEL, not a COMMAND.
@@ -209,5 +217,6 @@ Before treating a model as done, verify:
 - [ ] The timeline starts with a state-view or an automation reacting to an event — not a bare COMMAND
 - [ ] No two `state-change`/`state-change` slices are chained without a new trigger between them
 - [ ] No SCREEN is wired to more than one COMMAND (the bed — see Structural Shapes)
+- [ ] The model follows one real flow with real data, not a generic one (see Concrete Over Generic)
 
 This is the fast pass — the full, deeper check is `eventmodeling-validating-event-models-checklist`.