@eventmodelers/cli 1.0.138 → 1.0.139

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@eventmodelers/cli",
-  "version": "1.0.138",
+  "version": "1.0.139",
   "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/stacks/classic/templates/.claude/skills/build-automation/SKILL.md

@@ -43,7 +43,7 @@ If `storylines[]` includes a beat sequence running through this automation's tri
 
 ## Step 3 — Find the trigger point
 
-Locate where the trigger event's state change happens in the code (the service method / persistence of the event that feeds the processor), and pick the mechanism from `ARCHITECTURE.md`:
+Locate where the trigger event's state change happens in the code — the **Slice map** in `ARCHITECTURE.md` names the code of the Done slice that produces it. If the map has a Done automation slice, build this one the way that one is built (same mechanism, registration and test style); otherwise pick the mechanism from `ARCHITECTURE.md`:
 
 | Codebase has | Build the automation as |
 |---|---|
@@ -57,6 +57,7 @@ Rules:
 - The reaction must be **idempotent**: reprocessing the same trigger must not issue the command twice (check the resulting state, a processed-marker, or the todo-list query condition — whatever the codebase already uses).
 - Follow the codebase's transaction boundaries: the command must not run inside a transaction that can still roll back the trigger unless the reference does exactly that.
 - Never add a new messaging/scheduling library just for this slice.
+- **Isolated and deletable**: the listener/consumer/job is its own class in the slice's own place (see *New slices — isolation*). Prefer subscribing to an existing event or querying for pending work over editing the trigger's service method; if a hook in that method is unavoidable (no event mechanism exists), keep it to a single call and list it under `Shared seams`.
 
 ## Step 4 — Register it
 
@@ -70,14 +71,24 @@ Besides the command tests from Step 2, write one test per `specifications[]` ent
 
 Run the build command and the single-test command from `ARCHITECTURE.md` for the tests this slice added or changed. Do not run the full suite.
 
+## Step 7 — Record the slice in the Slice map
+
+Add (or update) this slice's row in the **Slice map** of `ARCHITECTURE.md`, with the trigger and every shared file it touched under `Shared seams`. Commit it with the slice.
+
+## Step 8 — Record the evidence on the board
+
+After the commit, invoke `/record-evidence`: it writes this slice's element → code mapping, field mapping, specification → test mapping, files, seams, assumptions and commit as a markdown note into the slice's column (chapter lane `Implementation`). Only then is the slice set to `Done`.
+
 ---
 
 ## Checklist
 
 - [ ] The command was built (or reused) via build-state-change, with all its specifications tested
-- [ ] The trigger uses the codebase's existing reactive mechanism, registered like the reference
+- [ ] The trigger uses the codebase's existing reactive mechanism, registered like the precedent automation slice (or the reference)
+- [ ] The automation is its own class; any hook into existing code is listed under `Shared seams` in its Slice map row
 - [ ] Trigger → command field mapping matches slice.json exactly
 - [ ] Reprocessing the same trigger does not issue the command twice
 - [ ] Every specification has a passing test
 - [ ] If `storylines[]` is present, its command segment is covered via build-state-change's storyline-derived tests
 - [ ] No new framework, library or architectural style was introduced; any first-time mechanism choice is recorded in `ARCHITECTURE.md`
+- [ ] The evidence note exists in the slice's column on the board (`/record-evidence`)

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

@@ -33,15 +33,19 @@ From the slice definition, extract:
 
 ---
 
-## Step 2 — Check what already exists
+## Step 2 — Find the precedent slices
 
-Search the codebase for the command name, event names, the entity they act on, and the key fields. A slice that reappears as `Planned` may be partly or fully implemented already — then this skill is a **diff**: update the existing code to match slice.json field by field, add missing specifications, remove fields slice.json no longer has. Never dismiss a mismatch as harmless drift.
+This codebase is usually a legacy system whose event model was built from its code, so most neighbouring slices already exist in the code. Before writing anything, find out how they were built:
 
-Also find the entity/table the events write to. If it exists, extend it; if not, create it the way the reference implementation creates one (entity + migration, schema file, ...).
+1. **Is this slice itself already in the code?** Look it up in the **Slice map** of `ARCHITECTURE.md` and search for the command name, event names, the entity and the key fields (also under their code names from *Code vs. board terms*). If it exists — a slice that reappears as `Planned`, or one the analysis found but never marked `Done` — this skill is a **diff**: update the existing code to match slice.json field by field, add missing specifications, remove fields slice.json no longer has. Never dismiss a mismatch as harmless drift, and don't rebuild it next to the existing code.
+2. **Which existing slices are its neighbours?** From the Slice map and the context's `index.json`, pick the `Done` slices closest to this one — same context, same entity/aggregate, same events (e.g. the slice that produces this slice's `given` events, or another status transition on the same entity), same type. Read their `slice.json` and the code the map lists for them, **side by side**: that is exactly how a COMMAND, its EVENTs and its specifications from this board become code here. If no Done slice is close, fall back to the reference implementation in `ARCHITECTURE.md`.
+3. **What does the slice build on?** Events this slice reads in its `given`/specifications that other Done slices produce are already persisted somewhere — reuse that entity/table, never re-implement or duplicate it.
 
-## Step 3 — Map the slice onto the reference write path
+If a Done slice in this context has no row in the Slice map, run `/learn-architecture slices` first.
 
-Open the **write** reference implementation from `ARCHITECTURE.md` and build the same shape for this slice, file by file, in the same locations and with the same naming:
+## Step 3 — Map the slice the way its precedent is mapped
+
+Take the precedent slice from Step 2 (or the **write** reference implementation from `ARCHITECTURE.md`) and build the same shape for this slice — same layers, naming, validation, error mapping and test style — placed as described in *New slices — isolation* of `ARCHITECTURE.md`:
 
 | From slice.json | Becomes (per `ARCHITECTURE.md`) |
 |---|---|
@@ -51,6 +55,7 @@ Open the **write** reference implementation from `ARCHITECTURE.md` and build the
 | event that represents a status transition (`...Approved`, `...Cancelled`) | the field/status column update the codebase uses for such transitions |
 
 Rules:
+- **Isolated and deletable**: the slice's code lives in its own files (its own package/folder where the layout allows — see *New slices — isolation*), not as new methods appended to an existing shared service, controller or repository. Shared files are touched only at the seams `ARCHITECTURE.md` names (registration, routing, a new migration), each as one small, recognisable change. No other code may start depending on this slice's internals; it reaches shared state through the existing entity/repository. Removing the slice should mean deleting its files and reverting its seams.
 - Every command field, every event field ends up somewhere concrete — persisted, validated or returned. A field with no destination is a gap: record your assumption.
 - No fields that are not in slice.json. Technical columns the codebase always adds (ids, timestamps, version, audit) are fine if every comparable entity has them.
 - Schema changes go through the codebase's migration mechanism — add a new migration, never edit an existing one.
@@ -84,6 +89,14 @@ Group these separately (own test class/`describe`/region, named after the storyl
 
 Run the build command and the single-test command from `ARCHITECTURE.md` for the tests this slice added or changed. Do not run the full suite.
 
+## Step 7 — Record the slice in the Slice map
+
+Add (or update) this slice's row in the **Slice map** of `ARCHITECTURE.md`: entry point, persistence, tests, and every shared file it touched under `Shared seams` — that column is the checklist for deleting the slice later. Commit it with the slice.
+
+## Step 8 — Record the evidence on the board
+
+After the commit, invoke `/record-evidence`: it writes this slice's element → code mapping, field mapping, specification → test mapping, files, seams, assumptions and commit as a markdown note into the slice's column (chapter lane `Implementation`). Only then is the slice set to `Done`.
+
 ---
 
 ## Final Verification: Does the Implementation Match slice.json?
@@ -94,5 +107,8 @@ Run the build command and the single-test command from `ARCHITECTURE.md` for the
 - [ ] If `storylines[]` is present, a storyline-derived test was added for every COMMAND beat
 - [ ] No business rules, defaults, or constraints were added that do not appear in slice.json `description`, `comments` or specifications
 - [ ] No field names were assumed or guessed — if a field is not in slice.json, it is not in the code
-- [ ] The new code mirrors the reference implementation's layout, naming and conventions; no new framework, library or architectural style was introduced
+- [ ] The new code mirrors its precedent slice (or the reference implementation): layout, naming and conventions; no new framework, library or architectural style was introduced
+- [ ] Data produced by existing slices was reused, not duplicated
+- [ ] The slice lives in its own files; shared files were touched only at the seams in `ARCHITECTURE.md`, and its Slice map row lists them
 - [ ] Assumptions are recorded in `progress.txt` and as code comments
+- [ ] The evidence note exists in the slice's column on the board (`/record-evidence`)

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

@@ -27,13 +27,22 @@ From the slice definition, extract:
 - **readmodels[]** / **projections[]** / **queries[]** — the read model(s) this slice serves, with their fields
 - the **events** feeding each read model — they tell you which persisted state the fields come from
 - **specifications[]** — test scenarios (given events → expected read model)
-- **storylines[]** (optional) — present only when the board author built an explicit walkthrough for this flow; most slices have none. See "Storyline-derived tests" under Step 5.
+- **storylines[]** (optional) — present only when the board author built an explicit walkthrough for this flow; most slices have none. See "Storyline-derived tests" under Step 6.
 
 > **Comments & description**: each element carries a `comments: string[]` array (board comments) and a `description` field — use them as implementation hints, and resolve consumed comments via `POST <BASE_URL>/api/org/<ORG_ID>/boards/<BOARD_ID>/nodes/<nodeId>/comments/<commentId>/resolve`.
 
 ---
 
-## Step 2 — Locate the source data
+## Step 2 — Find the precedent slices
+
+This codebase is usually a legacy system whose event model was built from its code, so most neighbouring slices already exist in the code. Before writing anything:
+
+1. **Is this read already in the code?** Look the slice up in the **Slice map** of `ARCHITECTURE.md` and search for the read model name, its fields and the endpoint (also under the code names from *Code vs. board terms*). If it exists, this skill is a **diff** (see Step 3) — don't build a second query next to it.
+2. **Which existing slices are its neighbours?** Pick the closest `Done` slices — the state-change slices that produce this read model's events (they show where the data is persisted), and another state-view slice in the same context or over the same entity (it shows how reads are built here). Read their `slice.json` and the code the map lists for them side by side. If no Done state-view is close, fall back to the read reference implementation in `ARCHITECTURE.md`.
+
+If a Done slice in this context has no row in the Slice map, run `/learn-architecture slices` first.
+
+## Step 3 — Locate the source data
 
 For every read model field, find where the feeding event's data is persisted (the entity/table/column written by that event's state-change slice). Search by event name, entity and field names.
 
@@ -42,9 +51,9 @@ For every read model field, find where the feeding event's data is persisted (th
 
 If the slice reappears as `Planned` and a query for it already exists, treat this skill as a **diff** against slice.json: add missing fields, remove fields slice.json no longer has, add missing specifications.
 
-## Step 3 — Map the slice onto the reference read path
+## Step 4 — Map the slice the way its precedent is mapped
 
-Open the **read** reference implementation from `ARCHITECTURE.md` and build the same shape, in the same locations and with the same naming:
+Take the precedent state-view slice from Step 2 (or the **read** reference implementation from `ARCHITECTURE.md`) and build the same shape, with the same naming, placed as described in *New slices — isolation* of `ARCHITECTURE.md` — its own query class/DTO/endpoint files (own package/folder where the layout allows), not new methods appended to a shared repository or controller when a separate class works just as well. Shared files are touched only at the seams `ARCHITECTURE.md` names, and the query reads existing tables without changing them for other readers:
 
 | From slice.json | Becomes (per `ARCHITECTURE.md`) |
 |---|---|
@@ -55,11 +64,11 @@ Open the **read** reference implementation from `ARCHITECTURE.md` and build the
 
 In an event-based codebase (per `ARCHITECTURE.md`), build the projection/read-model updater the existing way instead and register it like the reference does.
 
-## Step 4 — Expose it
+## Step 5 — Expose it
 
 Expose the read the way comparable reads are exposed (REST endpoint, RPC, UI loader, ...), including registration, routing, API documentation and permission config, mirroring the reference. If the read is only consumed internally (e.g. by an automation's todo list), a service/repository method is enough.
 
-## Step 5 — Write the tests
+## Step 6 — Write the tests
 
 Write one executable test per entry in `specifications[]`, in the test style and location of the reference test:
 
@@ -80,10 +89,18 @@ A storyline is `{ id, title, elements: [...] }`, where `elements` is an ordered
 
 Group these separately, named after the storyline. Skip a beat pair when a COMMAND beat sits in between (that half belongs to build-state-change) or when the run includes a SCREEN/AUTOMATION beat with no traceable event — a one-line comment noting the storyline segment exists is enough.
 
-## Step 6 — Quality gate
+## Step 7 — Quality gate
 
 Run the build command and the single-test command from `ARCHITECTURE.md` for the tests this slice added or changed. Do not run the full suite.
 
+## Step 8 — Record the slice in the Slice map
+
+Add (or update) this slice's row in the **Slice map** of `ARCHITECTURE.md`, including every shared file it touched under `Shared seams`. Commit it with the slice.
+
+## Step 9 — Record the evidence on the board
+
+After the commit, invoke `/record-evidence`: it writes this slice's element → code mapping, field mapping, specification → test mapping, files, seams, assumptions and commit as a markdown note into the slice's column (chapter lane `Implementation`). Only then is the slice set to `Done`.
+
 ---
 
 ## Checklist
@@ -93,5 +110,7 @@ Run the build command and the single-test command from `ARCHITECTURE.md` for the
 - [ ] No parallel data store was invented for data that already exists
 - [ ] Every specification has exactly one corresponding, passing test
 - [ ] If `storylines[]` is present, a storyline-derived test was added for every isolable read-model transition (adjacent READMODEL beats with only EVENT beats between them)
-- [ ] The new code mirrors the reference implementation's layout, naming and conventions; no new framework, library or architectural style was introduced
+- [ ] The new code mirrors its precedent slice (or the reference implementation): layout, naming and conventions; no new framework, library or architectural style was introduced
+- [ ] The slice lives in its own files; shared files were touched only at the seams in `ARCHITECTURE.md`, and its Slice map row lists them
 - [ ] Assumptions and data gaps are recorded in `progress.txt` and as code comments
+- [ ] The evidence note exists in the slice's column on the board (`/record-evidence`)

package/stacks/classic/templates/.claude/skills/learn-architecture/SKILL.md

@@ -1,15 +1,19 @@
 ---
 name: learn-architecture
-description: Analyzes the existing codebase once and writes .build-kit/ARCHITECTURE.md — layers, feature layout, persistence, how writes/reads/background work are built, test style, build/test commands, and how Event Modeling slices map onto it. Run before the first slice is built, or when ARCHITECTURE.md is missing or stale.
+description: Analyzes the existing codebase once and writes .build-kit/ARCHITECTURE.md — layers, feature layout, persistence, how writes/reads/background work are built, test style, build/test commands, and the slice map — which code every existing (Done) slice on the board corresponds to, and the mapping pattern they share. Run before the first slice is built, when ARCHITECTURE.md is missing or stale, or with `slices` when Done slices are missing from the slice map.
 ---
 
 # Learn Architecture
 
 The classic build kit implements slices inside a codebase it did not create. Before any slice is built, the agent has to know how *this* codebase builds a feature — otherwise every slice drifts toward a generic pattern. This skill finds that out once and writes it down in `.build-kit/ARCHITECTURE.md`, which every `build-*` skill reads instead of re-exploring.
 
-**Arguments** (optional): `refresh` — re-analyze and rewrite `ARCHITECTURE.md` even if it exists.
+**The typical situation is a legacy system.** Someone ran a code base analysis (`analyze-code-base`), built the event model from the existing code, and now extends it. Most slices on the board therefore *already exist in the code* — usually in status `Done` — and their elements' `description`s carry code references (`path/to/File.java:57`, `Class#method`, tables, endpoints). Those slices are the most valuable input this skill has: each one is a worked example of how a COMMAND, EVENT, READMODEL or AUTOMATION from *this* board is realized in *this* code. The mapping is learned from them first, and from generic code reading only where no slice covers it.
 
-If `.build-kit/ARCHITECTURE.md` exists and `refresh` was not passed, stop: read it and return.
+**Arguments** (optional):
+- `refresh` — re-analyze and rewrite `ARCHITECTURE.md` even if it exists.
+- `slices` — keep everything else, only bring the **Slice map** up to date (Steps 2–3, then only the **Slice map** and *Code vs. board terms* sections in Step 6): add Done slices that are missing from it, re-check rows whose code moved.
+
+If `.build-kit/ARCHITECTURE.md` exists and neither argument was passed: read it, then compare its **Slice map** against the `Done` slices in the local `index.json` files. If every Done slice has a row, return. Otherwise run as `slices`.
 
 ---
 
@@ -19,9 +23,37 @@ Read the build/dependency files at the project root and one level down (`package
 
 Record: language + version, framework(s), persistence (database, ORM/query layer, migration tool), messaging if any, test framework(s), and the exact commands to build, run all tests, and run a **single** test file/class. Prefer what CI actually runs over what a README claims. Do not guess a command — if one can't be determined, say so in `ARCHITECTURE.md`.
 
-## Step 2 — Find reference features
+## Step 2 — Collect the existing slices
+
+Make sure the slice files are present (`/load-slice` without arguments refreshes all of them), then read every `.build-kit/.slices/*/index.json`. This is read-only reference work, so it covers **all** contexts, not only the current one.
+
+Every slice with status `Done` is already implemented — treat it as a precedent. Slices in other statuses (`Created`, `Planned`, ...) may also carry code references from the analysis (the code exists, the slice was just never marked Done); include them when their descriptions point at code. Sort each slice by type the way `CLAUDE.md` *Building a Slice* does (state-change / state-view / automation / translation).
+
+For each such slice, read its `slice.json` and collect the code references from:
+- the `description` (and `comments`) of the slice and of every command, event, read model, screen and processor — paths with line numbers, `Class#method`, tables, endpoints, tests, templates;
+- if the board is reachable and the chapter has them: the `Legacy Sources — <Chapter>` note (*Where this flow lives*) and the `Decisions — <column>` notes in the chapter's **Decisions** lane (`get_nodes { boardId, type: "MARKDOWN", projection: "line" }` for the ids, then read only the notes of chapters you need). They map elements to code with exact references and record code-vs-board term differences (`PetType` → *Species*).
+
+A slice without any reference is located by search instead (Step 3).
+
+## Step 3 — Map each existing slice onto its code
+
+For every slice from Step 2, find the code that implements it. Open the referenced files (or search for the command/event/read model names, their fields, and the code terms from the Decisions notes) and record, per slice:
+
+- **COMMAND** → entry point (endpoint/handler/action) + input DTO + service method
+- **EVENT** → what it writes: entity/table + columns, status column + value, or the published event class
+- **READMODEL** → query/repository method + response DTO + endpoint
+- **AUTOMATION / processor** → listener/consumer/job + what it calls
+- **Specifications** → the test class/method that covers them, if any
+
+Verify, don't copy: a line number may be stale, a file may have moved. Fix the reference in the map; if a slice's code can't be found at all, record it as `not found` — never treat it as a feature to build, and never invent a location.
+
+Then **look for the pattern across slices**. The same board construct is usually realized the same way every time — e.g. every `... Registered` event is an insert into the aggregate's table, every `... Approved/Cancelled` event is an update of a `status` column, every read model is a repository method + DTO in the same package, every automation is a `@Scheduled` job. That shared pattern *is* the Event Modeling mapping of this codebase (Step 5). Where slices are realized differently (two persistence styles, an old and a new module), record both and which slices use which, so a new slice can follow its nearest neighbour.
 
-Pick **one or two existing features** that look like the slices the board will produce — something that accepts input and changes state, and something that only reads/lists data. A recently changed, ordinary feature is a better reference than the oldest or the most special one (`git log --stat -20` helps).
+Do not read the whole codebase — follow the references.
+
+## Step 4 — Fill the gaps with reference features
+
+Only for what the existing slices don't cover (no Done slices at all, or e.g. no automation among them) pick **one or two existing features** that look like the slices the board will produce — something that accepts input and changes state, something that only reads/lists data. A recently changed, ordinary feature is a better reference than the oldest or the most special one (`git log --stat -20` helps). When existing slices cover a path, the best-mapped Done slice of that type *is* the reference implementation.
 
 Trace each one end to end, reading only the files on that path:
 
@@ -32,9 +64,9 @@ Trace each one end to end, reading only the files on that path:
 
 Do not read the whole codebase. Search (`grep`/glob) for a concept, then follow references.
 
-## Step 3 — Decide the Event Modeling mapping
+## Step 5 — Decide the Event Modeling mapping
 
-Decide how each board element is built **in this codebase**, based on what you found — not on Event Modeling theory:
+Decide how each board element is built **in this codebase**, based on what the existing slices show (Step 3) and, only where they say nothing, on the reference features (Step 4) — not on Event Modeling theory:
 
 - **Is it event-based?** Only if the code already persists or publishes events (event store, domain events, outbox, audit log of facts). Otherwise it is state-based (typically CRUD) and board EVENTs become the state transitions a command persists, not new event classes.
 - **COMMAND** → which entry point + DTO + service method shape, and where business-rule violations go (exception type, result type, validation error).
@@ -43,7 +75,16 @@ Decide how each board element is built **in this codebase**, based on what you f
 - **AUTOMATION / processor** → the existing reactive mechanism (or, if none exists, the least invasive option consistent with the codebase — usually a direct call or a scheduled job; note that choice explicitly).
 - **Specification (given/when/then)** → how `given` events become pre-existing state in a test, and what `then` asserts on.
 
-## Step 4 — Write `.build-kit/ARCHITECTURE.md`
+Then decide **where a new slice goes so it stays isolated and deletable**. Existing slices show how the code *is* built; new slices follow those conventions but are placed as self-contained as the codebase allows — ideally, removing a slice means deleting its own files plus undoing a short, known list of registrations. Settle, from what the codebase tolerates:
+
+- **Own unit per slice** — the most local place the layout allows: a package/folder per slice inside the context's module (best), otherwise own files (controller, DTOs, service/handler, query, test) next to the comparable ones — never new methods appended to an existing shared service, controller or repository when a separate class registered the same way works just as well.
+- **Shared seams** — the unavoidable touch points (router/DI registration, a menu entry, a schema migration, an existing entity that must gain a column) and how to keep each one to a single, small, recognisable change.
+- **Dependencies between slices** — a new slice reads shared state through the existing entity/repository (or the codebase's query style), never by calling another slice's internals; no other slice depends on the new one.
+- **Data** — new state goes into a new table or new columns via a new migration; existing columns are not repurposed.
+
+Where the codebase genuinely forces a shared file (one big controller per aggregate, a central route file), follow it — and record that the slice touches it.
+
+## Step 6 — Write `.build-kit/ARCHITECTURE.md`
 
 Keep it short and concrete — paths, class names and commands, not prose. Use this structure:
 
@@ -65,27 +106,52 @@ Keep it short and concrete — paths, class names and commands, not prose. Use t
 - Naming conventions (classes, files, endpoints, tables, columns)
 
 ## Reference implementations
-- Write: `path/to/Controller` → `path/to/Service` → `path/to/Repository` (+ migration)
+Prefer a mapped Done slice per type; a plain feature only where no slice covers the type.
+- Write: slice *Register Owner* — `path/to/Controller` → `path/to/Service` → `path/to/Repository` (+ migration)
 - Read: ...
 - Background: ... (or "none")
 - Tests: `path/to/ReferenceTest` — how state is set up and asserted
 
 ## Event Modeling mapping
-| Board element | Built as |
+Derived from the slices in the Slice map — cite the slices that show each row.
+| Board element | Built as | Seen in |
+|---|---|---|
+| COMMAND | ... | *Register Owner*, *Book Visit* |
+| EVENT (creation) | ... | ... |
+| EVENT (status transition) | ... | ... |
+| READMODEL | ... | ... |
+| AUTOMATION | ... | ... |
+| Specification | ... | ... |
+
+## Code vs. board terms
+| Code | Board |
 |---|---|
-| COMMAND | ... |
-| EVENT | ... |
-| READMODEL | ... |
-| AUTOMATION | ... |
-| Specification | ... |
+| `PetType` | *Species* |
+
+## Slice map
+Every slice that exists in the code. One row per slice; paths relative to the repo root. `Shared seams` lists the shared files a slice changed — for slices built by the kit it is the deletion checklist.
+| Slice | Context | Type | Status | Command / entry point | Persistence (events) | Read / query | Trigger | Tests | Shared seams |
+|---|---|---|---|---|---|---|---|---|---|
+| Register Owner | owners | state-change | Done | `OwnerController#processCreationForm` → `OwnerService#register` | `owners` insert | — | — | `OwnerControllerTests` | legacy |
+| Owner Details | owners | state-view | Done | `GET /owners/{id}` | — | `OwnerRepository#findById` → `OwnerDto` | — | ... | legacy |
+| Remind Visit | visits | automation | Done | `VisitService#remind` | `visits.reminded_at` | — | `VisitReminderJob` (`@Scheduled`) | ... | legacy |
+
+## New slices — isolation
+- Placement: e.g. `src/main/java/org/acme/<context>/<slicename>/` with `<Slice>Controller`, `<Slice>Request`, `<Slice>Handler`, `<Slice>Test`
+- Shared seams (the only shared files a slice may touch): `RouteConfig.java` (one line), `db/migration/V<n>__<slice>.sql` (new file), ...
+- Codebase constraints that force sharing, and what to do then
 
 ## Rules
 - Conventions a new slice must follow (transactions, validation, error mapping, auth, migrations append-only, ...)
 - Files a slice must not touch (app bootstrap, global config, lockfiles, ...)
 ```
 
-## Step 5 — Verify the commands
+## Step 7 — Verify the commands
 
 Run the build command and the single-test command against one existing test. If either fails for reasons unrelated to the code (missing service, missing env var), record the prerequisite under **Commands**. Do not "fix" the project to make it pass.
 
-Commit `ARCHITECTURE.md` on its own: `chore: document architecture for build kit`.
+Commit `ARCHITECTURE.md` on its own: `chore: document architecture for build kit` (with `slices`: `chore: update slice map`).
+
+## Keeping the slice map current
+
+The `build-*` skills add a row for every slice they build, so the map grows with the code. When a later code base analysis puts new Done slices on the board, the next build notices the missing rows and runs this skill with `slices` — only those slices are mapped, the rest of `ARCHITECTURE.md` stays as it is.

package/stacks/classic/templates/.claude/skills/record-evidence/SKILL.md

@@ -0,0 +1,177 @@
+---
+name: record-evidence
+description: Writes the implementation evidence for a built slice onto the board — a markdown note in the slice's own column, in the chapter's "Implementation" feedback lane — listing the files, the board-element → code mapping, the specification → test mapping, the shared seams touched, assumptions and the commit. Run after the slice is committed, before it is set to Done. Also usable to document where an existing (legacy) Done slice lives in the code.
+---
+
+# Record Evidence
+
+> **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Do not proceed until the connect skill has completed.
+
+Prefer `mcp__eventmodelers__*` tools when available (registered by the `connect` skill) — the curl blocks below are the fallback for sessions without MCP connected. Send `x-agent-id: $EVENTMODELERS_AGENT_ID` on every write when it is set.
+
+The evidence note is how a human reviewing the board sees **where** a slice lives in the code and **how** each modeled element and scenario was realized, without opening the repository. It is proof, not prose: every line names a concrete file, class, method, endpoint, table or test that exists in the commit.
+
+---
+
+## Step 1 — Collect the evidence
+
+From the slice you just built (or, for a legacy slice, from its row in the **Slice map** of `.build-kit/ARCHITECTURE.md` and the code it names):
+
+| Item | Source |
+|------|--------|
+| `SLICE_ID`, slice title | `slice.json` → `id`, `title` |
+| Commit | `git rev-parse --short HEAD` after the `feat: [Slice Name]` commit (`legacy` for a slice that pre-dates the kit) |
+| Files created / modified | `git show --stat --format= HEAD` — repo-relative paths, split into *created* and *modified* |
+| Element → code mapping | every COMMAND, EVENT, READMODEL, SCREEN and AUTOMATION in `slice.json` (with its `id`) and the code that realizes it |
+| Field → code mapping | every command / event / read-model field and the parameter, property or column it maps to |
+| Specification → test mapping | every entry in `specifications[]` (and storyline-derived tests) and the test class + method that covers it |
+| Shared seams | the `Shared seams` column of the slice's Slice map row |
+| Assumptions | the lines this slice added to `progress.txt` |
+| Quality checks | the build and test commands from `ARCHITECTURE.md` you ran, and their result |
+
+Only list what is really in the code. If an element has no counterpart (e.g. a modeled event the CRUD codebase has no equivalent for), say so explicitly — `— (persisted as the row insert, no event class)` — instead of leaving it out.
+
+## Step 2 — Write the note
+
+Reference board elements with `ref:<nodeId>` (the element ids from `slice.json`) so the note links back to them and keeps their current titles. Put code in backticks. Use this structure:
+
+```markdown
+# Implementation — <Slice Title>
+
+**Commit** `<sha>` · **Type** <state-change|state-view|automation> · **Recorded** <YYYY-MM-DD> · **Checks** <build ✅ / tests ✅ (n passed)>
+
+## Element → Code
+| Element | Code | Where |
+|---------|------|-------|
+| ref:<commandId> | `RegisterMicrochipController#processCreationForm` — `POST /owners/{ownerId}/pets/{petId}/microchip/new` | `src/main/kotlin/.../microchip/RegisterMicrochipController.kt` |
+| ref:<eventId> | insert into `microchips` via `MicrochipRepository#save` | `src/main/kotlin/.../microchip/MicrochipRepository.kt` |
+
+## Fields
+| Element | Field | Code |
+|---------|-------|------|
+| ref:<commandId> | `microchipNumber` | request param → `Microchip.microchipNumber` → column `microchips.microchip_number` |
+
+## Specifications → Tests
+| Specification | Test |
+|---------------|------|
+| <spec title> | `RegisterMicrochipControllerTest#<method>` |
+
+## Files
+**Created**
+- `path/to/NewFile.kt`
+
+**Modified (shared seams)**
+- `path/to/schema.sql` — <what changed: new table / route / registration>
+
+## Assumptions
+- <one line each, or "none">
+```
+
+Keep it compact: one row per element, field and specification — no code excerpts, no narrative. Paths are repo-relative.
+
+## Step 3 — Locate the slice's column
+
+The slice border carries its chapter and column: `parentId` is the chapter (timeline) id, `data.colId` the column id.
+
+Prefer MCP:
+
+```
+mcp__eventmodelers__get_node { "boardId": "<BOARD_ID>", "nodeId": "<SLICE_ID>" }
+```
+
+**Fallback (no MCP):**
+
+```bash
+curl -s -H "x-token: <TOKEN>" -H "x-user-id: record-evidence-skill" \
+  "<BASE_URL>/api/org/<ORG_ID>/boards/<BOARD_ID>/nodes/<SLICE_ID>"
+```
+
+Save `parentId` as `CHAPTER_ID` and `data.colId` (or `meta.colId`) as `COLUMN_ID`.
+
+## Step 4 — Find or add the "Implementation" lane
+
+Read the chapter's grid:
+
+```
+mcp__eventmodelers__get_node { "boardId": "<BOARD_ID>", "nodeId": "<CHAPTER_ID>", "projection": "cells" }
+```
+
+```bash
+curl -s -H "x-token: <TOKEN>" -H "x-user-id: record-evidence-skill" \
+  "<BASE_URL>/api/org/<ORG_ID>/boards/<BOARD_ID>/nodes/<CHAPTER_ID>?projection=cells"
+```
+
+In `rows`, look for a row with `type: "feedback"` and label `Implementation` (case-insensitive). Save its `id` as `ROW_ID`.
+
+**Never write into any other feedback lane** — other lanes (e.g. `Decisions`) belong to the modeling kit or to people. If there is no `Implementation` lane, add one:
+
+```
+mcp__eventmodelers__add_lane { "boardId": "<BOARD_ID>", "timelineId": "<CHAPTER_ID>", "lanes": [{ "type": "feedback", "label": "Implementation" }] }
+```
+
+```bash
+curl -s -X POST "<BASE_URL>/api/org/<ORG_ID>/boards/<BOARD_ID>/timelines/<CHAPTER_ID>/lanes" \
+  -H "Content-Type: application/json" -H "x-token: <TOKEN>" -H "x-user-id: record-evidence-skill" \
+  -d '{"type":"feedback","label":"Implementation"}'
+```
+
+and take `ROW_ID` from the response.
+
+Then check `cells` for an entry with `rowId == ROW_ID` and `colId == COLUMN_ID`. If there is one, save its `nodeId` as `NOTE_ID` — this slice already has an evidence note (from an earlier build) and it gets **replaced**, not duplicated.
+
+## Step 5 — Create or update the note
+
+The note's content lives in `meta.description` (markdown source) — **not** `meta.content`, which is stored but never rendered.
+
+**No note yet** — create it in the cell `<ROW_ID>-<COLUMN_ID>`:
+
+```bash
+curl -s -X POST "<BASE_URL>/api/org/<ORG_ID>/boards/<BOARD_ID>/nodes/events" \
+  -H "Content-Type: application/json" -H "x-token: <TOKEN>" -H "x-user-id: record-evidence-skill" \
+  -d '[{
+    "id": "<new-random-uuid>",
+    "eventType": "node:created",
+    "nodeId": "<new-random-uuid>",
+    "chapterId": "<CHAPTER_ID>",
+    "cellId": "<ROW_ID>-<COLUMN_ID>",
+    "meta": {
+      "type": "MARKDOWN",
+      "title": "Implementation — <Slice Title>",
+      "description": "<markdown from step 2, JSON-escaped>"
+    }
+  }]'
+```
+
+**Note exists (`NOTE_ID`)** — replace its content:
+
+```bash
+curl -s -X POST "<BASE_URL>/api/org/<ORG_ID>/boards/<BOARD_ID>/nodes/events" \
+  -H "Content-Type: application/json" -H "x-token: <TOKEN>" -H "x-user-id: record-evidence-skill" \
+  -d '[{
+    "id": "<new-random-uuid>",
+    "eventType": "node:changed",
+    "nodeId": "<NOTE_ID>",
+    "changedAttributes": ["meta.title", "meta.description"],
+    "meta": {
+      "type": "MARKDOWN",
+      "title": "Implementation — <Slice Title>",
+      "description": "<markdown from step 2, JSON-escaped>"
+    }
+  }]'
+```
+
+With MCP, send the same event through `mcp__eventmodelers__submit_node_events { "boardId": "<BOARD_ID>", "events": [ ... ], "autoConnect": false }`.
+
+Build the JSON body with a tool that escapes properly (e.g. `jq -n --arg d "$(cat note.md)" ...` or a short script) — never hand-escape newlines and quotes.
+
+## Step 6 — Verify and report
+
+Read the note back (`GET .../nodes/<noteId>`) and check that `meta.description` is non-empty and every `ref:` id is one from `slice.json`. Then report:
+
+```
+Recorded evidence for "<Slice Title>" (<SLICE_ID>)
+Note: <noteId> in lane Implementation, column <COLUMN_ID> (created|updated)
+Commit: <sha>
+```
+
+A failed write here never undoes the build: log it in `progress.txt` and continue with the status update — but do not skip this step silently.

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

@@ -4,11 +4,14 @@ This build kit was installed into an **existing codebase** — it ships no scaff
 
 The codebase is typically a classic application (layered, CRUD, a relational database behind services/repositories) — but not necessarily: it may already use domain events, messaging, or event sourcing. Never assume; look.
 
+The usual situation is a **legacy system being extended**: a code base analysis built the event model from the existing code, so most slices on the board — typically those in status `Done` — already exist in the code, and their elements' descriptions reference it. Those slices are the map from board to code: every new slice is built the way its closest existing slice is built.
+
 ## Architecture First
 
-`.build-kit/ARCHITECTURE.md` describes how this codebase works: language, layers, where a feature's files go, persistence and migrations, how state changes are exposed (REST, RPC, UI actions), how reads are served, how background/reactive work is wired, the test style, and the exact build/test commands.
+`.build-kit/ARCHITECTURE.md` describes how this codebase works: language, layers, where a feature's files go, persistence and migrations, how state changes are exposed (REST, RPC, UI actions), how reads are served, how background/reactive work is wired, the test style, the exact build/test commands — and the **Slice map**: which code every existing slice corresponds to, plus where a new slice goes so it stays isolated.
 
 - If `.build-kit/ARCHITECTURE.md` does not exist, run `/learn-architecture` before building anything.
+- If a `Done` slice in the local `index.json` files has no row in the Slice map, run `/learn-architecture slices` before building.
 - Treat it as the authority for *how* to build. Treat `slice.json` as the authority for *what* to build.
 - If the code contradicts `ARCHITECTURE.md` (a moved folder, a renamed base class, a wrong command), fix `ARCHITECTURE.md` in the same iteration rather than working around it.
 
@@ -18,6 +21,7 @@ The codebase is typically a classic application (layered, CRUD, a relational dat
 - **No new architecture**: never introduce a new framework, library, persistence technology or architectural style (event store, CQRS bus, mediator, ...) to build a slice. If the codebase is CRUD, the slice is CRUD.
 - **No dependency changes**: do not add or upgrade dependencies unless slice.json or a slice prompt explicitly asks for it.
 - **Minimal footprint**: touch only the files the slice needs. Do not refactor, reformat or "clean up" unrelated code.
+- **Isolated and deletable**: build each new slice as self-contained as the codebase allows — its own files (its own package/folder where the layout permits), shared files touched only at the seams `ARCHITECTURE.md` names (registration, routing, a new migration), no other code depending on its internals. Deleting a slice should mean deleting its files and reverting the seams listed in its Slice map row. Conventions still come from the codebase; isolation decides *where* the code goes, not *how* it is written.
 
 Ignore case for files and slices in prompts. "CartItems" slice is the same as "cartitems".
 
@@ -37,7 +41,7 @@ When starting to work on a slice, invoke the `update-slice-status` skill with `I
 When asked to build a slice, always follow this flow:
 
 1. Read the slice definition from `.build-kit/.slices/<context>/<slicename>/slice.json`.
-2. Make sure `.build-kit/ARCHITECTURE.md` exists — run `/learn-architecture` if it does not.
+2. Make sure `.build-kit/ARCHITECTURE.md` exists and its Slice map covers every `Done` slice — run `/learn-architecture` (or `/learn-architecture slices`) if not.
 3. Determine the slice type:
    - **Translation** — `sliceType === "TRANSLATION"` → read `description` and `notes` from slice.json for hints; default to `/build-automation` if nothing else is specified
    - **Automation** — `processors` array is non-empty → invoke `/build-automation`
@@ -46,13 +50,15 @@ When asked to build a slice, always follow this flow:
 4. Invoke the matching skill and follow its instructions completely. Do not deviate.
 5. **Verify against slice.json**: After the skill completes, check that every command field, event field, read model field and specification in slice.json has its counterpart 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 the quality checks from `.build-kit/ARCHITECTURE.md` (build/compile, then only the tests this slice touched).
-7. If checks pass, commit with `feat: [Slice Name]` and set slice status to `Done`.
+7. If checks pass, make sure the slice's row in the Slice map is added/updated and commit with `feat: [Slice Name]`.
+8. Invoke `/record-evidence` — it writes the implementation evidence (element → code mapping, files, specification → test mapping, seams, assumptions, commit) as a markdown note into the slice's column, in the chapter's `Implementation` feedback lane.
+9. Set slice status to `Done`.
 
 After you are done, automatically run the tests for the slice that was edited.
 
 ## How Event Modeling maps onto this codebase
 
-The board speaks Event Modeling; the codebase may not. `/learn-architecture` records the concrete mapping in `ARCHITECTURE.md` — the default for a CRUD codebase is:
+The board speaks Event Modeling; the codebase may not. `/learn-architecture` derives the concrete mapping from the existing slices and records it in `ARCHITECTURE.md` — that mapping, and the closest `Done` slice's code, always beat the defaults below. The default for a CRUD codebase, used only where no existing slice shows the way, is:
 
 | Board element | Typical CRUD counterpart |
 |---|---|

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

@@ -4,6 +4,8 @@ You are an autonomous coding agent working on a software project. You apply your
 
 This kit runs inside an **existing codebase** — nothing was scaffolded for you. The code is not necessarily event-sourced; typically it is a classic layered/CRUD application. The slice describes *what* must happen (commands, events, read models, specifications); the existing code decides *how* it is built. `.build-kit/ARCHITECTURE.md` is the record of how this codebase works — if it does not exist yet, run `/learn-architecture` before anything else.
 
+Usually this is a legacy system being extended: the event model was built from the existing code, so most slices — typically those in status `Done` — already exist in the code. The **Slice map** in `ARCHITECTURE.md` says where; every new slice is built the way its closest existing slice is built, and placed as isolated and deletable as the codebase allows.
+
 ## Context Boundary (READ FIRST — NON-NEGOTIABLE)
 
 You work within **exactly ONE context at a time** — the one named in `.build-kit/.slices/current_context.json`.
@@ -11,11 +13,12 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 - **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 "Planned" slices, and even if the current context has no work left.
 - A "Planned" slice in a *different* context is **NOT yours to build**. Ignore it completely.
+- The one exception is **reading** `Done` slices of other contexts as precedents (through the Slice map in `ARCHITECTURE.md`, or by `/learn-architecture` building that map) — they show how the codebase builds things, they are never built.
 - If the current context has no "Planned" slice, you are **done for this iteration** — reply `<promise>NO_TASKS</promise>` and stop. Do not go looking elsewhere. The context is only ever changed on the board, never by you.
 
 ## Your Task
 
-0. Do not read the entire code base. `.build-kit/ARCHITECTURE.md` tells you where to look; read the reference implementations it names and the files the slice actually touches.
+0. Do not read the entire code base. `.build-kit/ARCHITECTURE.md` tells you where to look; read the code of the precedent slices its Slice map names and the files the slice actually touches. If a `Done` slice has no row in the Slice map, run `/learn-architecture slices` first.
 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 "planned" is a task.
 2. Read the progress log at `progress.txt` **if it exists** (check Codebase Patterns section first) — it is absent until the first slice is built, which is not an error; create it when you write your first entry
 3. Make sure you are on the right branch "feature/<slicename>", if unsure, start from main.
@@ -33,10 +36,11 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 12. Make sure to write the ui-prompt.md as defined if defined in the skill
 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. 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).
-16. Append your progress to `progress.txt` after each step in the iteration.
-17. Append your new learnings to `.build-kit/AGENTS.md` in a compressed form, reusable for future iterations. Only add learnings if they are not already there.
-18. Finish the iteration.
+15. Invoke `/record-evidence` to write the implementation evidence (element → code mapping, files, specification → test mapping, seams, assumptions, commit) as a note into the slice's column, in the chapter's `Implementation` feedback lane.
+16. 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).
+17. Append your progress to `progress.txt` after each step in the iteration.
+18. Append your new learnings to `.build-kit/AGENTS.md` in a compressed form, reusable for future iterations. Only add learnings if they are not already there.
+19. Finish the iteration.
 
 ## Escalating Ambiguity
 
@@ -93,7 +97,8 @@ Only update AGENTS.md if you have **genuinely reusable knowledge** that would he
 - If a command there turns out to be wrong, fix it in `ARCHITECTURE.md` in the same iteration
 - Do NOT commit broken code
 - Keep changes focused and minimal
-- Follow existing code patterns — match the architecture, naming and test style already in the codebase; never introduce a new framework, library or architectural style to build a slice
+- Follow existing code patterns — match the architecture, naming and test style already in the codebase (the closest `Done` slice's code first); never introduce a new framework, library or architectural style to build a slice
+- Keep each slice isolated and deletable: its own files, shared files only at the seams `ARCHITECTURE.md` names, listed in the slice's Slice map row
 
 ## Skills
 

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

@@ -54,7 +54,7 @@ This is the build trigger. Setting `InProgress` and building are one atomic step
 
 2. Run `/load-slice sliceId=<payload.sliceId>` to fetch the full slice, then read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json`. The runner keeps a `slice.json` fresh from a summary endpoint, so a file holding only `id`, `title`, `status` and `sliceType` is that stub, not an empty slice — never conclude a slice has no elements from it. Only if the full fetch itself returns no commands/events/read models/fields is the slice actually empty.
 
-3. Make sure `.build-kit/ARCHITECTURE.md` exists — if it is missing, run `/learn-architecture` first. This kit installs into an existing codebase: that file records how *this* project is built (layers, persistence, naming, tests, build/test commands), and every `build-*` skill implements the slice the way the codebase already works.
+3. Make sure `.build-kit/ARCHITECTURE.md` exists — if it is missing, run `/learn-architecture` first; if a `Done` slice has no row in its Slice map, run `/learn-architecture slices`. This kit installs into an existing codebase — usually a legacy system whose event model was built from its code, so most `Done` slices already exist in it. That file records how *this* project is built (layers, persistence, naming, tests, build/test commands) and which code each existing slice maps to; every `build-*` skill implements the slice the way its closest existing slice is built, kept as isolated and deletable as the codebase allows.
 
 4. Determine the **slice type** from the slice.json:
    - **Translation** — `sliceType === "TRANSLATION"` → read `description` and `notes` from slice.json for hints; default to `/build-automation` if nothing else is specified
@@ -70,7 +70,9 @@ This is the build trigger. Setting `InProgress` and building are one atomic step
 
 8. If checks pass, commit all changes with message: `feat: [Slice Name]`.
 
-9. Call `/update-slice-status` to set the slice to `Done` on the board.
+9. Call `/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 on the board.
+
+10. Call `/update-slice-status` to set the slice to `Done` on the board.
 
 #### `InProgress`
 Another agent is already building this slice. Log it and skip — do not build.

package/stacks/modeling-kit/templates/.claude/skills/detect-model-drift/SKILL.md

@@ -1,21 +1,29 @@
 ---
 name: detect-model-drift
-description: Compare the event model on the board with the code in this repository and report where they have drifted apart — fields on commands/events/read models, specifications vs tests, screens, edges, slices missing in code, and slices in code that the model doesn't have. `--branch <name>` compares against that branch's code (default: the current branch's working tree). Read-only; every finding comes with a suggested fix the user confirms first.
+description: Find where the code has moved away from the event model since the last analysis — reads the baseline commit from each chapter's first-column note (Analysis history), takes every commit since then as the changes made, and reports how the changed code now differs from the board (fields, specifications/tests, screens, edges, elements, slices). Changes on the board are out of scope — the model leads, the code follows. `--branch <name>` checks that branch's history instead of the current one. Read-only; every finding comes with a suggested fix the user confirms first.
 ---
 
 # Detect Model Drift
 
-## Step 0 — Is there a code base?
+**Drift is a change in the code that the model doesn't reflect.** People model first and then have an agent build it, so a difference that comes from the board (a field renamed on the board, a new slice not built yet) is planned work, not drift, and this skill ignores it. What it looks for is the other direction: someone changed the code by hand (a manual commit, a hotfix, a refactoring) and the board no longer describes what the code does.
 
-Drift is the gap between the board and the code, so it can only be detected where code exists. **Before anything else — before `connect`, before reading the board — resolve the directory to check**: `$EVENTMODELERS_CODE_DIR` if it is set (the agent runs from the global install and was started inside that directory — treat it as the repository root for every step below, not the current directory), otherwise the current directory. Check that it is a code base: it contains source code (e.g. `src/`, `.build-kit/`, a `package.json`, `pom.xml`, `*.csproj`, `build.gradle`, or similar project files with slice/command/event/projection code).
+So the skill looks at **the code changes since the last analysis**, nothing else:
 
-If it is not (an empty folder, a modeling-only workspace holding just `.claude/`, `.eventmodelers/` or `.agent-modeling-kit/`), **stop and answer in one or two plain sentences**, e.g.:
+1. the baseline is the commit of the last row in the chapter note's *Analysis history* (first column of the chapter),
+2. every commit since then (plus uncommitted changes) is a change that was made,
+3. for each change, compare what the code now does with what the board says. The differences are the drift.
 
-> Model drift can't be detected here — there is no code to compare the board against. Run this in the code base that implements the model.
+## Step 0 — Is there a code base with history?
 
-Do not connect, do not read the board, do not produce a report or snippet, and do not offer other fixes.
+**Before anything else — before `connect`, before reading the board — resolve the directory to check**: `$EVENTMODELERS_CODE_DIR` if it is set (the agent runs from the global install and was started inside that directory — treat it as the repository root for every step below, not the current directory), otherwise the current directory.
 
-**With `--branch <name>`** (see Step 1), also check that the branch exists in that code base: `git rev-parse --verify <name>`, else `git fetch origin <name>` and `git rev-parse --verify origin/<name>`. Use whichever resolves as `REF`. If neither does, stop the same way in one sentence (*"There is no branch `<name>` in this repository."*).
+- It must contain source code (e.g. `src/`, `.build-kit/`, a `package.json`, `pom.xml`, `build.gradle`, `*.csproj`, or similar). If it does not (an empty folder, a modeling-only workspace holding just `.claude/`, `.eventmodelers/` or `.agent-modeling-kit/`), **stop and answer in one or two plain sentences**, e.g.:
+  > Model drift can't be detected here — there is no code to compare the board against. Run this in the code base that implements the model.
+- It must be a git repository (`git rev-parse --is-inside-work-tree`). If it is not, stop the same way: *"Drift is detected from the git history since the last analysis, and this code base has no git history. Run `/analyze-code-base` for a full analysis instead."*
+
+Do not connect, do not read the board, and do not produce a report when either check fails.
+
+**With `--branch <name>`** (see Step 1), check that the branch exists: `git rev-parse --verify <name>`, else `git fetch origin <name>` and `git rev-parse --verify origin/<name>`. Use whichever resolves as `REF`. If neither does, stop in one sentence (*"There is no branch `<name>` in this repository."*). Without `--branch`, `REF` is `HEAD`, and uncommitted changes in the working tree count too.
 
 ---
 
@@ -23,7 +31,7 @@ Do not connect, do not read the board, do not produce a report or snippet, and d
 
 Prefer `mcp__eventmodelers__*` tools when available. See `learn-eventmodelers-api` for the curl fallback.
 
-The board is the intended design, the code is what was built. Over time the two part ways: someone edits a handler without touching the model, someone renames a field on the board after the slice was built. This skill finds those places and proposes how to close each gap. **It never changes the board or the code** — it reports, and only acts on what the person confirms.
+**This skill never changes the code**, and it changes the board only for what the person confirms — plus the one *Analysis history* row of Step 7.
 
 ---
 
@@ -33,158 +41,189 @@ From `$ARGUMENTS` and the prompt context, extract:
 
 | Field | How to find it | Default |
 |-------|---------------|---------|
-| `timelineId` | `context.timelineId` of the prompt (overrules the prompt's own `timeline_id`), or a timeline/chapter named in the text | whole board |
+| `timelineId` | `context.timelineId` of the prompt (overrules the prompt's own `timeline_id`), or a timeline/chapter named in the text | every chapter on the board |
 | `contextName` | a bounded context named in the text | all contexts |
 | `sliceTitle` | a single slice named in the text | all slices in scope |
-| `branch` | `--branch <name>` in `$ARGUMENTS`, or a branch named in the text | the current branch's working tree |
-
-**If a timeline is in focus, only that timeline's slices are compared** — both on the board side and, through the slice → code mapping of Step 3, on the code side. Code that belongs to no slice in scope is not reported as "additional" in a scoped run; say so in the report footer instead of guessing.
+| `branch` | `--branch <name>` in `$ARGUMENTS`, or a branch named in the text | the current branch (`HEAD` + working tree) |
+| `since` | `--since <commit>` in `$ARGUMENTS`, or a commit named in the text | the baseline of Step 2 |
 
 ---
 
-## Step 2 — Read the model (once)
+## Step 2 — Find the baseline (per chapter)
 
-Cheapest read first, once per run:
-
-```
-mcp__eventmodelers__list_slices   { "boardId": "$BOARD_ID" }
-mcp__eventmodelers__get_slice_data { "boardId": "$BOARD_ID", "contextName": "<CONTEXT>", "format": "toon" }
-```
+Every chapter carries its own baseline. For each chapter in scope:
 
-Use the **full** slice data (no `projection`): you need fields with types and `idAttribute`, dependencies (the edges), specifications, storylines and screens together. If the scope is a timeline, pass its title as `contextName` and keep only slices whose `chapter` is that timeline.
+1. `get_board_outline { boardId, chapterId }` and take the **first column's** MARKDOWN node in a `feedback` lane — the chapter note (`Legacy Sources — <Chapter>` when `/analyze-code-base` wrote it). Read it with `get_node` → `meta.description`.
+2. Find its `## Analysis history` table and take the **Commit** of the **last row**. Strip a `+dirty` suffix (and note it: the files dirty back then are changed files too). Save it as `BASE`.
+3. Check it: `git cat-file -e <BASE>^{commit}` and `git merge-base --is-ancestor <BASE> <REF>` — the baseline must be in this branch's history.
 
-Call `validate_model { boardId, chapterId }` for a scoped timeline — it already lists structural gaps on the board side (zero/multi-issuer commands, sourceless read models, missing scenarios). Those are model problems, not drift: mention them in one line, don't duplicate them as findings.
+The rest of the note is context for judging findings too — *Where this flow lives* says which folders belong to the chapter, *Chapter decisions* and *Not modeled* say what is deliberately different or left out.
 
-**Always read each chapter's context note before comparing.** The MARKDOWN note in the `feedback` lane of a chapter's **first column** holds the context for that chapter — architecture decisions, intended deviations, what the code is supposed to look like. For every chapter in scope, call `get_board_outline { boardId, chapterId }`, take the first column's node with `type: "MARKDOWN"` in a `feedback` lane, and read its `meta.description` with `get_node`. Judge every finding against it: a difference the note explains is intentional, not drift. A chapter without such a note is fine — carry on without it.
+**No usable baseline** — no first-column note, no *Analysis history*, `no git`, or a hash that is unreachable or not an ancestor (rebased/squashed history): **don't fall back to comparing the whole board against the whole code.** Ask once which commit to start from, offering the most likely one: the newest commit recorded anywhere on the board for that chapter (an `Implementation — <Slice>` evidence note's **Commit**, a column note), or else the last few entries of `git log --oneline -10 <REF>`. A `since` argument answers this up front and overrules the note's baseline.
 
-Index the result in memory: per slice → commands, events, read models, screens, automations, specifications, dependencies.
+Chapters with the same baseline share one git read in Step 3.
 
 ---
 
-## Step 3 — Understand the code
+## Step 3 — Collect the changes since the baseline
 
-The code base is the directory resolved in Step 0 (`$EVENTMODELERS_CODE_DIR`, else the current directory) — every path below is relative to it, and it may hold any stack. Find out which, don't assume.
+For each distinct `BASE`, list the commits and walk them **one by one, oldest first** — never judge from the net diff `<BASE>..<REF>` alone:
 
-**With a `branch` other than the one checked out, read the code from git, never from the working tree:** `git ls-tree -r --name-only $REF [<dir>]` lists the files, `git show $REF:<path>` reads one. That applies to everything below — `.build-kit/CLAUDE.md`, the slice folders. Never `git checkout`/`git switch`: the working tree may hold someone's uncommitted work. Without `branch`, or when it is the current branch, read the working tree as usual.
+```bash
+git log --reverse --format='%h %ad %an %s' --date=short <BASE>..<REF>   # the commits, oldest first
+git show --name-status --format= <sha>                                  # the files one commit touched
+git show <sha> -- <file>                                                # that commit's change to one file
+git diff <sha>..<REF> -- <file>                                         # what happened to a file after a given commit
+git status --porcelain && git diff HEAD                                 # without --branch: uncommitted changes too
+```
+
+Why per commit: when the range contains the commit that **created** a file (e.g. the build kit's `feat: <Slice>`), the net diff shows the file only as "added" with its final content, and a later hand edit (a renamed field, a removed check) disappears inside it — attributed to the build. Walking the commits keeps them apart. Never `git checkout`/`git switch` — read other refs with `git show <REF>:<path>`; the working tree may hold someone's uncommitted work.
 
-1. Read `.build-kit/CLAUDE.md` (and `.build-kit/AGENTS.md` if present) — its *Structure* section says where slices live and how they're named (e.g. `src/slices/{slice}/` for Node, `src/main/java/.../slices/{context}/{slice}/` for Axon).
-2. Without a build kit, infer the layout from the repo (folders named after slices, `*Command*`, `*Event*`, projection/read-model files, route/UI files). If you cannot find any slice structure, stop and tell the user what you looked at — do not fabricate a mapping.
+**Sort per file, not per commit.** One commit can mix kit or tooling files with real code (e.g. a commit that installs a kit *and* renames a field) — the noise files of that commit are dropped, its code files still count:
 
-Build a **code inventory** per slice folder: the command type and its fields, the events it emits and their fields, read-model/projection types and fields, the screens/components/routes wired to it, tests and what they assert, and what each handler/projection/automation reads and writes.
+| Group | Examples | Handling |
+|-------|----------|----------|
+| **Behavior** | controllers/handlers, services, entities/aggregates, events, projections/queries, schema & migrations, validation, templates/UI, tests | compared in Step 5 |
+| **Noise** | dependency bumps, build/CI config, gradle/maven wrappers, formatting-only diffs, docs, `.build-kit/`, `.claude/`, `.agent-modeling-kit/`, `.eventmodelers/`, `.mcp.json`, `CLAUDE.md`, `progress.txt`, generated files | listed in the report footer as *not relevant*, never a finding |
 
-Map slice → code folder by name (ignore case, spaces and the `slice:` prefix, same slug rule as `load-slice`). A slice with no matching folder, or a folder with no matching slice, is itself a finding (5a/5b).
+**Build-kit commits vs. hand-made commits.** A commit is the build kit's only if an `Implementation — <Slice>` evidence note names its sha, or — without evidence notes — its subject is `feat: <Slice Name>` for a slice on the board. It implemented the board, so its files are the **as-built state**: compare it cheaply against that slice only. Every other commit — including any commit after it that touches the same files — is a **hand-made change** and the main subject of this skill: for each file the build kit wrote, the drift candidates are `git diff <buildSha>..<REF> -- <file>`, attributed to the later commits.
 
-Read only the slice folders in scope. Shared event/type folders are read only for the events the in-scope slices reference.
+No behavior changes since the baseline → report *"No code changes since `<BASE>` (<date of that row>) that affect the model"*, do Step 7, and stop.
 
 ---
 
-## Step 4 — Compare
+## Step 4 — Map the changes to the board
 
-Work slice by slice. Every finding records: **kind**, **slice**, **element** (board `nodeId` where there is one), **what the model says**, **what the code says**.
+For every behavior change, find the slice(s) and element(s) it belongs to. Use, in this order:
 
-| Kind | Look for |
-|------|----------|
-| **Slice missing in code** | Slice on the board in status `Planned`/`InProgress`/`Done`… with no code folder. Status `Created`/`Planned` is expected not to have code yet — report only slices the board calls `Done`/`Review`. |
-| **Slice only in code** | Code folder shaped like a slice (command handler, projection, automation) with no slice on the board. |
-| **Fields** | On every COMMAND, EVENT and READMODEL: a field only in the model, a field only in the code, a name that differs (case or typo), a type that differs, `idAttribute` vs `@TargetEntityId`/event tag/aggregate key mismatch, optional vs required. |
-| **Specifications** | A model GWT scenario with no test asserting it; a test (given/when/then) with no matching model scenario; a scenario whose events/fields no longer match the code. Storylines are narrative — compare their beats only for elements that no longer exist. |
-| **Screens** | A SCREEN on the board with no UI counterpart; a UI screen/route/component wired to a slice's command or read model that the board doesn't show; a screen whose displayed read-model fields or submitted command fields differ from the model's dependencies. |
-| **Edges** | Model dependency with no code counterpart, and the reverse: command → event (handler emits it), event → read model (projection consumes it), read model → screen, event → automation → command. A handler that emits an event the model doesn't connect, or a projection subscribing to events the model doesn't wire in. |
-| **Elements** | An event/command/read model present on one side only, or a rename (same fields, different name). |
+1. **`Implementation — <Slice>` evidence notes** (build kit, `Implementation` feedback lane, one per slice column): their *Element → Code*, *Fields*, *Specifications → Tests* and *Files* tables map code back to `ref:<nodeId>`s directly.
+2. **`.build-kit/ARCHITECTURE.md` → Slice map**, if present: entry point, persistence, read/query, tests and shared seams per slice.
+3. **The chapter note's** *Where this flow lives*, and the column decision notes' `Source` references (paths with line numbers).
+4. Names: a command/event/read model/field whose name (or code name) appears in the changed code.
 
-Rules for judging, in order:
+Then read the model **only for the slices you hit**: `get_slice_data { boardId, contextName, sliceId?, format: "toon" }` (full data: fields with types and `idAttribute`, dependencies, specifications, screens), and `get_node` for single elements. Don't read the rest of the board.
 
-- **Obvious typos and clearly wrong flags are one finding with a direct fix** (`custoemrId` in the code vs `customerId` on the board; `idAttribute: false` on the entity's own id) — name the correct side, don't ask which it is.
-- **Direction matters.** A mismatch with no earlier evidence has no "right" side: propose the fix in the direction the evidence points (see Step 5), and say when it is a judgement call.
-- Don't report framework noise: generated ids, metadata/envelope fields, serialization annotations, test fixtures' helper types, routes when the slice has no screen.
-- Don't flag what is clearly intentional (an internal slice with no screen; a read model used only by another read model), or what the chapter's first-column feedback note (Step 2) describes as intended.
-- Report each underlying difference **once**, at the element where it starts; a renamed field shows up on the command and the event and the read model — that is one finding listing the chain, not three.
+A change that maps to no slice is itself a candidate finding — new behavior the board doesn't have (Step 5, *Element* / *Slice*). If it falls inside a chapter's *Where this flow lives* folders, it belongs to that chapter; otherwise say which chapter it most likely belongs to, or that it needs a new one.
 
 ---
 
-## Step 5 — Decide the direction, propose the fix
+## Step 5 — Compare the changed code with the board
 
-For every finding, pick who should move:
+Go change by change. Read the code **as it is at `REF`** (not just the diff hunk) for the elements the change touches, and compare it with what the board says about those elements. Every finding records: **kind**, **commit(s)** (short sha + subject + author), **file(s)** with line, **slice**, **element** (board `nodeId` where there is one), **what the board says**, **what the code now does**.
 
-| Evidence | Fix goes to | How it's done |
-|----------|-------------|---------------|
-| A field, element, spec, screen or edge differs | **Judgement call** — present both options, recommend one | Recommend by which side is more specific/complete. Model fix: `/attributes` (fields), `/timeline` / `/place-element` (elements), `/eventmodeling-elaborating-scenarios` (specs), `/storyboard-screen` or `/html-screen` (screens — including updating every existing screen connected to a changed element, see below). Code fix: set the slice back to `Planned` with `/update-slice-status` so the build kit picks it up again |
-| Slice only in code | **Model** | Add the slice, via `/eventmodeling-slicing-event-models` after placing its elements |
-| Slice missing in code, board says `Done` | **Model status** (it isn't done) | `/update-slice-status` → `Planned` |
+| Kind | A change in the code that … |
+|------|------------------------------|
+| **Fields** | adds, removes or renames a field/parameter/column on a command input, a persisted state (event) or a query result; changes its type, nullability/required-ness, or which field identifies the entity (`idAttribute`) |
+| **Rules / specifications** | adds, removes or changes a validation, a guard, an error case or a default — or a test (given/when/then) — so that the board's GWT scenarios no longer describe the behavior |
+| **Screens** | changes a UI template/component/route so that what it shows (read-model fields) or submits (command fields) differs from the board's SCREEN and its edges |
+| **Edges** | makes a handler persist/emit something the board doesn't connect, a query read data the board doesn't wire in, a reaction (listener, job) trigger or issue something new — or removes such a connection |
+| **Element** | adds a new command/state change/query/reaction, or removes or renames one the board has |
+| **Slice** | adds a whole new feature (entry point + persistence/query) that is no slice on the board, or removes one the board says is `Done` |
 
-**A model fix always includes the existing screens.** When a field, command or read model changes on the board, every SCREEN/HTML_SCREEN that shows or submits it must change with it — otherwise the drift just moves from the code into the storyboard. List each affected screen in the same finding (follow the read model → screen and screen → command edges), and update it in place: `/html-screen` with its `nodeId` (loads the current pages and edits them, plus its `meta.fields`), `/storyboard-screen` for a wireframe sketch. Never create a new screen next to an outdated one.
+Rules for judging:
 
-Never propose "fix the code" by editing it from this skill — code changes belong to the build kit (`/update-slice-status` → `Planned`).
+- **Only changes since the baseline.** Code that was already different from the board at `BASE` is not this run's drift (the last analysis accepted it) — unless a change since then touched it.
+- **Ignore everything that changed only on the board.** A board field the code never had, a `Planned` slice with no code, scenarios added after the build — that is planned work for the build kit, not drift. Don't report it, not even as a footnote.
+- **A change that brings the code closer to the board is no finding** (e.g. a fix that finally implements a modeled scenario). Mention it in the summary at most.
+- Don't flag what the chapter note's *Chapter decisions* / *Not modeled* or a column decision note explain as intended.
+- No framework noise: generated ids, metadata/envelope fields, serialization annotations, test helpers, logging, refactorings that keep behavior (rename of a private method, extract class).
+- **One difference, one finding**: a field renamed in the controller, the entity, the column and the template is one finding listing the chain, at the element where it starts.
 
 ---
 
-## Step 6 — Show the findings; act only on confirmation
+## Step 6 — Propose the fix, show the findings, act only on confirmation
+
+**The code change is the newer decision**, so the default fix is to **update the model** to describe what the code does now. The alternative is to treat the code change as a mistake and have the build kit bring the code back to the board.
+
+| Finding | Recommended fix | Alternative |
+|---------|-----------------|-------------|
+| Field, rule/spec, screen, edge or element changed in code | **Model**: `/attributes` (fields), `/timeline` / `/place-element` (elements, edges), `/eventmodeling-elaborating-scenarios` (rules → GWT), `/html-screen` / `/storyboard-screen` (screens) | **Code**: `/update-slice-status` → `Planned` so the build kit rebuilds it from the board |
+| New feature in code, no slice on the board | **Model**: place its elements, then `/eventmodeling-slicing-event-models` | **Code**: remove it — a decision for a human, never done from here |
+| Board says `Done`, the code was removed | **Model**: remove the slice, or set it back to `Planned` if it is still wanted | — |
+
+Recommend the alternative instead only when the change is evidently accidental (a typo like `custoemrId`, a debugging leftover, a disabled test) — say why.
+
+**A model fix always includes the existing screens.** When a field, command or read model changes on the board, every SCREEN/HTML_SCREEN that shows or submits it changes with it — list each affected screen in the same finding (follow read model → screen and screen → command edges) and update it in place (`/html-screen` with its `nodeId`, `/storyboard-screen`). Never create a new screen next to an outdated one. **Never edit the code from this skill.**
 
 Nothing is modified until the person answers.
 
 ### In a chat (`CHAT_SESSION_ID` is set)
 
-Post **one** `post_chat_message` with a `tasks` snippet — the list of findings *and* the question which fixes to apply (same mechanics as `/wdyt` Step 4.0):
+Post **one** `post_chat_message` with a `tasks` snippet — the findings *and* the question which fixes to apply. Name the range in `text`, so the answering turn can read it back for Step 7:
 
 ```
 mcp__eventmodelers__post_chat_message {
   "boardId": "$BOARD_ID",
   "sessionId": "<CHAT_SESSION_ID>",
-  "text": "Found 6 places where the model and the code differ in Registration. Tick the fixes to apply.",
+  "text": "Since the last analysis (a1b2c3d → 9c1e2f0, 3 commits) the code changed in 2 places the board doesn't show. Tick the fixes to apply.",
   "snippet": {
     "kind": "tasks",
     "headline": "Apply these fixes?",
     "submitLabel": "Apply",
     "tasks": [
-      { "id": "d:model:<nodeId>:field:customerId", "title": "Rename field “custoemrId” to “customerId” on Register Customer", "description": "Code has customerId — model has a typo", "nodeId": "<nodeId>" },
-      { "id": "d:code:<sliceId>", "title": "Rebuild “Cancel Order” — the board added the field “reason” after it was built", "description": "Sets the slice back to Planned", "nodeId": "<sliceId>" }
+      { "id": "d:model:<nodeId>:field:chipId", "title": "Rename field “microchipNumber” to “chipId” on Register Microchip and Microchip Registered", "description": "9c1e2f0 “chip id” renamed it in Microchip.kt and the controller after the slice was built — the board still says microchipNumber", "nodeId": "<nodeId>" },
+      { "id": "d:code:<sliceId>:rule:uniqueness", "title": "Rebuild “Register Microchip” — the uniqueness check was removed in code", "description": "Sets the slice back to Planned", "nodeId": "<sliceId>" }
     ]
   }
 }
 ```
 
-- `title` is the proposed fix, one sentence, plain language. `description` says what differs (model vs code). `nodeId` is the element or slice border to jump to.
+- `title` is the proposed fix, one sentence, plain language. `description` names the commit (sha, subject, author) and what differs.
 - `id` is `d:<model|code|decide>:<nodeId>:<kind>[:<detail>]` — the answering turn remembers nothing, so it must carry the direction and target. Put **every** finding in the one snippet (it pages itself at 5).
-- Zero findings: a one-line text reply, no snippet. Then **end the turn.**
+- Zero findings: a one-line text reply, no snippet, then Step 7.
 
-The answer comes as a `CHAT` turn (`Please do these:` + ticked titles or ids). Read the snippet back with `get_chat_session`, match what was ticked, and create **one prompt** per direction: model fixes → *"Apply these model-drift fixes: `<id> | <title>` per line"*; code fixes → set each slice to `Planned`. Unticked fixes are declined — drop them.
+The answer comes as a `CHAT` turn (`Please do these:` + ticked titles or ids). Read the snippet back with `get_chat_session`, match what was ticked, and create **one prompt** per direction: model fixes → *"Apply these model-drift fixes: `<id> | <title>` per line"*; code fixes → set each slice to `Planned`. Unticked fixes are declined — drop them. Then Step 7.
 
 ### Without a chat
 
-Print the report below, with every finding as a `- [ ]` checkbox carrying its proposed fix, and ask which to apply. Wait for the answer.
+Print the report below, every finding as a `- [ ]` checkbox carrying its proposed fix, and ask which to apply. Wait for the answer, act on it, then Step 7.
 
-Name each slice and element as `[<title>](ref:<nodeId>)` (the slice border's id for a slice). The terminal shows the title, and once the report is in a board note or an element description, a click zooms the canvas to it (see `/learn-eventmodelers-api` *Linking to elements in markdown*). A slice that exists only in code has no node, so it stays plain text.
+Name each slice and element as `[<title>](ref:<nodeId>)` (the slice border's id for a slice); code that has no node stays plain text.
 
 ```
 ## Model Drift — <scope: board | timeline "<title>" | context "<name>">
-Compared: <n> slices on the board, <n> slice folders in code<, branch <name> @ <short sha>>    Analysed: <ISO timestamp>
-
-### Slices
-- [ ] <slice> — in code, not on the board → add it to the model
-- [ ] [<slice>](ref:<sliceBorderId>) — board says Done, no code → set back to Planned
+Changes: <BASE> (<date>, last analysis) → <REF short sha><, branch <name>><, + uncommitted> · <n> commits, <n> files with behavior changes    Analysed: <ISO timestamp>
 
 ### Fields
-- [ ] [<slice>](ref:<sliceBorderId>) / [<element>](ref:<nodeId>): model `customerId: String`, code `custoemrId` → fix model typo
+- [ ] [<slice>](ref:<sliceBorderId>) / [<element>](ref:<nodeId>): board says `microchipNumber`; `9c1e2f0 chip id` renamed it to `chipId` after the build (`7e3d1a2 feat: Register Microchip`) — `Microchip.kt:27`, `RegisterMicrochipController.kt:41`, both tests → rename the field on the command, the event and the screen
 
-### Specifications / Screens / Edges
+### Rules / Specifications · Screens · Edges · Elements · Slices
 - [ ] ...
 
 ### Summary
-<2–3 sentences: how far apart they are, which direction the drift mostly runs, the one fix worth doing first.>
-Not checked: <what was out of scope or unreadable>
+<2–3 sentences: what changed in the code since the last analysis, how much of it the board is missing, the one fix worth doing first.>
+Commits: <sha subject — one line each; mark build-kit commits>
+Not relevant: <noise commits/files>
 ```
 
 Omit empty sections. Say plainly when nothing drifted.
 
 ---
 
+## Step 7 — Move the baseline forward
+
+Once the person has answered (or there was nothing to report), append **one row** to the *Analysis history* of every chapter in scope (`node:changed` on that note's `meta.description` — never edit or drop earlier rows), so the next run starts from here:
+
+```
+| 4 | 2026-10-07 | `9c1e2f0` | drift check since `a1b2c3d` | `Microchip.kt`, `RegisterMicrochipController.kt` | 2 findings: 1 model fix applied, 1 declined |
+```
+
+- **Commit** is `REF`'s short sha; add `+dirty` when uncommitted changes were part of the check. With `--branch`, write `<sha> (<branch>)`.
+- A declined finding is accepted as intended — that is why the baseline still moves past it; record it in the row so it can be found later.
+- A chapter without a chapter note: don't create one here — say in the report that `/analyze-code-base` would add it, and that the next drift check needs `--since` until then.
+- If the person never answers, the baseline stays where it was — the same changes come up again next time.
+
+---
+
 ## Learnings
 
-- No code base in the working directory → drift can't be detected; say so in one line and stop (Step 0).
-- Read-only until confirmed — the report is the product; the fixes run as separate, ticked work.
-- A scoped run (timeline in focus) never reports "slice only in code" for code outside the scope.
-- One difference, one finding: follow a rename along the chain instead of listing it per element.
-- Fixing drift on the model side means updating the existing screens connected to the changed elements too (pages and `meta.fields`), in place — not just the command/event/read model.
-- `--branch` reads the code via `git ls-tree`/`git show` from that ref — never check it out, the working tree may hold someone's uncommitted work. No `--branch` = the working tree, as before.
-- Always read the MARKDOWN note in the feedback lane of each chapter's first column first — it is the chapter's context, and differences it explains are not drift.
-- `.build-kit/.slices` is no evidence for the direction of a fix: every fetch, `/load-slice` and runner loop rewrites it, so it holds the last fetch, not what the code was built from — reading it as "the build" recommends undoing board changes. The direction is a judgement call.
+- Drift = code changed, board didn't. Board-only changes are planned work for the build kit — never report them.
+- The baseline is the last *Analysis history* row of the chapter's first-column note; the changes are `git log/diff <BASE>..<REF>` plus uncommitted work. No baseline → ask for a starting commit, never fall back to a whole-board comparison.
+- The code change is the newer decision: recommend updating the model, unless the change is evidently accidental.
+- Map changes to the board through the `Implementation — <Slice>` evidence notes and the Slice map first, names last; read only the slices hit.
+- Walk the commits one by one and sort per file: a net diff hides a hand edit inside a file the build kit created in the same range, and one commit can mix kit-install noise with real code changes.
+- A build-kit commit (evidence note names its sha, else `feat: <Slice>`) is the as-built state; every later change to its files is a hand-made change.
+- No git history → no drift detection; say so in one line and stop (Step 0).
+- `--branch` reads the code via `git show <REF>:<path>` — never check it out, the working tree may hold someone's uncommitted work.
+- Every completed run appends one *Analysis history* row; an unanswered run doesn't move the baseline.
+- `.build-kit/.slices` is no evidence of what the code was built from: every fetch, `/load-slice` and runner loop rewrites it.

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

@@ -413,7 +413,7 @@ nothing to sanitize either, since a board change is not user text.
 | Business analysis, gap spotting, posting questions | `/wdyt` |
 | Analyse the existing model structure, slice coverage, element counts | `/analyze-existing-model` |
 | Reverse-engineer the business process of an existing code base into the model, as an interview — all chapters first, then one chapter at a time | `/analyze-code-base` |
-| Find where the model and the code have drifted apart (fields, specs, screens, edges, missing/extra slices) and propose fixes | `/detect-model-drift` |
+| Find what changed in the code since the last analysis (git history from the chapter note's baseline) that the model doesn't reflect, and propose fixes | `/detect-model-drift` |
 | Walk someone through a feature slice by slice, or through every slice a planned feature needs (existing, to adjust, new), as a player in the chat | `/walkthrough` |
 | Turn a document or image (e.g. a tender/RFP) into a chaptered event model with screens, scenarios and a written blueprint summary | `/summarize` |
 | Look up any API endpoint or element type not already covered by the skill you're executing | `/learn-eventmodelers-api` |