@eventmodelers/cli 2.0.8 → 2.0.9

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@eventmodelers/cli",
3
- "version": "2.0.8",
3
+ "version": "2.0.9",
4
4
  "description": "Eventmodelers CLI — real-time Claude agent + skills for Claude Code, for any stack (Node, Supabase, Axon, OpenCQRS, UmaDB, Kurrent, or modeling-only)",
5
5
  "type": "module",
6
6
  "bin": {
@@ -70,7 +70,7 @@ Write tools take their items as an array (`nodeIds[]`, `elements[]`, `connection
70
70
  | `get_image_snapshot_description` | `boardId`, `nodeId` | Load the `{elements:[...]}` sketch description from storage | — (reads what §4 sketch endpoints write) |
71
71
  | `validate_slice_data` | `sliceData` | Offline validation of a `SliceDataOutput` payload — no board access | — (MCP-only, pure function) |
72
72
  | `commit_board_to_git` | `boardId` | Force a git-extension commit/push, bypassing the autoCommit gate | — (MCP-only; git extension) |
73
- | `update_prompt_status` | `promptId`, `newStatus`, `comment?` | Update a prompt's lifecycle status (`ADDED`/`CLAIMED`/`IN_PROGRESS`/`DONE`), optionally with a progress comment. Not board-scoped — no `boardId` arg; the prompt's board is resolved server-side. | §14 `POST .../prompts/:id/status` |
73
+ | `update_prompt_status` | `promptId`, `newStatus`, `comment?` | Update a prompt's lifecycle status (`ADDED`/`CLAIMED`/`IN_PROGRESS`/`DONE`/`FAILED`), optionally with a progress comment. Not board-scoped — no `boardId` arg; the prompt's board is resolved server-side. | §14 `POST .../prompts/:id/status` |
74
74
 
75
75
  **Not exposed via MCP at all** — always use REST/curl for these: §7 Config Import, §10 Snapshots, §11–12 Invitations, §13 Utility (`/api/user`, swagger), and the rest of §14 Prompts (submission, claiming, deletion, realtime-token) — only the status-update endpoint has an MCP tool (`update_prompt_status`, used by the `update-prompt-status` skill); everything else in Prompts is an intentionally separate lifecycle the board-content MCP server doesn't otherwise own.
76
76
 
@@ -1013,7 +1013,7 @@ OpenAPI specification (JSON)
1013
1013
 
1014
1014
  **File**: `src/slices/change/api-prompts/routes.ts`
1015
1015
 
1016
- Prompts are how a human submits work to a modeling agent from the board UI, and how that agent reports its lifecycle back onto the board. Every prompt row has a `status`: `ADDED` (submitted, default) → `CLAIMED` (an agent has picked it up) → `IN_PROGRESS` (an agent is actively working it) → `DONE` (finished). See the `update-prompt-status` skill for the agent-side half of this lifecycle.
1016
+ Prompts are how a human submits work to a modeling agent from the board UI, and how that agent reports its lifecycle back onto the board. Every prompt row has a `status`: `ADDED` (submitted, default) → `CLAIMED` (an agent has picked it up) → `IN_PROGRESS` (an agent is actively working it) → `DONE` (finished) or `FAILED` (not resolved, whether nothing or only part of it could be done — the board keeps the agent task, red, instead of fading it out). See the `update-prompt-status` skill for the agent-side half of this lifecycle.
1017
1017
 
1018
1018
  ### POST `/api/org/:orgId/prompts`
1019
1019
  Submit a prompt for a board timeline. Auth: Supabase JWT (`Authorization: Bearer`).
@@ -30,7 +30,8 @@ Valid `newStatus` values (case-sensitive):
30
30
  | `ADDED` | Default — submitted, not yet claimed. You should never need to set this yourself. |
31
31
  | `CLAIMED` | Already set automatically when `/api/org/:orgId/prompts/next` hands you the prompt — you should never need to set this yourself either. |
32
32
  | `IN_PROGRESS` | You have started working on this prompt. |
33
- | `DONE` | You have finished working on this prompt. |
33
+ | `DONE` | You have finished working on this prompt and it is resolved. |
34
+ | `FAILED` | The prompt is not resolved: you could not do it at all (nothing changed on the board), or only part of it, because it was ambiguous, blocked, or the work did not succeed. The board shows the task red and keeps it instead of fading it out like a `DONE` one. Always give a `comment` saying what is unresolved. |
34
35
 
35
36
  If `newStatus` is not one of these exact values, stop and tell the user the valid options.
36
37
 
@@ -103,7 +103,7 @@ attribute names, `get_node` `projection: "cells"` for a grid and `"edges"` for o
103
103
  `get_slice_data` `projection: "outline"` / `"fields"` / `"specs"` instead of the full graph unless the step needs
104
104
  elements, specs and comments together. The decision table is in `learn-eventmodelers-api` → *Which read to use*.
105
105
 
106
- **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.
106
+ **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` (or `FAILED` if it could not be resolved) 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.
107
107
 
108
108
  ## Per-turn steps
109
109
 
@@ -147,8 +147,8 @@ mention it in the `DONE` comment, and leave it for a self-directed turn (or for
147
147
 
148
148
  **Questioning rule**: you are running autonomously — no human is available to answer questions. (A `CHAT` turn never reaches this rule: there someone *is* waiting, and you ask back in the chat — see "Chat turns".) If you need clarification, do not pause or ask interactively — post a comment (`/handle-comment` with `action=place`, `type=COMMENT`) on the most relevant node. Then:
149
149
  - If a reasonable default interpretation exists, continue with it.
150
- - If it doesn't — the prompt is ambiguous enough that any guess risks doing the wrong thing — stop instead of guessing. Skip straight to step 6 and mark the prompt `DONE` with a comment explaining what's unclear and pointing to the comment you just posted. Never leave a prompt neither progressed nor closed.
151
- 6. **Mark the prompt as finished** — invoke `/update-prompt-status` with this turn's `prompt_id`, `newStatus=DONE`, and a `comment` that summarizes what you actually did (e.g. "Added the OrderPlaced event and wired it to the read model"). Do this once, right after the work is done — not per skill call within the turn.
150
+ - If it doesn't — the prompt is ambiguous enough that any guess risks doing the wrong thing — stop instead of guessing. Skip straight to step 6 and mark the prompt `FAILED` with a comment explaining what's unclear and pointing to the comment you just posted. Never leave a prompt neither progressed nor closed.
151
+ 6. **Mark the prompt as finished** — invoke `/update-prompt-status` with this turn's `prompt_id`, `newStatus=DONE`, and a `comment` that summarizes what you actually did (e.g. "Added the OrderPlaced event and wired it to the read model"). If the prompt was not resolved (you could not do it at all, stopped on an ambiguity, hit an error you could not fix, or only part of it was done), use `newStatus=FAILED` instead, with a `comment` saying what is unresolved — a `DONE` prompt disappears from the board, a `FAILED` one stays visible in red. Do this once, right after the work is done — not per skill call within the turn.
152
152
  7. If this turn has a `comment_id` field, invoke `/handle-comment` with `action=resolve`, `nodeId` from the resolved `NODE_ID` (step 3), `commentId` from `comment_id`.
153
153
  8. **`standalone=off` only** — if you noticed something reusable this turn (a pattern, a gotcha, useful context about this model), end your reply with one line per learning: `Learning [<topic>]: <one terse line>` (the topic is optional, at most five lines). The CLI records them — never write them into a file yourself, and add nothing that is already in `.agent-modeling-kit/AGENTS.md`. In a `standalone=on` session skip this: that session writes no files (see Mode), so note anything worth keeping as a board comment instead.
154
154
  **In every session, `standalone=on` too:** anything that is *not* a reusable learning — something you could not change and why, a decision you took — goes the same way as `Info [limitation|decision|note]: <one terse line>` (at most five lines). The CLI records each as an event; never leave it only in prose.