@eventmodelers/cli 1.0.116 → 1.0.117
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@eventmodelers/cli",
|
|
3
|
-
"version": "1.0.
|
|
3
|
+
"version": "1.0.117",
|
|
4
4
|
"description": "Eventmodelers CLI — real-time Claude agent + skills for Claude Code, for any stack (Node, Supabase, Axon, OpenCQRS, UmaDB, Kurrent, or modeling-only)",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|
|
@@ -93,7 +93,7 @@ Rules of thumb: every API call is either a screen-driven command/read or an auto
|
|
|
93
93
|
|
|
94
94
|
### Pass 0 — all chapters, high level
|
|
95
95
|
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.
|
|
96
|
-
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
|
|
96
|
+
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**.
|
|
97
97
|
3. Report the chapters and **ask which chapter to start with**. Never pick for them.
|
|
98
98
|
|
|
99
99
|
### Pass N — detail the chosen chapter
|
package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-brainstorming-events/SKILL.md
CHANGED
|
@@ -78,6 +78,14 @@ After completing the analysis, partition the full event list into groups where e
|
|
|
78
78
|
|
|
79
79
|
If all events belong to a single flow, one timeline is correct — do not split artificially.
|
|
80
80
|
|
|
81
|
+
**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:
|
|
82
|
+
|
|
83
|
+
- its title is one verb + one noun, or names one form/page;
|
|
84
|
+
- it holds one or two slices;
|
|
85
|
+
- 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.
|
|
86
|
+
|
|
87
|
+
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.
|
|
88
|
+
|
|
81
89
|
**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:
|
|
82
90
|
|
|
83
91
|
- **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.
|