@eventmodelers/cli 2.0.1 → 2.0.3

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 `Handover`, 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` — 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.
@@ -64,6 +64,16 @@ npx @eventmodelers/cli learn "<one terse line>" --topic "<topic>"
 - `--scope system` for what is true of the modeled domain (a business rule, a naming convention of the model); `repo` (the default) for the codebase and its tooling. `--tag <tag>` labels it (repeatable).
 - One in `.build-kit/AGENTS.md` that turned out wrong or obsolete: `npx @eventmodelers/cli learnings --ids` lists each with its id, `npx @eventmodelers/cli learn --retract <id>` removes it.
 
+### Recording Info
+
+Something that is **not** a reusable learning — you cannot change something and why, a decision you took, a note for whoever reads the board — is an info, not a learning. Never leave it only in your reply:
+
+```
+npx @eventmodelers/cli info "<one terse line>" --kind limitation|decision|note
+```
+
+It is recorded as an event and posted as a comment on the slice you are building (`--slice <id>` to name another). Reusable knowledge stays a `learn`.
+
 ## Update AGENTS.md Files
 
 Before committing, check if any edited files have learnings worth preserving in nearby AGENTS.md files:

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

@@ -58,6 +58,20 @@ This is the build trigger. Setting `InProgress` and building are one atomic step
 
 4. Invoke the matching skill and follow its instructions **completely**. Do NOT implement the slice manually.
 
+   **Baseline gate** — before touching any code, run `npx @eventmodelers/cli build-baseline check --scope backend`.
+   It compares the board's node hashes of every element of the slice (commands, events, read models,
+   processors, specifications, ...) with what was recorded after the last successful build:
+   - `UNCHANGED` — nothing on the board changed. Do not rebuild or re-diff; run the slice's tests and
+     finish. Only now is "no code changes needed" a valid outcome.
+   - `NO_BASELINE` / `UNKNOWN` — no recorded build, or the board could not be read: do one full
+     field-by-field diff of slice.json against the code (never treat `UNKNOWN` as `UNCHANGED`).
+   - `CHANGED` — it lists the elements that changed, were added or were removed. Diff slice.json
+     against the code for exactly those and fix every drift; leave what matches alone.
+
+   When the checks pass, run `npx @eventmodelers/cli build-baseline record --scope backend` **before
+   committing**, so `ui-baseline.json` is committed with the slice. Never record without having done the
+   work the verdict asked for. Screens and UI prompts are not this kit's business and never trigger a build.
+
 5. **Verify against slice.json**: Cross-check the implementation — every command field, event field, and specification in slice.json must appear in the code. No invented fields — if it is not in slice.json, it must not be in the code.
 
 6. Run quality checks:
@@ -98,6 +112,16 @@ npx @eventmodelers/cli learn "<one terse line>" --topic "<topic>"
 - `--scope system` for what is true of the modeled domain (a business rule, a naming convention of the model); `repo` (the default) for the codebase and its tooling. `--tag <tag>` labels it (repeatable).
 - One in `.build-kit/AGENTS.md` that turned out wrong or obsolete: `npx @eventmodelers/cli learnings --ids` lists each with its id, `npx @eventmodelers/cli learn --retract <id>` removes it.
 
+### Recording Info
+
+Something that is **not** a reusable learning — you cannot change something and why, a decision you took, a note for whoever reads the board — is an info, not a learning. Never leave it only in your reply:
+
+```
+npx @eventmodelers/cli info "<one terse line>" --kind limitation|decision|note
+```
+
+It is recorded as an event and posted as a comment on the slice you are building (`--slice <id>` to name another). Reusable knowledge stays a `learn`.
+
 ## Important
 
 - Process **one task per iteration**.

package/stacks/modeling-kit/templates/.claude/skills/analyze-existing-model/SKILL.md

@@ -39,7 +39,7 @@ Save the full slice list. Count total slices and group by status:
 
 | Status values |
 |---------------|
-| `Created`, `Ready`, `Planned`, `InProgress`, `Handover`, `Review`, `Done`, `Blocked`, `Assigned`, `Informational` |
+| `Created`, `Ready`, `Planned`, `InProgress`, `Waiting`, `Review`, `Done`, `Blocked`, `Assigned`, `Informational` |
 
 ---
 

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

@@ -35,6 +35,8 @@ From `$ARGUMENTS`: the context (a MODEL_CONTEXT name or a timeline name) and opt
 
 The unit is the **effective context**: a timeline assigned to or connected with a MODEL_CONTEXT belongs to that context; a timeline with neither is its own context. Either name returns the whole effective context — every timeline in it, each slice carrying its `chapter`.
 
+**Pass the id, not the name, whenever you have it** — the turn's `timelineId` (or a MODEL_CONTEXT's id) goes straight into `--context "<id>"`. A chapter may have no name at all; never rename a chapter to make the lookup work, and never ask about it.
+
 No context given, or a name that matches nothing: list the options once —
 
 ```

package/stacks/modeling-kit/templates/.claude/skills/prototype/assets/prototype.mjs

@@ -97,10 +97,12 @@ async function status() {
     return res.json();
   };
 
-  const ctx = encodeURIComponent(args.context);
+  // --context is a name, or the id of a MODEL_CONTEXT / timeline (a chapter without a name has only that).
+  const contextIsId = /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i.test(args.context);
+  const ctx = `${contextIsId ? 'contextId' : 'contextName'}=${encodeURIComponent(args.context)}`;
   const [fields, specs] = await Promise.all([
-    get(`/slicedata?contextName=${ctx}&projection=fields&format=json`),
-    get(`/slicedata?contextName=${ctx}&projection=specs&format=json`),
+    get(`/slicedata?${ctx}&projection=fields&format=json`),
+    get(`/slicedata?${ctx}&projection=specs&format=json`),
   ]);
   const specsById = Object.fromEntries((specs.slices || []).map((s) => [s.id, s]));
 
@@ -127,7 +129,7 @@ async function status() {
   // The baseline whose blocks can be kept: the page the platform stores for this context — what everyone
   // plays, and there in any session or folder (its sanitizer leaves the blocks byte for byte) — else a
   // local one, from an earlier run whose upload failed. Neither: every slice is new.
-  const contextId = args['context-id'] || (await contextIdOf(get, args.context));
+  const contextId = contextIsId ? args.context : await contextIdOf(get, args.context);
   const storedRes = await fetch(`${api}/prototype/${encodeURIComponent(contextId)}`, { headers });
   if (!storedRes.ok && storedRes.status !== 404) fail(`GET /prototype/${contextId} → ${storedRes.status} ${await storedRes.text()}`);
   const stored = storedRes.ok ? await storedRes.text() : null;
@@ -158,7 +160,7 @@ async function status() {
   const removed = existing.filter((b) => !current.has(b.id)).map(({ id, title }) => ({ id, title }));
   const cssFramework = Object.entries(frameworkVotes).sort((a, b) => b[1] - a[1])[0]?.[0] || 'bulma';
 
-  const report = { context: args.context, contextId, baseline, cssFramework, mixedFrameworks: Object.keys(frameworkVotes).length > 1, slices, removed };
+  const report = { context: fields.contextName || args.context, contextId, baseline, cssFramework, mixedFrameworks: Object.keys(frameworkVotes).length > 1, slices, removed };
   writeFileSync(join(WORK, 'status.json'), JSON.stringify(report, null, 2));
   for (const s of slices) console.log(`${s.state.padEnd(9)} ${s.hash}  ${s.id}  ${s.title}`);
   for (const r of removed) console.log(`removed   ${''.padEnd(16)}  ${r.id}  ${r.title}`);

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

@@ -199,7 +199,7 @@ Steps:
    ever get here in a `standalone=on` session, which is ad-hoc: its kit dir is shared across
    every board and nobody reads it afterwards. The board is the only place anything is kept, so
    anything reusable — including what a subagent reported back — goes there, as a comment on the
-   node it concerns.
+   node it concerns. The exception: end the reply with `Info [limitation|decision|note]: <one terse line>` for anything you could not change (and why) or decided — the CLI records it as an event, standalone included.
 8. Reply `<promise>DONE</promise>`, naming what you dispatched and what each agent did, or —
    when step 2 turned up nothing worth doing — change nothing at all and reply
    `<promise>NOOP</promise>`. A NOOP is a perfectly good outcome, and the CLI widens the gap

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

@@ -19,7 +19,7 @@ session: it belongs to no project, its kit dir is a `~/.eventmodelers/kit` share
 and nobody goes looking in there afterwards. So in a `standalone=on` session the **board is the
 only place anything is kept** — comments, elements, slice statuses, scenarios. Write no file at
 all: no `Learning:` lines in your reply (step 8), no `.agent-modeling-kit/AGENTS.md`, and nothing a skill's
-own instructions suggest writing down either. Anything worth keeping goes on the board, as a
+own instructions suggest writing down either. The one exception is `Info [kind]:` lines (step 8): the CLI records those as events in every session, standalone included. Anything worth keeping goes on the board, as a
 comment on the node it concerns. This overrides every "write it down" instruction elsewhere in this
 file and in any skill.
 
@@ -151,6 +151,7 @@ mention it in the `DONE` comment, and leave it for a self-directed turn (or for
 6. **Mark the prompt as finished** — invoke `/update-prompt-status` with this turn's `prompt_id`, `newStatus=DONE`, and a `comment` that summarizes what you actually did (e.g. "Added the OrderPlaced event and wired it to the read model"). Do this once, right after the work is done — not per skill call within the turn.
 7. If this turn has a `comment_id` field, invoke `/handle-comment` with `action=resolve`, `nodeId` from the resolved `NODE_ID` (step 3), `commentId` from `comment_id`.
 8. **`standalone=off` only** — if you noticed something reusable this turn (a pattern, a gotcha, useful context about this model), end your reply with one line per learning: `Learning [<topic>]: <one terse line>` (the topic is optional, at most five lines). The CLI records them — never write them into a file yourself, and add nothing that is already in `.agent-modeling-kit/AGENTS.md`. In a `standalone=on` session skip this: that session writes no files (see Mode), so note anything worth keeping as a board comment instead.
+   **In every session, `standalone=on` too:** anything that is *not* a reusable learning — something you could not change and why, a decision you took — goes the same way as `Info [limitation|decision|note]: <one terse line>` (at most five lines). The CLI records each as an event; never leave it only in prose.
 9. Reply `<promise>DONE</promise>` and wait for the next turn.
 
 
@@ -165,10 +166,13 @@ form, do the work another way or tell the person what you can't do.
   `$TOKEN` / `$EVENTMODELERS_TOKEN` only in a `-H` header; uuids with `uuidgen`, `$(uuidgen)`,
   `for i in $(seq <n>); do uuidgen; done` or `python3 -c` using only `uuid.uuid4()`; `jq`; `python3 -m json.tool`;
   read-only `git` (`git -C <code dir> …`); `cat`/`head`/`tail`/`wc`/`sort`/`uniq`/`grep`/`cut`/`tr`/`ls`, `echo`,
-  `printf`, `mkdir`; `for NAME in …; do …; done` loops over these. No other `$(…)`, no `while`/`if`, other `python3`
-  scripts, `node`, `rm`, `cd`. Build a JSON payload with the Write tool in `/tmp`, then
+  `printf`, `mkdir`; `for NAME in …; do …; done` loops over these. `node` runs exactly one script, the `/prototype`
+  skill's `node .claude/skills/prototype/assets/prototype.mjs status|assemble|upload …` (relative path, no `cd`; the
+  skill gives the flags) — try it, don't assume it is refused. No other `$(…)`, no `while`/`if`, other `python3`
+  scripts, other `node`, `rm`, `cd`. Build a JSON payload with the Write tool in `/tmp`, then
   `curl … --data-binary @/tmp/<file>.json`.
-- **Files:** read and write in this directory and `/tmp`, read the code directory. Never `.claude/`, `.mcp.json`,
+- **Files:** read and write in this directory and `/tmp`, read the code directory. Reading `.claude/skills/` is fine
+  (skills' templates and assets); never edit `.claude/`, never read `.claude/settings*.json`, `.mcp.json`,
   `.eventmodelers/*.json` or `.env` files (`.eventmodelers/interviews/` is fine). No web access.
 
 ## Chat turns — `CHAT`
@@ -254,7 +258,9 @@ for it. Instead:
      however small** — never change the board in a chat turn. Create one `create_prompt` per
      independent piece of work, each with `originMessageId` = this turn's `message_id` (for a
      confirmation, that is the yes), phrased so
-     the prompt turn can do it on its own (element names, chapter). The context and a handed-over
+     the prompt turn can do it on its own (element names, chapter). A prompt needs a chapter: if the
+     board has none (no `timelineId` in the header, `get_chapter_bounds` empty), call `create_chapter`
+     yourself first and pass its id as `timelineId` — never ask the person to add one. The context and a handed-over
      comment (`comment_id`) carry over from the message by themselves. The prompts are addressed to
      you and are worked right after this turn.
 4. **Reply exactly once** — `post_chat_message` with `replyTo` = this turn's `message_id`. It is the

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

@@ -48,9 +48,10 @@ When asked to build a slice, always follow this flow:
    - **State-view** — `projections` or `queries` array is non-empty → invoke `/build-state-view`
    - **State-change** — default (has `commands` / `events`) → invoke `/build-state-change`
 3. Invoke the matching skill and follow its instructions completely. Do not deviate.
-4. **Verify against slice.json**: After the skill completes, check that every command field, event field, and specification in slice.json appears in the implementation. No invented fields — if it is not in slice.json, it must not be in the code. This applies even when the slice was previously `Done` and reappears as `Planned` — never dismiss a mismatch as "already implemented" or harmless drift; diff slice.json against the code field by field and update the code to match every change.
-5. Run quality checks (`npm run build`, then the slice tests only).
-6. If checks pass, commit with `feat: [Slice Name]` and set slice status to `Done`. 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.
+4. **Baseline gate**: run `npx @eventmodelers/cli build-baseline check --scope backend` first and act only on its verdict — `UNCHANGED` means nothing on the board changed since the last recorded build: do not rebuild, just run the slice's tests and finish; `NO_BASELINE`/`UNKNOWN` mean one full field-by-field diff of slice.json against the code; `CHANGED` (`ELEMENTS_CHANGED`) means the same diff, to fix every drift. After the checks pass and before committing, run `build-baseline record --scope backend`. A screen or UI prompt change never triggers a backend build.
+5. **Verify against slice.json**: After the skill completes, check that every command field, event field, and specification in slice.json appears in the implementation. No invented fields — if it is not in slice.json, it must not be in the code. This applies even when the slice was previously `Done` and reappears as `Planned` — never dismiss a mismatch as "already implemented" or harmless drift; diff slice.json against the code field by field and update the code to match every change.
+6. Run quality checks (`npm run build`, then the slice tests only).
+7. If checks pass, commit with `feat: [Slice Name]` and set slice status to `Done`. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to set is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4.
 
 After you are done, automatically run the tests for the slice that was edited.
 

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 `Handover`, 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` — 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.
@@ -58,6 +58,16 @@ npx @eventmodelers/cli learn "<one terse line>" --topic "<topic>"
 - `--scope system` for what is true of the modeled domain (a business rule, a naming convention of the model); `repo` (the default) for the codebase and its tooling. `--tag <tag>` labels it (repeatable).
 - One in `.build-kit/AGENTS.md` that turned out wrong or obsolete: `npx @eventmodelers/cli learnings --ids` lists each with its id, `npx @eventmodelers/cli learn --retract <id>` removes it.
 
+### Recording Info
+
+Something that is **not** a reusable learning — you cannot change something and why, a decision you took, a note for whoever reads the board — is an info, not a learning. Never leave it only in your reply:
+
+```
+npx @eventmodelers/cli info "<one terse line>" --kind limitation|decision|note
+```
+
+It is recorded as an event and posted as a comment on the slice you are building (`--slice <id>` to name another). Reusable knowledge stays a `learn`.
+
 ## Update AGENTS.md Files
 
 Before committing, check if any edited files have learnings worth preserving in nearby AGENTS.md files:

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

@@ -94,6 +94,16 @@ npx @eventmodelers/cli learn "<one terse line>" --topic "<topic>"
 - `--scope system` for what is true of the modeled domain (a business rule, a naming convention of the model); `repo` (the default) for the codebase and its tooling. `--tag <tag>` labels it (repeatable).
 - One in `.build-kit/AGENTS.md` that turned out wrong or obsolete: `npx @eventmodelers/cli learnings --ids` lists each with its id, `npx @eventmodelers/cli learn --retract <id>` removes it.
 
+### Recording Info
+
+Something that is **not** a reusable learning — you cannot change something and why, a decision you took, a note for whoever reads the board — is an info, not a learning. Never leave it only in your reply:
+
+```
+npx @eventmodelers/cli info "<one terse line>" --kind limitation|decision|note
+```
+
+It is recorded as an event and posted as a comment on the slice you are building (`--slice <id>` to name another). Reusable knowledge stays a `learn`.
+
 ## Important
 
 - Process **one task per iteration**.

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

@@ -73,13 +73,14 @@ When asked to build a slice, always follow this flow:
    - **State-view** — `projections` or `queries` array is non-empty → invoke `/build-state-view`
    - **State-change** — default (has `commands` / `events`) → invoke `/build-state-change`
 3. Invoke the matching skill and follow its instructions completely. Do not deviate.
-4. **Verify against slice.json**: After the skill completes, check that every command field, event field,
+4. **Baseline gate**: run `npx @eventmodelers/cli build-baseline check --scope backend` first and act only on its verdict — `UNCHANGED` means nothing on the board changed since the last recorded build: do not rebuild, just run the slice's tests and finish; `NO_BASELINE`/`UNKNOWN` mean one full field-by-field diff of slice.json against the code; `CHANGED` lists exactly which elements changed, were added or removed — diff and fix only those. After the checks pass and before committing, run `build-baseline record --scope backend`. A screen or UI prompt change never triggers a backend build.
+5. **Verify against slice.json**: After the skill completes, check that every command field, event field,
    and specification in slice.json appears in the implementation. No invented fields — if it is not in
    slice.json, it must not be in the code. This applies even when the slice was previously `Done` and
    reappears as `Planned` — never dismiss a mismatch as "already implemented" or harmless drift; diff
    slice.json against the code field by field and update the code to match every change.
-5. Run quality checks (`./mvnw compile -q`, then the slice tests only).
-6. If checks pass, commit with `feat: [Slice Name]` and set slice status to `Done`. 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.
+6. Run quality checks (`./mvnw compile -q`, then the slice tests only).
+7. If checks pass, commit with `feat: [Slice Name]` and set slice status to `Done`. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to set is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4.
 
 After you are done, automatically run the tests for the slice that was edited.
 

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 `Handover`, 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` — 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.
@@ -64,6 +64,16 @@ npx @eventmodelers/cli learn "<one terse line>" --topic "<topic>"
 - `--scope system` for what is true of the modeled domain (a business rule, a naming convention of the model); `repo` (the default) for the codebase and its tooling. `--tag <tag>` labels it (repeatable).
 - One in `.build-kit/AGENTS.md` that turned out wrong or obsolete: `npx @eventmodelers/cli learnings --ids` lists each with its id, `npx @eventmodelers/cli learn --retract <id>` removes it.
 
+### Recording Info
+
+Something that is **not** a reusable learning — you cannot change something and why, a decision you took, a note for whoever reads the board — is an info, not a learning. Never leave it only in your reply:
+
+```
+npx @eventmodelers/cli info "<one terse line>" --kind limitation|decision|note
+```
+
+It is recorded as an event and posted as a comment on the slice you are building (`--slice <id>` to name another). Reusable knowledge stays a `learn`.
+
 ## Update AGENTS.md Files
 
 Before committing, check if any edited files have learnings worth preserving in nearby AGENTS.md files:

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

@@ -58,6 +58,20 @@ This is the build trigger. Setting `InProgress` and building are one atomic step
 
 4. Invoke the matching skill and follow its instructions **completely**. Do NOT implement the slice manually.
 
+   **Baseline gate** — before touching any code, run `npx @eventmodelers/cli build-baseline check --scope backend`.
+   It compares the board's node hashes of every element of the slice (commands, events, read models,
+   processors, specifications, ...) with what was recorded after the last successful build:
+   - `UNCHANGED` — nothing on the board changed. Do not rebuild or re-diff; run the slice's tests and
+     finish. Only now is "no code changes needed" a valid outcome.
+   - `NO_BASELINE` / `UNKNOWN` — no recorded build, or the board could not be read: do one full
+     field-by-field diff of slice.json against the code (never treat `UNKNOWN` as `UNCHANGED`).
+   - `CHANGED` — it lists the elements that changed, were added or were removed. Diff slice.json
+     against the code for exactly those and fix every drift; leave what matches alone.
+
+   When the checks pass, run `npx @eventmodelers/cli build-baseline record --scope backend` **before
+   committing**, so `ui-baseline.json` is committed with the slice. Never record without having done the
+   work the verdict asked for. Screens and UI prompts are not this kit's business and never trigger a build.
+
 5. **Verify against slice.json**: Cross-check the implementation — every command field, event field, and specification in slice.json must appear in the code. No invented fields — if it is not in slice.json, it must not be in the code.
 
 6. Run quality checks:
@@ -98,6 +112,16 @@ npx @eventmodelers/cli learn "<one terse line>" --topic "<topic>"
 - `--scope system` for what is true of the modeled domain (a business rule, a naming convention of the model); `repo` (the default) for the codebase and its tooling. `--tag <tag>` labels it (repeatable).
 - One in `.build-kit/AGENTS.md` that turned out wrong or obsolete: `npx @eventmodelers/cli learnings --ids` lists each with its id, `npx @eventmodelers/cli learn --retract <id>` removes it.
 
+### Recording Info
+
+Something that is **not** a reusable learning — you cannot change something and why, a decision you took, a note for whoever reads the board — is an info, not a learning. Never leave it only in your reply:
+
+```
+npx @eventmodelers/cli info "<one terse line>" --kind limitation|decision|note
+```
+
+It is recorded as an event and posted as a comment on the slice you are building (`--slice <id>` to name another). Reusable knowledge stays a `learn`.
+
 ## Important
 
 - Process **one task per iteration**.

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

@@ -43,9 +43,10 @@ When asked to build a slice, always follow this flow:
    - **State-view** — `projections` or `queries` array is non-empty → invoke `/build-state-view`
    - **State-change** — default (has `commands` / `events`) → invoke `/build-state-change`
 3. Invoke the matching skill and follow its instructions completely. Do not deviate.
-4. **Verify against slice.json**: After the skill completes, check that every command field, event field, and specification in slice.json appears in the implementation. No invented fields — if it is not in slice.json, it must not be in the code.
-5. Run quality checks (TODO: this stack's build + test commands), then the slice tests only.
-6. If checks pass, commit with `feat: [Slice Name]` and set slice status to `Done`.
+4. **UI baseline gate**: run `npx @eventmodelers/cli ui-baseline check` first and act only on its verdict — `UNCHANGED` means skip all UI work; `NO_BASELINE`/`UNKNOWN` mean one full screen diff and every `codeGen.uiPrompts` entry; `CHANGED` names the elements that changed, were added or removed (work on exactly those) and flags `SCREEN_CHANGED` (re-fetch the screen node and adjust the components to it), `ELEMENTS_CHANGED` (diff slice.json against the code) and `PROMPTS_CHANGED` (apply the printed prompts). Details in `lib/prompt.md`, Step 4. After the checks pass and before committing, run `ui-baseline record`.
+5. **Verify against slice.json**: After the skill completes, check that every command field, event field, and specification in slice.json appears in the implementation. No invented fields — if it is not in slice.json, it must not be in the code.
+6. Run quality checks (TODO: this stack's build + test commands), then the slice tests only.
+7. If checks pass, commit with `feat: [Slice Name]` and set slice status to `Done`.
 
 After you are done, automatically run the tests for the slice that was edited.
 

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

@@ -43,4 +43,4 @@ These files are always up to date — read them directly before invoking any ski
 - The `boardId` and `organizationId` from each payload provide full context — pass them to skills.
 - Node events use `node:created`, `node:changed`, `node:deleted` — always POST to `/api/org/:orgId/boards/:boardId/nodes/events`.
 - Slice metadata (title, status) lives on the SLICE_BORDER node under `meta.sliceStatus` and `meta.title`.
-- `/update-slice-status` rejects moving a slice into a status it's already in — this is a concurrency guard, not a bug. It means another agent already claimed the slice. Treat it as `ALREADY_IN_STATUS`, skip that slice, and move on to the next `Handover` one instead of erroring out. This applies to queued tasks only: when the task request names the slice to build, the run loop owns its status — never call `/update-slice-status` there.
+- `/update-slice-status` rejects moving a slice into a status it's already in — this is a concurrency guard, not a bug. It means another agent already claimed the slice. Treat it as `ALREADY_IN_STATUS`, skip that slice, and move on to the next `Waiting` one instead of erroring out. This applies to queued tasks only: when the task request names the slice to build, the run loop owns its status — never call `/update-slice-status` there.

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

@@ -9,9 +9,9 @@ The structure defined in the Project-Skills is relevant.
 You work within **exactly ONE context at a time** — the one named in `.build-kit/.slices/current_context.json` (the runner picks it).
 
 - **ONLY** look for and build slices inside `.build-kit/.slices/<currentContext>/`.
-- **NEVER** read, scan, or build slices from any other context directory, even if it has "Handover" slices, and even if the current context has no work left.
-- A "Handover" slice in a *different* context is **NOT yours to build**. Ignore it completely.
-- If the current context has no "Handover" slice, you are **done for this iteration** — reply `<promise>NO_TASKS</promise>` and stop. Do not go looking elsewhere. The runner moves `current_context.json` on to the next context with Handover work between iterations — never change it yourself.
+- **NEVER** read, scan, or build slices from any other context directory, even if it has "Waiting" slices, and even if the current context has no work left.
+- A "Waiting" slice in a *different* context is **NOT yours to build**. Ignore it completely.
+- If the current context has no "Waiting" slice, you are **done for this iteration** — reply `<promise>NO_TASKS</promise>` and stop. Do not go looking elsewhere. The runner moves `current_context.json` on to the next context with Waiting work between iterations — never change it yourself.
 
 ## Your Task
 
@@ -19,8 +19,8 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 1. Read `.build-kit/.slices/current_context.json` to find the active context name, then read `.build-kit/.slices/<contextName>/index.json`. Every item in status "handover" is a task.
 2. Read `.build-kit/AGENTS.md` **if it exists** — the project's accumulated learnings, generated from what earlier builds recorded. If the slice's `slice.json` has a `lastAttempt`, an earlier attempt at it failed: read its `reason`, `lastReply`, `branch` and `changed`, and do not repeat what failed.
 3. Make sure you are on the right branch "feature/<slicename>", if unsure, start from main.
-5. Your slice is the one the task request names (the run loop picked the highest priority slice with status "Handover"); it becomes your PRD. The run loop has already claimed it — its status is "InProgress" in index.json and on the board. Build that slice and do not call `update-slice-status`: the run loop owns the slice's status on the board.
-   **IMPORTANT: Only work on the slice named in the task request. Never switch to another slice, whatever its status. If the task request names no slice and no slice has status "Handover" in the current context, reply with:**
+5. Your slice is the one the task request names (the run loop picked the highest priority slice with status "Waiting"); it becomes your PRD. The run loop has already claimed it — its status is "InProgress" in index.json and on the board. Build that slice and do not call `update-slice-status`: the run loop owns the slice's status on the board.
+   **IMPORTANT: Only work on the slice named in the task request. Never switch to another slice, whatever its status. If the task request names no slice and no slice has status "Waiting" in the current context, reply with:**
    <promise>NO_TASKS</promise> and stop immediately. Do not work on other slices and do not switch to another context.
 6. Pick the slice definition from `.build-kit/.slices/<contextName>/<folder>/slice.json` as defined in the prd. Never work on more than one slice per iteration.
 7. A slice can define additional prompts as codegen/backendPrompt. Any additional prompts defined in backend are hints for the implementation of the slice and have to be taken into account.
@@ -54,6 +54,16 @@ npx @eventmodelers/cli learn "<one terse line>" --topic "<topic>"
 - `--scope system` for what is true of the modeled domain (a business rule, a naming convention of the model); `repo` (the default) for the codebase and its tooling. `--tag <tag>` labels it (repeatable).
 - One in `.build-kit/AGENTS.md` that turned out wrong or obsolete: `npx @eventmodelers/cli learnings --ids` lists each with its id, `npx @eventmodelers/cli learn --retract <id>` removes it.
 
+### Recording Info
+
+Something that is **not** a reusable learning — you cannot change something and why, a decision you took, a note for whoever reads the board — is an info, not a learning. Never leave it only in your reply:
+
+```
+npx @eventmodelers/cli info "<one terse line>" --kind limitation|decision|note
+```
+
+It is recorded as an event and posted as a comment on the slice you are building (`--slice <id>` to name another). Reusable knowledge stays a `learn`.
+
 ## Update AGENTS.md Files
 
 Before committing, check if any edited files have learnings worth preserving in nearby AGENTS.md files — API patterns/conventions, gotchas, dependencies between files, testing approaches, configuration/environment requirements.
@@ -90,12 +100,12 @@ A Slice is not complete if specifications are missing or can't be executed.
 
 ## Stop Condition
 
-**After completing ONE slice, always stop — regardless of whether more slices are in Handover.** The ralph loop will invoke you again for the next slice. Never chain multiple slices in one iteration.
+**After completing ONE slice, always stop — regardless of whether more slices are in Waiting.** The ralph loop will invoke you again for the next slice. Never chain multiple slices in one iteration.
 
 If the slice was completed and committed successfully, reply with:
 <promise>DONE</promise>
 
-If no slice has status "Handover" in the current context, reply with:
+If no slice has status "Waiting" in the current context, reply with:
 <promise>NO_TASKS</promise>
 (Do NOT switch to another context to find work — stop here.)
 

package/stacks/react/templates/build-kit/lib/kit.json

@@ -1,3 +1,3 @@
 {
-  "pickupStatus": "Handover"
+  "pickupStatus": "Waiting"
 }

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

@@ -38,13 +38,13 @@ Run `/load-slice sliceId=<payload.sliceId>` to fetch full slice details (title,
 
 Inspect the `sliceStatus` in the payload:
 
-#### `Handover` — build the slice
+#### `Waiting` — build the slice
 
 This is the build trigger. Setting `InProgress` and building are one atomic step:
 
 1. Immediately call `/update-slice-status` to set the slice to `InProgress` on the board.
 
-   **Claim conflict**: if this call reports the slice is already in `InProgress` (or any status other than `Handover`), another agent already claimed it first — this is expected, not an error. Say so in your reply, drop this task without building, and continue the loop (the next task will naturally cover the next slice). Do not retry.
+   **Claim conflict**: if this call reports the slice is already in `InProgress` (or any status other than `Waiting`), another agent already claimed it first — this is expected, not an error. Say so in your reply, drop this task without building, and continue the loop (the next task will naturally cover the next slice). Do not retry.
 
 2. Run `/load-slice sliceId=<payload.sliceId>` to fetch the full slice, then read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json`. The runner keeps a `slice.json` fresh from a summary endpoint, so a file holding only `id`, `title`, `status` and `sliceType` is that stub, not an empty slice — never conclude a slice has no elements from it. Only if the full fetch itself returns no commands/events/read models/fields is the slice actually empty.
 
@@ -56,6 +56,33 @@ This is the build trigger. Setting `InProgress` and building are one atomic step
 
 4. Invoke the matching skill and follow its instructions **completely**. Do NOT implement the slice manually.
 
+   **UI baseline gate** — before touching any code, run `npx @eventmodelers/cli ui-baseline check`. It
+   compares the board's node hashes (the slice's screen and every element) and `codeGen.uiPrompts` with
+   what was recorded after the last UI build, and decides what this build has to do:
+   - `UNCHANGED` — nothing on the board changed since the last UI build. Skip all UI work; do not
+     re-fetch or diff the screen. Only now is "no code changes needed" a valid outcome.
+   - `NO_BASELINE` — no UI build recorded yet (first build, or the slice predates the baseline). Do one
+     full screen diff (below), apply every UI prompt.
+   - `UNKNOWN` — the board could not be read. Treat it as `NO_BASELINE`; never as `UNCHANGED`.
+   - `CHANGED` — it also lists, per element, what changed, was added or was removed since the last recorded
+     build (e.g. `changed: Contact Details (screen), Assign Tag (command)`). Work on exactly those nodes
+     and leave what matches alone. Act on the parts it flags:
+     - `SCREEN_CHANGED`: re-fetch the live screen node (`get_node`, its `meta.pages` / `meta.marks`) —
+       never trust the JSX already in the repo — and diff the existing component(s) against the marked
+       (or whole, if unmarked) HTML: tags, classes, layout, copy, fields/buttons added, removed or
+       reordered, and `cssFrameworks`. Edit the components (and `src/pages/<ScreenTitle>.tsx`, for this
+       slice's marked position only) until they match 1:1 and update `samples/`. Keep what already
+       matches; do not regenerate the slice from scratch.
+     - `ELEMENTS_CHANGED`: diff slice.json against the code field by field (fields,
+       `apiEndpoint`/UI contract) and fix every drift.
+     - `PROMPTS_CHANGED`: apply the UI prompts it prints — each is an instruction the user typed on the
+       board for this slice's UI (e.g. "adjust the UI to the new layout!") — to the component(s) and
+       screen markup. Name each prompt and the change you made for it in your final reply.
+
+   When the UI work is done and the checks in step 6 pass, run `npx @eventmodelers/cli ui-baseline record`
+   **before committing**, so `ui-baseline.json` is committed with the slice. Never record without having
+   done the work the verdict asked for.
+
 5. **Verify against slice.json**: cross-check the implementation — every command field, event field, and specification in slice.json must appear in the code. No invented fields — if it is not in slice.json, it must not be in the code.
 
 6. Run quality checks (TODO: your stack's build + test commands — slice-scoped tests only, not the full suite).
@@ -98,6 +125,16 @@ npx @eventmodelers/cli learn "<one terse line>" --topic "<topic>"
 - `--scope system` for what is true of the modeled domain (a business rule, a naming convention of the model); `repo` (the default) for the codebase and its tooling. `--tag <tag>` labels it (repeatable).
 - One in `.build-kit/AGENTS.md` that turned out wrong or obsolete: `npx @eventmodelers/cli learnings --ids` lists each with its id, `npx @eventmodelers/cli learn --retract <id>` removes it.
 
+### Recording Info
+
+Something that is **not** a reusable learning — you cannot change something and why, a decision you took, a note for whoever reads the board — is an info, not a learning. Never leave it only in your reply:
+
+```
+npx @eventmodelers/cli info "<one terse line>" --kind limitation|decision|note
+```
+
+It is recorded as an event and posted as a comment on the slice you are building (`--slice <id>` to name another). Reusable knowledge stays a `learn`.
+
 ## Important
 
 - Process **one task per iteration**.

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

@@ -42,8 +42,22 @@ CREATE TABLE IF NOT EXISTS "public"."{tablename}"
     -- use snake_case for all column names
     created_at  TIMESTAMP DEFAULT NOW()
 );
+
+-- The UI reads this table DIRECTLY through Supabase (no read endpoint in between), so it must be readable.
+-- RLS on with no policy returns an EMPTY list, not an error - always ship the policy with the table.
+ALTER TABLE "public"."{tablename}" ENABLE ROW LEVEL SECURITY;
+GRANT SELECT ON "public"."{tablename}" TO authenticated;
+CREATE POLICY "{tablename}_select" ON "public"."{tablename}"
+    FOR SELECT TO authenticated USING (true);
 ```
 
+**The UI reads the read-model table directly.** The frontend never goes through the `GET` route for a
+read model: it selects from this table with the user's session, and Row Level Security decides which
+rows come back. `USING (true)` is the default (every signed-in user sees every row); when the read
+model is per user or per tenant (an owner/user/tenant column, or `description`/`comments[]` say so),
+narrow the policy to it, e.g. `USING (owner_id = auth.uid()::text)`. The `GET` route in Step 5 stays
+for API consumers and tests; the UI does not depend on it.
+
 **Column type guide** — field `type` values are the canonical set from the [event-modeling-spec schema](https://github.com/dilgerma/event-modeling-spec/blob/main/eventmodeling.schema.json):
 
 | Field type | SQL type |
@@ -487,6 +501,7 @@ src/common/
 ## Checklist
 
 - [ ] Migration file created with correct version number and all columns
+- [ ] Migration enables RLS, grants `SELECT` to `authenticated` and creates a select policy: the UI reads the table directly, and no policy means an empty list
 - [ ] `tableName` constant matches the migration table name exactly
 - [ ] Projection registered in `loadPostgresEventstore.ts`
 - [ ] `canHandle` lists every event type the projection reacts to

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

@@ -49,9 +49,10 @@ When asked to build a slice, always follow this flow:
    - **State-view** — `projections` or `queries` array is non-empty → invoke `/build-state-view`
    - **State-change** — default (has `commands` / `events`) → invoke `/build-state-change`
 3. Invoke the matching skill and follow its instructions completely. Do not deviate.
-4. **Verify against slice.json**: After the skill completes, check that every command field, event field, and specification in slice.json appears in the implementation. No invented fields — if it is not in slice.json, it must not be in the code. This applies even when the slice was previously `Done` and reappears as `Planned` — never dismiss a mismatch as "already implemented" or harmless drift; diff slice.json against the code field by field and update the code to match every change.
-5. Run quality checks (`npm run build`, then the slice tests only).
-6. If checks pass, commit with `feat: [Slice Name]` and set slice status to `Done`. 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.
+4. **Baseline gate**: run `npx @eventmodelers/cli build-baseline check --scope backend` first and act only on its verdict — `UNCHANGED` means nothing on the board changed since the last recorded build: do not rebuild, just run the slice's tests and finish; `NO_BASELINE`/`UNKNOWN` mean one full field-by-field diff of slice.json against the code; `CHANGED` lists exactly which elements changed, were added or removed — diff and fix only those. After the checks pass and before committing, run `build-baseline record --scope backend`. A screen or UI prompt change never triggers a backend build.
+5. **Verify against slice.json**: After the skill completes, check that every command field, event field, and specification in slice.json appears in the implementation. No invented fields — if it is not in slice.json, it must not be in the code. This applies even when the slice was previously `Done` and reappears as `Planned` — never dismiss a mismatch as "already implemented" or harmless drift; diff slice.json against the code field by field and update the code to match every change.
+6. Run quality checks (`npm run build`, then the slice tests only).
+7. If checks pass, commit with `feat: [Slice Name]` and set slice status to `Done`. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to set is `Waiting`, not `Done` — see the `ui-contract` skill, Step 4.
 
 After you are done, automatically run the tests for the slice that was edited.
 

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 `Handover`, 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` — 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.
@@ -58,6 +58,16 @@ npx @eventmodelers/cli learn "<one terse line>" --topic "<topic>"
 - `--scope system` for what is true of the modeled domain (a business rule, a naming convention of the model); `repo` (the default) for the codebase and its tooling. `--tag <tag>` labels it (repeatable).
 - One in `.build-kit/AGENTS.md` that turned out wrong or obsolete: `npx @eventmodelers/cli learnings --ids` lists each with its id, `npx @eventmodelers/cli learn --retract <id>` removes it.
 
+### Recording Info
+
+Something that is **not** a reusable learning — you cannot change something and why, a decision you took, a note for whoever reads the board — is an info, not a learning. Never leave it only in your reply:
+
+```
+npx @eventmodelers/cli info "<one terse line>" --kind limitation|decision|note
+```
+
+It is recorded as an event and posted as a comment on the slice you are building (`--slice <id>` to name another). Reusable knowledge stays a `learn`.
+
 ## Update AGENTS.md Files
 
 Before committing, check if any edited files have learnings worth preserving in nearby AGENTS.md files:

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

@@ -95,6 +95,16 @@ npx @eventmodelers/cli learn "<one terse line>" --topic "<topic>"
 - `--scope system` for what is true of the modeled domain (a business rule, a naming convention of the model); `repo` (the default) for the codebase and its tooling. `--tag <tag>` labels it (repeatable).
 - One in `.build-kit/AGENTS.md` that turned out wrong or obsolete: `npx @eventmodelers/cli learnings --ids` lists each with its id, `npx @eventmodelers/cli learn --retract <id>` removes it.
 
+### Recording Info
+
+Something that is **not** a reusable learning — you cannot change something and why, a decision you took, a note for whoever reads the board — is an info, not a learning. Never leave it only in your reply:
+
+```
+npx @eventmodelers/cli info "<one terse line>" --kind limitation|decision|note
+```
+
+It is recorded as an event and posted as a comment on the slice you are building (`--slice <id>` to name another). Reusable knowledge stays a `learn`.
+
 ## Important
 
 - Process **one task per iteration**.