@eventmodelers/cli 1.0.120 → 1.0.122

package/cli.js

@@ -2106,7 +2106,7 @@ async function runModeling(kitDir, projectDir, { codeDir = null, verbose = false
   const claudeArgs = ['--dangerously-skip-permissions', '-p', '--input-format', 'stream-json', '--output-format', 'stream-json', '--verbose'];
   if (cfg.model) claudeArgs.push('--model', cfg.model);
   // The global install runs in ~/.eventmodelers/kit, away from the code base the person started
-  // the agent in — hand that directory over so code-reading skills (detect-architecture-drift)
+  // the agent in — hand that directory over so code-reading skills (detect-model-drift)
   // can still see it.
   if (codeDir) claudeArgs.push('--add-dir', codeDir);
   const claudeEnv = {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@eventmodelers/cli",
-  "version": "1.0.120",
+  "version": "1.0.122",
   "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/build-kit/lib/ralph.js

@@ -689,6 +689,17 @@ async function runWithRetry(label, fn) {
   }
 }
 
+// prompt.md and backend-prompt.md are instruction manuals with no request in them. Handed one
+// alone, the agent read it as background, answered "what would you like me to help with?" with
+// no tool calls, and a Planned slice stayed Planned until the stuck-slice guard blocked it. So
+// every turn ends with the concrete request — here, once, for every runner.
+function taskRequest(planned = null) {
+  const task = planned
+    ? `build the Planned slice "${planned.title}" (id=${planned.id}, context="${planned.ctx}")`
+    : 'process the pending tasks in tasks.json';
+  return `\n\n---\n\nYour task now: ${task}, following the instructions above. Start immediately.\n`;
+}
+
 async function ralphLoop(kitDir, cfg, onTask, onPlannedSlice, localOnly = false) {
   const promptFile = join(kitDir, 'lib', 'prompt.md');
   const backendPromptFile = join(kitDir, 'lib', 'backend-prompt.md');
@@ -707,7 +718,7 @@ async function ralphLoop(kitDir, cfg, onTask, onPlannedSlice, localOnly = false)
     let didWork = false;
 
     if (credentialed && hasPendingTasks(kitDir)) {
-      const prompt = readFileSync(promptFile, 'utf-8');
+      const prompt = readFileSync(promptFile, 'utf-8') + taskRequest();
       for (const t of readTasks(join(kitDir, 'tasks.json'))) await fetchFullSlice(cfg, kitDir, t.payload?.sliceId);
       await runWithRetry('onTask: loading slice from board...', () => inTurn(kitDir, () => onTask(prompt)));
       await fetchAndPersistSlices(cfg, kitDir).catch(() => {});
@@ -727,7 +738,7 @@ async function ralphLoop(kitDir, cfg, onTask, onPlannedSlice, localOnly = false)
         continue;
       }
 
-      const prompt = readFileSync(backendPromptFile, 'utf-8');
+      const prompt = readFileSync(backendPromptFile, 'utf-8') + taskRequest(planned);
       if (credentialed) await fetchFullSlice(cfg, kitDir, planned.id);
       lastReply = null;
       const built = await runWithRetry(`onPlannedSlice: building slice "${planned.title}"...`, async () => { lastReply = await onPlannedSlice(prompt, {

package/shared/build-kit/ralph-claude.js

@@ -80,15 +80,11 @@ function describeToolUse(block) {
 // `slice` is set for a planned-slice build (see startRalph) — the only turns that are traced.
 function runClaude(prompt, slice = null) {
   return new Promise((resolve, reject) => {
-    // The prompt goes in on stdin, never as a `-p` argument: on Windows a multi-line argv entry
-    // is cut at its first newline, so `claude` saw only the connect header, answered "I don't see
-    // a request" and the slice stayed Planned until the stuck-slice guard blocked it.
-    const proc = spawn('claude', [...claudeArgs, '-p'], {
+    const proc = spawn('claude', [...claudeArgs, '-p', inlineHeader + prompt], {
       cwd: projectDir,
-      stdio: ['pipe', 'pipe', 'inherit'],
+      stdio: ['inherit', 'pipe', 'inherit'],
       env: claudeEnv,
     });
-    proc.stdin.end(inlineHeader + prompt);
     const turn = superviseTurn(proc, { timeoutMs, label: 'Claude turn', log: (line) => console.error(`[ralph] ${line}`) });
 
     let buffer = '';

package/stacks/bridge/templates/bridge/ralph-claude.js

@@ -26,13 +26,11 @@ const claudeEnv = cfg.anthropicBaseUrl
 
 function runClaude(prompt) {
   return new Promise((resolve, reject) => {
-    // Prompt on stdin, not as a `-p` argument — Windows cuts a multi-line argv entry at its first newline.
-    const proc = spawn('claude', [...claudeArgs, '-p'], {
+    const proc = spawn('claude', [...claudeArgs, '-p', inlineHeader + prompt], {
       cwd: projectDir,
-      stdio: ['pipe', 'inherit', 'inherit'],
+      stdio: 'inherit',
       env: claudeEnv,
     });
-    proc.stdin.end(inlineHeader + prompt);
     proc.on('close', (code) => (code === 0 ? resolve() : reject(new Error(`Claude exited ${code}`))));
     proc.on('error', reject);
   });

package/stacks/modeling-kit/templates/.claude/skills/{detect-architecture-drift → detect-model-drift}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: detect-architecture-drift
+name: detect-model-drift
 description: Compare the event model on the board with the code in this repository and report where they have drifted apart — fields on commands/events/read models, specifications vs tests, screens, edges, slices missing in code, and slices in code that the model doesn't have. Read-only; every finding comes with a suggested fix the user confirms first.
 ---
 
-# Detect Architecture Drift
+# Detect Model Drift
 
 ## Step 0 — Is there a code base?
 
@@ -11,7 +11,7 @@ Drift is the gap between the board and the code, so it can only be detected wher
 
 If it is not (an empty folder, a modeling-only workspace holding just `.claude/`, `.eventmodelers/` or `.agent-modeling-kit/`), **stop and answer in one or two plain sentences**, e.g.:
 
-> Architecture drift can't be detected here — there is no code to compare the board against. Run this in the code base that implements the model.
+> Model drift can't be detected here — there is no code to compare the board against. Run this in the code base that implements the model.
 
 Do not connect, do not read the board, do not produce a report or snippet, and do not offer other fixes.
 
@@ -52,6 +52,8 @@ Use the **full** slice data (no `projection`): you need fields with types and `i
 
 Call `validate_model { boardId, chapterId }` for a scoped timeline — it already lists structural gaps on the board side (zero/multi-issuer commands, sourceless read models, missing scenarios). Those are model problems, not drift: mention them in one line, don't duplicate them as findings.
 
+**Always read each chapter's context note before comparing.** The MARKDOWN note in the `feedback` lane of a chapter's **first column** holds the context for that chapter — architecture decisions, intended deviations, what the code is supposed to look like. For every chapter in scope, call `get_board_outline { boardId, chapterId }`, take the first column's node with `type: "MARKDOWN"` in a `feedback` lane, and read its `meta.description` with `get_node`. Judge every finding against it: a difference the note explains is intentional, not drift. A chapter without such a note is fine — carry on without it.
+
 Index the result in memory: per slice → commands, events, read models, screens, automations, specifications, dependencies.
 
 ---
@@ -91,7 +93,7 @@ Rules for judging, in order:
 - **Obvious typos and clearly wrong flags are one finding with a direct fix** (`custoemrId` in the code vs `customerId` on the board; `idAttribute: false` on the entity's own id) — name the correct side, don't ask which it is.
 - **Direction matters.** A mismatch with no earlier evidence has no "right" side: propose the fix in the direction the evidence points (see Step 5), and say when it is a judgement call.
 - Don't report framework noise: generated ids, metadata/envelope fields, serialization annotations, test fixtures' helper types, routes when the slice has no screen.
-- Don't flag what is clearly intentional (an internal slice with no screen; a read model used only by another read model).
+- Don't flag what is clearly intentional (an internal slice with no screen; a read model used only by another read model), or what the chapter's first-column feedback note (Step 2) describes as intended.
 - Report each underlying difference **once**, at the element where it starts; a renamed field shows up on the command and the event and the read model — that is one finding listing the chain, not three.
 
 ---
@@ -102,12 +104,14 @@ For every finding, pick who should move:
 
 | Evidence | Fix goes to | How it's done |
 |----------|-------------|---------------|
-| Code differs from `.build-kit/.slices` snapshot, board still equals the snapshot | **Model** — the code moved on deliberately | Skill that changes the board: `/attributes` (fields), `/timeline` / `/place-element` (elements), `/eventmodeling-elaborating-scenarios` (specs), `/storyboard-screen` or `/html-screen` (screens) |
+| Code differs from `.build-kit/.slices` snapshot, board still equals the snapshot | **Model** — the code moved on deliberately | Skill that changes the board: `/attributes` (fields), `/timeline` / `/place-element` (elements), `/eventmodeling-elaborating-scenarios` (specs), `/storyboard-screen` or `/html-screen` (screens — including updating every existing screen connected to a changed element, see below) |
 | Board differs from the snapshot, code still equals it | **Code** — the model moved on | Set the slice back to `Planned` with `/update-slice-status` so the build kit picks it up again and diffs code against `slice.json` |
 | Both moved, or no snapshot | **Judgement call** — present both options, recommend one | Recommend by which side is more specific/complete |
 | Slice only in code | **Model** | Add the slice, via `/eventmodeling-slicing-event-models` after placing its elements |
 | Slice missing in code, board says `Done` | **Model status** (it isn't done) | `/update-slice-status` → `Planned` |
 
+**A model fix always includes the existing screens.** When a field, command or read model changes on the board, every SCREEN/HTML_SCREEN that shows or submits it must change with it — otherwise the drift just moves from the code into the storyboard. List each affected screen in the same finding (follow the read model → screen and screen → command edges), and update it in place: `/html-screen` with its `nodeId` (loads the current pages and edits them, plus its `meta.fields`), `/storyboard-screen` for a wireframe sketch. Never create a new screen next to an outdated one.
+
 Never propose "fix the code" by editing it from this skill — code changes belong to the build kit (`/update-slice-status` → `Planned`).
 
 ---
@@ -150,7 +154,7 @@ Print the report below, with every finding as a `- [ ]` checkbox carrying its pr
 Name each slice and element as `[<title>](ref:<nodeId>)` (the slice border's id for a slice). The terminal shows the title, and once the report is in a board note or an element description, a click zooms the canvas to it (see `/learn-eventmodelers-api` *Linking to elements in markdown*). A slice that exists only in code has no node, so it stays plain text.
 
 ```
-## Architecture Drift — <scope: board | timeline "<title>" | context "<name>">
+## Model Drift — <scope: board | timeline "<title>" | context "<name>">
 Compared: <n> slices on the board, <n> slice folders in code    Analysed: <ISO timestamp>
 
 ### Slices
@@ -178,3 +182,5 @@ Omit empty sections. Say plainly when nothing drifted.
 - Read-only until confirmed — the report is the product; the fixes run as separate, ticked work.
 - A scoped run (timeline in focus) never reports "slice only in code" for code outside the scope.
 - One difference, one finding: follow a rename along the chain instead of listing it per element.
+- Fixing drift on the model side means updating the existing screens connected to the changed elements too (pages and `meta.fields`), in place — not just the command/event/read model.
+- Always read the MARKDOWN note in the feedback lane of each chapter's first column first — it is the chapter's context, and differences it explains are not drift.

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-code-base`, `/detect-architecture-drift`, `/add-next-slice`, `/examples`, `/timeline …`,
+     writes these: `/analyze-existing-model`, `/analyze-code-base`, `/detect-model-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
@@ -357,7 +357,7 @@ nothing to sanitize either, since a board change is not user text.
 | 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 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` |
+| Find where the model and the code have drifted apart (fields, specs, screens, edges, missing/extra slices) and propose fixes | `/detect-model-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` |
 | Add or rename an attribute across a chain of elements | `/attributes` |