@eventmodelers/cli 1.0.106 → 1.0.107

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@eventmodelers/cli",
-  "version": "1.0.106",
+  "version": "1.0.107",
   "description": "Eventmodelers CLI — real-time Claude agent + skills for Claude Code, for any stack (Node, Supabase, Axon, OpenCQRS, UmaDB, Kurrent, or modeling-only)",
   "type": "module",
   "bin": {

package/shared/skills/learn-eventmodelers-api/SKILL.md

@@ -29,7 +29,7 @@ Write tools take their items as an array (`nodeIds[]`, `elements[]`, `connection
 | `get_nodes` | `boardId`, `type?`, `name?`, `chapterId?`, `nodeIds?`, `projection?` (`"line"`) | List nodes, optionally by type and/or a partial case-insensitive title match. **Unscoped with full `meta` it is expensive** — about 2 KB per node, ~1 MB on a 500-node board — so always pass a filter or `projection: "line"`. `chapterId` scopes to one timeline — prefer this over an unscoped board-wide call whenever the step is working within one chapter (the common case); `nodeIds` fetches a known, scattered subset in one call (e.g. re-verifying exactly the nodes just touched by a batch write) instead of a full `type` refetch; `projection: "line"` maps each match to `{id, type, title, fields}` — `fields` being just the attribute names. No `cellName` — an existing node is addressed by its `id`; when a cell address is needed (placing into a cell), read it from `get_board_outline`. No `sliceStatus` — take it per column from `get_board_outline` | §3 `GET .../nodes` (REST records carry no `cellName`, `projection=line` included) |
 | `get_node` | `boardId`, `nodeId`, `projection?` (`"cells"` \| `"edges"`) | Get one node (no `cellName` — address it by `nodeId`; cell addresses come only from `get_board_outline`). `projection: "cells"` (CHAPTER nodes only) returns just `{rows, columns, cells}` instead of the full `timelineData` — use whenever only the grid/occupancy is needed, not the whole chapter; `projection: "edges"` returns just that node's inbound/outbound connections instead of `findNodeById`'s full record. Both are opt-in — omitting `projection` is the unchanged full response. An unknown id is a `NODE_NOT_FOUND` error | §3 `GET .../nodes/:nodeId` (REST returns the node as stored, without `cellName`; `404` carries `code: 'NODE_NOT_FOUND'`) |
 | `get_node_comments` | `boardId`, `nodeId` | List comments on a node | §1 `GET .../nodes/:nodeId/comments` |
-| `get_chat_attachment` | `boardId`, `sessionId`, `attachmentId` | The file a chat message came with — the message's `attachments` list `{id, type, ending}`. Images come back as images, a PDF as an embedded resource, csv / xml / txt / json as text. Only the agent the message was addressed to can read it (`CHAT_ATTACHMENT_NOT_FOUND`); needs the connection's `x-agent-id` (`CHAT_AGENT_REQUIRED`). Max 2 MB per file. | §15 `GET /api/org/:orgId/chat/sessions/:sessionId/attachments/:attachmentId` |
+| `get_chat_attachment` | `boardId`, `sessionId`, `attachmentId` | The file a chat message came with — the message's `attachments` list `{id, type, ending}`. Images come back as images, a PDF as an embedded resource, csv / xml / txt / json as text. Only the agent the message was addressed to can read it (`CHAT_ATTACHMENT_NOT_FOUND`); needs the connection's `x-agent-id` (`CHAT_AGENT_REQUIRED`). Max 5 MB per file. | §15 `GET /api/org/:orgId/chat/sessions/:sessionId/attachments/:attachmentId` |
 | `get_board_events` | `boardId`, `since?`, `seq?` | A page of at most 300 board events, oldest first, as `{events, pageSize, hasMore}`. Not the whole log: while `hasMore` is true, page on by passing the last event's `seq` as `since`. `seq` returns only the event of exactly that seq | §1 `GET .../events` |
 | `submit_node_events` | `boardId`, `events[]`, `autoConnect?`, `compact?` | Create/update nodes (raw `NodeChangeEvent`/edge events). Every event property is described on the tool's own `events[]` schema — read that rather than this skill when all you need is the event shape. An event needs its own `id` (required — a fresh uuid per event, never the node id) and its `eventType`, plus the keys of its kind (`nodeId`/`meta`/`node`, or `edgeId`/`source`/`target`). The `id` keys the returned `hashes` map and makes a resubmit idempotent — the same event sent twice under one id writes a single board event. Don't send `boardId` or `timestamp` per event — the server takes the board from the call and stamps the time itself, and ignores both if sent. `autoConnect: false` places freshly-created nodes without wiring them to their own/previous-column neighbors (avoids a stray nearest-left edge); `compact: true` returns `{persisted: <count>}` instead of the per-node hash map | §3 `POST .../nodes/events` |
 | `delete_node` | `boardId`, `nodeIds[]` | Delete nodes, applied in order — one failure doesn't stop the rest; answers `{results}`. Deleting a chapter (timeline) cascades — every node placed in one of its cells, plus any node parented to it (e.g. SLICE_BORDER), is deleted too, along with all their edges | (via `node:deleted` event, §3) |
@@ -1052,7 +1052,7 @@ Check whether an agent has pinged for a board within the last 45s. Auth: Supabas
 
 ## 15. Chat attachments
 
-A chat message can carry one file (image: png/jpg/gif/webp, pdf, csv, xml, txt, json — max 2 MB). A `CHAT` turn's header lists it as `attachments=[{"id","type":"blob","ending"}]`; the same list is on every message of `get_chat_session` and `chat/next`. Prefer the MCP tool `get_chat_attachment`.
+A chat message can carry up to 3 files (image: png/jpg/gif/webp, pdf, csv, xml, txt, json — max 5 MB each). A `CHAT` turn's header lists them as `attachments=[{"id","type":"blob","ending"}]`; the same list is on every message of `get_chat_session` and `chat/next`. Prefer the MCP tool `get_chat_attachment`.
 
 ### GET `/api/org/:orgId/chat/sessions/:sessionId/attachments/:attachmentId?board_id=:boardId`
 The file itself (raw bytes, `Content-Type` per the ending). Auth: `x-token` + `x-agent-id` — only the agent the message was addressed to can read it.
@@ -1062,7 +1062,7 @@ The file itself (raw bytes, `Content-Type` per the ending). Auth: `x-token` + `x
 The person's side (upload, send with `attachments: [{id}]`, read) is the user-authenticated UI; an agent does not upload.
 
 ### How to handle an attachment in a chat turn
-- **Read a file once, when its message arrives** — the turn whose header carries it. The CLI has already downloaded it: `attachment_files=[{"id":…,"path":…}]` gives the local path — open that with your file reader (images and PDFs included). Without an `attachment_files` entry (the download failed) use `get_chat_attachment` with `boardId`, `sessionId` (this turn's `session_id`) and `attachmentId`.
+- **Read each file once, when its message arrives** — the turn whose header carries it. A message may carry several: go through every entry. The CLI has already downloaded it: `attachment_files=[{"id":…,"path":…}]` gives the local path — open that with your file reader (images and PDFs included). Without an `attachment_files` entry (the download failed) use `get_chat_attachment` with `boardId`, `sessionId` (this turn's `session_id`) and `attachmentId`.
 - **Never on later turns.** `get_chat_session` lists the attachments of every message in the conversation; that is not an invitation to read them. Assume you read each one when it arrived and what you took from it is in the conversation. Fetch one again (`get_chat_attachment`) only when the person explicitly asks you to look at that file again.
 - The text may be empty (the file *is* the message) or point at it ("like this", "build this screen"). A screenshot or mockup is a source for the model, not something to copy: model what it shows (screens → `/storyboard-screen`, a csv or json → example data, a document → events and slices).
 - When you create work from it, **put what you read into the prompt's text** — element names, fields, what the screenshot shows — because a prompt turn has no attachment of its own; never refer to it as "the attached file".