@eventmodelers/cli 1.0.147 → 1.0.149

package/lib/update-check.js

@@ -48,12 +48,38 @@ export async function latestPublishedVersion({ cachePath, now = Date.now(), fetc
   }
 }
 
+// A loud banner, so a stale CLI is not missed among the startup output — an old CLI can lack
+// features the board expects (e.g. chat), and npx happily reuses a cached copy. Bold yellow
+// when stderr is a terminal (NO_COLOR respected); plain box otherwise, so piped output stays clean.
+function updateBanner(currentVersion, latestVersion) {
+  const paint = process.stderr.isTTY && !process.env.NO_COLOR ? (t) => `\x1b[1;33m${t}\x1b[0m` : (t) => t;
+  const lines = [
+    '!!  UPDATE REQUIRED — YOUR EVENTMODELERS CLI IS OUT OF DATE  !!',
+    '',
+    `Installed: ${currentVersion}        Latest: ${latestVersion}`,
+    '',
+    'Update now:',
+    '',
+    '  npx @eventmodelers/cli@latest <command>',
+    '      (still old? clear the npx cache: rm -rf ~/.npm/_npx)',
+    '',
+    '  npm i -g @eventmodelers/cli@latest        (global install)',
+    '',
+    'Old versions miss features the board expects —',
+    'e.g. agents that do not reply in the board chat.',
+  ];
+  const width = Math.max(...lines.map((l) => l.length));
+  const bar = '█'.repeat(width + 6);
+  const body = lines.map((l) => `██ ${l.padEnd(width)} ██`);
+  return paint(['', bar, ...body, bar, ''].join('\n'));
+}
+
 // Hint lines for everything that's behind: this CLI against npm, and each installed kit
 // against the CLI running now (its install manifest records the version that wrote it).
 export function updateHints({ currentVersion, latestVersion, kitDirs = [], cwd = process.cwd() }) {
   const hints = [];
   if (latestVersion && compareVersions(currentVersion, latestVersion) < 0) {
-    hints.push(`💡 A new eventmodelers CLI is available: ${currentVersion} → ${latestVersion}. Update with: npm i -g @eventmodelers/cli@latest (or use npx @eventmodelers/cli@latest)`);
+    hints.push(updateBanner(currentVersion, latestVersion));
   }
   for (const kitDir of kitDirs) {
     const reinit = REINIT_COMMANDS[basename(kitDir)];

package/package.json

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

@@ -164,7 +164,7 @@ UUID       // universally unique identifier
 Custom     // structured/nested value — use with `subfields` or `schema`
 ```
 
-Other `Field` properties: `name`, `example`, `subfields[]` (nested `Field`s), `mapping`, `optional`, `technicalAttribute`, `generated`, `idAttribute`, `pii`, `schema`, `cardinality` (`"List"` | `"Single"`).
+Other `Field` properties: `name`, `example`, `subfields[]` (nested `Field`s), `mapping`, `optional`, `technicalAttribute`, `generated`, `idAttribute`, `pii`, `tag` (the field's value tags the event for Dynamic Consistency Boundaries — DCB; see https://dcb.events), `schema`, `cardinality` (`"List"` | `"Single"`).
 
 Use exactly these type names (case-sensitive) — not lowercase (`string`), synonyms (`Number`, `Text`, `Integer`), or types outside this set.
 

package/stacks/axon/templates/.claude/skills/build-state-change/SKILL.md

@@ -28,8 +28,9 @@ Read `.build-kit/.slices/{context}/{slicename}/slice.json`. Extract, and use **o
 - `commands[].fields[]` → Command record fields, in order
 - `events[].fields[]` → Event record fields, in order
 - `specifications[]` (GWT scenarios) → one test method per scenario
-- Which command field(s) have `idAttribute: true` — these carry `@TargetEntityId` (see Step 1) and the
-  matching event field(s) carry `@EventTag`
+- Which command field(s) have `idAttribute: true` — these carry `@TargetEntityId` (see Step 1)
+- The event's DCB tags — **both** the field(s) matching the command's `idAttribute` field(s) **and**
+  every event field with `tag: true` carry `@EventTag` (see Step 2); each gets its own `EventTags` constant
 - `storylines[]` (optional, may be absent) → narrated walkthroughs with ordered `elements[]` "beats";
   see Step 7b for how a COMMAND beat in one of these can add a supplementary test
 

package/stacks/modeling-kit/templates/.claude/skills/html-screen/SKILL.md

@@ -52,14 +52,20 @@ Skip this step entirely when creating a brand-new node (no `nodeId` given) — g
 Write normal, full-size HTML/CSS for each page — as if designing a real webpage, not a tiny thumbnail. The canvas node renders this at a real page width and visually scales it down to fit, so there is no need to shrink font sizes or padding to fit a small box; design at a realistic scale (e.g. 16px body text, generous padding) and let the node handle the shrink.
 
 Guidelines:
-- **Keep it simple — this is a view-only mockup, not a working app.** No JavaScript, no interactivity beyond what a static page can show (enforced server-side, see below). Keep the CSS compact: inline styles or a handful of Bulma classes are enough — don't write a large embedded `<style>` block or reinvent what Bulma already gives you for free.
+- **Keep it simple — this is a view-only mockup, not a working app.** No JavaScript, no interactivity beyond what a static page can show (enforced server-side, see below). Keep the CSS compact: inline styles or a handful of the screen's framework classes (see "CSS framework" below; Bulma by default) are enough — don't write a large embedded `<style>` block or reinvent what the framework already gives you for free.
 - Each page is one complete, standalone HTML fragment — not a `data-step` div nested inside a shared blob. A multi-step flow (e.g. cart → payment → confirmation) is three separate pages in the array, each fully self-contained.
-- **Each page may be at most 6000 characters** (the full markup string, including inline styles). The server rejects a longer page with `400 HTML_SCREEN_PAGE_TOO_LONG` (`context: {pageIndex, length, maxLength}`) and saves nothing — the render call fails as a whole. Check each page's length before rendering; if one is over, trim it (fewer inline styles, Bulma classes instead of custom CSS, fewer repeated sample rows) or split the content into another page. Adding a mark also counts toward the limit, since it adds attributes to the page's markup.
+- **Each page may be at most 6000 characters** (the full markup string, including inline styles). The server rejects a longer page with `400 HTML_SCREEN_PAGE_TOO_LONG` (`context: {pageIndex, length, maxLength}`) and saves nothing — the render call fails as a whole. Check each page's length before rendering; if one is over, trim it (fewer inline styles, framework classes instead of custom CSS, fewer repeated sample rows) or split the content into another page. Adding a mark also counts toward the limit, since it adds attributes to the page's markup.
 - Inline styles (`style="..."`) are the simplest way to keep each page self-contained.
 - No `<script>` tags, no inline event handlers (`onclick`, `onload`, ...), no `javascript:` URIs — these are stripped server-side from every page before persisting regardless of what's sent. This is a static visual mockup, not an interactive prototype.
 - A real page background (e.g. a light gray full-bleed background behind a centered white card) reads more realistically than a bare form floating on white.
 - Don't add `<html>`/`<head>`/`<body>` tags to a page — every page is a body-only fragment. The canvas wraps each page in its own `<html><head>` (stylesheet + resize script) `<body>...</body></html>` at render time, so anything sent is placed inside that generated `<body>`.
-- Bulma CSS (0.9.4) is loaded by default in that `<head>` — classes like `title`, `button`, `is-primary`, `field`/`control`/`input` etc. all work out of the box, no need to write custom CSS for standard form/layout components. Note headings need a size modifier too, e.g. `class="title is-1"` — a bare `title` class alone is always 2rem regardless of the tag (`h1` vs `h2` etc.).
+- **CSS framework — one per screen.** Each screen loads exactly one CSS framework (or none) into every page's `<head>`, chosen by the user in the HTML editor's header and stored on the node as `cssFrameworks` (an array holding one id: `"bulma"`, `"bootstrap"` or `"tailwind"`; `[]` = none). A screen where nothing was chosen gets **Bulma** — that is the default for new screens. Write markup for the framework the screen uses, and never mix classes from several frameworks in one screen:
+  - **Bulma 0.9.4** (default) — classes like `title`, `button`, `is-primary`, `field`/`control`/`input` work out of the box. Note headings need a size modifier too, e.g. `class="title is-1"` — a bare `title` class alone is always 2rem regardless of the tag (`h1` vs `h2` etc.).
+  - **Bootstrap 5.3.3** — CSS only (no JS, so no working dropdowns/modals/collapse): `container`, `row`/`col-*`, `card`, `btn btn-primary`, `form-control`, `table`, etc.
+  - **Tailwind 3.4.16** — utility classes only (`flex`, `p-6`, `bg-gray-100`, `rounded-lg`, ...), built in the page by the Tailwind Play script, so arbitrary values like `w-[320px]` work too. Don't write `@apply`, a `tailwind.config`, or any `<script>`/`<style type="text/tailwindcss">`; stick to utility classes.
+  - **None** — the page is unstyled apart from the browser defaults, so use inline styles for everything.
+
+  When a screen already exists (Step 2), keep using whichever framework its existing pages use — read `cssFrameworks` from the node's data if it's returned, otherwise infer it from the classes in `meta.pages`. Don't switch frameworks while editing; changing it is the user's choice in the editor. When creating a new screen from scratch, use Bulma unless the user names another framework.
 
 ### Marks — only when the user explicitly asks for one
 

package/stacks/umadb/templates/.claude/skills/build-state-change/SKILL.md

@@ -33,8 +33,8 @@ Read `.build-kit/.slices/{context}/{slicename}/slice.json`. Extract, and use **o
 - `commands[].fields[]` → Command record fields, in order
 - `events[].fields[]` → Event record fields, in order
 - `specifications[]` (GWT scenarios) → one test method per scenario
-- Which command field(s) have `idAttribute: true` — these become the tag(s) the command's Query and
-  the resulting event are both scoped to (see Step 1/Step 3)
+- The DCB tags — **both** the command field(s) with `idAttribute: true` **and** every field with
+  `tag: true` become tag(s) the command's Query and the resulting event are both scoped to (see Step 1/Step 3)
 - `storylines[]` (optional, may be absent) → narrated walkthroughs with ordered `elements[]`
   "beats"; see Step 7b for how a COMMAND beat in one of these can add a supplementary test