@eventmodelers/cli 1.0.80 → 1.0.84

package/stacks/modeling-kit/templates/.claude/skills/timeline/references/api-fallback.md

@@ -48,8 +48,6 @@ curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/events" \
     "id": "<event-uuid>",
     "eventType": "node:created",
     "nodeId": "<node-uuid>",
-    "boardId": "<BOARD_ID>",
-    "timestamp": <Date.now()>,
     "chapterId": "<CHAPTER_ID>",
     "cellId": "<CELL_ID>",
     "meta": { "type": "EVENT", "title": "<EventName>" },
@@ -67,8 +65,6 @@ curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/events" \
     "id": "<new-uuid>",
     "eventType": "node:changed",
     "nodeId": "<eventNodeId>",
-    "boardId": "<BOARD_ID>",
-    "timestamp": <Date.now()>,
     "changedAttributes": ["meta.title"],
     "meta": { "type": "EVENT", "title": "<NewTitle>" },
     "node": { "id": "<eventNodeId>", "data": {} }
@@ -84,8 +80,6 @@ curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/events" \
   -d '[{
     "id": "<new-uuid>",
     "eventType": "node:deleted",
-    "nodeId": "<eventNodeId>",
-    "boardId": "<BOARD_ID>",
-    "timestamp": <Date.now()>
+    "nodeId": "<eventNodeId>"
   }]'
 ```

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

@@ -138,7 +138,7 @@ Use the `handle-comment` skill with `action=place` to post each comment. Pass:
 - `type` — `COMMENT` (there is no separate question type — the text itself carries the question)
 - `author` — `wdyt`
 
-Post them together, not one at a time: `handle-comment` sends every comment of a run in a single batch request (`add_comments` over MCP, `POST .../boards/:boardId/comments` over REST).
+Post them together, not one at a time: `handle-comment` sends every comment of a run in a single batch request (one `add_comment` call over MCP, `POST .../boards/:boardId/comments` over REST).
 
 Only post questions that are **genuinely unclear or missing** — don't post observations that are clearly intentional design decisions.
 
@@ -153,18 +153,30 @@ There are two kinds — no text-callout kind; a drawing never carries the questi
 - **Arrow** (`kind: "path"`, `arrowEnd: true`) — the concern is about a missing or unclear relationship *between two elements* (e.g. "does this event actually reach this automation?"). Draw a straight line from one element's position to the other's. `path` is `M 0 0 L <dx> <dy>` in the box's own local coordinates; `x`/`y`/`width`/`height` describe that box in canvas space (so `width`/`height` = the delta between the two elements' positions).
 ```
 mcp__eventmodelers__create_drawing {
-  "boardId": "$BOARD_ID", "kind": "path",
-  "x": <sourceX>, "y": <sourceY>, "width": <dx>, "height": <dy>,
-  "path": "M 0 0 L <dx> <dy>", "arrowEnd": true
+  "boardId": "$BOARD_ID",
+  "drawings": [{
+    "kind": "path",
+    "x": <sourceX>,
+    "y": <sourceY>,
+    "width": <dx>,
+    "height": <dy>,
+    "path": "M 0 0 L <dx> <dy>",
+    "arrowEnd": true
+  }]
 }
 ```
 Get element positions from the slice data already loaded in Step 2. If a position is missing, fetch the nodes you need in **one** call — `mcp__eventmodelers__get_nodes { "boardId": "$BOARD_ID", "nodeIds": [<the ids>] }` — not `get_node` per element.
 - **Group loop** (`kind: "rect"`, drawn around a computed bounding box) — the concern spans a *cluster* of elements together (e.g. "this whole flow assumes nothing ever fails"). There's no dedicated group endpoint — union the elements' own `x`/`y`/`width`/`height` (plus some padding) yourself and draw one `rect` around that box:
 ```
 mcp__eventmodelers__create_drawing {
-  "boardId": "$BOARD_ID", "kind": "rect",
-  "x": <minX - pad>, "y": <minY - pad>,
-  "width": <maxX - minX + 2*pad>, "height": <maxY - minY + 2*pad>
+  "boardId": "$BOARD_ID",
+  "drawings": [{
+    "kind": "rect",
+    "x": <minX - pad>,
+    "y": <minY - pad>,
+    "width": <maxX - minX + 2*pad>,
+    "height": <maxY - minY + 2*pad>
+  }]
 }
 ```
 This is a visual grouping only — unrelated to the `MODEL_CONTEXT` node type; never touch a `modelContext` field to satisfy this.

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

@@ -14,9 +14,10 @@ ones in a compressed, reusable form; only add if not already covered here.
 - `/update-slice-status` rejects moving a slice into a status it's already in — this is a concurrency guard so two agents can't both claim the same slice. Treat this as `ALREADY_IN_STATUS`, not a task failure: drop the prompt, move on to the next task, and do not retry the same update.
 - macOS/BSD `date` silently ignores GNU-only format specifiers like `%N`/`%3N` (sub-second precision) instead of erroring — it prints the literal characters, producing a malformed timestamp that only fails downstream. Don't shell out to `date` for sub-second precision; use `$(( $(date +%s) * 1000 ))` for whole-second-in-ms, or a runtime call (`Date.now()`, `process.hrtime()`) instead.
 - Before retrying a failed shell command a second time, diagnose why it failed (e.g. a GNU/BSD flag mismatch) rather than re-running it unchanged — repeating the same command produces the same failure and just burns retries.
+- A cell address (`B2`, `AE6`) is always read, never computed: `get_board_outline`, `get_nodes` and `get_node` each report a node's `cellName`. An address inferred from a column letter plus a node's place in a list is a guess, and a guess that happens to name an occupied cell is accepted silently by every cell-addressed tool.
 - Orientation and working set are two different reads, in that order: `get_board_outline` (or `get_nodes` with `projection: "line"`) answers *where is the work*, and only then does one full-`meta` `get_nodes`, scoped by `chapterId`/`nodeIds`, cover the nodes actually being touched. Opening with an unscoped full-`meta` read pulls every field body and rendered HTML page on the board to answer the cheapest question of the turn.
 - Both reads are once per turn. A chapter's outline and grid don't move unless something writes to them, so re-read only after a structural write. Three `get_board_outline` calls in one turn means the first two were thrown away.
-- Mint ids and timestamps once per turn, in one shell: `for i in $(seq <n>); do uuidgen; done; echo $(( $(date +%s) * 1000 ))`. Nothing in it depends on anything being read, so splitting it across three calls buys three round trips for nothing.
+- Mint ids once per turn, in one shell: `for i in $(seq <n>); do uuidgen; done` — one per new node, plus one per event, since every event needs its own fresh `id` (required; not the node id). Nothing in it depends on anything being read, so splitting it across several calls buys round trips for nothing. Never mint a per-event `boardId` or `timestamp` — both are server-derived and ignored if sent.
 - A subagent is a fresh session: it gets `token=`/`org=`/`baseUrl=`/`board=` inline as already-resolved values (which satisfies `connect` at its Step 0 — tell it not to invoke `/connect`) plus the board state already read for it, inline. Handed bare node ids instead, it has exactly one way to recover the rest — re-reading the whole board, once per agent.
 - Dispatch executor agents with `model:` set to the session header's `subagent_model` (default `sonnet`). The judging happened before the dispatch, on this session's model; what's left is execution against a written brief. Keep an agent on the session model only where its piece re-derives modeling structure (a chain's shape, a slice boundary).
 - Only slices in status `Created` may be modified. `get_nodes` returns `sliceStatus` per node and `get_board_outline` per column, so the board read at `/connect` Step 5 already answers it — absent means the element is in no slice (writable), not locked. Never spend a `list_slices`/`get_slice_data` call just to check whether you may write.

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

@@ -96,7 +96,7 @@ stale. Then a single full-`meta` `get_nodes`, scoped by
 `chapterId` or `nodeIds`, covering the nodes you concluded you will touch. Both tiers are once per turn: keep what
 came back and answer later questions from it instead of re-fetching a chapter you already hold. `/connect` Step 5
 carries the full discipline — the two tiers, the one-call `submit_node_events` rule for writes, and the per-turn
-pool for the ids and timestamps a `node:created` needs. Whatever you hand a subagent comes out of that same read,
+pool for the ids a `node:created` needs (one for the node, one for the event itself). Whatever you hand a subagent comes out of that same read,
 never out of a second one it pays for itself (step 2).
 
 **Every prompt gets exactly two `/update-prompt-status` calls per turn — never zero, never one.** `IN_PROGRESS` before you start the work (step 4), `DONE` after you finish it (step 6). This holds even for a prompt that turns out to be trivial or a no-op — the board UI has no other way to know the agent picked it up and finished it.