@eventmodelers/cli 1.0.97 → 1.0.98

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

@@ -20,6 +20,7 @@
 import { startRalph, loadLocalConfig, resolveAgentIdentity, connectHeader } from './lib/ralph.js';
 import { createSliceTracer, usageFromHarnessEvent, sumUsage } from './lib/tracing.js';
 import { turnTimeoutMs, superviseTurn } from './lib/turn.js';
+import { registerMcp, shellQuote } from './lib/mcp-register.js';
 import { spawn } from 'child_process';
 import { writeFileSync, mkdtempSync } from 'fs';
 import { tmpdir } from 'os';
@@ -33,9 +34,9 @@ const cfg = loadLocalConfig(kitDir);
 const localOnly = process.env.RALPH_LOCAL === '1';
 // Same as ralph-claude.js: childEnv is built at load time, before startRalph resolves identity.
 Object.assign(cfg, resolveAgentIdentity(kitDir, 'BUILD', cfg));
-const execCmd = process.env.RALPH_EXEC_CMD || cfg.localAi?.exec;
+const configuredCmd = process.env.RALPH_EXEC_CMD || cfg.localAi?.exec;
 
-if (!execCmd) {
+if (!configuredCmd) {
   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');
@@ -60,6 +61,7 @@ const tracer = createSliceTracer({
   baseUrl: cfg.baseUrl,
   token: cfg.token,
   organizationId: cfg.organizationId,
+  boardId: cfg.boardId,
   agentId: cfg.agentId,
   traceFile: join(projectDir, '.eventmodelers', 'trace', 'slices.jsonl'),
   log: (line) => console.log(`[ralph-exec] ${line}`),
@@ -68,12 +70,10 @@ const tracer = createSliceTracer({
 
 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, `'\\''`)}'`;
-}
-
+// A known harness (OpenCode, Gemini, Codex) learns about the eventmodelers MCP server here, with the
+// platform URL from the config — rewritten every run so a changed baseUrl never goes stale. A local-only
+// run has no platform to register, and an unknown command is left to the skills' REST fallback.
+const execCmd = localOnly ? configuredCmd : registerMcp(configuredCmd, projectDir, cfg.baseUrl, (line) => console.log(`[ralph-exec] ${line}`)).command;
 console.log(`[ralph-exec] command: ${execCmd}`);
 
 // Parses a harness's stdout for usage while still passing it through. Most harnesses emit JSONL;

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

@@ -124,7 +124,6 @@ MODEL_CONTEXT  // Context/domain modeling container
 CHAPTER        // Timeline/sequence container — a "chapter" IS a timeline (chapterId === timelineId); the terms are used interchangeably across the API
 ACTOR          // System participant (swimlane label)
 AUTOMATION     // Automated action
-API            // External service
 SCREEN         // UI screen
 COMMAND        // State-changing operation
 EVENT          // Domain event

package/shared/skills/request-feedback/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: request-feedback
-description: Post a comment on a slice and mark it Blocked when the slice's requirements are genuinely ambiguous, contradictory, or missing something a decision depends on. This is an escalation path, not a routine step — reach for it only when you cannot proceed without guessing.
+description: Post a comment on a slice and mark it Blocked — ONLY when the slice literally cannot be built, even with reasonable assumptions. The absolute exception; for unclear or missing details, assume and build instead.
 ---
 
 # Request Feedback
@@ -11,41 +11,32 @@ Prefer `mcp__eventmodelers__*` tools when available (registered by the `connect`
 
 ---
 
-## When to use this skill — the exception, not the rule
+## When to use this skill — the absolute exception
 
-Building a slice is normally unambiguous: `slice.json` names every command field, event field, and
-GWT scenario, and the matching build skill (`build-state-change`, `build-state-view`,
-`build-automation`, ...) tells you exactly how to turn that into code. **Read `slice.json` fully, and
-read the build skill's own instructions and reference docs, before ever concluding something is
-missing.** Most slices need none of this.
+**The default is to assume and build.** A missing example value, an unclear field type, a status
+mapping, a referenced event that isn't modeled yet, a dependency slice that isn't built yet — none of
+these is a reason to stop. Pick the most sensible interpretation from `slice.json`, its
+`specifications[]` and the surrounding model, build the slice, and record each assumption in one line
+in `progress.txt` and as a code comment. **Read `slice.json` fully, and read the build skill's own
+instructions and reference docs, before concluding anything is missing.**
 
-Only invoke `request-feedback` when, after that reading, a decision the implementation depends on
-still cannot be made without guessing — for example:
-
-- A business rule mentioned in `description`/`comments`/`notes` isn't backed by any field, event, or
-  `specifications[]` scenario, so there's no way to encode it.
-- Two fields, or a field and an `idAttribute` flag, contradict each other about what the slice is
-  supposed to do.
-- A `specifications[]` scenario references a prior event or state that no command/event in this slice
-  (or its declared dependencies) actually produces.
-- The slice depends on another slice, screen, or read model that doesn't exist yet and it's unclear
-  whether one should be created, or the dependency was meant to point elsewhere.
+Invoke `request-feedback` **only if the slice literally cannot be built**: even with sensible
+assumptions, nothing runnable and tested can be produced. For example, the slice has no elements at
+all (no command/read model, no fields), or two parts of it contradict each other so that no single
+implementation satisfies both.
 
 **Do not use this skill for:**
-- Implementation-detail choices the build skill's own instructions already answer (e.g. package
-  naming, file layout, which annotation to use) — those aren't ambiguity in the slice, they're just
-  reading the skill more carefully.
-- Style or naming preferences with no functional consequence — pick the reasonable option and move on.
-- "This would be nice to confirm" — if you *can* proceed correctly from what `slice.json` says, proceed.
-
-When in doubt, prefer finishing the slice over escalating. Escalating on every minor uncertainty
-defeats the purpose — it should be rare enough that a `Blocked` slice reliably means "a human needs to
-look at this," not "the agent didn't feel like deciding."
-
-**When this skill does apply: do not guess and build anyway.** Post the question and stop work on this
-slice for this run — do not implement your best interpretation first. A wrong guess encoded into
-working, tested, committed code is harder to catch and undo than an unbuilt slice waiting for an
-answer.
+- Missing examples, field types, names, or status values — assume, build, note the assumption.
+- A dependency (event, command, other slice) that isn't implemented yet — assume its definition from
+  the model and build against it.
+- Implementation-detail choices the build skill's own instructions already answer.
+- Style or naming preferences, or "this would be nice to confirm".
+
+A `Blocked` slice must reliably mean "impossible without a human", never "the agent preferred to ask".
+When in doubt, build.
+
+**When this skill does apply:** post the question and stop work on this slice for this run — an
+impossible build can't be finished by guessing.
 
 ---
 

package/stacks/axon/templates/build-kit/CLAUDE.md

@@ -42,12 +42,7 @@ When starting to work on a slice, invoke the `update-slice-status` skill with `I
 **CRITICAL: You MUST always use the provided skills to build slices. NEVER implement a slice manually.**
 **ALL fields, event names, command names, and business rules MUST come exclusively from slice.json. Do NOT invent, assume, or guess any field or logic not present in the slice definition.**
 
-**If, at any point below, the slice's requirements are genuinely ambiguous, contradictory, or missing
-a decision you need in order to proceed — do not guess, and do not build anyway.** Invoke the
-`request-feedback` skill with the specific question; it posts the question as a comment on the slice
-and marks it `Blocked`, and you then stop work on this slice for this run. This is an escalation path,
-not a routine step — read `slice.json` and the matching build skill's own instructions fully first;
-most slices are fully specified and need none of this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 When asked to build a slice, always follow this flow:
 

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

@@ -50,14 +50,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 ## Escalating Ambiguity
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
-in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
-specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
-board (overriding the `InProgress` set earlier), then stop this iteration without finishing the
-build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
-implement the slice. This is an escalation path, not a routine step — read the slice.json and the
-matching build skill's own instructions fully first; most slices are fully specified and need none of
-this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 ## Progress Report Format
 

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

@@ -48,13 +48,13 @@ Inspect the `sliceStatus` in the payload:
 
 This is the build trigger. Setting `InProgress` and building are one atomic step:
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked` (superseding the `InProgress` set in step 1), then drop this task without finishing the build. This is an escalation path, not a routine step — most slices are fully specified.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 1. Immediately call `/update-slice-status` to set the slice to `InProgress` on the board.
 
    **Claim conflict**: if this call reports the slice is already in `InProgress` (or any status other than `Planned`), another agent already claimed it first — this is expected, not an error. Log it in `progress.txt`, drop this task without building, and continue the loop (the next task will naturally cover the next slice). Do not retry.
 
-2. Read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json` (written by `/load-slice`).
+2. Run `/load-slice sliceId=<payload.sliceId>` to fetch the full slice, then read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json`. The runner keeps a `slice.json` fresh from a summary endpoint, so a file holding only `id`, `title`, `status` and `sliceType` is that stub, not an empty slice — never conclude a slice has no elements from it. Only if the full fetch itself returns no commands/events/read models/fields is the slice actually empty.
 
 3. Determine the **slice type** from the slice.json:
    - **Translation** — `sliceType === "TRANSLATION"` → read `description` and `notes` from slice.json for hints; default to `/build-automation` if nothing else is specified

package/stacks/blank/templates/build-kit/CLAUDE.md

@@ -32,12 +32,7 @@ When starting to work on a slice, invoke the `update-slice-status` skill with `I
 **CRITICAL: You MUST always use the provided skills to build slices. NEVER implement a slice manually.**
 **ALL fields, event names, command names, and business rules MUST come exclusively from slice.json. Do NOT invent, assume, or guess any field or logic not present in the slice definition.**
 
-**If, at any point below, the slice's requirements are genuinely ambiguous, contradictory, or missing
-a decision you need in order to proceed — do not guess, and do not build anyway.** Invoke the
-`request-feedback` skill with the specific question; it posts the question as a comment on the slice
-and marks it `Blocked`, and you then stop work on this slice for this run. This is an escalation path,
-not a routine step — read `slice.json` and the matching build skill's own instructions fully first;
-most slices are fully specified and need none of this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 When asked to build a slice, always follow this flow:
 

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

@@ -40,14 +40,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 ## Escalating Ambiguity
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
-in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
-specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
-board (overriding the `InProgress` set in step 5), then stop this iteration without finishing the
-build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
-implement the slice. This is an escalation path, not a routine step — read the slice.json and the
-matching build skill's own instructions fully first; most slices are fully specified and need none of
-this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 ## Progress Report Format
 

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

@@ -52,7 +52,7 @@ This is the build trigger. Setting `InProgress` and building are one atomic step
 
    **Claim conflict**: if this call reports the slice is already in `InProgress` (or any status other than `Planned`), another agent already claimed it first — this is expected, not an error. Log it in `progress.txt`, drop this task without building, and continue the loop (the next task will naturally cover the next slice). Do not retry.
 
-2. Read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json` (written by `/load-slice`).
+2. Run `/load-slice sliceId=<payload.sliceId>` to fetch the full slice, then read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json`. The runner keeps a `slice.json` fresh from a summary endpoint, so a file holding only `id`, `title`, `status` and `sliceType` is that stub, not an empty slice — never conclude a slice has no elements from it. Only if the full fetch itself returns no commands/events/read models/fields is the slice actually empty.
 
 3. Determine the **slice type** from the slice.json:
    - **Translation** — `sliceType === "TRANSLATION"` → read `description` and `notes` from slice.json for hints; default to `/build-automation` if nothing else is specified
@@ -93,14 +93,7 @@ After completing a task, remove it from the array and write the updated array ba
 
 ## Escalating Ambiguity
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
-in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
-specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
-board (overriding the `InProgress` set earlier), then stop this iteration without finishing the
-build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
-implement the slice. This is an escalation path, not a routine step — read the slice.json and the
-matching build skill's own instructions fully first; most slices are fully specified and need none of
-this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 ## Progress Report Format
 

package/stacks/kurrent/templates/build-kit/CLAUDE.md

@@ -76,12 +76,7 @@ doing anything else.
 **ALL fields, event names, command names, and business rules MUST come exclusively from slice.json. Do NOT
 invent, assume, or guess any field or logic not present in the slice definition.**
 
-**If, at any point below, the slice's requirements are genuinely ambiguous, contradictory, or missing a
-decision you need in order to proceed — do not guess, and do not build anyway.** Invoke the
-`request-feedback` skill with the specific question; it posts the question as a comment on the slice and
-marks it `Blocked`, and you then stop work on this slice for this run. This is an escalation path, not a
-routine step — read `slice.json` and the matching build skill's own instructions fully first; most slices
-are fully specified and need none of this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 When asked to build a slice, always follow this flow:
 

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

@@ -50,14 +50,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 ## Escalating Ambiguity
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
-in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
-specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
-board (overriding the `InProgress` set earlier), then stop this iteration without finishing the
-build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
-implement the slice. This is an escalation path, not a routine step — read the slice.json and the
-matching build skill's own instructions fully first; most slices are fully specified and need none of
-this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 ## Progress Report Format
 

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

@@ -48,13 +48,13 @@ Inspect the `sliceStatus` in the payload:
 
 This is the build trigger. Setting `InProgress` and building are one atomic step:
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked` (superseding the `InProgress` set in step 1), then drop this task without finishing the build. This is an escalation path, not a routine step — most slices are fully specified.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 1. Immediately call `/update-slice-status` to set the slice to `InProgress` on the board.
 
    **Claim conflict**: if this call reports the slice is already in `InProgress` (or any status other than `Planned`), another agent already claimed it first — this is expected, not an error. Log it in `progress.txt`, drop this task without building, and continue the loop (the next task will naturally cover the next slice). Do not retry.
 
-2. Read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json` (written by `/load-slice`).
+2. Run `/load-slice sliceId=<payload.sliceId>` to fetch the full slice, then read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json`. The runner keeps a `slice.json` fresh from a summary endpoint, so a file holding only `id`, `title`, `status` and `sliceType` is that stub, not an empty slice — never conclude a slice has no elements from it. Only if the full fetch itself returns no commands/events/read models/fields is the slice actually empty.
 
 3. Determine the **slice type** from the slice.json:
    - **Translation** — `sliceType === "TRANSLATION"` → read `description` and `notes` from slice.json for hints; default to `/build-automation` if nothing else is specified

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

@@ -91,7 +91,7 @@ For each group, create a chapter on the board **before placing any events**. Reu
 
 **Prefer MCP — create a chapter:**
 ```
-mcp__eventmodelers__create_chapter { "boardId": "<BOARD_ID>", "x": 0, "y": 1200, "columns": <numberOfEventsInGroup> }
+mcp__eventmodelers__create_chapter { "boardId": "<BOARD_ID>", "columns": <numberOfEventsInGroup> }
 ```
 (`x`/`y` are optional — see the vertical-stacking note below. `columns` is optional too — the group's event count is already known at this point, so pass it here to create the chapter with exactly the columns this group needs, instead of the default 3 plus a follow-up `add_column` batch. Response includes the new `timelineId` and `columnIds` — one id per column, left to right, ready to use directly in Step A below.)
 
@@ -115,11 +115,11 @@ mcp__eventmodelers__submit_node_events {
 **Fallback (no MCP):** see `references/api-fallback.md` — "Timeline Discovery — Step 2: Create one chapter per group — set its title".
 
 **Stack timelines vertically so they do not overlap, and in general place new chapters close to existing ones they relate to.**
-After creating each chapter, position it below the previous one. Use `y = index * 1200` (0-based creation order), `x = 0`. If existing chapters are already on the board, query their positions first. Prefer placing the new chapter directly below the existing chapter it is most closely related to (e.g. the same bounded context or an adjacent workflow), rather than mechanically appending below the lowest one — this keeps related chapters visually near each other on the canvas. Only fall back to `y = maxExistingY + 1200` when no related chapter exists yet. Pass this directly as `x`/`y` on `create_chapter` above, or reposition an existing chapter with:
+Omit `x`/`y` on `create_chapter`: the backend stacks the new chapter below the lowest existing one, using each chapter's real current size plus a generous gap, so titles never overlap. Do not use a fixed offset like `index * 1200` — chapters are taller than that. Only pass a position to put a chapter elsewhere; if the box overlaps an existing chapter the backend moves it below everything. Prefer placing the new chapter directly below the existing chapter it is most closely related to (e.g. the same bounded context or an adjacent workflow), rather than mechanically appending below the lowest one — this keeps related chapters visually near each other on the canvas. Otherwise leave the position to the backend. To place next to a related chapter, read `get_chapter_bounds` and use `y = related.y + related.height + 600`, or reposition an existing chapter with:
 
 **Prefer MCP:**
 ```
-mcp__eventmodelers__move_timeline_position { "boardId": "<BOARD_ID>", "timelineId": "<TL>", "x": 0, "y": 1200 }
+mcp__eventmodelers__move_timeline_position { "boardId": "<BOARD_ID>", "timelineId": "<TL>", "x": 0, "y": <y> }
 ```
 
 **Fallback (no MCP):** see `references/api-fallback.md` — "Timeline Discovery — Step 2: Reposition an existing chapter".
@@ -426,6 +426,6 @@ Include error and boundary conditions:
 - [ ] Events group into at least one recognizable business process flow
 - [ ] No overlapping event semantics — two events don't mean the same thing
 - [ ] Every event is placed into a **named chapter** — no event left in an untitled or default timeline
-- [ ] **Multiple chapters are stacked vertically** (y offset of 1200 per chapter) — no two chapters overlap on the canvas
+- [ ] **Multiple chapters are stacked vertically** (auto-stacked by the backend) — no two chapters overlap on the canvas
 - [ ] No unnecessary swimlanes created — a swimlane exists only to mark integration with another system; never added for a new actor, a new role, or visual grouping
 - [ ] **When a second (external-system) swimlane exists, events follow one continuous story from this chapter's own swimlane throughout** — the external swimlane only ever holds isolated single-column handovers, never a run of its own, and the story resumes in this chapter's swimlane immediately after each one

package/stacks/node/templates/build-kit/CLAUDE.md

@@ -37,12 +37,7 @@ When starting to work on a slice, invoke the `update-slice-status` skill with `I
 **CRITICAL: You MUST always use the provided skills to build slices. NEVER implement a slice manually.**
 **ALL fields, event names, command names, and business rules MUST come exclusively from slice.json. Do NOT invent, assume, or guess any field or logic not present in the slice definition.**
 
-**If, at any point below, the slice's requirements are genuinely ambiguous, contradictory, or missing
-a decision you need in order to proceed — do not guess, and do not build anyway.** Invoke the
-`request-feedback` skill with the specific question; it posts the question as a comment on the slice
-and marks it `Blocked`, and you then stop work on this slice for this run. This is an escalation path,
-not a routine step — read `slice.json` and the matching build skill's own instructions fully first;
-most slices are fully specified and need none of this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 When asked to build a slice, always follow this flow:
 

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

@@ -44,14 +44,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 ## Escalating Ambiguity
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
-in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
-specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
-board (overriding the `InProgress` set earlier), then stop this iteration without finishing the
-build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
-implement the slice. This is an escalation path, not a routine step — read the slice.json and the
-matching build skill's own instructions fully first; most slices are fully specified and need none of
-this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 ## Progress Report Format
 

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

@@ -48,13 +48,13 @@ Inspect the `sliceStatus` in the payload:
 
 This is the build trigger. Setting `InProgress` and building are one atomic step:
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked` (superseding the `InProgress` set in step 1), then drop this task without finishing the build. This is an escalation path, not a routine step — most slices are fully specified.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 1. Immediately call `/update-slice-status` to set the slice to `InProgress` on the board.
 
    **Claim conflict**: if this call reports the slice is already in `InProgress` (or any status other than `Planned`), another agent already claimed it first — this is expected, not an error. Log it in `progress.txt`, drop this task without building, and continue the loop (the next task will naturally cover the next slice). Do not retry.
 
-2. Read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json` (written by `/load-slice`).
+2. Run `/load-slice sliceId=<payload.sliceId>` to fetch the full slice, then read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json`. The runner keeps a `slice.json` fresh from a summary endpoint, so a file holding only `id`, `title`, `status` and `sliceType` is that stub, not an empty slice — never conclude a slice has no elements from it. Only if the full fetch itself returns no commands/events/read models/fields is the slice actually empty.
 
 3. Determine the **slice type** from the slice.json:
    - **Translation** — `sliceType === "TRANSLATION"` → read `description` and `notes` from slice.json for hints; default to `/build-automation` if nothing else is specified

package/stacks/opencqrs/templates/build-kit/CLAUDE.md

@@ -62,12 +62,7 @@ doing anything else.
 **ALL fields, event names, command names, and business rules MUST come exclusively from slice.json. Do NOT
 invent, assume, or guess any field or logic not present in the slice definition.**
 
-**If, at any point below, the slice's requirements are genuinely ambiguous, contradictory, or missing a
-decision you need in order to proceed — do not guess, and do not build anyway.** Invoke the
-`request-feedback` skill with the specific question; it posts the question as a comment on the slice and
-marks it `Blocked`, and you then stop work on this slice for this run. This is an escalation path, not a
-routine step — read `slice.json` and the matching build skill's own instructions fully first; most slices
-are fully specified and need none of this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 When asked to build a slice, always follow this flow:
 

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

@@ -50,14 +50,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 ## Escalating Ambiguity
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
-in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
-specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
-board (overriding the `InProgress` set earlier), then stop this iteration without finishing the
-build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
-implement the slice. This is an escalation path, not a routine step — read the slice.json and the
-matching build skill's own instructions fully first; most slices are fully specified and need none of
-this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 ## Progress Report Format
 

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

@@ -48,13 +48,13 @@ Inspect the `sliceStatus` in the payload:
 
 This is the build trigger. Setting `InProgress` and building are one atomic step:
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked` (superseding the `InProgress` set in step 1), then drop this task without finishing the build. This is an escalation path, not a routine step — most slices are fully specified.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 1. Immediately call `/update-slice-status` to set the slice to `InProgress` on the board.
 
    **Claim conflict**: if this call reports the slice is already in `InProgress` (or any status other than `Planned`), another agent already claimed it first — this is expected, not an error. Log it in `progress.txt`, drop this task without building, and continue the loop (the next task will naturally cover the next slice). Do not retry.
 
-2. Read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json` (written by `/load-slice`).
+2. Run `/load-slice sliceId=<payload.sliceId>` to fetch the full slice, then read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json`. The runner keeps a `slice.json` fresh from a summary endpoint, so a file holding only `id`, `title`, `status` and `sliceType` is that stub, not an empty slice — never conclude a slice has no elements from it. Only if the full fetch itself returns no commands/events/read models/fields is the slice actually empty.
 
 3. Determine the **slice type** from the slice.json:
    - **Translation** — `sliceType === "TRANSLATION"` → read `description` and `notes` from slice.json for hints; default to `/build-automation` if nothing else is specified

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

@@ -32,12 +32,7 @@ When starting to work on a slice, invoke the `update-slice-status` skill with `I
 **CRITICAL: You MUST always use the provided skills to build slices. NEVER implement a slice manually.**
 **ALL fields, event names, command names, and business rules MUST come exclusively from slice.json. Do NOT invent, assume, or guess any field or logic not present in the slice definition.**
 
-**If, at any point below, the slice's requirements are genuinely ambiguous, contradictory, or missing
-a decision you need in order to proceed — do not guess, and do not build anyway.** Invoke the
-`request-feedback` skill with the specific question; it posts the question as a comment on the slice
-and marks it `Blocked`, and you then stop work on this slice for this run. This is an escalation path,
-not a routine step — read `slice.json` and the matching build skill's own instructions fully first;
-most slices are fully specified and need none of this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 When asked to build a slice, always follow this flow:
 

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

@@ -40,14 +40,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 ## Escalating Ambiguity
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
-in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
-specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
-board (overriding the `InProgress` set in step 5), then stop this iteration without finishing the
-build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
-implement the slice. This is an escalation path, not a routine step — read the slice.json and the
-matching build skill's own instructions fully first; most slices are fully specified and need none of
-this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 ## Progress Report Format
 

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

@@ -52,7 +52,7 @@ This is the build trigger. Setting `InProgress` and building are one atomic step
 
    **Claim conflict**: if this call reports the slice is already in `InProgress` (or any status other than `Planned`), another agent already claimed it first — this is expected, not an error. Log it in `progress.txt`, drop this task without building, and continue the loop (the next task will naturally cover the next slice). Do not retry.
 
-2. Read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json` (written by `/load-slice`).
+2. Run `/load-slice sliceId=<payload.sliceId>` to fetch the full slice, then read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json`. The runner keeps a `slice.json` fresh from a summary endpoint, so a file holding only `id`, `title`, `status` and `sliceType` is that stub, not an empty slice — never conclude a slice has no elements from it. Only if the full fetch itself returns no commands/events/read models/fields is the slice actually empty.
 
 3. Determine the **slice type** from the slice.json:
    - **Translation** — `sliceType === "TRANSLATION"` → read `description` and `notes` from slice.json for hints; default to `/build-automation` if nothing else is specified
@@ -93,14 +93,7 @@ After completing a task, remove it from the array and write the updated array ba
 
 ## Escalating Ambiguity
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
-in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
-specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
-board (overriding the `InProgress` set earlier), then stop this iteration without finishing the
-build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
-implement the slice. This is an escalation path, not a routine step — read the slice.json and the
-matching build skill's own instructions fully first; most slices are fully specified and need none of
-this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 ## Progress Report Format
 

package/stacks/supabase/templates/build-kit/CLAUDE.md

@@ -37,12 +37,7 @@ When starting to work on a slice, invoke the `update-slice-status` skill with `I
 **CRITICAL: You MUST always use the provided skills to build slices. NEVER implement a slice manually.**
 **ALL fields, event names, command names, and business rules MUST come exclusively from slice.json. Do NOT invent, assume, or guess any field or logic not present in the slice definition.**
 
-**If, at any point below, the slice's requirements are genuinely ambiguous, contradictory, or missing
-a decision you need in order to proceed — do not guess, and do not build anyway.** Invoke the
-`request-feedback` skill with the specific question; it posts the question as a comment on the slice
-and marks it `Blocked`, and you then stop work on this slice for this run. This is an escalation path,
-not a routine step — read `slice.json` and the matching build skill's own instructions fully first;
-most slices are fully specified and need none of this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 When asked to build a slice, always follow this flow:
 

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

@@ -44,14 +44,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 ## Escalating Ambiguity
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
-in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
-specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
-board (overriding the `InProgress` set earlier), then stop this iteration without finishing the
-build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
-implement the slice. This is an escalation path, not a routine step — read the slice.json and the
-matching build skill's own instructions fully first; most slices are fully specified and need none of
-this.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 ## Progress Report Format
 

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

@@ -48,13 +48,13 @@ Inspect the `sliceStatus` in the payload:
 
 This is the build trigger. Setting `InProgress` and building are one atomic step:
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked` (superseding the `InProgress` set in step 1), then drop this task without finishing the build. This is an escalation path, not a routine step — most slices are fully specified.
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 1. Immediately call `/update-slice-status` to set the slice to `InProgress` on the board.
 
    **Claim conflict**: if this call reports the slice is already in `InProgress` (or any status other than `Planned`), another agent already claimed it first — this is expected, not an error. Log it in `progress.txt`, drop this task without building, and continue the loop (the next task will naturally cover the next slice). Do not retry.
 
-2. Read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json` (written by `/load-slice`).
+2. Run `/load-slice sliceId=<payload.sliceId>` to fetch the full slice, then read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json`. The runner keeps a `slice.json` fresh from a summary endpoint, so a file holding only `id`, `title`, `status` and `sliceType` is that stub, not an empty slice — never conclude a slice has no elements from it. Only if the full fetch itself returns no commands/events/read models/fields is the slice actually empty.
 
 3. Determine the **slice type** from the slice.json:
    - **Webhook** — `sliceType === "WEBHOOK"` → invoke `/build-webhook`