@eventmodelers/cli 1.0.75 → 1.0.77

package/README.md

@@ -79,6 +79,7 @@ your-project/
 ├── .build-kit/                    ← agent runner (name is .agent-modeling-kit/ for the modeling-kit stack)
 │   ├── ralph-claude.js            ← realtime agent + task loop
 │   ├── ralph-local-ai.js          ← same, via a local/self-hosted model
+│   ├── ralph-exec.js              ← same, via an external agent command (Codex CLI, OpenCode, …)
 │   ├── ralph.sh                   ← bash-only loop (no realtime)
 │   ├── lib/                       ← stack-specific agent prompts + helpers
 │   └── .slices/                   ← board slices, written by `fetch`/`listen` (or pre-seeded by `init --demo`)
@@ -125,6 +126,7 @@ npx @eventmodelers/cli init --stack <name> --demo   # same, plus a ready-made de
 npx @eventmodelers/cli re-init                      # refresh an already-installed kit's scripts/skills only — never touches the root scaffold
 npx @eventmodelers/cli run                          # start the agent loop (ralph-claude.js) from the installed kit dir
 npx @eventmodelers/cli run --local-ai [target]      # same, via a local/self-hosted model (ralph-local-ai.js)
+npx @eventmodelers/cli run --exec "<command>"        # same, via an external agent harness (ralph-exec.js)
 npx @eventmodelers/cli run --bash                   # bash-only loop, no realtime (ralph.sh)
 npx @eventmodelers/cli run --local                  # skip platform config/credential lookup entirely — local-only, no board sync
 npx @eventmodelers/cli run --modeling               # modeling-kit: warm Claude process driven by the board's prompt queue

package/cli.js

@@ -31,7 +31,7 @@ const __dirname = dirname(__filename);
 
 // Each stack is a template set under stacks/<key>/templates/{.claude,root,<kitSubdir>}.
 // Stacks with useShared:true also get shared/build-kit/* copied into their kit dir
-// first (ralph.js, ralph-claude.js, ralph-local-ai.js, ralph.sh, realtime-agent.js,
+// first (ralph.js, ralph-claude.js, ralph-local-ai.js, ralph-exec.js, ralph.sh, realtime-agent.js,
 // code-export.mjs, lib/agent.sh, lib/local-ai-agent.js, package.json, README.md) —
 // those files have no per-stack content, so they live once instead of being
 // copy-pasted into every stack (that copy-pasting is exactly how they drifted out
@@ -222,9 +222,11 @@ const MCP_MANUAL_CLIENTS = [
 // directory tells it to go read the canonical .claude/skills/<name>/SKILL.md and
 // follow it — the same pattern spec-kitty uses (verified directly against its repo,
 // not just its docs: every "stub" host below reads plain Markdown, no per-host
-// format transform needed). Codex CLI, Mistral Vibe, Pi, and Letta Code share one
-// convention that already matches our native SKILL.md format, so those get the
-// real file copied as-is instead of a stub.
+// format transform needed). Codex CLI, Mistral Vibe, Pi, Letta Code, and Hermes
+// share one convention that already matches our native SKILL.md format, so those
+// get the real file copied as-is instead of a stub. (Hermes also has a native
+// .hermes/skills/ location, but its docs list .agents/skills/ as an equally
+// first-class project skill root, so there's no reason to write the tree twice.)
 const AGENT_HOSTS = {
   cursor: { label: 'Cursor', dir: '.cursor/commands', kind: 'stub' },
   windsurf: { label: 'Windsurf', dir: '.windsurf/workflows', kind: 'stub' },
@@ -238,12 +240,33 @@ const AGENT_HOSTS = {
   augment: { label: 'Augment Code', dir: '.augment/commands', kind: 'stub' },
   antigravity: { label: 'Google Antigravity', dir: '.agent/workflows', kind: 'stub' },
   codex: {
-    label: 'Codex CLI / Mistral Vibe / Pi / Letta Code (shared .agents/skills/ convention)',
+    label: 'Codex CLI / Mistral Vibe / Pi / Letta Code / Hermes (shared .agents/skills/ convention)',
     dir: '.agents/skills',
     kind: 'skill-package',
   },
 };
 
+// Several hosts share one directory convention, so they resolve to a single
+// canonical entry above instead of each getting their own: writing the same
+// .agents/skills/ tree four times would be pure duplication, and `--hosts all`
+// would print four "installed" lines for one install. These exist so people can
+// name the agent they actually use — `--hosts pi` is a friendlier spelling of
+// `--hosts codex`, not a different install.
+const AGENT_HOST_ALIASES = {
+  pi: 'codex',
+  hermes: 'codex',
+  vibe: 'codex',
+  'mistral-vibe': 'codex',
+  letta: 'codex',
+  'letta-code': 'codex',
+};
+
+// Alias -> canonical, deduped and order-preserving. Unknown keys pass through
+// untouched so the caller keeps reporting them as unknown.
+function resolveAgentHostKeys(keys) {
+  return [...new Set(keys.map((k) => AGENT_HOST_ALIASES[k] || k))];
+}
+
 function agentHostStub(skillName) {
   return `# ${skillName} (eventmodelers)\n\nThis host should read the canonical skill at:\n\n**\`.claude/skills/${skillName}/SKILL.md\`**\n\nFollow those instructions when this command is invoked.\n`;
 }
@@ -269,15 +292,18 @@ async function configureAgentHosts({ hosts, global: useGlobal } = {}) {
   if (!hostKeys || !hostKeys.length) {
     console.log('\nAvailable agent hosts:');
     Object.entries(AGENT_HOSTS).forEach(([key, h]) => console.log(`  ${key.padEnd(12)} ${h.label}`));
+    const aliasKeys = Object.keys(AGENT_HOST_ALIASES);
+    if (aliasKeys.length) console.log(`\n  (also accepted: ${aliasKeys.join(', ')})`);
     const answer = await prompt('\nWhich hosts? (comma-separated keys, or "all"): ');
     hostKeys = answer.trim() === 'all'
       ? Object.keys(AGENT_HOSTS)
       : answer.split(',').map((s) => s.trim()).filter(Boolean);
   }
+  hostKeys = resolveAgentHostKeys(hostKeys);
 
   const unknown = hostKeys.filter((k) => !AGENT_HOSTS[k]);
   if (unknown.length) {
-    console.error(`❌ Unknown host(s): ${unknown.join(', ')}. Available: ${Object.keys(AGENT_HOSTS).join(', ')}`);
+    console.error(`❌ Unknown host(s): ${unknown.join(', ')}. Available: ${Object.keys(AGENT_HOSTS).join(', ')} (aliases: ${Object.keys(AGENT_HOST_ALIASES).join(', ')})`);
     process.exit(1);
   }
   if (!hostKeys.length) {
@@ -1011,7 +1037,7 @@ async function installStack(stackKey, stackCfg, options = {}) {
     }
 
     // Make scripts executable
-    for (const script of ['ralph.sh', 'lib/agent.sh', 'ralph-claude.js', 'ralph-local-ai.js']) {
+    for (const script of ['ralph.sh', 'lib/agent.sh', 'ralph-claude.js', 'ralph-local-ai.js', 'ralph-exec.js']) {
       const p = join(kitDir, script);
       if (existsSync(p)) {
         try { execSync(`chmod +x "${p}"`); } catch {}
@@ -2821,7 +2847,7 @@ program
 program
   .command('init-agents')
   .description(`Expose installed skills to other AI agent hosts (${Object.keys(AGENT_HOSTS).join(', ')}) as thin stub commands pointing at the canonical .claude/skills/ files — no skill content duplicated per host`)
-  .option('--hosts <list>', `Comma-separated host keys (${Object.keys(AGENT_HOSTS).join(', ')})`)
+  .option('--hosts <list>', `Comma-separated host keys (${Object.keys(AGENT_HOSTS).join(', ')}; aliases: ${Object.keys(AGENT_HOST_ALIASES).join(', ')})`)
   .option('--all', 'Expose to every known host')
   .option('--global', 'Read skills from ~/.claude/skills/ instead of the project')
   .action(async (opts) => {
@@ -3041,6 +3067,7 @@ credentialFlags(program
   .command('run')
   .description('Start the agent loop from the installed kit dir — build-kit stacks: ralph-claude.js (default); modeling-kit: --modeling, or --standalone, which needs no install at all')
   .option('--local-ai [target]', `Drive the loop with a local (or self-hosted) model instead of the default Claude runner, via ralph-local-ai.js (build-kit stacks only). Optional target preset picks the URL and wire dialect: ${LOCAL_AI_TARGETS.join(', ')} — bare --local-ai means ollama. Anything OpenAI-compatible (vLLM, LM Studio, llama.cpp, TGI) works by pointing LOCAL_AI_URL at it; see LOCAL_AI_* in the docs. Claude remains the default when this flag is absent.`)
+  .option('--exec [command]', 'Hand each prompt to an external agent command instead of the default Claude runner, via ralph-exec.js (build-kit stacks only) — for agentic harnesses that bring their own tool loop, e.g. "codex exec --full-auto" or "opencode run". The prompt is appended as a quoted argument and also written to the file named by RALPH_PROMPT_FILE. Bare --exec uses localAi.exec from .eventmodelers/config.json. Claude remains the default when this flag is absent.')
   .option('--bash', 'Use the bash-only ralph.sh loop (build-kit stacks only, no realtime)')
   .option('--modeling', 'Keep one Claude process warm across prompts instead of spawning a fresh one per task, for low-latency voice/live use. Runs from a modeling-kit install in this directory, or from the global install (~/.eventmodelers/kit) when there is none. Built into the CLI, not a per-project file.')
   .option('--standalone', 'Let the modeling agent work the board in the background, on its own initiative: on top of direct prompts it subscribes to the board\'s change channel (like the build agents do) and, whenever the board goes quiet after an edit — or has simply been idle for a while — it takes a turn nobody asked for. Changed nodes are a notification, not the task: it judges the model as a whole and fans the work out over parallel subagents, one per changed area (examples on a new node, specs for a new command or read model, a missing attribute along a chain, a screen, a question comment). Filling that detail in while the human keeps modeling is the point — it does not wait for the board to be finished. Implies --modeling.')
@@ -3109,8 +3136,8 @@ credentialFlags(program
     // no meaning for a build kit, which is scaffolded per project by definition.
     if (opts.modeling || opts.standalone || opts.global) {
       const picked = opts.modeling ? '--modeling' : opts.standalone ? '--standalone' : '--global';
-      if (opts.bash || opts.localAi) {
-        console.error(`❌ ${picked} is mutually exclusive with --bash/--local-ai — those select a build-kit runner, which the modeling loop has no use for.`);
+      if (opts.bash || opts.localAi || opts.exec) {
+        console.error(`❌ ${picked} is mutually exclusive with --bash/--local-ai/--exec — those select a build-kit runner, which the modeling loop has no use for.`);
         process.exit(1);
       }
       if (opts.local) {
@@ -3169,9 +3196,9 @@ credentialFlags(program
     const kitDir = buildKitDir;
 
     const localAiTarget = resolveLocalAiTarget(opts);
-    const pickedCount = [opts.bash, localAiTarget !== null].filter(Boolean).length;
+    const pickedCount = [opts.bash, localAiTarget !== null, !!opts.exec].filter(Boolean).length;
     if (pickedCount > 1) {
-      console.error('❌ --bash and --local-ai are mutually exclusive — pick one.');
+      console.error('❌ --bash, --local-ai and --exec are mutually exclusive — pick one runner.');
       process.exit(1);
     }
 
@@ -3179,7 +3206,7 @@ credentialFlags(program
     // is just a thin dispatcher so users don't have to remember the kit-dir name or which
     // runner file to invoke. Users (and the agent itself, via AGENT.md) may customize these
     // files freely; `run` always executes whatever is currently on disk.
-    const runner = opts.bash ? 'ralph.sh' : localAiTarget !== null ? 'ralph-local-ai.js' : 'ralph-claude.js';
+    const runner = opts.bash ? 'ralph.sh' : opts.exec ? 'ralph-exec.js' : localAiTarget !== null ? 'ralph-local-ai.js' : 'ralph-claude.js';
     const runnerPath = join(kitDir, runner);
     if (!existsSync(runnerPath)) {
       console.error(`❌ ${relative(cwd, runnerPath)} not found.`);
@@ -3195,7 +3222,7 @@ credentialFlags(program
       // local-only branch even when .eventmodelers/config.json has valid credentials.
       // RALPH_AGENT_ID/RALPH_AGENT_NAME (--id/--name) are read in ralph.js's startRalph, so
       // they reach both node runners but not ralph.sh, which has no heartbeat to identify.
-      execSync(cmd, { cwd: kitDir, stdio: 'inherit', env: { ...process.env, RALPH_VERBOSE: opts.verbose ? '1' : '', RALPH_LOCAL: opts.local ? '1' : '', RALPH_AGENT_ID: identity.agentId ?? '', RALPH_AGENT_NAME: identity.agentName ?? '', ...(typeof localAiTarget === 'string' ? { LOCAL_AI_TARGET: localAiTarget } : {}) } });
+      execSync(cmd, { cwd: kitDir, stdio: 'inherit', env: { ...process.env, RALPH_VERBOSE: opts.verbose ? '1' : '', RALPH_LOCAL: opts.local ? '1' : '', RALPH_AGENT_ID: identity.agentId ?? '', RALPH_AGENT_NAME: identity.agentName ?? '', ...(typeof localAiTarget === 'string' ? { LOCAL_AI_TARGET: localAiTarget } : {}), ...(typeof opts.exec === 'string' ? { RALPH_EXEC_CMD: opts.exec } : {}) } });
     } catch (err) {
       process.exit(err.status || 1);
     }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@eventmodelers/cli",
-  "version": "1.0.75",
+  "version": "1.0.77",
   "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/README.md

@@ -26,6 +26,7 @@ node .build-kit/ralph-claude.js /path/to/project
 |------|---------|
 | `ralph-claude.js` | Runs the full loop using Claude Code as the executor |
 | `ralph-local-ai.js` | Runs the full loop using a local/self-hosted model (Ollama, vLLM, LM Studio, llama.cpp) |
+| `ralph-exec.js` | Runs the full loop handing each prompt to an external agent command (Codex CLI, OpenCode, …) |
 | `ralph.sh` | Shell-based loop — alternative to the JS entry points |
 | `realtime-agent.js` | Standalone realtime agent — only needed to run it in a separate terminal |
 
@@ -87,6 +88,43 @@ default here is raised rather than left to the server. On the `openai` dialect t
 equivalent is set when you launch the server (vLLM `--max-model-len 32768`,
 llama.cpp `-c 32768`); an overflow there surfaces as an HTTP 400.
 
+
+## External agent commands (`--exec`)
+
+Agentic harnesses that bring their own tool loop — Codex CLI, OpenCode, Gemini CLI —
+are not `--local-ai` targets: `--local-ai` *supplies* the agent loop, while a harness
+already is one and only wants a prompt. They go through `ralph-exec.js` instead:
+
+```bash
+npx @eventmodelers/cli run --exec "codex exec --full-auto"
+npx @eventmodelers/cli run --exec "opencode run"
+
+# …or persist it and use the bare flag
+RALPH_EXEC_CMD="codex exec --full-auto" node .build-kit/ralph-exec.js
+```
+
+The prompt is appended to the command as one shell-quoted argument, and is also written
+to a temp file named by `RALPH_PROMPT_FILE` for commands that prefer to read it. The
+child runs with the project dir as its cwd and inherits stdio — a harness owns its own
+output format, so there is no condensed per-step logging here the way `ralph-claude.js`
+has it.
+
+Persist a default alongside the local-AI settings:
+
+```json
+{
+  "localAi": {
+    "exec": "codex exec --full-auto"
+  }
+}
+```
+
+One caveat worth knowing before reaching for this: the kits' prompts assume Claude
+Code's `Skill` tool and `CLAUDE.md`. Other harnesses read `AGENTS.md` and have no skill
+primitive, so `init-agents` puts the skill files where they can find them, but
+`lib/prompt.md` / `lib/backend-prompt.md` still need wording that says *read and follow*
+a skill file rather than *invoke* it.
+
 ## Config
 
 Credentials are stored in `.build-kit/.eventmodelers/config.json` (written by `eventmodelers init`):

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

@@ -0,0 +1,92 @@
+#!/usr/bin/env node
+// Ralph loop handing each prompt to an arbitrary external agent command, instead
+// of the default Claude runner.
+//
+// This is the escape hatch for agentic harnesses that bring their own tool loop —
+// Codex CLI, OpenCode, Gemini CLI, and whatever comes next. They are NOT --local-ai
+// targets: --local-ai supplies the agent loop (we load the MCP tools and drive the
+// tool-call rounds), whereas a harness already is one and only wants a prompt. One
+// generic spawn covers all of them, which beats a hand-written runner per vendor.
+//
+// The prompt is appended to the command as a single quoted argument (what most
+// harnesses expect) and is also written to a temp file named by RALPH_PROMPT_FILE,
+// for commands that would rather read it than take it on the command line.
+//
+// Usage: node ralph-exec.js [project_dir]
+//        RALPH_EXEC_CMD="codex exec --full-auto" node ralph-exec.js
+//        RALPH_EXEC_CMD="opencode run" node ralph-exec.js
+// Or persist it as localAi.exec in .eventmodelers/config.json.
+
+import { startRalph, loadLocalConfig } from './lib/ralph.js';
+import { spawn } from 'child_process';
+import { writeFileSync, mkdtempSync } from 'fs';
+import { tmpdir } from 'os';
+import { dirname, join, resolve } from 'path';
+import { fileURLToPath } from 'url';
+
+const kitDir = dirname(fileURLToPath(import.meta.url));
+const projectDir = process.argv[2] ? resolve(process.argv[2]) : resolve(kitDir, '..');
+
+const cfg = loadLocalConfig(kitDir);
+const localOnly = process.env.RALPH_LOCAL === '1';
+const execCmd = process.env.RALPH_EXEC_CMD || cfg.localAi?.exec;
+
+if (!execCmd) {
+  console.error('[ralph-exec] No agent command configured.');
+  console.error('  Set one for this run: eventmodelers run --exec "codex exec --full-auto"');
+  console.error('  Or persist a default as localAi.exec in .eventmodelers/config.json');
+  process.exit(1);
+}
+
+// Same rule as ralph-claude.js: --local must mean zero board contact, so credentials
+// never reach the child even when config.json has them.
+const inlineHeader = !localOnly && cfg.boardId
+  ? `board=${cfg.boardId} token=${cfg.token} org=${cfg.organizationId} baseUrl=${cfg.baseUrl}\n\n`
+  : '';
+
+const childEnv = {
+  ...process.env,
+  ...(cfg.token && !localOnly ? { EVENTMODELERS_TOKEN: cfg.token } : {}),
+  ...(cfg.agentId && !localOnly ? { EVENTMODELERS_AGENT_ID: cfg.agentId } : {}),
+};
+
+const promptDir = mkdtempSync(join(tmpdir(), 'ralph-exec-'));
+
+// POSIX single-quote escaping: close, insert an escaped quote, reopen. The prompt is
+// multi-line Markdown with backticks and $ in it, so it cannot go in unquoted.
+function shellQuote(s) {
+  return `'${String(s).replace(/'/g, `'\\''`)}'`;
+}
+
+console.log(`[ralph-exec] command: ${execCmd}`);
+
+function runExec(prompt) {
+  return new Promise((resolvePromise, reject) => {
+    const full = inlineHeader + prompt;
+    const promptFile = join(promptDir, 'prompt.md');
+    writeFileSync(promptFile, full);
+
+    // stdio inherit: the harness owns its own output format, and there is no
+    // cross-harness stream schema to parse into the condensed per-step logging
+    // that ralph-claude.js does — so it goes straight through.
+    const proc = spawn(`${execCmd} ${shellQuote(full)}`, {
+      cwd: projectDir,
+      stdio: 'inherit',
+      shell: true,
+      env: { ...childEnv, RALPH_PROMPT_FILE: promptFile },
+    });
+    proc.on('close', (code) => (code === 0 ? resolvePromise() : reject(new Error(`exec command exited ${code}`))));
+    proc.on('error', reject);
+  });
+}
+
+startRalph({
+  kitDir,
+  projectDir,
+  onTask: runExec,
+  onPlannedSlice: runExec,
+  localOnly,
+}).catch((err) => {
+  console.error('[ralph] Fatal:', err);
+  process.exit(1);
+});

package/shared/skills/learn-eventmodelers-api/SKILL.md

@@ -25,39 +25,40 @@ Server name: `eventmodelers`. Every tool takes `boardId` explicitly; none need `
 | `get_node_comments` | `boardId`, `nodeId` | List comments on a node | §1 `GET .../nodes/:nodeId/comments` |
 | `get_board_events` | `boardId` | All board events, in sequence | §1 `GET .../events` |
 | `search_board_events` | `boardId`, `name` | Search events by node name | §1 `GET .../events/search` |
-| `submit_node_events` | `boardId`, `events[]`, `autoConnect?`, `compact?` | Create/update nodes (raw `NodeChangeEvent`/edge events). `autoConnect: false` places freshly-created nodes without wiring them to their own/previous-column neighbors (avoids a stray nearest-left edge); `compact: true` returns `{persisted: <count>}` instead of the per-node hash map | §3 `POST .../nodes/events` |
+| `submit_node_events` | `boardId`, `events[]`, `autoConnect?`, `compact?` | Create/update nodes (raw `NodeChangeEvent`/edge events). Every event property is described on the tool's own `events[]` schema — read that rather than this skill when all you need is the event shape. `autoConnect: false` places freshly-created nodes without wiring them to their own/previous-column neighbors (avoids a stray nearest-left edge); `compact: true` returns `{persisted: <count>}` instead of the per-node hash map | §3 `POST .../nodes/events` |
 | `delete_node` | `boardId`, `nodeId` | Delete a node. Deleting a chapter (timeline) cascades — every node placed in one of its cells, plus any node parented to it (e.g. SLICE_BORDER), is deleted too, along with all their edges | (via `node:deleted` event, §3) |
-| `create_drawing` | `boardId`, `kind`, `x`, `y`, `width`, `height`, ... | Freehand canvas annotation (path/rect/text) — never placed in a cell | — (no REST equivalent; MCP-only) |
+| `create_drawing` / `create_drawings` | `boardId`, `kind`, `x`, `y`, `width`, `height`, ... (plural: `drawings[]`) | Freehand canvas annotation (path/rect/text/sticky) — never placed in a cell. Use the plural form whenever an annotation is more than one stroke (a loop plus its arrows and label is one annotation, not three calls) | — (REST `POST .../drawing/draw` accepts a single drawing or an array) |
 | `find_nodes_in_drawing` | `boardId`, `drawingId` | Nodes fully contained inside a drawing's bounding box | — (no REST equivalent; MCP-only) |
-| `create_chapter` | `boardId`, `x?`, `y?` | Create a timeline. Omitting `x`/`y` auto-stacks it below the lowest existing chapter (by its *actual current* row-height total, not the height it was created with — safe even after `add_lane` growth), plus a fixed margin | §2 `POST .../chapters` |
+| `create_chapter` | `boardId`, `x?`, `y?`, `title?`, `columns?`, `lanes?: [{type, label?, height?}]` | Create a timeline. Omitting `x`/`y` auto-stacks it below the lowest existing chapter (by its *actual current* row-height total, not the height it was created with — safe even after `add_lane` growth), plus a fixed margin. Pass `title` to name it, `columns` for a known column count, and `lanes` to create named lanes (or several of one type, e.g. one swimlane per context) — none of the three needs a follow-up call, and the lanes are sorted into the required order automatically. The response carries every `columnId` and lane id, so the chapter needn't be read back before placing into it | §2 `POST .../chapters` |
 | `get_chapter_bounds` | `boardId` | Absolute canvas bounding box `{id, title, x, y, width, height}` of every chapter on the board — width/height derived from each chapter's current row/column layout, not a guessed default. Use before picking explicit `x`/`y` for `create_chapter` (e.g. placing below the chapter with the largest `y + height`) to avoid overlapping one that grew since it was created | §2 `GET .../chapters/bounds` |
 | `add_column` | `boardId`, `timelineId`, `index?`, `beforeNodeId?`, `afterNodeId?`, `count?` | Add one or more columns in one call. `count` inserts that many contiguously starting at the insertion point (default 1). Position with at most one of `index` (0-based), `beforeNodeId`, or `afterNodeId` (resolves the index from where that already-placed node currently sits) — omit all three to append | §2 `POST .../timelines/:id/columns` |
 | `delete_column` | `boardId`, `timelineId`, `columnId` | Delete a column | §2 `DELETE .../columns/:columnId` |
-| `add_lane` | `boardId`, `timelineId`, `type`, `label?`, `index?` | Add a lane/row | §2 `POST .../timelines/:id/lanes` |
+| `add_lane` / `add_lanes` | `boardId`, `timelineId`, `type`, `label?`, `index?`, `height?` (plural: `lanes[]`) | Add a lane/row. Use the plural form for more than one; for a chapter that doesn't exist yet, pass `lanes` to `create_chapter` instead — that needs no lane call at all | §2 `POST .../timelines/:id/lanes` (accepts an array too) |
 | `remove_lane` | `boardId`, `timelineId`, `rowId` | Remove a lane | — (extends §2; no direct REST route) |
 | `move_node_in_timeline` | `boardId`, `timelineId`, `movedNodeId`, `toCellId` | Move a placed node to another cell — its previous cell is automatically cleared | — (MCP-only convenience) |
 | `move_timeline_structure` | `boardId`, `timelineId`, `kind` (`'column'\|'lane'`), `id`, `toIndex` | Reorder a column or lane (row) — `kind` picks which `id` refers to | — (MCP-only convenience) |
 | `move_timeline_position` | `boardId`, `timelineId`, `x`, `y` | Move a chapter node on canvas | — (MCP-only convenience) |
 | `drop_node_to_cell` | `boardId`, `timelineId`, `cellId`, `nodeId`, `nodeType` | Place an existing node into a cell — if it was already placed elsewhere on this timeline, that cell is automatically cleared | §2 `POST .../cells/:cellId/drop` |
 | `clear_cell` | `boardId`, `timelineId`, `cellId` | Unassign the node from a cell without deleting it — the cell becomes empty and the node survives (unplaced); no-op if already empty. Use `delete_node` to remove the node entirely | — (MCP-only convenience) |
-| `create_slice` | `boardId`, `timelineId`, `type`, `index?`, `nodes?: {actor?, interaction?, swimlane?}` (each `{rowId?, title?}`) | Create a full slice (column + nodes + SLICE_BORDER). `rowId` targets a specific lane when the chapter has more than one lane of that type (e.g. several actor lanes); omit to use the first matching lane | §5 `POST .../slices` |
-| `create_slice_definition` | `boardId`, `timelineId`, `columnId`, `title`, `data?`, `meta?` | Create a SLICE_BORDER over an existing column | §5 `POST .../slice-definitions` |
-| `place_element` | `boardId`, `timelineId`, `elementType`, `title`, `columnIndex?`, `compact?`, `autoConnect?` | Find/create an empty cell in the right lane and place a COMMAND/READMODEL/EVENT. `autoConnect: false` places without wiring to timeline neighbors — wire the edges yourself | — (MCP-only convenience; composes §2+§3) |
+| `create_slice` | `boardId`, `timelineId`, `type`, `index?`, `nodes?: {actor?, interaction?, swimlane?}` (each `{rowId?, title?, fields?}`), `status?` | Create a full slice (column + nodes + SLICE_BORDER). `rowId` targets a specific lane when the chapter has more than one lane of that type (e.g. several actor lanes); omit to use the first matching lane. `fields` writes that node's attributes in the same call, and `status` gives the SLICE_BORDER its `sliceStatus` on creation — neither needs a follow-up write | §5 `POST .../slices` |
+| `create_slice_definition` | `boardId`, `timelineId`, `columnId`, `title`, `status?`, `data?`, `meta?` | Create a SLICE_BORDER over an existing column. `status` sets its `sliceStatus` straight away instead of a follow-up `update_slice_status` | §5 `POST .../slice-definitions` |
+| `place_element` / `place_elements` | `boardId`, `timelineId`, `elementType`, `title`, `fields?`, `lane?`, `columnIndex?`, `compact?`, `autoConnect?` (plural: `elements[]`) | Find/create an empty cell in the right lane and place a COMMAND/READMODEL/EVENT. `fields` writes the element's attributes in the same call — don't follow a placement with a `submit_node_events` just to set them. The plural form places a whole slice's or column run's worth in one call, applied in order so each entry sees the columns the previous one added. `autoConnect: false` places without wiring to timeline neighbors — wire the edges yourself | — (MCP-only convenience; composes §2+§3) |
 | `list_slices` | `boardId` | List slices (id, title, status) | §8 `GET .../slicedata/slices` |
-| `update_slice_status` | `boardId`, `sliceId`, `newStatus` | Change a SLICE_BORDER's `sliceStatus` | — (via `node:changed` event, §3) |
+| `get_slice_rework` | `boardId`, `contextId` | How much each slice of one context has been reworked: changes, steps backwards, and reopens after Done, most reworked first, plus planning metrics over them. `contextId` is a MODEL_CONTEXT or a timeline (a timeline resolves to the context it belongs to). Always per context — there is no board-wide form | §8 `GET .../reporting/rework/contexts/:contextId` |
+| `update_slice_status` | `boardId`, `newStatus`, plus exactly one of `sliceId` / `sliceTitle` / `columnId` | Change a SLICE_BORDER's `sliceStatus`. With a title or column id there is no need to call `list_slices` first; an ambiguous title comes back with its candidates. A slice being created takes its status from `create_slice`/`create_slice_definition` instead | — (via `node:changed` event, §3) |
 | `get_slice_data` | `boardId`, `contextName?`, `contextId?`, `sliceId?` | Full element graph for slices in a context | §8 `GET /slicedata` |
 | `get_spec_info` | `boardId`, `timelineId`, `elementTypes?` | EVENT/COMMAND/READMODEL nodes valid in GWT steps. Pass `elementTypes` (subset of `EVENT`/`COMMAND`/`READMODEL`) to avoid pulling the full element list when only one or two types are needed — filtered server-side, not just after a full fetch | §6 `GET .../spec-info` |
 | `get_board_outline` | `boardId`, `chapterId` | One chapter's structure, compact: per-column node lists (`{id, type, title, lane}`) + a flat edge list, no HTML pages / field bodies / meta. The cheap "what is where and how is it wired" read — prefer over `get_nodes` (no projection) for orientation checks | — (MCP-only convenience) |
 | `get_connected_nodes` | `boardId`, `nodeId`, `chapterId?`, `direction?` (`inbound`/`outbound`/`both`), `depth?`, `types?`, `includeFields?` | Neighbours of **one** node — what feeds it and what it feeds. Answers from a single anchor, unlike `get_attribute_chain` (which needs both ends of the chain as cell names up front). `depth` follows a whole chain; `types` filters the result only, never the traversal. Each neighbour carries `via`: `"edge"` for a real connection, `"layout"` when the node has none in that direction and the neighbour was inferred from the grid using auto-connect's own window (own column + adjacent one, forward-only pairs). Real edges always win. The `layout` fallback is what makes hand-built/imported chapters — which routinely carry **zero** edges — readable instead of falsely empty | — (MCP-only convenience) |
 | `validate_model` | `boardId`, `chapterId`, `checks?[]` | Server-side Event Modeling structural checklist over one chapter — compact `findings` only. Checks: unplaced nodes, backward arrows (with the todo-list `EVENT→READMODEL` exception), zero/multi-issuer commands, sourceless read models, two-screens-in-a-column, missing scenarios. Replaces the manual per-type `get_nodes` + `get_node projection=edges` validation pass | — (MCP-only convenience) |
-| `add_scenario` | `boardId`, `timelineId`, `columnId`, `scenarios[]`, `compact?` | Append GWT scenario(s) to a column's spec node. `compact: true` returns `{specNodeId, added, scenarioCount, isNewNode}` instead of echoing every scenario back | §6 `POST .../scenarios` |
+| `add_scenario` | `boardId`, `timelineId`, `columnId`, `scenarios[]`, `compact?` | Append GWT scenario(s) to a column's spec node — created automatically, and a scenario `id` is generated when omitted. A given/when/then step may be addressed by `{title, type}` instead of a node id, resolved against that timeline, so no `get_spec_info` call is needed first (an ambiguous title is reported with its candidates). `compact: true` returns `{specNodeId, added, scenarioCount, isNewNode}` instead of echoing every scenario back | §6 `POST .../scenarios` |
 | `add_storyline` | `boardId`, `timelineId`, `columnId`, `storylines[]`, `compact?` | Append storyline(s) (ordered, branchable beats over existing elements) to a column's spec node. Use whenever `eventmodeling-elaborating-scenarios`'s GWT-vs-storyline decision rule calls for one (e.g. a todo list's open→close lifecycle) — not only when a user explicitly names "storyline"; that skill's own per-read-model judgment is the trigger, this catalog entry isn't a stricter gate on top of it. `compact: true` suppresses the full storyline echo | §6 `POST .../storylines` |
 | `set_connection` | `boardId`, `source`, `target`, `action` (`'connect'\|'remove'`) | Add or remove a type-checked directed edge. Batch form `set_connections` takes `connections[]` (applied in order) plus `compact?` — `compact: true` returns a `{connected, existed, removed, notFound, failed, errors}` tally instead of one row per edge | — (via `edges` on §3 events) |
 | `auto_connect_node` | `boardId`, `nodeId` | Re-run auto-connect for a node | §3 `POST .../nodes/:nodeId/auto-connect` |
-| `link_element` | `boardId`, `nodeId`, `targetNodeId` | Link two existing same-type nodes: `targetNodeId` is replaced with a full copy of `nodeId`'s meta plus `meta.linkedTo`. Linking means first create, then link | §3 `POST .../nodes/:nodeId/link` |
-| `add_comment` | `boardId`, `nodeId`, `text`, `type?` (`'COMMENT'\|'TASK'`), `author?` | Add a comment — word the `text` as a question to flag gaps/edge cases during review; there is no separate `QUESTION` type | — (via comment events) |
+| `link_element` | `boardId`, `nodeId`, plus either `targetNodeId` or `timelineId` (+ `columnIndex?`, `lane?`) | Turn a node into a linked copy of `nodeId` — it receives a full copy of that node's meta plus `meta.linkedTo`. Name an existing `targetNodeId`, or pass `timelineId` to have the copy placed and linked in this one call (inheriting the original's type and title), which is what a translation or automation chain wants | §3 `POST .../nodes/:nodeId/link` |
+| `add_comment` / `add_comments` | `boardId`, `nodeId`, `text`, `type?` (`'COMMENT'\|'TASK'\|'QUESTION'`), `author?` (plural: `comments[]`, each with its own `nodeId`) | Add a comment — `QUESTION` is the type for a gap/edge case raised during review. Use the plural form for a review that has a question per element: all of them go in one call | §1 `POST .../boards/:boardId/comments` (batch) |
 | `update_comment` | `boardId`, `nodeId`, `commentId`, `action` (`'resolve'\|'delete'`) | Resolve or delete a comment | — (via comment events) |
-| `create_screen` | `boardId`, `contentType` (`'image'\|'sketch'\|'html'`), `nodeId?`, `chapterId`, `cellId?`/`cellName?`, plus content fields (`imageBase64`/`mimeType`, `elements[]`, or `pages[]`/`backgroundColor`), `description?`, `fields?`, `autoConnect?` | Create + place a new screen node (SCREEN or HTML_SCREEN) atomically, in one call. Batch form `create_screens` takes `screens[]` (HTML only) + `autoConnect?`. `autoConnect: false` places without wiring to timeline neighbors | §4 `POST .../images/:id/sketch` + `image-nodes` |
+| `create_screen` | `boardId`, `contentType` (`'image'\|'sketch'\|'html'`), `nodeId?`, `chapterId`, `cellId?`/`cellName?`, plus content fields (`imageBase64`/`mimeType`, `elements[]`, or `pages[]`/`backgroundColor`), `title?`, `description?`, `fields?`, `autoConnect?` | Create + place a new screen node (SCREEN or HTML_SCREEN) atomically, in one call. `title` names the node (`meta.title`) in the same call — no follow-up `node:changed` just to label the screen; `create_screens` takes it per entry. Batch form `create_screens` takes `screens[]` (HTML only) + `autoConnect?`. `autoConnect: false` places without wiring to timeline neighbors | §4 `POST .../images/:id/sketch` + `image-nodes` |
 | `render_screen` | `boardId`, `nodeId`, `elements[]?` (SCREEN) or `pages[]?`+`backgroundColor?` (HTML_SCREEN), `description?` | Update an existing screen's content — exactly one of `elements`/`pages` | §4 `POST .../images/:id/sketch` + `image-nodes` |
 | `add_field_examples` | `boardId`, `nodeId?`, `name?`, `cellName?`, `timelineId?` | Fill empty field examples using linked-node context | — (MCP-only convenience) |
 | `get_attribute_chain` | `boardId`, `timelineId`, `targetCellName`, `sourceCellName` | Resolve every node between two cells, ordered target→source | — (MCP-only convenience) |
@@ -209,6 +210,24 @@ Get all comments for a node.
 
 ---
 
+### POST `/api/org/:orgId/boards/:boardId/nodes/:nodeId/comments`
+Add one comment to one node.
+
+**Request body**: `{ text: string, type?: 'COMMENT' | 'TASK' | 'QUESTION', author?: string }`
+**Response**: `201` — `{ id }`
+
+---
+
+### POST `/api/org/:orgId/boards/:boardId/comments`
+Post several comments, on any nodes of one board, in a single request — the batch form. Use it for a review that raises a question per element (`/wdyt`) instead of one request per comment.
+
+**Request body**: `Array<{ nodeId: string, text: string, type?: 'COMMENT' | 'TASK' | 'QUESTION', author?: string }>`
+**Response**: `201` — `{ results: Array<{ nodeId, id } | { nodeId, error }> }`, in request order
+
+Entries are independent: one naming a node that doesn't exist is reported in `results` while the rest are still posted.
+
+---
+
 ### POST `/api/org/:orgId/boards/:boardId/bucket`
 Create a Supabase storage bucket for the board.
 
@@ -225,8 +244,19 @@ A "chapter" is a timeline — the same entity, referenced as `chapterId` in node
 ### POST `/api/org/:orgId/boards/:boardId/chapters`
 Create a chapter node.
 
-**Request body**: `{ position?: { x: number, y: number } }`  
-**Response**: `200` — chapter data
+**Request body**:
+```typescript
+{
+  position?: { x: number, y: number }
+  title?: string      // names the chapter on creation — no follow-up rename
+  columns?: number    // initial column count, default 3
+  lanes?: Array<{ type: 'actor'|'interaction'|'swimlane'|'spec'|'feedback'|'table', label?: string, height?: number }>
+}
+```
+
+**Response**: `200` — `{ id, eventId, columnIds: string[], lanes: Array<{id, type, label}> }`
+
+`lanes` replaces the default Actor/Interaction/Swimlane/Spec set — this is how a chapter gets lanes named after what they hold, or several lanes of one type (one swimlane per context), without an `add_lane` call per lane. They are sorted into the required order (actor → interaction → swimlane → spec → feedback/table) automatically, keeping the given order within a type, so no ordering error is possible. Every column id and lane id comes back in the response — don't re-read the chapter just to place something into it.
 
 Omitting `position` auto-stacks the new chapter below the lowest existing chapter on the board, using each existing chapter's *actual current* row-height total (not the height it was created with) plus a fixed margin — so a chapter that grew via `add_lane`/`add_column` after another was stacked below it won't get overlapped by yet another auto-stacked chapter.
 
@@ -258,18 +288,22 @@ Delete a column from a timeline. Removes the column and all its cells. Cannot de
 ---
 
 ### POST `/api/org/:orgId/boards/:boardId/timelines/:timelineId/lanes`
-Add a lane (row) to a timeline.
+Add one or more lanes (rows) to a timeline.
 
 **Request body**:
 ```typescript
 {
-  type: 'actor' | 'interaction' | 'swimlane' | 'spec' | 'feedback'
+  type: 'actor' | 'interaction' | 'swimlane' | 'spec' | 'feedback' | 'table'
   label?: string
   index?: number
   height?: number
 }
+// or, batch form — every lane added in one request, applied in order:
+[ { type: 'interaction', label: 'Interaction' }, { type: 'swimlane', label: 'Ordering' } ]
 ```
-**Response**: `200` — lane data
+**Response**: `200` — lane data, or `{ lanes: [...] }` for the batch form
+
+For a chapter that doesn't exist yet, pass `lanes` to `POST .../chapters` instead — that needs no lane call at all.
 
 ---
 
@@ -434,16 +468,27 @@ Create a single type-checked directed edge between two existing nodes — the RE
 ---
 
 ### POST `/api/org/:orgId/boards/:boardId/nodes/:nodeId/link`
-Link two existing same-type nodes — the REST fallback for `link_element`. Linking means first create, then link: `targetNodeId` must already exist. It's replaced with a full copy of `:nodeId`'s meta (not a merge) plus `meta.linkedTo`. COMMAND/EVENT/READMODEL only; `:nodeId` must not itself already be a linked copy.
+Turn a node into a linked copy of `:nodeId` — the REST fallback for `link_element`. The copy receives a full copy of `:nodeId`'s meta (a replacement, not a merge) plus `meta.linkedTo`. COMMAND/EVENT/READMODEL only; `:nodeId` must not itself already be a linked copy.
 
-**Request body**:
+**Request body** — exactly one of the two:
 ```typescript
 {
   targetNodeId: string  // existing same-type node to convert into a linked copy
 }
+// or: create the copy in this same request
+{
+  place: {
+    timelineId: string     // chapter to place the copy on
+    columnIndex?: number   // columns are added to reach it
+    lane?: string          // row id or label, when the chapter has several lanes of that type
+    autoConnect?: boolean  // default true
+  }
+}
 ```
 
-**Response**: `200` — `{ nodeId, linkedTo, type }` · `400` — missing `targetNodeId`, type mismatch, self-link, unsupported element type, or the original is itself a linked copy · `404` — the original or `targetNodeId` doesn't exist
+With `place` the copy inherits the original's element type and title, so a translation or automation chain no longer needs a `node:created` call before this one.
+
+**Response**: `200` — `{ nodeId, linkedTo, type }`, plus `placed: { nodeId, cellName, columnIndex }` when `place` was used · `400` — neither or both of `targetNodeId`/`place`, type mismatch, self-link, unsupported element type, or the original is itself a linked copy · `404` — the original or `targetNodeId` doesn't exist
 
 ---
 
@@ -470,7 +515,7 @@ Update an image snapshot.
 ### POST `/api/org/:orgId/boards/:boardId/image-nodes/:nodeId`
 Create an image node.
 
-**Request**: `multipart/form-data` — fields: `file`, `chapterId`, `cellName`  
+**Request**: `multipart/form-data` — fields: `file`, `chapterId`, `cellName`, `title?` (label shown on the node, `meta.title`)  
 **Response**: `204`
 
 ---
@@ -499,6 +544,7 @@ Create a SCREEN node from a sketch description.
   cellName: string
   description: { elements: object[] }
   semanticDescription?: string
+  title?: string               // label shown on the node (meta.title)
 }
 ```
 **Response**: `204` OR `400` (validation error)
@@ -518,13 +564,16 @@ Create a complete slice (1 column + its nodes automatically placed).
   type: 'state-change' | 'state-view' | 'automation'
   index?: number
   nodes?: {
-    actor?: Partial<NodeData> & { rowId?: string }
-    interaction?: Partial<NodeData> & { rowId?: string }
-    swimlane?: Partial<NodeData> & { rowId?: string }
+    actor?: Partial<NodeData> & { rowId?: string, fields?: FieldDef[] }
+    interaction?: Partial<NodeData> & { rowId?: string, fields?: FieldDef[] }
+    swimlane?: Partial<NodeData> & { rowId?: string, fields?: FieldDef[] }
   }
+  status?: 'Created' | 'Planned' | 'InProgress' | 'Review' | 'Done' | 'Blocked' | 'Assigned' | 'Informational'
 }
 ```
 
+`fields` writes that node's attributes in the same call, and `status` gives the SLICE_BORDER its `sliceStatus` on creation — neither needs a follow-up write.
+
 **Slice node mapping**:
 - `state-change` → HTML_SCREEN (actor) + COMMAND (interaction) + EVENT (swimlane)
 - `state-view` → HTML_SCREEN (actor) + READMODEL (interaction) + EVENT (swimlane, **only when `nodes.swimlane` is passed**)
@@ -546,12 +595,13 @@ Create a standalone SLICE_BORDER node spanning an **existing** column. Unlike th
 {
   columnId: string   // id of an existing column on this timeline
   title: string      // slice title — always taken from this field, never derived
+  status?: 'Created' | 'Planned' | 'InProgress' | 'Review' | 'Done' | 'Blocked' | 'Assigned' | 'Informational'
   data?: Record<string, unknown>   // optional node.data payload
   meta?: Record<string, unknown>   // optional extra meta fields (type, colId, title are always set explicitly and cannot be overridden here)
 }
 ```
 
-**Response**: `200` — `{ nodeId, timelineId, columnId, title }`
+**Response**: `200` — `{ nodeId, timelineId, columnId, title, status? }` — `status` sets `sliceStatus` straight away, instead of a follow-up `update_slice_status`
 **Errors**: `400` missing `columnId`/`title` or column not found · `404` timeline not found
 
 ---
@@ -560,47 +610,47 @@ Create a standalone SLICE_BORDER node spanning an **existing** column. Unlike th
 
 **File**: `src/slices/change/api-specs/routes.ts`
 
-### POST `/api/org/:orgId/boards/:boardId/contexts/:contextName/slices/:sliceName/scenarios`
-Append a Given-When-Then scenario to a spec node.
+### POST `/api/org/:orgId/boards/:boardId/timelines/:timelineId/columns/:columnId/scenarios`
+Append Given-When-Then scenario(s) to a column's spec node — the node is created automatically if the spec cell is empty. Accepts a single scenario object or an array.
 
 **Request body**:
 ```typescript
 {
-  id: string
+  id?: string       // generated when omitted
   title: string
   vertical?: boolean
   examples?: unknown[]
-  given: string[]   // nodeIds — must be EVENTs from same timeline
-  when: string[]    // nodeIds — at most one COMMAND; empty if then has READMODEL
-  then: string[]    // nodeIds — EVENTs only OR exactly one READMODEL (not mixed)
+  given?: SpecStep[]  // EVENTs from this timeline
+  when?: SpecStep[]   // at most one COMMAND, or one inline QUERY object; empty if then has a READMODEL
+  then?: SpecStep[]   // EVENTs only OR exactly one READMODEL (not mixed)
+  expectError?: boolean, errorDescription?: string   // error case: leave `then` empty
 }
+
+// A step is addressed either way:
+{ id: 'node-uuid' }                          // a board node
+{ title: 'OrderPlaced', type: 'EVENT' }      // resolved against this timeline's own elements
 ```
 
+A step given as `{title, type}` is resolved server-side, so the names you already know need **no `get_spec_info`/`get_nodes` call first**. A title matching more than one element is rejected (`SCENARIO_ITEM_AMBIGUOUS`) with the candidates rather than guessed at, and resolution runs before anything is written — a bad name leaves no empty spec node behind.
+
 **Validation rules**:
 - `given`: only EVENTs from same timeline
-- `when`: max one COMMAND; must be empty when `then` contains a READMODEL
+- `when`: max one COMMAND; must be empty when `then` contains a READMODEL (use an inline QUERY item for a state-view)
 - `then`: all EVENTs OR exactly one READMODEL — never mixed
 - All referenced nodes must belong to the same chapter/timeline
 
 **Response**:
-- `201` — `{ scenario, scenarios, specNodeId, isNewNode: boolean }`
+- `201` — `{ specNodeId, scenarios, added, isNewNode: boolean }`
 - `400` — validation error
-- `404` — context or slice not found
+- `404` — timeline, column, or a referenced node not found
 - `409` — duplicate scenario title
 
 ---
 
-### GET `/api/org/:orgId/boards/:boardId/contexts/:contextName/spec-info`
-Get valid elements for a context (by name lookup).
-
-**Response**: `200` — `{ chapterId: string, elements: ElementRecord[] }`
-
----
-
-### GET `/api/org/:orgId/boards/:boardId/contexts/:contextName/slices/:sliceName/spec-info`
-Get valid elements for a specific slice.
+### GET `/api/org/:orgId/boards/:boardId/timelines/:timelineId/spec-info`
+Get the elements a scenario's given/when/then steps may legally reference (EVENT, COMMAND, READMODEL of that timeline). Only needed when you want the ids themselves — a scenario step can name its element by title instead.
 
-**Response**: `200` — `{ chapterId: string, elements: ElementRecord[] }`
+**Response**: `200` — `{ timelineId: string, elements: ElementRecord[] }`
 
 ---
 
@@ -682,6 +732,30 @@ List all slices on a board.
 
 ---
 
+### GET `/api/org/:orgId/boards/:boardId/reporting/rework/contexts/:contextId`
+**File**: `src/slices/change/reporting/rework/routes.ts`
+
+How much each slice of one context has been reworked — read-only, derived from the board event log; nothing is stored
+for it.
+
+A slice's rework is read from its own SLICE_BORDER history. Going backwards means a step down the progress order
+(Created → Planned → Assigned → InProgress → Review → Done), or reaching `Blocked` from `Review`/`Done`;
+`Informational` is never scored. `reopens` counts transitions leading away from `Done`, `changes` counts writes to the
+slice itself. This says nothing about edits to the elements inside a slice.
+
+`contextId` is a MODEL_CONTEXT node id, or a timeline id — a timeline resolves through the board's own effective
+context (the same rule `slicedata` uses), so one that inherits a context is reported under that context and one with
+none is its own. Any other node type is rejected. Always scoped to one context; there is no board-wide form.
+
+**Response**: `200` — `{ contextId, contextName, metrics, slices[] }`, slices most reworked first.
+`slices[]` = `{ sliceId, title, status, changes, reopens, regressions, everReachedDone }`.
+`metrics` = `{ slices, everReachedDone, reopenedAfterDone, firstTimeRightRate, currentlyReopened, avgReopensPerSlice,
+avgChangesPerSlice }` — `firstTimeRightRate` is the share of the slices that reached Done and never came back, or
+`null` when none got there yet.
+`400` `CONTEXT_ID_REQUIRED` / `CONTEXT_NODE_INVALID` · `404` `CONTEXT_NOT_FOUND`
+
+---
+
 ## 9. Extensions
 
 **File**: `src/slices/extensions/routes.ts`

package/shared/skills/update-slice-status/SKILL.md

@@ -71,6 +71,14 @@ Prefer the MCP tool — it does the same `node:changed`/`sliceStatus` update in
 mcp__eventmodelers__update_slice_status { "boardId": "<BOARD_ID>", "sliceId": "<SLICE_NODE_ID>", "newStatus": "<newStatus>" }
 ```
 
+The tool also resolves the slice itself — pass `sliceTitle` (or `columnId`) instead of `sliceId` and the listing step above can be skipped entirely; an ambiguous title comes back with its candidates instead of a guess:
+
+```
+mcp__eventmodelers__update_slice_status { "boardId": "<BOARD_ID>", "sliceTitle": "Place Order", "newStatus": "<newStatus>" }
+```
+
+A slice that is being *created* takes its status straight from `create_slice`/`create_slice_definition` (`status`) — don't create it and then call this.
+
 **Fallback (no MCP)** — send a `node:changed` event to update the `sliceStatus` field in the SLICE_BORDER node's meta directly:
 
 ```bash

package/stacks/axon/templates/build-kit/lib/backend-prompt.md

@@ -17,7 +17,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 0. Do not read the entire code base. Focus on the tasks in this description.
 1. Read `.build-kit/.slices/current_context.json` to find the active context name, then read `.build-kit/.slices/<contextName>/index.json`. Every item in status "planned" is a task.
-2. Read the progress log at `progress.txt` (check Codebase Patterns section first)
+2. Read the progress log at `progress.txt` **if it exists** (check Codebase Patterns section first) — it is absent until the first slice is built, which is not an error; create it when you write your first entry
 3. Make sure you are on the right branch "feature/<slicename>", if unsure, start from main.
 5. Pick the **highest priority** slice where status is **exactly** "Planned" (case insensitive). This becomes your PRD. Set the status "InProgress" in the index.json **and** update the slice status on the eventmodelers board using the `update-slice-status` skill (or MCP if available).
    **IMPORTANT: Only work on slices with status "Planned" in the CURRENT context. Never pick up a slice that is "InProgress", "Done", "Blocked", "Created", or any other status — even if it looks incomplete. If no slice has status "Planned" in the current context, reply with:**

package/stacks/blank/templates/build-kit/lib/backend-prompt.md

@@ -17,7 +17,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 0. Do not read the entire code base. Focus on the tasks in this description.
 1. Read `.build-kit/.slices/current_context.json` to find the active context name, then read `.build-kit/.slices/<contextName>/index.json`. Every item in status "planned" is a task.
-2. Read the progress log at `progress.txt` (check Codebase Patterns section first)
+2. Read the progress log at `progress.txt` **if it exists** (check Codebase Patterns section first) — it is absent until the first slice is built, which is not an error; create it when you write your first entry
 3. Make sure you are on the right branch "feature/<slicename>", if unsure, start from main.
 5. Pick the **highest priority** slice where status is **exactly** "Planned" (case insensitive). This becomes your PRD. Set the status "InProgress" in the index.json **and** update the slice status on the eventmodelers board using the `update-slice-status` skill (or MCP if available).
    **IMPORTANT: Only work on slices with status "Planned" in the CURRENT context. Never pick up a slice that is "InProgress", "Done", "Blocked", "Created", or any other status — even if it looks incomplete. If no slice has status "Planned" in the current context, reply with:**

package/stacks/kurrent/templates/build-kit/lib/backend-prompt.md

@@ -17,7 +17,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 0. Do not read the entire code base. Focus on the tasks in this description.
 1. Read `.build-kit/.slices/current_context.json` to find the active context name, then read `.build-kit/.slices/<contextName>/index.json`. Every item in status "planned" is a task.
-2. Read the progress log at `progress.txt` (check Codebase Patterns section first)
+2. Read the progress log at `progress.txt` **if it exists** (check Codebase Patterns section first) — it is absent until the first slice is built, which is not an error; create it when you write your first entry
 3. Make sure you are on the right branch "feature/<slicename>", if unsure, start from main.
 5. Pick the **highest priority** slice where status is **exactly** "Planned" (case insensitive). This becomes your PRD. Set the status "InProgress" in the index.json **and** update the slice status on the eventmodelers board using the `update-slice-status` skill (or MCP if available).
    **IMPORTANT: Only work on slices with status "Planned" in the CURRENT context. Never pick up a slice that is "InProgress", "Done", "Blocked", "Created", or any other status — even if it looks incomplete. If no slice has status "Planned" in the current context, reply with:**

package/stacks/modeling-kit/templates/.claude/skills/discover-storyboard/SKILL.md

@@ -309,6 +309,7 @@ mcp__eventmodelers__create_screen {
   "nodeId": "<SCREEN_NODE_ID>",
   "chapterId": "<CHAPTER_ID>",
   "cellId": "<CELL_ID>",
+  "title": "<screen.title>",
   "pages": ["<reconstructed HTML fragment for this screen>"],
   "description": "<screen.description — 'Shows X. Arrived via: Y. Actions: user can do A, user can do B.'>"
 }
@@ -325,6 +326,7 @@ mcp__eventmodelers__create_screen {
   "nodeId": "<SCREEN_NODE_ID>",
   "chapterId": "<CHAPTER_ID>",
   "cellName": "<CELL_NAME>",
+  "title": "<screen.title>",
   "imageBase64": "<base64-encoded contents of screen.filepath, no data: URI prefix>",
   "mimeType": "image/png",
   "description": "<screen.description — 'Shows X. Arrived via: Y. Actions: user can do A, user can do B.'>"

package/stacks/modeling-kit/templates/.claude/skills/discover-storyboard/references/api-fallback.md

@@ -58,6 +58,7 @@ curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/image-nodes/$SCREEN_
   -H "x-token: $TOKEN" \
   -F "file=@<screen.filepath>" \
   -F "chapterId=$CHAPTER_ID" \
-  -F "cellName=$CELL_NAME"
+  -F "cellName=$CELL_NAME" \
+  -F "title=<screen.title>"
 ```
 For the HTML path with no MCP, use the `html-screen-nodes` endpoint per the `html-screen` skill's fallback mechanics instead.

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-storyboarding-events/references/api-fallback.md

@@ -36,6 +36,7 @@ curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/html-screen-nodes/<n
   -d '{
     "chapterId": "<CHAPTER_ID>",
     "cellId": "<actorRowId>-<columnId>",
+    "title": "<Screen Title>",
     "pages": ["<div>...</div>"]
   }'
 ```

package/stacks/modeling-kit/templates/.claude/skills/handle-comment/SKILL.md

@@ -48,7 +48,17 @@ mcp__eventmodelers__add_comment { "boardId": "$BOARD_ID", "nodeId": "$NODE_ID",
 
 **Fallback (no MCP):** see `references/api-fallback.md` — "Action: place".
 
-**Batching (when called in bulk, e.g. from `wdyt`):** send one request per comment — there is no batch endpoint for comments. Fire them sequentially, not in a single payload.
+**Batching (when called in bulk, e.g. from `wdyt`):** send them all in one request instead of one per comment — each entry names its own node:
+
+```bash
+curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/comments" \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '[{"nodeId":"<id>","text":"<text>","type":"QUESTION","author":"wdyt"},
+       {"nodeId":"<id2>","text":"<text2>","type":"QUESTION","author":"wdyt"}]'
+```
+
+Response: `201 {"results":[{"nodeId":"<id>","id":"<commentId>"}, …]}` in request order — an entry whose node doesn't exist reports `error` there without dropping the rest. Over MCP this is the `add_comments` tool.
 
 **Report:**
 ```

package/stacks/modeling-kit/templates/.claude/skills/html-screen/references/api-fallback.md

@@ -31,7 +31,7 @@ curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/html-screen-nodes/$N
   -H "x-board-id: $BOARD_ID" \
   -H "x-user-id: agent" \
   -H "Content-Type: application/json" \
-  -d '{"chapterId": "'"$CHAPTER_ID"'", "cellName": "'"$CELL_NAME"'", "pages": ["<div>...</div>"]}'
+  -d '{"chapterId": "'"$CHAPTER_ID"'", "cellName": "'"$CELL_NAME"'", "title": "<Screen Title>", "pages": ["<div>...</div>"]}'
 ```
 
 ## Step 5 — Define field data lineage

package/stacks/modeling-kit/templates/.claude/skills/place-element/SKILL.md

@@ -46,10 +46,13 @@ mcp__eventmodelers__place_element {
   "timelineId": "<TIMELINE_ID>",
   "elementType": "<COMMAND|READMODEL|EVENT>",
   "title": "<title>",
-  "columnIndex": <position, if given>
+  "columnIndex": <position, if given>,
+  "fields": [{ "name": "orderId", "type": "String", "example": "ord-1" }]
 }
 ```
 
+Pass `fields` whenever the element's attributes are already known — they are written by this same call, so don't follow a placement with a `submit_node_events` just to set them. Placing **more than one** element is `place_elements` with an `elements` array (same per-entry options), applied in order so each entry sees the columns the previous one added — one call for a whole slice's or column run's worth instead of one per element.
+
 This tool finds or creates an empty cell in the correct lane and places the node in one call — it collapses the "resolve timeline → fetch columns → determine lane → check occupancy → create node" sequence (Steps 2–3, 4, 6, 7b below) into a single round trip. A `columnIndex` past the timeline's current column count is handled automatically (columns are added to reach it) — no need to pre-check the column count or catch an out-of-range error yourself. If `timelineId` is unknown, resolve it first via Step 2's MCP call. Pass `compact: true` for a smaller `{nodeId, cellName, columnIndex}` response (plus `connectedCount` if auto-connect wired an edge) when you don't need the full `lane`/`elementType`/`title`/`autoConnected` detail back. Go straight to Step 8 once it returns.
 
 **This does not cover**: `SCREEN`/`AUTOMATION`/`SCENARIO` (see their dedicated steps below), the `"after <title>"` position form, or an explicit `cellName` fast path (Step 1) — `place_element` has no way to express either. For those cases, or when MCP isn't connected, fall through to the manual steps below.
@@ -246,12 +249,14 @@ If no matching row is found, stop and report the error — the timeline may be m
 
 **Connections only ever pair nodes on the same timeline** — a node in Chapter A can never be wired directly to a node in Chapter B, even for an otherwise-valid type pair (e.g. `EVENT → READMODEL`). If the element you're placing needs to connect to something that lives on a *different* timeline, do not place it and then attempt `set_connection`/auto-connect across timelines — it will fail.
 
-Instead, create a **linked copy**: place the new node normally (Step 7, same title/type as the origin), then call `link_element` to mark it as a copy of the origin node:
+Instead, create a **linked copy**. `link_element` places it for you — pass the timeline (and optionally the column/lane) instead of an already-placed `targetNodeId`, and it creates the copy with the origin's type and title and links it in the same call:
 
 ```
-mcp__eventmodelers__link_element { "boardId": "<BOARD_ID>", "nodeId": "<origin-node-id>", "targetNodeId": "<newly-placed-node-id>" }
+mcp__eventmodelers__link_element { "boardId": "<BOARD_ID>", "nodeId": "<origin-node-id>", "timelineId": "<TIMELINE_ID>", "columnIndex": 4 }
 ```
 
+(If the copy already exists — e.g. it was placed by an earlier step — pass `targetNodeId: "<existing-node-id>"` instead.)
+
 (REST fallback: see `references/api-fallback.md` — "Step 6a — Link a node to an origin on a different timeline".) This replaces the new node's meta with a full copy of the origin's, sets `meta.linkedTo`, and only works for COMMAND/EVENT/READMODEL. Once linked, wire the local copy to its neighbors with normal same-timeline `set_connection`/auto-connect calls. `eventmodeling-checking-completeness` treats any `linkedTo`-marked node it finds as this intentional pattern, never a duplicate to flag.
 
 ---
@@ -273,6 +278,7 @@ mcp__eventmodelers__create_screen {
   "nodeId": "<node-uuid>",
   "chapterId": "<TIMELINE_ID>",
   "cellId": "<CELL_ID>",
+  "title": "<title>",
   "pages": ["<div>...</div>"],
   "description": "<title — what this screen shows>"
 }
@@ -291,6 +297,7 @@ mcp__eventmodelers__create_screen {
   "nodeId": "<node-uuid>",
   "chapterId": "<TIMELINE_ID>",
   "cellId": "<CELL_ID>",
+  "title": "<title>",
   "elements": [...],
   "description": "<title — what this screen shows>"
 }

package/stacks/modeling-kit/templates/.claude/skills/place-element/references/api-fallback.md

@@ -95,6 +95,7 @@ curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/html-screen-nodes/<n
   -d '{
     "chapterId": "<TIMELINE_ID>",
     "cellId": "<CELL_ID>",
+    "title": "<title>",
     "pages": ["<div>...</div>"]
   }'
 ```
@@ -110,6 +111,7 @@ curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/image-nodes/<node-uu
   -d '{
     "chapterId": "<TIMELINE_ID>",
     "cellId": "<CELL_ID>",
+    "title": "<title>",
     "description": {"elements": [...]},
     "semanticDescription": "<title — what this screen shows>"
   }'

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

@@ -183,6 +183,7 @@ mcp__eventmodelers__create_screen {
   "nodeId": "<SCREEN_NODE_ID>",
   "chapterId": "<CHAPTER_ID>",
   "cellId": "<actorCellId>",
+  "title": "<screenTitle>",
   "pages": ["<div>...</div>"],
   "description": "<screenTitle — what this screen shows>"
 }
@@ -201,6 +202,7 @@ mcp__eventmodelers__create_screen {
   "nodeId": "<SCREEN_NODE_ID>",
   "chapterId": "<CHAPTER_ID>",
   "cellId": "<actorCellId>",
+  "title": "<screenTitle>",
   "elements": [...],
   "description": "<screenTitle — what this screen shows>"
 }

package/stacks/modeling-kit/templates/.claude/skills/storyboard/references/api-fallback.md

@@ -39,6 +39,7 @@ curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/html-screen-nodes/$S
   -d '{
     "chapterId": "<CHAPTER_ID>",
     "cellId": "<actorCellId>",
+    "title": "<screenTitle>",
     "pages": ["<div>...</div>"]
   }'
 ```
@@ -54,6 +55,7 @@ curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/image-nodes/$SCREEN_
   -d '{
     "chapterId": "<CHAPTER_ID>",
     "cellId": "<actorCellId>",
+    "title": "<screenTitle>",
     "description": {"elements": [...]},
     "semanticDescription": "<screenTitle — what this screen shows>"
   }'

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

@@ -138,7 +138,7 @@ Use the `handle-comment` skill with `action=place` to post each comment. Pass:
 - `type` — `COMMENT` (there is no separate question type — the text itself carries the question)
 - `author` — `wdyt`
 
-The comment API has no batch endpoint — `handle-comment` sends one request per comment. Fire them sequentially.
+Post them together, not one at a time: `handle-comment` sends every comment of a run in a single batch request (`add_comments` over MCP, `POST .../boards/:boardId/comments` over REST).
 
 Only post questions that are **genuinely unclear or missing** — don't post observations that are clearly intentional design decisions.
 

package/stacks/node/templates/build-kit/lib/backend-prompt.md

@@ -17,7 +17,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 0. Do not read the entire code base. Focus on the tasks in this description.
 1. Read `.build-kit/.slices/current_context.json` to find the active context name, then read `.build-kit/.slices/<contextName>/index.json`. Every item in status "planned" is a task.
-2. Read the progress log at `progress.txt` (check Codebase Patterns section first)
+2. Read the progress log at `progress.txt` **if it exists** (check Codebase Patterns section first) — it is absent until the first slice is built, which is not an error; create it when you write your first entry
 3. Make sure you are on the right branch "feature/<slicename>", if unsure, start from main.
 5. Pick the **highest priority** slice where status is **exactly** "Planned" (case insensitive). This becomes your PRD. Set the status "InProgress" in the index.json **and** update the slice status on the eventmodelers board using the `update-slice-status` skill (or MCP if available).
    **IMPORTANT: Only work on slices with status "Planned" in the CURRENT context. Never pick up a slice that is "InProgress", "Done", "Blocked", "Created", or any other status — even if it looks incomplete. If no slice has status "Planned" in the current context, reply with:**

package/stacks/opencqrs/templates/build-kit/lib/backend-prompt.md

@@ -17,7 +17,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 0. Do not read the entire code base. Focus on the tasks in this description.
 1. Read `.build-kit/.slices/current_context.json` to find the active context name, then read `.build-kit/.slices/<contextName>/index.json`. Every item in status "planned" is a task.
-2. Read the progress log at `progress.txt` (check Codebase Patterns section first)
+2. Read the progress log at `progress.txt` **if it exists** (check Codebase Patterns section first) — it is absent until the first slice is built, which is not an error; create it when you write your first entry
 3. Make sure you are on the right branch "feature/<slicename>", if unsure, start from main.
 5. Pick the **highest priority** slice where status is **exactly** "Planned" (case insensitive). This becomes your PRD. Set the status "InProgress" in the index.json **and** update the slice status on the eventmodelers board using the `update-slice-status` skill (or MCP if available).
    **IMPORTANT: Only work on slices with status "Planned" in the CURRENT context. Never pick up a slice that is "InProgress", "Done", "Blocked", "Created", or any other status — even if it looks incomplete. If no slice has status "Planned" in the current context, reply with:**

package/stacks/react/templates/build-kit/README.md

@@ -32,6 +32,7 @@ node .build-kit/ralph-claude.js /path/to/project
 |------|---------|
 | `ralph-claude.js` | Runs the full loop using Claude Code as the executor |
 | `ralph-local-ai.js` | Runs the full loop using a local/self-hosted model (Ollama, vLLM, LM Studio, llama.cpp) |
+| `ralph-exec.js` | Runs the full loop handing each prompt to an external agent command (Codex CLI, OpenCode, …) |
 | `ralph.sh` | Shell-based loop — alternative to the JS entry points |
 
 **Internals** (`lib/`):
@@ -80,6 +81,43 @@ default here is raised rather than left to the server. On the `openai` dialect t
 equivalent is set when you launch the server (vLLM `--max-model-len 32768`,
 llama.cpp `-c 32768`); an overflow there surfaces as an HTTP 400.
 
+
+## External agent commands (`--exec`)
+
+Agentic harnesses that bring their own tool loop — Codex CLI, OpenCode, Gemini CLI —
+are not `--local-ai` targets: `--local-ai` *supplies* the agent loop, while a harness
+already is one and only wants a prompt. They go through `ralph-exec.js` instead:
+
+```bash
+npx @eventmodelers/cli run --exec "codex exec --full-auto"
+npx @eventmodelers/cli run --exec "opencode run"
+
+# …or persist it and use the bare flag
+RALPH_EXEC_CMD="codex exec --full-auto" node .build-kit/ralph-exec.js
+```
+
+The prompt is appended to the command as one shell-quoted argument, and is also written
+to a temp file named by `RALPH_PROMPT_FILE` for commands that prefer to read it. The
+child runs with the project dir as its cwd and inherits stdio — a harness owns its own
+output format, so there is no condensed per-step logging here the way `ralph-claude.js`
+has it.
+
+Persist a default alongside the local-AI settings:
+
+```json
+{
+  "localAi": {
+    "exec": "codex exec --full-auto"
+  }
+}
+```
+
+One caveat worth knowing before reaching for this: the kits' prompts assume Claude
+Code's `Skill` tool and `CLAUDE.md`. Other harnesses read `AGENTS.md` and have no skill
+primitive, so `init-agents` puts the skill files where they can find them, but
+`lib/prompt.md` / `lib/backend-prompt.md` still need wording that says *read and follow*
+a skill file rather than *invoke* it.
+
 ## Config
 
 Credentials are stored in `.build-kit/.eventmodelers/config.json` (written by `eventmodelers init`):

package/stacks/react/templates/build-kit/lib/prompt.md

@@ -17,7 +17,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 0. Do not read the entire code base. Focus on the tasks in this description.
 1. Read `.build-kit/.slices/current_context.json` to find the active context name, then read `.build-kit/.slices/<contextName>/index.json`. Every item in status "planned" is a task.
-2. Read the progress log at `progress.txt` (check Codebase Patterns section first)
+2. Read the progress log at `progress.txt` **if it exists** (check Codebase Patterns section first) — it is absent until the first slice is built, which is not an error; create it when you write your first entry
 3. Make sure you are on the right branch "feature/<slicename>", if unsure, start from main.
 5. Pick the **highest priority** slice where status is **exactly** "Planned" (case insensitive). This becomes your PRD. Set the status "InProgress" in the index.json **and** update the slice status on the eventmodelers board using the `update-slice-status` skill (or MCP if available).
    **IMPORTANT: Only work on slices with status "Planned" in the CURRENT context. Never pick up a slice that is "InProgress", "Done", "Blocked", "Created", or any other status — even if it looks incomplete. If no slice has status "Planned" in the current context, reply with:**

package/stacks/supabase/templates/build-kit/lib/backend-prompt.md

@@ -17,7 +17,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 0. Do not read the entire code base. Focus on the tasks in this description.
 1. Read `.build-kit/.slices/current_context.json` to find the active context name, then read `.build-kit/.slices/<contextName>/index.json`. Every item in status "planned" is a task.
-2. Read the progress log at `progress.txt` (check Codebase Patterns section first)
+2. Read the progress log at `progress.txt` **if it exists** (check Codebase Patterns section first) — it is absent until the first slice is built, which is not an error; create it when you write your first entry
 3. Make sure you are on the right branch "feature/<slicename>", if unsure, start from main.
 5. Pick the **highest priority** slice where status is **exactly** "Planned" (case insensitive). This becomes your PRD. Set the status "InProgress" in the index.json **and** update the slice status on the eventmodelers board using the `update-slice-status` skill (or MCP if available).
    **IMPORTANT: Only work on slices with status "Planned" in the CURRENT context. Never pick up a slice that is "InProgress", "Done", "Blocked", "Created", or any other status — even if it looks incomplete. If no slice has status "Planned" in the current context, reply with:**

package/stacks/supabase-react/templates/build-kit/lib/backend-prompt.md

@@ -17,7 +17,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 0. Do not read the entire code base. Focus on the tasks in this description.
 1. Read `.build-kit/.slices/current_context.json` to find the active context name, then read `.build-kit/.slices/<contextName>/index.json`. Every item in status "planned" is a task.
-2. Read the progress log at `progress.txt` (check Codebase Patterns section first)
+2. Read the progress log at `progress.txt` **if it exists** (check Codebase Patterns section first) — it is absent until the first slice is built, which is not an error; create it when you write your first entry
 3. Make sure you are on the right branch "feature/<slicename>", if unsure, start from main.
 5. Pick the **highest priority** slice where status is **exactly** "Planned" (case insensitive). This becomes your PRD. Set the status "InProgress" in the index.json **and** update the slice status on the eventmodelers board using the `update-slice-status` skill (or MCP if available).
    **IMPORTANT: Only work on slices with status "Planned" in the CURRENT context. Never pick up a slice that is "InProgress", "Done", "Blocked", "Created", or any other status — even if it looks incomplete. If no slice has status "Planned" in the current context, reply with:**

package/stacks/umadb/templates/build-kit/lib/backend-prompt.md

@@ -17,7 +17,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 0. Do not read the entire code base. Focus on the tasks in this description.
 1. Read `.build-kit/.slices/current_context.json` to find the active context name, then read `.build-kit/.slices/<contextName>/index.json`. Every item in status "planned" is a task.
-2. Read the progress log at `progress.txt` (check Codebase Patterns section first)
+2. Read the progress log at `progress.txt` **if it exists** (check Codebase Patterns section first) — it is absent until the first slice is built, which is not an error; create it when you write your first entry
 3. Make sure you are on the right branch "feature/<slicename>", if unsure, start from main.
 5. Pick the **highest priority** slice where status is **exactly** "Planned" (case insensitive). This becomes your PRD. Set the status "InProgress" in the index.json **and** update the slice status on the eventmodelers board using the `update-slice-status` skill (or MCP if available).
    **IMPORTANT: Only work on slices with status "Planned" in the CURRENT context. Never pick up a slice that is "InProgress", "Done", "Blocked", "Created", or any other status — even if it looks incomplete. If no slice has status "Planned" in the current context, reply with:**