@eventmodelers/cli 1.0.156 → 1.0.158

package/README.md

@@ -202,7 +202,7 @@ and the agent starts building — `--local` skips platform config and credential
 
 **Backend → UI handover.** Besides the usual statuses a slice can be `Ready` (modeling done, waiting to be planned) and `Handover` (backend built, UI contract published, waiting for the UI kit). The flow is `Ready → Planned → InProgress → Handover → InProgress → Done`. Install with `init --handover` (or `re-init --handover`; switch later with `eventmodelers config --handover on|off`; for a single run `run --handover` overrides the setting without saving anything), which saves `"handover": true` in `.eventmodelers/config.json` — then a backend kit ends STATE_VIEW / STATE_CHANGE slices at `Handover` instead of `Done` (the `ui-contract` skill, Step 4, owns that rule); without the flag nothing changes: slices end at `Done`, exactly as before. A kit claims work from the status named in its `lib/kit.json` — `{ "pickupStatus": "Handover" }` for the `react` / `supabase-react` UI kits, absent (= `Planned`) for backend kits. A new UI kit ships that file and sets `Done` when its half is built; a new backend kit just invokes `ui-contract`. Needs a platform with the `Ready` / `Handover` statuses.
 
-**UI contract.** The scaffolded `build-state-view` / `build-state-change` skills already end by invoking the shared `ui-contract` skill, which publishes each slice's read (`GET`) or write (`POST`) contract — the endpoint's OpenAPI operation, as a ```` ```yaml ui-contract ```` block — as a `## UI Contract` section in the slice's feedback-lane markdown node (exported in `slice.json` `notes[]`, so a UI build kit can look it up directly). Two things are yours to decide: *where the contract is derived from* (point the `UI Contract` section of those skills at your stack's machine-readable API description, if it has one — the `node`/`supabase` stacks use their `@openapi` blocks via a `ui-contract-from-openapi.md` reference, taking the operation verbatim — otherwise the skill writes the equivalent OpenAPI operation from the route code), and, if you need a different shape or location, a whole-skill override: ship `.claude/skills/ui-contract/SKILL.md` in the stack's templates and it replaces the shared one (stack templates are applied after `shared/skills/`).
+**UI contract (handover only).** With handover on, the scaffolded `build-state-view` / `build-state-change` skills end by invoking the shared `ui-contract` skill, which publishes each slice's read (`GET`) or write (`POST`) contract — the endpoint's OpenAPI operation, as a ```` ```yaml ui-contract ```` block — as a `## UI Contract` section in the slice's feedback-lane markdown node (exported in `slice.json` `notes[]`, so a UI build kit can look it up directly). Two things are yours to decide: *where the contract is derived from* (point the `UI Contract` section of those skills at your stack's machine-readable API description, if it has one — the `node`/`supabase` stacks use their `@openapi` blocks via a `ui-contract-from-openapi.md` reference, taking the operation verbatim — otherwise the skill writes the equivalent OpenAPI operation from the route code), and, if you need a different shape or location, a whole-skill override: ship `.claude/skills/ui-contract/SKILL.md` in the stack's templates and it replaces the shared one (stack templates are applied after `shared/skills/`).
 
 Installing both a build stack and `init-modeling` into the same project reuses this one `.eventmodelers/config.json` — run whichever `init` command second and it finds the existing config already satisfies the required fields and skips straight past the credential prompt.
 
@@ -668,7 +668,7 @@ npx @eventmodelers/cli run --handover                 # this run only — writes
 
 | | Handover off (default) | Handover on |
 |---|---|---|
-| Backend kit, STATE_VIEW / STATE_CHANGE slice | ends at `Done` | publishes the UI contract, ends at `Handover` |
+| Backend kit, STATE_VIEW / STATE_CHANGE slice | ends at `Done`, no UI contract published | publishes the UI contract, ends at `Handover` |
 | Backend kit, automation / translation | `Done` | `Done` — no UI counterpart |
 | UI kit (`react`, `supabase-react`) | claims `Handover` only | claims `Handover` only, sets `Done` when its UI is built |
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@eventmodelers/cli",
-  "version": "1.0.156",
+  "version": "1.0.158",
   "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/skills/load-slice/SKILL.md

@@ -22,7 +22,28 @@ If neither is provided, load and persist all slices without filtering.
 
 ---
 
-## Step 2 — Fetch all slices from the slicedata API
+## Step 2 — Fetch the slice(s) from the slicedata API
+
+### When `sliceId` is given: fetch exactly that one slice — never all
+
+Do **not** fetch the board's full slice data, and do not loop over contexts. Only the one slice's full
+definition is fetched, and only that one is persisted in Step 3:
+
+1. **Context known?** If the caller passed a `contextId` (or the chapter id), skip to 3.
+2. **Otherwise locate it with one summary call** — `list_slices { "boardId": "<BOARD_ID>" }` (or the
+   `slicedata/slices` curl below). This is a lookup only: take the entry whose `id === sliceId` and read
+   its `contextName`. Don't persist or fan out over the rest of the list. If the id isn't in the list, stop
+   and report it.
+3. **Resolve the context id unambiguously** (see "A name is not a safe key" below — chapters can share a
+   title), then fetch the full slice with one call:
+   `get_slice_data { "boardId": "<BOARD_ID>", "contextId": "<contextId>", "sliceId": "<sliceId>" }`
+   (curl: `GET …/slicedata?contextId=<contextId>&sliceId=<sliceId>`).
+4. `ALL_SLICES` is then just that one slice; Step 3 persists only it.
+
+A `sliceTitle` without an id is resolved to an id via the same one summary call (stop and ask if the
+title matches more than one slice), then continues from step 3.
+
+### When neither is given: load all slices
 
 Prefer the MCP tool when `mcp__eventmodelers__*` tools are visible in this session:
 
@@ -40,6 +61,22 @@ This call stays full (no `projection`): Step 3 persists the complete slice objec
 
 (`get_slice_data` requires a `contextName` or `contextId`. If the context isn't already known, list the context names in one call — `mcp__eventmodelers__get_nodes { "boardId": "<BOARD_ID>", "type": "MODEL_CONTEXT", "projection": "line" }` (only titles needed; a timeline name works as `contextName` too, so fall back to `type: "CHAPTER"` with `projection: "line"` when there are no MODEL_CONTEXT nodes) — then map slices to contexts with `list_slices { "boardId": "<BOARD_ID>", "contextName": "<name>" }` per context. Don't `get_node` each `SLICE_BORDER`.)
 
+**A name is not a safe key — chapters and contexts can share a title.** The backend resolves `contextName`
+to the *first* chapter/context whose title matches (case-insensitive) and silently returns nothing
+if that one holds no slices — even when a same-titled twin holds them. A `SLICE_NOT_FOUND` (404) or an
+empty `slices: []` for a slice that `list_slices` clearly shows is therefore **not** proof the slice is
+missing. Before trusting it:
+
+1. List the chapters (`get_nodes { "boardId": "<BOARD_ID>", "type": "CHAPTER", "projection": "line" }`)
+   and the MODEL_CONTEXT nodes. If two or more share the title in question, **warn in the output**
+   (`Duplicate chapter title "<title>": <id1>, <id2>`) and retry the full fetch with **`contextId`**
+   set to each candidate id until the slice is found — `contextId` is matched exactly, so it is
+   unambiguous.
+2. Only if it is not found under any candidate id is the slice really absent.
+
+Prefer `contextId` over `contextName` whenever the id is known (a calling harness that already has the
+chapter id, or the list entry's `contextId`).
+
 **Fallback (no MCP):**
 
 ```bash
@@ -57,7 +94,22 @@ Save the full array as `ALL_SLICES`.
 
 ## Step 3 — Persist slices to .build-kit/.slices/ directory
 
-Apply the following logic for every slice in `ALL_SLICES`.
+Apply the following logic for every slice in `ALL_SLICES` — **or, when `sliceId`/`sliceTitle` was given,
+only for that one slice** (and only its own context's `index.json`). Don't rewrite 90 other slices'
+folders and indexes to load one; they may hold uncommitted local changes.
+
+**`slice.json` must be the full slice, never the list entry.** The `list_slices` / `slicedata/slices`
+payload is a summary (id, title, status, type, context name — no commands, events, fields, specs or
+comments). If the full fetch (Step 2) for a requested slice failed or came back without elements, do
+**not** write the summary as `slice.json` — it reads as an empty slice and has made agents conclude
+"nothing to build". Stop and report the failed fetch instead (see the duplicate-title handling in Step 2).
+
+**Check for collisions before writing.** Two slices in one `<contextSlug>` whose `<sliceFolder>` is
+identical (same title, or titles differing only by spaces/case) would overwrite each other, and so
+would two contexts that slugify identically. Detect this before writing; on a collision, don't write
+either, and report it: `Slice folder collision in <contextSlug>: "<title>" (<idA>, <status>) vs
+"<title>" (<idB>, <status>)`. Also report same-titled slices that don't collide (different contexts) as
+a one-line warning, so callers address slices by id.
 
 ### Derive paths
 
@@ -132,7 +184,9 @@ If `sliceId` was given: find the entry in `ALL_SLICES` where `id === sliceId`.
 If `sliceTitle` was given: find the entry where `title` matches case-insensitively.  
 If neither: return all slices.
 
-If a specific slice was requested but not found, stop and list the available titles.
+If a specific slice was requested but not found, stop and list the available titles — after ruling out the
+duplicate-chapter-title case from Step 2. If several slices share the requested title, don't pick one:
+list them with their ids, contexts and statuses and ask the caller to choose by id.
 
 ---
 
@@ -157,4 +211,11 @@ All slices (<count>) — context: <contextSlug>:
   - ...
 ```
 
+Append any warnings collected above (duplicate chapter titles, same-titled slices, folder collisions):
+
+```
+Warnings:
+  - Duplicate chapter title "Teams": d151f017-… , e985e6b3-… (slice found under e985e6b3-…)
+```
+
 Make the matched slice's `id`, `title`, `status`, and local folder path available to subsequent steps in the same session.

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

@@ -71,6 +71,37 @@ Find the slice whose `title` matches `sliceName` (case-insensitive), or whose `i
 If no match is found, stop and list the available slice titles so the caller can pick one. Save the
 matched slice's `id` as `SLICE_NODE_ID` and its current `status` as `CURRENT_STATUS`.
 
+## Step 2.5 — Verify the slice is really empty, and check for duplicate names
+
+"The slice has no elements" is the most common reason to block — and also the easiest to get wrong.
+The backend resolves `contextName` to the *first* chapter/context with a matching title, so when two
+chapters share a title, `slicedata?contextName=…` (and `slicedata/slices?contextName=…`) can return
+nothing for a slice that is fully modeled under the twin. A comment claiming "no elements" then
+blocks a healthy slice. Before posting anything:
+
+1. **Fetch the slice by id, not by name.** Resolve the slice's chapter/context id and call
+   `get_slice_data { "boardId": "<BOARD_ID>", "contextId": "<id>", "sliceId": "<SLICE_NODE_ID>" }`
+   (curl: `GET …/slicedata?contextId=<id>&sliceId=<SLICE_NODE_ID>`). Fetch only this one slice.
+2. **Check for duplicate chapter/context titles.** List chapters and MODEL_CONTEXT nodes
+   (`get_nodes { "boardId": "<BOARD_ID>", "type": "CHAPTER", "projection": "line" }`, and likewise
+   `MODEL_CONTEXT`). If two or more share the slice's chapter/context title (case-insensitive), retry
+   step 1 with each candidate `contextId` before concluding the slice is empty.
+3. **Check for duplicate slice names.** From the `list_slices` result, note any other slice with the
+   same title (case-insensitive) — in the same or another context — with its id and status.
+4. **Decide:**
+   - The slice has elements under some candidate id → **do not block, do not comment.** The "empty"
+     reading was a lookup artefact; go back and build using the correct `contextId`. Report the
+     duplicate-title problem to the caller instead.
+   - The slice really is empty (or contradictory) under every candidate → continue to Step 3, and
+     **name every duplicate you found in the question**, e.g. `Note: 2 timelines are titled "Teams"
+     (d151f017-…, e985e6b3-…) and a slice "Add Team" also exists in <context> (<id>, <status>) — please
+     check the content isn't under the twin.` so the human can tell a genuinely empty slice from a
+     misplaced one.
+   - Duplicates exist but the cause of the block is unrelated (e.g. a contradiction between two
+     specs): still mention them in the report (Step 5), not necessarily in the comment.
+
+---
+
 ## Step 3 — Post the comment
 
 There is no separate `QUESTION` type at the API level — post a normal `COMMENT` worded as a question.
@@ -138,6 +169,7 @@ Do not continue implementing the slice after this. Report back to whoever invoke
 Requested feedback on slice "<sliceName>" (<SLICE_NODE_ID>)
 Question posted: "<question>"
 Status: <CURRENT_STATUS> → Blocked
+Duplicates: <none | duplicate chapter titles "<title>" (<ids>) | same-titled slices "<title>" (<id> <status>, …)>
 ```
 
 Then stop work on this slice for this run. If the caller has other, unrelated slices queued, it may

package/shared/skills/ui-contract/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ui-contract
-description: Publish the slice's UI contract — the OpenAPI operation of its endpoint (read = GET, write/state-change = POST) — as its own `## UI Contract` section in the slice's MARKDOWN node in the feedback lane, which the slice export carries in `slice.json` `notes[]` — so the UI build kit finds the contract in one lookup instead of parsing the whole note. Called by every build-state-view / build-state-change skill after the endpoint is built. A build kit can override it by shipping its own `ui-contract` skill.
+description: When handover is on (`run --handover`), publish the slice's UI contract — the OpenAPI operation of its endpoint (read = GET, write/state-change = POST) — as its own `## UI Contract` section in the slice's MARKDOWN node in the feedback lane, which the slice export carries in `slice.json` `notes[]` — so the UI build kit finds the contract in one lookup instead of parsing the whole note. Called by every build-state-view / build-state-change skill after the endpoint is built. A build kit can override it by shipping its own `ui-contract` skill.
 ---
 
 # UI Contract
@@ -18,6 +18,8 @@ records that as a contract — the endpoint's **OpenAPI operation**, one per sli
 
 ## When
 
+**Only when handover is on** — the task request's `Handover: on|off` line (authoritative; the runner resolves `run --handover` over the project setting), else `"handover": true` in `.eventmodelers/config.json`. With handover **off/unset**, do nothing: publish no contract, write no `## UI Contract` section, and finish the slice as `Done` (Step 4). The contract exists only for the UI kit that picks up `Handover` slices.
+
 At the end of building a slice, **after** the endpoint exists (so the contract describes the real
 route, not the plan), before the final commit:
 

package/stacks/axon/templates/.claude/skills/build-state-change/SKILL.md

@@ -437,7 +437,7 @@ leave it undocumented rather than fabricating an assertion.
 
 ## UI Contract
 
-Once the command endpoint is built, invoke the `ui-contract` skill (write contract, `POST`): it publishes
+**Only when handover is on** (the task's `Handover: on` line, else `"handover": true` in `.eventmodelers/config.json`; with it off, skip this section): once the command endpoint is built, invoke the `ui-contract` skill (write contract, `POST`): it publishes
 the endpoint's contract as the `## UI Contract` section of the slice's feedback-lane markdown node, which the slice export then carries in `slice.json` `notes[]`. Do not restate the format here — the skill owns it
 (a build kit may override it).
 

package/stacks/axon/templates/.claude/skills/build-state-view/SKILL.md

@@ -321,7 +321,7 @@ class {SliceName}ProjectorTest {
 
 ## UI Contract
 
-Once the read endpoint is built, invoke the `ui-contract` skill (read contract, `GET`): it publishes
+**Only when handover is on** (the task's `Handover: on` line, else `"handover": true` in `.eventmodelers/config.json`; with it off, skip this section): once the read endpoint is built, invoke the `ui-contract` skill (read contract, `GET`): it publishes
 the endpoint's contract as the `## UI Contract` section of the slice's feedback-lane markdown node, which the slice export then carries in `slice.json` `notes[]`. Do not restate the format here — the skill owns it
 (a build kit may override it).
 

package/stacks/axon/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
 10. The slice in the json is always true, the code follows what is defined in the json
 11. slice is only 'Done' if business logic is implemented as defined in the JSON, APIs are implemented, all scenarios in  JSON are implemented in code and it
     fulfills the slice.json. There must be no specification in json, that has no equivalent in code.
-12. Invoke the `ui-contract` skill for STATE_VIEW / STATE_CHANGE slices (publishes the UI Contract section to the slice's feedback-lane markdown node)
+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 — it is enough to run the tests for the slice only, not all tests:
     - Compile: `./mvnw compile -q`
     - Test:    `./mvnw test -Dtest="<SliceName>*" -q`

package/stacks/blank/templates/.claude/skills/build-state-change/SKILL.md

@@ -44,7 +44,7 @@ TODO — this stack's build command and how to run only this slice's tests (not
 
 ## UI Contract
 
-Once the command endpoint is built, invoke the `ui-contract` skill (write contract, `POST`): it publishes the contract
+**Only when handover is on** (the task's `Handover: on` line, else `"handover": true` in `.eventmodelers/config.json`; with it off, skip this section): once the command endpoint is built, invoke the `ui-contract` skill (write contract, `POST`): it publishes the contract
 as the `## UI Contract` section of the slice's feedback-lane markdown node, which the slice export then carries in `slice.json` `notes[]`. Do not restate the format here — the skill owns it.
 
 TODO — **Source for this stack:** say where the contract is derived from. If your stack maintains a

package/stacks/blank/templates/.claude/skills/build-state-view/SKILL.md

@@ -43,7 +43,7 @@ TODO — this stack's build command and how to run only this slice's tests (not
 
 ## UI Contract
 
-Once the read endpoint is built, invoke the `ui-contract` skill (read contract, `GET`): it publishes the contract
+**Only when handover is on** (the task's `Handover: on` line, else `"handover": true` in `.eventmodelers/config.json`; with it off, skip this section): once the read endpoint is built, invoke the `ui-contract` skill (read contract, `GET`): it publishes the contract
 as the `## UI Contract` section of the slice's feedback-lane markdown node, which the slice export then carries in `slice.json` `notes[]`. Do not restate the format here — the skill owns it.
 
 TODO — **Source for this stack:** say where the contract is derived from. If your stack maintains a

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

@@ -58,7 +58,7 @@ TODO
 
 ## UI Contract
 
-`build-state-view` and `build-state-change` end by invoking the shared `ui-contract` skill (publishes the
-slice's read/write contract for the UI build kit). Decide for your stack where it is derived from — see
+`build-state-view` and `build-state-change` end by invoking the shared `ui-contract` skill when handover is on (publishes the
+slice's read/write contract for the UI build kit; skipped with handover off). Decide for your stack where it is derived from — see
 the `UI Contract` section of those two skills — or override the skill entirely by shipping
 `.claude/skills/ui-contract/SKILL.md`.

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

@@ -30,7 +30,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 9. Analyze and Implement that single slice, making use of the skills in the skills directory plus your previously collected knowledge. Make a TODO list for what needs to be done, and adjust the implementation according to the JSON definition. Carefully inspect events, fields and compare against the implemented slice. JSON is the desired state. ATTENTION: a "planned" task can also be just added specifications. So always look at the slice itself, but also the specifications. If specifications were added in json which are not on code, you need to add them in code.
 10. The slice in the json is always true, the code follows what is defined in the json
 11. Slice is only 'Done' if business logic is implemented as defined in the JSON, APIs are implemented, all scenarios in JSON are implemented in code and it fulfills the slice.json. There must be no specification in json that has no equivalent in code.
-12. Invoke the `ui-contract` skill for STATE_VIEW / STATE_CHANGE slices (publishes the UI Contract section to the slice's feedback-lane markdown node)
+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. Update the PRD to set `status: Done` for the completed story in index.json **and** update the slice status on the eventmodelers board using the `update-slice-status` skill (or MCP if available). For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to set is `Handover`, not `Done` — see the `ui-contract` skill, Step 4.

package/stacks/classic/templates/.claude/skills/build-state-change/SKILL.md

@@ -103,7 +103,7 @@ After the commit, invoke `/record-evidence`: it writes this slice's element →
 
 ## UI Contract
 
-Once the command endpoint is built, invoke the `ui-contract` skill (write contract, `POST`): it publishes
+**Only when handover is on** (the task's `Handover: on` line, else `"handover": true` in `.eventmodelers/config.json`; with it off, skip this section): once the command endpoint is built, invoke the `ui-contract` skill (write contract, `POST`): it publishes
 the endpoint's contract as the `## UI Contract` section of the slice's feedback-lane markdown node, which the slice export then carries in `slice.json` `notes[]`. Do not restate the format here — the skill owns it
 (a build kit may override it).
 

package/stacks/classic/templates/.claude/skills/build-state-view/SKILL.md

@@ -107,7 +107,7 @@ After the commit, invoke `/record-evidence`: it writes this slice's element →
 
 ## UI Contract
 
-Once the read endpoint is built, invoke the `ui-contract` skill (read contract, `GET`): it publishes
+**Only when handover is on** (the task's `Handover: on` line, else `"handover": true` in `.eventmodelers/config.json`; with it off, skip this section): once the read endpoint is built, invoke the `ui-contract` skill (read contract, `GET`): it publishes
 the endpoint's contract as the `## UI Contract` section of the slice's feedback-lane markdown node, which the slice export then carries in `slice.json` `notes[]`. Do not restate the format here — the skill owns it
 (a build kit may override it).
 

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

@@ -33,7 +33,7 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 9. Analyze and Implement that single slice, making use of the skills in the skills directory plus your previously collected knowledge. Make a TODO list for what needs to be done, and adjust the implementation according to the JSON definition. Carefully inspect events, fields and compare against the implemented slice. JSON is the desired state. ATTENTION: a "planned" task can also be just added specifications. So always look at the slice itself, but also the specifications. If specifications were added in json which are not on code, you need to add them in code.
 10. The slice in the json is always true, the code follows what is defined in the json
 11. Slice is only 'Done' if business logic is implemented as defined in the JSON, APIs are implemented, all scenarios in JSON are implemented in code and it fulfills the slice.json. There must be no specification in json that has no equivalent in code.
-12. Invoke the `ui-contract` skill for STATE_VIEW / STATE_CHANGE slices (publishes the UI Contract section to the slice's feedback-lane markdown node)
+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 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.

package/stacks/kurrent/templates/.claude/skills/build-state-change/SKILL.md

@@ -406,7 +406,7 @@ assertion.
 
 ## UI Contract
 
-Once the command endpoint is built, invoke the `ui-contract` skill (write contract, `POST`): it publishes
+**Only when handover is on** (the task's `Handover: on` line, else `"handover": true` in `.eventmodelers/config.json`; with it off, skip this section): once the command endpoint is built, invoke the `ui-contract` skill (write contract, `POST`): it publishes
 the endpoint's contract as the `## UI Contract` section of the slice's feedback-lane markdown node, which the slice export then carries in `slice.json` `notes[]`. Do not restate the format here — the skill owns it
 (a build kit may override it).
 

package/stacks/kurrent/templates/.claude/skills/build-state-view/SKILL.md

@@ -381,7 +381,7 @@ undocumented rather than fabricating an assertion.
 
 ## UI Contract
 
-Once the read endpoint is built, invoke the `ui-contract` skill (read contract, `GET`): it publishes
+**Only when handover is on** (the task's `Handover: on` line, else `"handover": true` in `.eventmodelers/config.json`; with it off, skip this section): once the read endpoint is built, invoke the `ui-contract` skill (read contract, `GET`): it publishes
 the endpoint's contract as the `## UI Contract` section of the slice's feedback-lane markdown node, which the slice export then carries in `slice.json` `notes[]`. Do not restate the format here — the skill owns it
 (a build kit may override it).
 

package/stacks/kurrent/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
 10. The slice in the json is always true, the code follows what is defined in the json
 11. slice is only 'Done' if business logic is implemented as defined in the JSON, APIs are implemented, all scenarios in  JSON are implemented in code and it
     fulfills the slice.json. There must be no specification in json, that has no equivalent in code.
-12. Invoke the `ui-contract` skill for STATE_VIEW / STATE_CHANGE slices (publishes the UI Contract section to the slice's feedback-lane markdown node)
+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 — it is enough to run the tests for the slice only, not all tests:
     - Compile: `./mvnw compile -q`
     - Test:    `./mvnw test -Dtest="<SliceName>*" -q`

package/stacks/node/templates/.claude/skills/build-state-change/SKILL.md

@@ -419,7 +419,7 @@ import {api as {SliceName}Api} from './slices/{context}/{SliceName}/routes';
 
 ## UI Contract
 
-Once the command endpoint is built, invoke the `ui-contract` skill (write contract, `POST`): it publishes
+**Only when handover is on** (the task's `Handover: on` line, else `"handover": true` in `.eventmodelers/config.json`; with it off, skip this section): once the command endpoint is built, invoke the `ui-contract` skill (write contract, `POST`): it publishes
 the endpoint's contract as the `## UI Contract` section of the slice's feedback-lane markdown node, which the slice export then carries in `slice.json` `notes[]`. Do not restate the format here — the skill owns it
 (a build kit may override it).
 

package/stacks/node/templates/.claude/skills/build-state-view/SKILL.md

@@ -486,7 +486,7 @@ import {api as {SliceName}Api} from './slices/{context}/{SliceName}/routes';
 
 ## UI Contract
 
-Once the read endpoint is built, invoke the `ui-contract` skill (read contract, `GET`): it publishes
+**Only when handover is on** (the task's `Handover: on` line, else `"handover": true` in `.eventmodelers/config.json`; with it off, skip this section): once the read endpoint is built, invoke the `ui-contract` skill (read contract, `GET`): it publishes
 the endpoint's contract as the `## UI Contract` section of the slice's feedback-lane markdown node, which the slice export then carries in `slice.json` `notes[]`. Do not restate the format here — the skill owns it
 (a build kit may override it).
 

package/stacks/node/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
 10. The slice in the json is always true, the code follows what is defined in the json
 11. slice is only 'Done' if business logic is implemented as defined in the JSON, APIs are implemented, all scenarios in  JSON are implemented in code and it
     fulfills the slice.json. There must be no specification in json, that has no equivalent in code.
-12. Invoke the `ui-contract` skill for STATE_VIEW / STATE_CHANGE slices (publishes the UI Contract section to the slice's feedback-lane markdown node)
+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 ( npm run build, npm run test ) - Attention - it´s enough to run the tests for the slice. Do not run all tests.
 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

package/stacks/opencqrs/templates/.claude/skills/build-state-change/SKILL.md

@@ -401,7 +401,7 @@ leave it undocumented rather than fabricating an assertion.
 
 ## UI Contract
 
-Once the command endpoint is built, invoke the `ui-contract` skill (write contract, `POST`): it publishes
+**Only when handover is on** (the task's `Handover: on` line, else `"handover": true` in `.eventmodelers/config.json`; with it off, skip this section): once the command endpoint is built, invoke the `ui-contract` skill (write contract, `POST`): it publishes
 the endpoint's contract as the `## UI Contract` section of the slice's feedback-lane markdown node, which the slice export then carries in `slice.json` `notes[]`. Do not restate the format here — the skill owns it
 (a build kit may override it).
 

package/stacks/opencqrs/templates/.claude/skills/build-state-view/SKILL.md

@@ -344,7 +344,7 @@ test — leave it undocumented in code rather than fabricating an assertion.
 
 ## UI Contract
 
-Once the read endpoint is built, invoke the `ui-contract` skill (read contract, `GET`): it publishes
+**Only when handover is on** (the task's `Handover: on` line, else `"handover": true` in `.eventmodelers/config.json`; with it off, skip this section): once the read endpoint is built, invoke the `ui-contract` skill (read contract, `GET`): it publishes
 the endpoint's contract as the `## UI Contract` section of the slice's feedback-lane markdown node, which the slice export then carries in `slice.json` `notes[]`. Do not restate the format here — the skill owns it
 (a build kit may override it).
 

package/stacks/opencqrs/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
 10. The slice in the json is always true, the code follows what is defined in the json
 11. slice is only 'Done' if business logic is implemented as defined in the JSON, APIs are implemented, all scenarios in  JSON are implemented in code and it
     fulfills the slice.json. There must be no specification in json, that has no equivalent in code.
-12. Invoke the `ui-contract` skill for STATE_VIEW / STATE_CHANGE slices (publishes the UI Contract section to the slice's feedback-lane markdown node)
+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 — it is enough to run the tests for the slice only, not all tests:
     - Compile: `./mvnw compile -q`
     - Test:    `./mvnw test -Dtest="<SliceName>*" -q`

package/stacks/supabase/templates/.claude/skills/build-state-change/SKILL.md

@@ -426,7 +426,7 @@ import {api as {SliceName}Api} from './slices/{context}/{SliceName}/routes';
 
 ## UI Contract
 
-Once the command endpoint is built, invoke the `ui-contract` skill (write contract, `POST`): it publishes
+**Only when handover is on** (the task's `Handover: on` line, else `"handover": true` in `.eventmodelers/config.json`; with it off, skip this section): once the command endpoint is built, invoke the `ui-contract` skill (write contract, `POST`): it publishes
 the endpoint's contract as the `## UI Contract` section of the slice's feedback-lane markdown node, which the slice export then carries in `slice.json` `notes[]`. Do not restate the format here — the skill owns it
 (a build kit may override it).
 

package/stacks/supabase/templates/.claude/skills/build-state-view/SKILL.md

@@ -461,7 +461,7 @@ import {api as {SliceName}Api} from './slices/{context}/{SliceName}/routes';
 
 ## UI Contract
 
-Once the read endpoint is built, invoke the `ui-contract` skill (read contract, `GET`): it publishes
+**Only when handover is on** (the task's `Handover: on` line, else `"handover": true` in `.eventmodelers/config.json`; with it off, skip this section): once the read endpoint is built, invoke the `ui-contract` skill (read contract, `GET`): it publishes
 the endpoint's contract as the `## UI Contract` section of the slice's feedback-lane markdown node, which the slice export then carries in `slice.json` `notes[]`. Do not restate the format here — the skill owns it
 (a build kit may override it).
 

package/stacks/supabase/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
 10. The slice in the json is always true, the code follows what is defined in the json
 11. slice is only 'Done' if business logic is implemented as defined in the JSON, APIs are implemented, all scenarios in  JSON are implemented in code and it
     fulfills the slice.json. There must be no specification in json, that has no equivalent in code.
-12. Invoke the `ui-contract` skill for STATE_VIEW / STATE_CHANGE slices (publishes the UI Contract section to the slice's feedback-lane markdown node)
+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 ( npm run build, npm run test ) - Attention - it´s enough to run the tests for the slice. Do not run all tests.
 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

package/stacks/umadb/templates/.claude/skills/build-state-change/SKILL.md

@@ -366,7 +366,7 @@ fabricating an assertion.
 
 ## UI Contract
 
-Once the command endpoint is built, invoke the `ui-contract` skill (write contract, `POST`): it publishes
+**Only when handover is on** (the task's `Handover: on` line, else `"handover": true` in `.eventmodelers/config.json`; with it off, skip this section): once the command endpoint is built, invoke the `ui-contract` skill (write contract, `POST`): it publishes
 the endpoint's contract as the `## UI Contract` section of the slice's feedback-lane markdown node, which the slice export then carries in `slice.json` `notes[]`. Do not restate the format here — the skill owns it
 (a build kit may override it).
 

package/stacks/umadb/templates/.claude/skills/build-state-view/SKILL.md

@@ -330,7 +330,7 @@ events to it in production exactly as it does for the already-verified slices.
 
 ## UI Contract
 
-Once the read endpoint is built, invoke the `ui-contract` skill (read contract, `GET`): it publishes
+**Only when handover is on** (the task's `Handover: on` line, else `"handover": true` in `.eventmodelers/config.json`; with it off, skip this section): once the read endpoint is built, invoke the `ui-contract` skill (read contract, `GET`): it publishes
 the endpoint's contract as the `## UI Contract` section of the slice's feedback-lane markdown node, which the slice export then carries in `slice.json` `notes[]`. Do not restate the format here — the skill owns it
 (a build kit may override it).
 

package/stacks/umadb/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
 10. The slice in the json is always true, the code follows what is defined in the json
 11. slice is only 'Done' if business logic is implemented as defined in the JSON, APIs are implemented, all scenarios in  JSON are implemented in code and it
     fulfills the slice.json. There must be no specification in json, that has no equivalent in code.
-12. Invoke the `ui-contract` skill for STATE_VIEW / STATE_CHANGE slices (publishes the UI Contract section to the slice's feedback-lane markdown node)
+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 — it is enough to run the tests for the slice only, not all tests:
     - Compile: `./mvnw compile -q`
     - Test:    `./mvnw test -Dtest="<SliceName>*" -q`