@eventmodelers/cli 2.0.56 → 2.0.57

package/README.md

@@ -204,6 +204,8 @@ npx @eventmodelers/cli run --standalone             # same, plus acting on board
 npx @eventmodelers/cli run --standalone --board-id <uuid>  # …from any directory, against any board (see Power users)
 npx @eventmodelers/cli run --id <id> --name <label>  # override this run's agent identity (id + display name); `init --name` persists a name instead
 npx @eventmodelers/cli run --handover               # backend kit, this run only: finish slices that have a UI at `Waiting` instead of `Done` (see Backend → UI handover)
+npx @eventmodelers/cli run --status-trigger Ready  # this run only: pick slices up from `Ready` instead of the kit's default (`Planned` backend, `Waiting` UI kits)
+npx @eventmodelers/cli run --status-target Review   # this run only: record `Review` when a slice is built instead of `Done` (wins over --handover)
 npx @eventmodelers/cli config --handover on|off      # persist that choice for the project (`handover` in .eventmodelers/config.json)
 npx @eventmodelers/cli fetch --context <name>                     # pull full slice detail for one context on the board into <kit-dir>/.slices/
 npx @eventmodelers/cli fetch --context <name> --slice-id <id>     # same, then print just that slice
@@ -830,8 +832,28 @@ Flow: `Ready → Planned → InProgress → Waiting → InProgress → Done`. Pr
 - **The platform must know the `Ready` / `Waiting` statuses.**
 - A kit declares what it claims in `lib/kit.json` — `{ "pickupStatus": "Waiting" }`; absent means `Planned`.
 - `run --status-trigger <status>` overrides that pickup status for a single run (e.g. `--status-trigger Ready`); nothing is saved.
+- `run --status-target <status>` overrides the status the agent records when it finishes a slice (default `Done`, or `Waiting` for a UI-bearing slice with handover on); a stack can declare it as `"targetStatus"` in `lib/kit.json`. Combine with `--status-trigger` for a whole transition, e.g. `--status-trigger Ready --status-target Review`. Nothing is saved.
 - `run --feature <name>` picks up only the slices that belong to that feature (the names set per slice on the board, matched case-insensitively); without it every slice in the pickup status is built. Slices without a feature wait for a run without the flag. Nothing is saved.
 
+#### Choosing the transition (`--status-trigger` / `--status-target`)
+
+Every build run is one status transition: the kit claims slices in a **start** status and the agent records a **target** status when it finishes. Both have defaults and both can be overridden per run.
+
+| | Start (`--status-trigger`) | Target (`--status-target`) |
+|---|---|---|
+| Backend kits | `Planned` | `Done` (`Waiting` for a slice with a UI when handover is on) |
+| UI kits (`react`, `supabase-react`) | `Waiting` | `Done` |
+| Stack default in `lib/kit.json` | `"pickupStatus"` | `"targetStatus"` |
+
+Precedence, highest first: the run flag, then `lib/kit.json`, then the built-in default. An explicit target overrides `--handover`; without one the handover rule applies as before.
+
+```bash
+npx @eventmodelers/cli run --status-trigger Ready --status-target Review   # build Ready slices, hand them to review
+npx @eventmodelers/cli run --status-target Waiting                         # backend: always finish at Waiting, whatever the slice
+```
+
+Notes: both flags apply to that run only and write nothing; status names are the board's (`Created`, `Ready`, `Planned`, `InProgress`, `Waiting`, `Review`, `Done`, `Blocked`, …), and an unknown target is rejected when the agent records it. The runner states an explicit target to the agent as a `Target status: <status>` line in its task. An already-installed kit needs a `re-init` to pick up `--status-target`.
+
 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.
 
 ### Env vars and `--config` (scripted/CI installs)

package/cli.js

@@ -4198,6 +4198,7 @@ credentialFlags(program
   .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 `Waiting` 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, Waiting). Defaults to the kit\'s own pickup status — `Planned` for backend kits, `Handover` for the UI kits. Nothing is written to disk.')
+  .option('--status-target <status>', 'Build kit: the status the agent records when it finishes a slice, for this run only (e.g. Done, Waiting, Review). Defaults to `Done` (`Waiting` for a UI-bearing slice with handover on); overrides both. Pair it with --status-trigger to pick the whole transition, e.g. `--status-trigger Ready --status-target Review`. Nothing is written to disk.')
   .option('--feature <name>', 'Build kit: only pick up slices that belong to this feature (the free-text names set per slice on the board, matched case-insensitively), for this run only. Other slices wait for a run without it or with their own feature. Nothing is written to disk.')
   .option('--prototype', 'Run the local prototype of this folder (set up with `init --prototype`): serves the page in the board\'s player and runs the agent loop — each iteration it reads what Sync, Rebuild and a saved feedback recorded in the control log (.prototype/events/) and works through the requests nobody processed yet: Sync and Rebuild right away (the CLI for a sync, Claude Code for a rebuild), feedback only with --sync, which applies it automatically and writes every model change back to the board, retrying until it lands. Without --sync, feedback waits for /local-prototype-control. The agent runs in a warm Agent Client Protocol session (claude by default; --agent <name> or --acp-cmd pick another), not one process per request. `prototype [--sync]` is the player alone.')
   .option('--port <port>', 'With --prototype: the port to serve on (the next free one is used when it is taken)', (v) => parseInt(v, 10), 4173)
@@ -4525,7 +4526,7 @@ credentialFlags(program
       // path with no stream-json parsing to gate. RALPH_LOCAL is read by ralph.js's startRalph to force
       // the local-only branch even when .eventmodelers/config.json has valid credentials.
       // RALPH_AGENT_ID/RALPH_AGENT_NAME (--id/--name) are read there too.
-      execSync(cmd, { cwd: kitDir, stdio: 'inherit', env: { ...process.env, RALPH_VERBOSE: opts.verbose ? '1' : '', RALPH_SYNC: opts.sync ? '1' : '', RALPH_LOCAL: opts.local ? '1' : '', RALPH_HANDOVER: opts.handover ? '1' : '', RALPH_STATUS_TRIGGER: opts.statusTrigger ? String(opts.statusTrigger).trim() : '', RALPH_FEATURE: opts.feature ? String(opts.feature).trim() : '', EVENTMODELERS_KIT_DIR: kitDir, 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 } : {}), ...(acpAgent ? { RALPH_ACP_AGENT: opts.acpAgent ?? '', RALPH_ACP_CMD: opts.acpCmd ?? '' } : {}) } });
+      execSync(cmd, { cwd: kitDir, stdio: 'inherit', env: { ...process.env, RALPH_VERBOSE: opts.verbose ? '1' : '', RALPH_SYNC: opts.sync ? '1' : '', RALPH_LOCAL: opts.local ? '1' : '', RALPH_HANDOVER: opts.handover ? '1' : '', RALPH_STATUS_TRIGGER: opts.statusTrigger ? String(opts.statusTrigger).trim() : '', RALPH_STATUS_TARGET: opts.statusTarget ? String(opts.statusTarget).trim() : '', RALPH_FEATURE: opts.feature ? String(opts.feature).trim() : '', EVENTMODELERS_KIT_DIR: kitDir, 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 } : {}), ...(acpAgent ? { RALPH_ACP_AGENT: opts.acpAgent ?? '', RALPH_ACP_CMD: opts.acpCmd ?? '' } : {}) } });
     } catch (err) {
       process.exit(err.status || 1);
     }

package/package.json

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

@@ -558,6 +558,20 @@ export function readPickupStatus(kitDir) {
   return 'Planned';
 }
 
+// The status the agent records when it finishes a slice — the other end of pickupStatus. `run --status-target <status>`
+// (RALPH_STATUS_TARGET) wins over a stack's `lib/kit.json` ({ "targetStatus": "..." }); null when neither is set, which
+// leaves the kit's own rule in force (`Done`, or `Waiting` for a UI-bearing slice with handover on). When set it is
+// stated in the task and overrides that rule.
+export function readTargetStatus(kitDir) {
+  const override = (process.env.RALPH_STATUS_TARGET || '').trim();
+  if (override) return canonicalStatus(override);
+  try {
+    const s = JSON.parse(readFileSync(join(kitDir, 'lib', 'kit.json'), 'utf-8')).targetStatus;
+    if (typeof s === 'string' && s.trim()) return canonicalStatus(s.trim());
+  } catch {}
+  return null;
+}
+
 // `run --feature <name>` (RALPH_FEATURE): only slices that belong to this feature are picked up.
 // Matched like the board does — trimmed, case-insensitive. Empty means no filter.
 export function readFeatureFilter() {
@@ -822,14 +836,16 @@ export function createBoard(cfg) {
   };
 }
 
-function taskRequest(planned = null, cfg = null, pickupStatus = 'Planned', queued = null) {
+function taskRequest(planned = null, cfg = null, pickupStatus = 'Planned', queued = null, targetStatus = null) {
   const task = planned
     ? `build the ${pickupStatus} slice "${planned.title}" (id=${planned.id}, context="${planned.ctx}")`
     : `process this queued task (id=${queued?.id}) — the slice change that queued it: ${JSON.stringify(queued?.payload ?? {})}`;
   // 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 Waiting) ignore it.
   const handover = planned && statusKey(pickupStatus) !== 'waiting' ? `\nHandover: ${resolveHandover(cfg) ? 'on' : 'off'}\n` : '';
-  return `\n\n---\n\nYour task now: ${task}, following the instructions above. Start immediately.\n${handover}`;
+  // Only when set explicitly (run flag or kit.json): the agent records exactly this status, handover or not.
+  const target = planned && targetStatus ? `\nTarget status: ${targetStatus}\n` : '';
+  return `\n\n---\n\nYour task now: ${task}, following the instructions above. Start immediately.\n${handover}${target}`;
 }
 
 // The slice-state event store (events/, events.log) holds pids and claims of this checkout and must never be
@@ -932,7 +948,7 @@ async function ralphLoop(kitDir, cfg, onTask, onPlannedSlice, localOnly = false,
         continue;
       }
 
-      const prompt = readFileSync(backendPromptFile, 'utf-8') + taskRequest(planned, cfg, readPickupStatus(kitDir));
+      const prompt = readFileSync(backendPromptFile, 'utf-8') + taskRequest(planned, cfg, readPickupStatus(kitDir), null, readTargetStatus(kitDir));
       if (credentialed) await fetchFullSlice(cfg, kitDir, planned.id);
       // The iteration opens first, so the claim (→ InProgress) is part of what the board's build log shows.
       if (planned.id) share.iterationStarted(planned);

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

@@ -42,7 +42,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
     If the tests for the slice are not yet named predictably, run `./mvnw test -q` and check for failures.
 15. If checks pass, commit ALL changes with message: `feat: [Slice Name]` and merge back to main as FF merge ( update
     first )
-16. Record the outcome with `npx @eventmodelers/cli slice-status Done` — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
+16. Record the outcome with `npx @eventmodelers/cli slice-status Done` (or `<status>` when the task has a `Target status: <status>` line — record exactly that, it overrides everything below) — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
 17. Record any reusable learning you have not recorded yet (see **Recording Learnings**).
 18. If an entry in `.build-kit/AGENTS.md` turned out wrong or obsolete, retract it (see **Recording Learnings**).
 19. Finish the iteration.

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

@@ -32,7 +32,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 12. Only when `handover` is on (the task's `Handover: on` line), invoke the `ui-contract` skill for STATE_VIEW / STATE_CHANGE slices; with handover off skip this step (publishes the UI Contract section to the slice's feedback-lane markdown node)
 13. Run quality checks — TODO: your stack's build command, TODO: your stack's test command (slice-scoped only; do not run all tests).
 14. If checks pass, commit ALL changes with message: `feat: [Slice Name]` and merge back to main as FF merge (update first)
-15. Record the outcome with `npx @eventmodelers/cli slice-status Done` — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
+15. Record the outcome with `npx @eventmodelers/cli slice-status Done` (or `<status>` when the task has a `Target status: <status>` line — record exactly that, it overrides everything below) — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
 16. Record any reusable learning you have not recorded yet (see **Recording Learnings**).
 17. If an entry in `.build-kit/AGENTS.md` turned out wrong or obsolete, retract it (see **Recording Learnings**).
 18. Finish the iteration.

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

@@ -36,7 +36,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 13. Run the quality checks listed in `.build-kit/ARCHITECTURE.md` — build/compile, then only the tests touched by this slice (do not run all tests).
 14. If checks pass, commit ALL changes with message: `feat: [Slice Name]` and merge back to main as FF merge (update first)
 15. Invoke `/record-evidence` to write the implementation evidence (element → code mapping, files, specification → test mapping, seams, assumptions, commit) as a note into the slice's column, in the chapter's `Implementation` feedback lane.
-16. Record the outcome with `npx @eventmodelers/cli slice-status Done` — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
+16. Record the outcome with `npx @eventmodelers/cli slice-status Done` (or `<status>` when the task has a `Target status: <status>` line — record exactly that, it overrides everything below) — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
 17. Record any reusable learning you have not recorded yet (see **Recording Learnings**).
 18. If an entry in `.build-kit/AGENTS.md` turned out wrong or obsolete, retract it (see **Recording Learnings**).
 19. Finish the iteration.

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

@@ -42,7 +42,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
     If the tests for the slice are not yet named predictably, run `./mvnw test -q` and check for failures.
 15. If checks pass, commit ALL changes with message: `feat: [Slice Name]` and merge back to main as FF merge ( update
     first )
-16. Record the outcome with `npx @eventmodelers/cli slice-status Done` — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
+16. Record the outcome with `npx @eventmodelers/cli slice-status Done` (or `<status>` when the task has a `Target status: <status>` line — record exactly that, it overrides everything below) — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
 17. Record any reusable learning you have not recorded yet (see **Recording Learnings**).
 18. If an entry in `.build-kit/AGENTS.md` turned out wrong or obsolete, retract it (see **Recording Learnings**).
 19. Finish the iteration.

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

@@ -48,7 +48,10 @@ for it. Instead:
    you change **nothing** on the board — no element, no screen edit, not even a small one — and only keep your own running
    list of what you would change; the person finishing (`finish` / an `instruction` to post the walkthrough) is the moment to
    post one `walkthrough` snippet (`/walkthrough`, mode impact) of that list. The person is not technical: never ask them
-   anything technical, and never repeat the instruction to them. The one-reply rule of step 4 still holds — the CLI posts a
+   anything technical, and never repeat the instruction to them. **`kind: "ask"`** (with a `topic`) is the wizard asking *you* to word
+   the next question — the chat text is just "Next question, please.": reply with **only that one question** (plain words, at most 25,
+   specific to `storySoFar`), no greeting, no options, no snippet; the wizard shows your reply to the person as the question.
+   The one-reply rule of step 4 still holds — the CLI posts a
    "Sorry, I could not finish" for any chat turn that ends without a reply — but where there is nothing to build (a `choice` or
    `skip`) the reply is one short, friendly sentence that fits what they did — never a bare "Noted.".
    **In `mode: "walkthrough"` the person still sees the proposal take shape**, in the wizard, without the board changing: when an

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

@@ -36,7 +36,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 14. even if the slice is fully implemented, run your test-analyzer skill and provide the code-slice.json file as defined in the skill
 15. If checks pass, commit ALL changes with message: `feat: [Slice Name]` and merge back to main as FF merge ( update
     first )
-16. Record the outcome with `npx @eventmodelers/cli slice-status Done` — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
+16. Record the outcome with `npx @eventmodelers/cli slice-status Done` (or `<status>` when the task has a `Target status: <status>` line — record exactly that, it overrides everything below) — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
 17. Record any reusable learning you have not recorded yet (see **Recording Learnings**).
 18. If an entry in `.build-kit/AGENTS.md` turned out wrong or obsolete, retract it (see **Recording Learnings**).
 19. Finish the iteration.

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

@@ -42,7 +42,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
     If the tests for the slice are not yet named predictably, run `./mvnw test -q` and check for failures.
 15. If checks pass, commit ALL changes with message: `feat: [Slice Name]` and merge back to main as FF merge ( update
     first )
-16. Record the outcome with `npx @eventmodelers/cli slice-status Done` — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
+16. Record the outcome with `npx @eventmodelers/cli slice-status Done` (or `<status>` when the task has a `Target status: <status>` line — record exactly that, it overrides everything below) — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
 17. Record any reusable learning you have not recorded yet (see **Recording Learnings**).
 18. If an entry in `.build-kit/AGENTS.md` turned out wrong or obsolete, retract it (see **Recording Learnings**).
 19. Finish the iteration.

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

@@ -32,7 +32,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 12. Build against the backend slice's published UI contract (see the `ui-contract` skill, "How the UI build kit looks the contract up") — the build-state-view / build-state-change skills say how to apply it
 13. Run quality checks — TODO: your stack's build command, TODO: your stack's test command (slice-scoped only; do not run all tests).
 14. If checks pass, commit ALL changes with message: `feat: [Slice Name]` and merge back to main as FF merge (update first)
-15. Record the outcome with `npx @eventmodelers/cli slice-status Done` — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
+15. Record the outcome with `npx @eventmodelers/cli slice-status Done` (or `<status>` when the task has a `Target status: <status>` line — record exactly that, it overrides everything below) — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
 16. Record any reusable learning you have not recorded yet (see **Recording Learnings**).
 17. If an entry in `.build-kit/AGENTS.md` turned out wrong or obsolete, retract it (see **Recording Learnings**).
 18. Finish the iteration.

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

@@ -36,7 +36,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 14. even if the slice is fully implemented, run your test-analyzer skill and provide the code-slice.json file as defined in the skill
 15. If checks pass, commit ALL changes with message: `feat: [Slice Name]` and merge back to main as FF merge ( update
     first )
-16. Record the outcome with `npx @eventmodelers/cli slice-status Done` — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
+16. Record the outcome with `npx @eventmodelers/cli slice-status Done` (or `<status>` when the task has a `Target status: <status>` line — record exactly that, it overrides everything below) — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
 17. Record any reusable learning you have not recorded yet (see **Recording Learnings**).
  18. If an entry in `.build-kit/AGENTS.md` turned out wrong or obsolete, retract it (see **Recording Learnings**).
 19. Finish the iteration.

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

@@ -32,7 +32,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 12. Build against the backend slice's published UI contract (see the `ui-contract` skill, "How the UI build kit looks the contract up") — the build-state-view / build-state-change skills say how to apply it
 13. Run quality checks — `npm run build` (typecheck + build) and `npm run lint`. No test runner is configured in this stack yet; if a slice's specifications demand behavioral tests, flag it via `request-feedback` instead of inventing a test setup ad hoc.
 14. If checks pass, commit ALL changes with message: `feat: [Slice Name]` and merge back to main as FF merge (update first)
-15. Record the outcome with `npx @eventmodelers/cli slice-status Done` — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
+15. Record the outcome with `npx @eventmodelers/cli slice-status Done` (or `<status>` when the task has a `Target status: <status>` line — record exactly that, it overrides everything below) — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
 16. Record any reusable learning you have not recorded yet (see **Recording Learnings**).
 17. If an entry in `.build-kit/AGENTS.md` turned out wrong or obsolete, retract it (see **Recording Learnings**).
 18. Finish the iteration.

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

@@ -42,7 +42,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
     If the tests for the slice are not yet named predictably, run `./mvnw test -q` and check for failures.
 15. If checks pass, commit ALL changes with message: `feat: [Slice Name]` and merge back to main as FF merge ( update
     first )
-16. Record the outcome with `npx @eventmodelers/cli slice-status Done` — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
+16. Record the outcome with `npx @eventmodelers/cli slice-status Done` (or `<status>` when the task has a `Target status: <status>` line — record exactly that, it overrides everything below) — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
 17. Record any reusable learning you have not recorded yet (see **Recording Learnings**).
 18. If an entry in `.build-kit/AGENTS.md` turned out wrong or obsolete, retract it (see **Recording Learnings**).
 19. Finish the iteration.