@eventmodelers/cli 1.0.161 → 1.0.163

package/README.md

@@ -680,6 +680,7 @@ Flow: `Ready → Planned → InProgress → Handover → InProgress → Done`. P
 - **Both sides need the new kit.** An already-installed backend kit keeps its old `ralph.js` and prompts and silently ignores `--handover` (slices still end at `Done`); `re-init` it to pick the feature up.
 - **The platform must know the `Ready` / `Handover` statuses.**
 - A kit declares what it claims in `lib/kit.json` — `{ "pickupStatus": "Handover" }`; absent means `Planned`.
+- `run --status-trigger <status>` overrides that pickup status for a single run (e.g. `--status-trigger Ready`); nothing is saved.
 
 The contract itself is the shared `ui-contract` skill's job (see above); it also owns the rule for which status a slice ends at.
 

package/cli.js

@@ -3718,6 +3718,7 @@ credentialFlags(program
   .option('--dangerously-skip-permissions', 'Run the modeling agent\'s Claude process with --dangerously-skip-permissions, as before the lockdown: every tool call is approved — any shell command, curl to anywhere, any file the user can read or write, every MCP server the machine configures. Off by default because the agent takes chat messages and snippet clicks from any collaborator on the board; pass it only for a board whose collaborators you trust with your shell. Default Claude runner of --modeling/--standalone/--worker/--global only — not with --agent, --exec or --local-ai, which bring their own permission flags.')
   .option('--browser', 'Give the locked-down modeling agent a browser: the Playwright MCP server (npx @playwright/mcp) next to the eventmodelers one, for discover-storyboard. Off by default because a browser can reach any site, which the lockdown otherwise rules out. Default Claude runner only; --dangerously-skip-permissions already loads every MCP server the machine configures.')
   .option('--handover', 'Backend build kit: for this run only, finish slices that have a UI at `Handover` instead of `Done` (same as the project setting `handover: true`, which `init --handover` / `config --handover on` save — this flag writes nothing). Without it the project setting applies; without both, slices end at `Done`.')
+  .option('--status-trigger <status>', 'Build kit: the slice status the agent picks work up from, for this run only (e.g. Ready, Planned, Handover). Defaults to the kit\'s own pickup status — `Planned` for backend kits, `Handover` for the UI kits. Nothing is written to disk.')
   .option('--verbose', 'Log every tool call\'s full input (commands, skill args, file paths) and assistant reasoning text. Default is condensed, high-level per-step logging only.')
   .option('--id <id>', 'Pin the agent id this run identifies itself with on the platform. A project install otherwise mints one id per project and reuses it on every restart; --global/--standalone mints a fresh one per run, since two ad-hoc agents for one board must not share a row (the heartbeat is keyed on token + agent_id + agent_type, so the second would replace the first). Pass this when an agent has to keep ONE identity across restarts — a supervisor that already knows the id, or a board where it is the starred "preferred agent". Per-run only: nothing is written to disk.')
   .option('--name <name>', 'A human-readable name for this agent, sent with every heartbeat so the board shows which agent is live rather than a bare uuid (e.g. "ci-builder", "martins-laptop"). Per-run only, like --id: the persistent name is `agentName` in config.json (set via `init --name` / `init-config --name`), and this overrides it for one run without writing anything.')
@@ -3988,7 +3989,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_HANDOVER: opts.handover ? '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 } : {}) } });
+      execSync(cmd, { cwd: kitDir, stdio: 'inherit', env: { ...process.env, RALPH_VERBOSE: opts.verbose ? '1' : '', RALPH_LOCAL: opts.local ? '1' : '', RALPH_HANDOVER: opts.handover ? '1' : '', RALPH_STATUS_TRIGGER: opts.statusTrigger ? String(opts.statusTrigger).trim() : '', 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.161",
+  "version": "1.0.163",
   "description": "Eventmodelers CLI — real-time Claude agent + skills for Claude Code, for any stack (Node, Supabase, Axon, OpenCQRS, UmaDB, Kurrent, or modeling-only)",
   "type": "module",
   "bin": {

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

@@ -521,8 +521,11 @@ function hasPendingTasks(kitDir) {
 
 // The slice status this kit claims work from. A stack declares it in `lib/kit.json`
 // ({ "pickupStatus": "Handover" } for the UI kits, which build what a backend kit handed over);
-// absent means "Planned", the backend default.
+// absent means "Planned", the backend default. `run --status-trigger <status>` (RALPH_STATUS_TRIGGER)
+// overrides either for that run.
 export function readPickupStatus(kitDir) {
+  const override = (process.env.RALPH_STATUS_TRIGGER || '').trim();
+  if (override) return override;
   try {
     const s = JSON.parse(readFileSync(join(kitDir, 'lib', 'kit.json'), 'utf-8')).pickupStatus;
     if (typeof s === 'string' && s.trim()) return s.trim();
@@ -550,8 +553,8 @@ function readTicketNumber(kitDir, ctx, folder) {
 // Returns the first Planned slice, preferring the current context so a context is finished
 // before the next one starts. When the current context has no planned work, the first other
 // context that does becomes the current one (current_context.json is rewritten), so a slice
-// set to Planned in any context is eventually built.
-function getFirstPlannedSlice(kitDir) {
+// set to Planned in any context is eventually built. Ids in `skipIds` are passed over.
+function getFirstPlannedSlice(kitDir, skipIds = new Set()) {
   const slicesDir = join(kitDir, '.slices');
   const currentCtx = readCurrentContext(kitDir);
   let others = [];
@@ -565,7 +568,7 @@ function getFirstPlannedSlice(kitDir) {
     if (!existsSync(indexPath)) continue;
     try {
       const { slices } = JSON.parse(readFileSync(indexPath, 'utf-8'));
-      const planned = slices && slices.find((s) => (s.status || '').toLowerCase() === pickup);
+      const planned = slices && slices.find((s) => (s.status || '').toLowerCase() === pickup && !skipIds.has(s.id));
       if (!planned) continue;
       if (ctx !== currentCtx) {
         writeFileSync(join(slicesDir, 'current_context.json'), JSON.stringify({ name: ctx }, null, 2), 'utf-8');
@@ -577,15 +580,35 @@ function getFirstPlannedSlice(kitDir) {
   return null;
 }
 
-// If the exact same Planned slice (by id) comes back up this many times in a
-// row without its status ever leaving "Planned", onPlannedSlice is stuck on
+// Ids of every slice currently waiting for pickup, across all contexts.
+function listPlannedIds(kitDir) {
+  const slicesDir = join(kitDir, '.slices');
+  const pickup = readPickupStatus(kitDir).toLowerCase();
+  const ids = new Set();
+  try {
+    for (const d of readdirSync(slicesDir, { withFileTypes: true })) {
+      if (!d.isDirectory()) continue;
+      try {
+        const { slices } = JSON.parse(readFileSync(join(slicesDir, d.name, 'index.json'), 'utf-8'));
+        for (const s of slices ?? []) if ((s.status || '').toLowerCase() === pickup) ids.add(s.id);
+      } catch {}
+    }
+  } catch {}
+  return ids;
+}
+
+// If the exact same Planned slice (by id) has been built this many times without its status ever leaving "Planned", onPlannedSlice is stuck on
 // it — declining to build it, or building it but its own status change keeps
 // getting reverted (e.g. a failed check). Rather than retry it forever (or
 // crash the whole loop, which would take down every other slice with it),
 // mark it Blocked with a note explaining why and move on to other work.
 // Critical for unsupervised/CI runs, which have no human watching to notice
 // a stall. Configurable for teams that want more slack.
-const MAX_PLANNED_ATTEMPTS = Number(process.env.RALPH_MAX_PLANNED_ATTEMPTS) || 2;
+const MAX_PLANNED_ATTEMPTS = Number(process.env.RALPH_MAX_PLANNED_ATTEMPTS) || 5;
+
+// After this many builds that left a slice Planned, the loop builds any other Planned slice first
+// and comes back to the stuck one only when nothing else is waiting (until MAX_PLANNED_ATTEMPTS).
+const SWITCH_AFTER_ATTEMPTS = Math.min(2, MAX_PLANNED_ATTEMPTS);
 
 // Marks a stuck slice Blocked (locally, and on the board if credentialed) and
 // records why, so the loop can move on instead of looping or exiting.
@@ -661,6 +684,23 @@ async function blockStuckSlice(kitDir, cfg, credentialed, planned, attempts, las
     }
   }
 
+  // Always leave a comment on the slice saying why it was blocked — a Blocked slice with no
+  // explanation is a dead end for whoever finds it. Its own try block, so a failed status sync
+  // above can't skip it; without credentials there is no board to comment on, so say so loudly.
+  if (credentialed) {
+    try {
+      await fetchJSON(`${cfg.baseUrl}/api/org/${cfg.organizationId}/boards/${cfg.boardId}/nodes/${planned.id}/comments`, {
+        method: 'POST',
+        headers: { 'Content-Type': 'application/json', 'x-token': cfg.token, 'x-user-id': 'ralph-loop', ...agentHeaders(cfg) },
+        body: JSON.stringify({ text: `Slice "${planned.title}" was auto-blocked by the Ralph loop. ${reason}`, type: 'COMMENT', author: 'ralph-loop' }),
+      });
+    } catch (err) {
+      console.error(`[ralph] Failed to post the auto-block comment on "${planned.title}" — the reason is only in progress.txt:`, err.message);
+    }
+  } else {
+    console.error(`[ralph] No board credentials — could not comment on "${planned.title}"; the reason is only in progress.txt.`);
+  }
+
   console.error(`[ralph] ${reason} Marked "${planned.title}" (id=${planned.id}) as Blocked — moving on.`);
 }
 
@@ -703,7 +743,7 @@ function taskRequest(planned = null, cfg = null, pickupStatus = 'Planned') {
     : 'process the pending tasks in tasks.json';
   // Stated explicitly so the agent never has to work it out from config.json: this run's effective
   // value, which is what the `ui-contract` skill (Step 4) follows. UI kits (pickup Handover) ignore it.
-  const handover = planned && pickupStatus === 'Planned' ? `\nHandover: ${resolveHandover(cfg) ? 'on' : 'off'}\n` : '';
+  const handover = planned && pickupStatus.toLowerCase() !== 'handover' ? `\nHandover: ${resolveHandover(cfg) ? 'on' : 'off'}\n` : '';
   return `\n\n---\n\nYour task now: ${task}, following the instructions above. Start immediately.\n${handover}`;
 }
 
@@ -715,9 +755,9 @@ async function ralphLoop(kitDir, cfg, onTask, onPlannedSlice, localOnly = false)
   // this back on.
   const credentialed = !localOnly && hasCredentials(cfg);
   let lastIdleCtx;
-  // Tracks consecutive sightings of the same Planned slice id — see
-  // MAX_PLANNED_ATTEMPTS above.
-  let stuckSlice = { id: null, count: 0 };
+  // Builds so far per slice id that is still Planned — see MAX_PLANNED_ATTEMPTS above. An id drops
+  // out as soon as its slice leaves Planned, so only builds that failed to move it count.
+  const plannedAttempts = new Map();
   // The build agent's final reply on the most recent planned-slice turn — quoted in the Blocked note.
   let lastReply = null;
 
@@ -732,18 +772,23 @@ async function ralphLoop(kitDir, cfg, onTask, onPlannedSlice, localOnly = false)
       didWork = true;
     }
 
-    const planned = onPlannedSlice && getFirstPlannedSlice(kitDir);
+    let planned = null;
+    if (onPlannedSlice) {
+      const stillPlanned = listPlannedIds(kitDir);
+      for (const id of plannedAttempts.keys()) if (!stillPlanned.has(id)) plannedAttempts.delete(id);
+      const stuckIds = new Set([...plannedAttempts].filter(([, n]) => n >= SWITCH_AFTER_ATTEMPTS).map(([id]) => id));
+      // Prefer a slice that hasn't been tried to the switch point; fall back to a stuck one.
+      planned = getFirstPlannedSlice(kitDir, stuckIds) ?? (stuckIds.size ? getFirstPlannedSlice(kitDir) : null);
+    }
     if (planned) {
-      stuckSlice = planned.id !== null && planned.id === stuckSlice.id
-        ? { id: stuckSlice.id, count: stuckSlice.count + 1 }
-        : { id: planned.id, count: 1 };
-
-      if (stuckSlice.count > MAX_PLANNED_ATTEMPTS) {
-        await blockStuckSlice(kitDir, cfg, credentialed, planned, stuckSlice.count, lastReply);
-        stuckSlice = { id: null, count: 0 };
+      const attempts = plannedAttempts.get(planned.id) ?? 0;
+      if (planned.id !== null && attempts >= MAX_PLANNED_ATTEMPTS) {
+        await blockStuckSlice(kitDir, cfg, credentialed, planned, attempts, lastReply);
+        plannedAttempts.delete(planned.id);
         didWork = true;
         continue;
       }
+      if (planned.id !== null) plannedAttempts.set(planned.id, attempts + 1);
 
       const prompt = readFileSync(backendPromptFile, 'utf-8') + taskRequest(planned, cfg, readPickupStatus(kitDir));
       if (credentialed) await fetchFullSlice(cfg, kitDir, planned.id);
@@ -754,7 +799,7 @@ async function ralphLoop(kitDir, cfg, onTask, onPlannedSlice, localOnly = false)
         context: planned.ctx,
         ticketNumber: planned.ticketNumber,
         boardId: cfg.boardId ?? null,
-        attempt: stuckSlice.count,
+        attempt: attempts + 1,
       }); });
       if (built) console.log(`[ralph] Slice build complete — waiting for next slice`);
       if (credentialed) await fetchAndPersistSlices(cfg, kitDir).catch(() => {});

package/shared/build-kit/ralph.sh

@@ -41,9 +41,12 @@ has_pending_tasks() {
   [[ "$content" != "[]" && -n "$content" ]]
 }
 
-# Returns 0 if any JSON under .build-kit/.slices/ contains a "Planned" status
+# Status this loop picks work up from — `run --status-trigger <status>` (RALPH_STATUS_TRIGGER), default Planned
+PICKUP_STATUS="${RALPH_STATUS_TRIGGER:-Planned}"
+
+# Returns 0 if any JSON under .build-kit/.slices/ contains a slice in the pickup status
 has_planned_slices() {
-  grep -rqi '"status"[[:space:]]*:[[:space:]]*"planned"' "$KIT_DIR/.slices/" --include='index.json' 2>/dev/null
+  grep -rqi "\"status\"[[:space:]]*:[[:space:]]*\"$PICKUP_STATUS\"" "$KIT_DIR/.slices/" --include='index.json' 2>/dev/null
 }
 
 # Returns the title of the first "Planned" slice, or empty string
@@ -54,10 +57,10 @@ get_planned_slice_title() {
     title=$(node -e "
       try {
         const d = JSON.parse(require('fs').readFileSync(process.argv[1], 'utf-8'));
-        const s = (d.slices||[]).find(s => (s.status||'').toLowerCase() === 'planned');
+        const s = (d.slices||[]).find(s => (s.status||'').toLowerCase() === process.argv[2].toLowerCase());
         if (s) process.stdout.write(s.slice || s.id || '');
       } catch(e) {}
-    " "$index_file" 2>/dev/null)
+    " "$index_file" "$PICKUP_STATUS" 2>/dev/null)
     if [[ -n "$title" ]]; then
       echo "$title"
       return
@@ -95,7 +98,7 @@ while [[ "$ITERATIONS" -eq 0 || "$cycle" -lt "$ITERATIONS" ]]; do
 
   if has_planned_slices; then
     slice_title=$(get_planned_slice_title)
-    run_agent "onPlannedSlice: building \"$slice_title\"..." "$(cat "$BACKEND_PROMPT_FILE"; task_request "build the Planned slice \"$slice_title\"")"
+    run_agent "onPlannedSlice: building \"$slice_title\"..." "$(cat "$BACKEND_PROMPT_FILE"; task_request "build the $PICKUP_STATUS slice \"$slice_title\"")"
     echo "[$(date -u +%H:%M:%S)] Slice \"$slice_title\" build complete — waiting for next slice"
     ran_something=true
   fi

package/shared/skills/connect/SKILL.md

@@ -287,11 +287,7 @@ Connecting is also where the session's read discipline starts. Every skill that
 
 ### The slice status comes with the outline
 
-The orientation read also tells you what you may write to. `get_board_outline` returns `sliceStatus` per column — a slice owns a column, so every element in that column shares its status. `get_nodes` does **not** carry it, so take it from the outline before any write:
-
-**Only a slice in `Created` may be written to.** Any other status — `Ready`, `Planned`, `Assigned`, `InProgress`, `Handover`, `Review`, `Blocked`, `Done`, `Informational` — means someone is working on that slice: read its elements for context, but never change, move, rename or delete them, and never add scenarios, fields or examples to them. An element in a column with **no** `sliceStatus` is in no slice at all, which is not the same as locked — that one is writable.
-
-Never spend a `list_slices`/`get_slice_data` call to answer this; the outline already did.
+The orientation read also gives each column's `sliceStatus` (`get_nodes` does **not** carry it) — a slice owns a column, so every element in that column shares its status. It is context, not a write lock: any slice may be changed, whatever its status.
 
 `get_node` without a projection is for **one** node you did not already load — most often re-reading a node right after writing it. A step that issues it in a loop over nodes that were already in a list response is doing the same fetch N times; collapse it to the single chapter-scoped read above.
 

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

@@ -114,22 +114,6 @@ Stop traversal when:
 
 ---
 
-## Step 3e — Check the slices first (before any write)
-
-Only elements in a slice with status `Created` may be changed — and an element in no slice at all is
-not locked. The chain you resolved does not carry that: `get_attribute_chain` and `get_node` do not
-report `sliceStatus`. Read it now, once: `mcp__eventmodelers__get_board_outline { "boardId": "$BOARD_ID", "chapterId": "$CHAPTER_ID" }`
-gives every column a `sliceStatus` when a slice spans it. Look up each chain node's column.
-
-- **Every node writable** (`Created`, or no `sliceStatus`) → continue with Step 4.
-- **Any node in a column with another status** (`Done`, `Review`, `Handover`, `InProgress`, `Blocked`, `Ready`, `Planned`, `Assigned`,
-  `Informational`) → **do not write that node.** If the task text says the person already confirmed changing
-  that locked slice (*"The person confirmed changing the locked slice '…'"*, with an `origin_message_id`), you may
-  change those elements and only those. Otherwise write **nothing** — not even the nodes that are writable, the
-  chain is one logical edit — and follow `CLAUDE.md` § *Locked slices in a chat*: ask in the chat with a
-  `confirm` snippet (or a `changes` snippet listing the elements) naming the slice and its status, post no
-  `COMMENT` on the slice, and end the turn. (No chat to ask in? Change nothing and post a `COMMENT` on the slice.)
-
 ## Step 4 — Apply the change to the whole chain in one write
 
 Compute the updated `fields` array for **every** node in the chain first, in order (TARGET_NODE first, then backwards to SOURCE_NODE), then submit them all in a **single** `submit_node_events` call. Do not write one node, check it, and move to the next — the chain is one logical edit and `events[]` takes the whole batch.
@@ -196,7 +180,7 @@ Tell the user:
 - **Operation**: add `"<name>"` / rename `"<old>"` → `"<new>"`
 - **Chain**: list each element in order (type + title + cell)
 - **Updated**: which nodes were changed
-- **Skipped**: which nodes were skipped and why (field already exists / field not found / slice not `Created` — asked to confirm)
+- **Skipped**: which nodes were skipped and why (field already exists / field not found)
 - **Lineage**: where the attribute starts (`generated` on which element) and any `mapping` you set for a renamed hop
 
 Example output:

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

@@ -25,14 +25,6 @@ From `$ARGUMENTS`, extract:
 
 ---
 
-## Step 1a — Locked slices
-
-Only elements in a slice with status `Created` may be changed (no slice at all = not locked).
-`get_board_outline` reports `sliceStatus` per column; read it for the chapter before writing, and for
-any target in a column with another status (`Done`, `Review`, `InProgress`, …) **write nothing to it**
-unless the task says the person already confirmed changing that locked slice. Otherwise ask in the chat
-with a `confirm` snippet — `CLAUDE.md` § *Locked slices in a chat* — and post no `COMMENT` on the slice.
-
 ## Step 1b — Many targets at once
 
 `target` is singular, but the common real request is "fill in the examples across this chapter". When you have more than one target, **do not run this skill once per element and do not fetch context a node at a time.**

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

@@ -89,8 +89,6 @@ In the text, name the **clusters** (elements hit by the same stressor pair), the
 
 Propose new slices (translations, reconciliation todo lists, grace periods, second entry paths …) and state the **new residue** for each stressor that hit the cluster. A `confirm` snippet: `headline` = *"Add these N slices for <cluster>?"*; the slices and their new residues go in the text, kept short.
 
-Never touch elements in non-`Created` slices without an explicit yes; name them instead ("Order Paid sits in a Done slice — I'd leave it and add a translation next to it").
-
 ## Step 4 — On yes
 
 One `create_prompt` per new slice (`originMessageId` = the yes), phrased so the prompt turn can do it on its own (chapter, slice name, its elements and fields). Reply in one line. A no: acknowledge it and offer the next cluster.

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

@@ -170,6 +170,6 @@ Impact mode, same shape with `status` (and `changes`, or `elements` for a new sl
 - `summary` is always there — the first page shows it under the slice count.
 - Every `nodeId` / `screenId` is an id you read in Steps 2–3 — never a guessed or remembered one. A `new` slice has no `nodeId`.
 - The snippet is at most 64 KB; keep descriptions short rather than dropping steps.
-- **Impact mode** ends there: the walkthrough is the proposal. If the person then asks for the changes, that is ordinary work (prompts per the kit's CLAUDE.md) — and a slice that is not `Created` still needs their confirmation first.
+- **Impact mode** ends there: the walkthrough is the proposal. If the person then asks for the changes, that is ordinary work (prompts per the kit's CLAUDE.md).
 
 **No chat** (run from a terminal): print the slice count and the summary, then the steps as a numbered list with the same fields, instead of posting.

package/stacks/modeling-kit/templates/kit/AGENTS.md

@@ -20,4 +20,3 @@ ones in a compressed, reusable form; only add if not already covered here.
 - Mint ids once per turn, in one shell: `for i in $(seq <n>); do uuidgen; done` — one per new node, plus one per event, since every event needs its own fresh `id` (required; not the node id). Nothing in it depends on anything being read, so splitting it across several calls buys round trips for nothing. Never mint a per-event `boardId` or `timestamp` — both are server-derived and ignored if sent.
 - A subagent is a fresh session: it gets `token=`/`org=`/`baseUrl=`/`board=` inline as already-resolved values (which satisfies `connect` at its Step 0 — tell it not to invoke `/connect`) plus the board state already read for it, inline. Handed bare node ids instead, it has exactly one way to recover the rest — re-reading the whole board, once per agent.
 - Dispatch executor agents with `model:` set to the session header's `subagent_model` (default `sonnet`). The judging happened before the dispatch, on this session's model; what's left is execution against a written brief. Keep an agent on the session model only where its piece re-derives modeling structure (a chain's shape, a slice boundary).
-- Only slices in status `Created` may be modified. `get_board_outline` returns `sliceStatus` per column (`get_nodes` does not carry it), so the outline read at `/connect` Step 5 already answers it — absent means the column is in no slice (writable), not locked. Never spend a `list_slices`/`get_slice_data` call just to check whether you may write.

package/stacks/modeling-kit/templates/kit/CLAUDE.md

@@ -84,22 +84,6 @@ header's `standalone=on|off` tells you which mode they come in.
 
 At the start of every session, read `.agent-modeling-kit/AGENTS.md` if it exists to load accumulated learnings.
 
-**Only touch elements in a slice whose status is `Created` — unless the person explicitly confirmed it.** Every other status — `Ready`, `Planned`,
-`Assigned`, `InProgress`, `Handover`, `Review`, `Blocked`, `Done`, `Informational` — means someone is working
-on that slice: read it for context, but never change, move, rename or delete its elements, and
-never add scenarios, fields or examples to them. An element in no slice at all is not locked.
-`get_board_outline` returns `sliceStatus` per column (`get_nodes` does not carry it), so the
-outline read `/connect` Step 5 already makes answers this — no `list_slices`/`get_slice_data` call needed.
-If only part of what you were asked to do is locked, do the rest and name what you skipped and
-why. **When the work came from a chat** (the prompt carries `origin_session_id=`, or you are in a
-`CHAT` turn), do not simply refuse and do not change it either: **ask the person to confirm**, in
-the chat, with a `confirm` snippet (see "Locked slices in a chat" below). Their yes is what unlocks
-exactly those elements — nothing else about the rule loosens. **No skill overrides this.** `/attributes`,
-`/examples`, `/place-element` and the rest write through their own steps; a skill that does not mention
-`sliceStatus` is not permission — check the outline before its first write, every time. A `COMMENT` on the slice is only for
-when there is no chat to ask in (a prompt that did not come from one, a standalone turn): then change
-nothing and comment which status blocked it. Where there is a chat, never comment — ask with the snippet.
-
 **Every field you add or rename must have a known source. This holds in every skill and every turn, not only in a full modeling run.**
 Follow `eventmodeling-information-completeness` before writing any field. It defines the three valid sources: a same-named upstream field, a `mapping`, or `generated: true`. A field with none of these is a gap to close upstream, never one to place unmapped.
 
@@ -249,19 +233,14 @@ for it. Instead:
      *"Run /<name> <the rest of the message>"*, with the target resolved from `context=` like any other
      (selected elements, chapter), and say so in one line. Don't re-interpret it as a question. A skill that
      needs something the message lacks (which attribute? which screen?) is a **clarify**: ask, with a
-     snippet if the answer is a pick. A locked slice still needs the person's confirmation
-     ("Locked slices in a chat" below).
+     snippet if the answer is a pick.
    - **a review in other words** ("what do you think?", "any questions on this?", "what's missing here?") —
      your call: a quick take is an **answer**, in prose; a thorough review of a whole context or chapter may
      be the same prompt as above. If a reply ends in a question the person answers with a click ("Want me to
      turn these into comments?"), that question is a snippet, not a sentence (step 4, Snippets).
    - **clarify** — too vague to act on even with the session behind it: do no work.
    - **work** — it asks for a change to the board: create the work now, as below — a request is its
-     own go-ahead, in every mode — **except for a locked slice.** Before `create_prompt`, find out whether
-     the elements it names (and, for a change that follows connections, the ones it reaches) sit in a slice
-     that is not `Created`: `get_board_outline` for that chapter, `sliceStatus` per column. If so, no
-     prompt for those: ask first (see "Locked slices in a chat"). A request is not a go-ahead to reopen
-     finished work.
+     own go-ahead, in every mode.
    - **confirm** — the message says yes to a proposal you started after a board change (`--modeling`
      proposes instead of acting on board changes; see "Propose mode" in CLAUDE-STANDALONE.md). Any
      form counts, typed or spoken ("yes", "sure", "go ahead", "do it", "ok, but only the
@@ -365,31 +344,6 @@ the reason: *"Added the fields to Register User. I left Order Placed alone — s
 The work card shows "Done", which the person would otherwise read as everything went through. Never
 reply `DONE` to a chat-originated prompt without having posted a message.
 
-### Locked slices in a chat
-
-A request that touches an element in a slice that is not `Created` (e.g. `Done`) is not refused and
-not silently turned into a comment: **you ask, explicitly, and wait for the yes.** Whichever turn
-notices it — the `CHAT` turn (the outline you read already has `sliceStatus`) or the prompt turn —
-does the same:
-
-1. **Change nothing in the locked slice.** Do everything else the request asked for.
-2. **Post one `post_chat_message`** (`replyTo` = this turn's `message_id` in a `CHAT` turn; `sessionId`
-   = `origin_session_id` in a prompt turn) with a **`confirm` snippet**: the text names the slice, its
-   status and what you would change — *"Order Placed is in the slice 'Place order', which is Done.
-   Changing it reopens finished work."* — and the snippet's `headline` is the question, with a
-   `yesLabel` that says what happens (*"Yes, change it"*, `noLabel` *"No, leave it"*). When the change is
-   several edits, a `changes` snippet (title = element as link, slice, before/after, one confirm) shows
-   exactly what will be touched instead.
-3. **Reply `DONE`** — a turn that asked is finished; the question is the result. **No `COMMENT` on the
-   slice, not now and not instead of asking** — the snippet in the chat is the only thing you post.
-4. **The click arrives as a `CHAT` turn** (`Yes, change it – …` / `Apply changes – …` is a yes, `No, leave it
-   – …` a no). On a yes, create the prompt for exactly the elements you asked about
-   (`originMessageId` = the yes) and **write the confirmation into the prompt's text**: *"The person
-   confirmed changing the locked slice 'Place order' (status Done): …"*. A prompt turn whose text carries
-   that confirmation, with `origin_message_id` pointing at the yes, may change those elements — and only
-   those; any other locked slice still needs its own yes. On a no, acknowledge in a line and drop it.
-   Not clearly a yes? Ask again, don't change it.
-
 ## Standalone board-change turns — see `CLAUDE-STANDALONE.md`
 
 These turns start with `BOARD_CHANGE` (the board changed) or `BOARD_REVIEW` (nothing has changed