@thehammer/danx-dashboard-mcp 0.1.308 → 0.1.310

package/README.md

@@ -61,7 +61,7 @@ Card and plan reads/writes go through `danxbot_api` against the issue/plan route
 
 ## `plan_events_wait` — a working session's plan events (DX-4233)
 
-A program calls this, not a person: the danxbot Claude Code plugin's relay loop, inside the session, calls it over and over on the session's own danx-dashboard MCP server and hands every event it gets to the session. A plan-orchestrator dispatch (a headless session that works one plan) has no plugin relay, so it keeps ONE background waiter sub-agent that loops on this tool until events exist and returns them with the last cursor, and the orchestrator passes that cursor to the next waiter it arms (DX-4667); the `plan-orchestrator` profile alone is granted the tool on a dispatch (it is an opt-in tool). The `bridge` subcommand is gone: no process is spawned, no `npx` cold start, and nothing outlives the session, because the stream lives in the MCP server, which ends with its session.
+A program calls this, not a person: the danxbot Claude Code plugin's relay loop, inside the session, calls it over and over on the session's own danx-dashboard MCP server and hands every event it gets to the session. An orchestrator dispatch (a headless session that works one plan) has no plugin relay, so it keeps ONE background waiter sub-agent that loops on this tool until events exist and returns them with the last cursor, and the orchestrator passes that cursor to the next waiter it arms (DX-4667); the `orchestrator` profile alone is granted the tool on a dispatch (it is an opt-in tool). The `bridge` subcommand is gone: no process is spawned, no `npx` cold start, and nothing outlives the session, because the stream lives in the MCP server, which ends with its session.
 
 Input `{plan_id: number | null, cursor: string | null, timeout_ms: 1000..30000, transcript_path?: string}`. `plan_id` is `null` for a signed-in session on no plan (DX-4882): its stream still carries the pacing and resume messages of its Claude account, and it receives no plan events. A move between a plan and `null` starts clean like a move between plans: the plan-scoped records of the plan left are dropped, the session-scoped ones kept. Answer, one of:
 

package/dist/index.js

@@ -170,7 +170,7 @@ let permissionRequests;
 // DX-4523 - late-bound with `access` and `client`; see `tool-surface.ts` and `permission-watch.ts`.
 let toolAccessSync;
 let permissionWatch;
-// DX-4233 - late-bound with `access`; see `plan-events-relay.ts`. The plugin's relay loop (a person's session) and a plan orchestrator's waiter sub-agent (DX-4667) call `plan_events_wait` on it.
+// DX-4233 - late-bound with `access`; see `plan-events-relay.ts`. The plugin's relay loop (a person's session) and an orchestrator's waiter sub-agent (DX-4667) call `plan_events_wait` on it.
 let planEventRelay;
 /**
  * Compose the dispatch's qualified board id (`<repo>:<slug>`) from the two env
@@ -799,7 +799,7 @@ async (args) => {
 // ---------------- plan_events_wait (DX-4233) ----------------
 strictTool("plan_events_wait", 
 // DX-4882 - `plan_id` is null for a signed-in session on no plan: its stream still carries its account's pacing and resume messages.
-// DX-4233 - for the danxbot plugin's relay loop. DX-4667 - and for a background waiter sub-agent of a plan orchestrator, which
+// DX-4233 - for the danxbot plugin's relay loop. DX-4667 - and for a background waiter sub-agent of an orchestrator, which
 // loops on it until events exist and returns them (and the cursor) to the orchestrator it wakes. It answers `events` (each
 // `{cursor, text, urgent}`; empty after `timeout_ms`), the cursor to send being the last delivered event's, or `stopped` with the remedy
 // to tell the session. General-audience text (DX-4550): nothing here names our own setup.

package/dist/plan-events-relay.js

@@ -2,7 +2,7 @@
  * DX-4233 - the IN-PROCESS relay of a session's plan events: what the `plan_events_wait` tool serves.
  *
  * WHO CALLS IT. In a person's session, the danxbot plugin's relay loop calls `plan_events_wait` over and over on this
- * session's own danx-dashboard MCP server and hands every record it gets to the session. In a plan orchestrator's dispatch
+ * session's own danx-dashboard MCP server and hands every record it gets to the session. In an orchestrator's dispatch
  * (DX-4667), which loads no relay, a background waiter sub-agent calls it the same way and returns the records and the last
  * cursor to the orchestrator. This class is everything on the
  * server side of that call: it opens the session's dashboard event stream (the mint / stream / heartbeat contract of

package/dist/route-board-scope.generated.js

@@ -7,6 +7,7 @@ export const GET_ROUTE_BOARD_SCOPE = [
     ["/api/boards/:boardId", "refuse"],
     ["/api/boards/:boardId/context-cost", "refuse"],
     ["/api/catalog/:catalogId", "refuse"],
+    ["/api/dispatch-queue", "refuse"],
     ["/api/dispatches", "refuse"],
     ["/api/dispatches/:dispatchId", "stamp"],
     ["/api/dispatches/:dispatchId/context-series", "refuse"],

package/dist/tool-access.js

@@ -48,9 +48,9 @@ export const TOOL_ACCESS = {
     design_publish: needs("cards.edit"),
     // DX-4233 - the plugin's relay waits on the session's plan events here: it opens the listener ticket
     // (`POST /api/plan-sessions/me/stream-ticket`) and heartbeats (`.../me/heartbeat`), both `plans.view`.
-    // DX-4667 - not operator-session-only: a plan orchestrator's dispatch calls it too, through a background waiter sub-agent that
+    // DX-4667 - not operator-session-only: an orchestrator's dispatch calls it too, through a background waiter sub-agent that
     // wakes the orchestrator when a person answers. What keeps it off every other dispatch is the opt-in (`MCP_SERVER_OPT_IN_TOOLS`,
-    // `src/tokens/tool-defs.ts`) granted to the `plan-orchestrator` profile alone, not this table.
+    // `src/tokens/tool-defs.ts`) granted to the `orchestrator` profile alone, not this table.
     plan_events_wait: needs("plans.view"),
     // DX-4632 - the plugin's session-start hook asks which plan the session this one replaced was working. A restarted session boots
     // signed out, so it holds no permission: like `plan_connect` it is a bootstrap tool, and a person's session's only (a dispatch

package/dist/urgent-records.js

@@ -1,7 +1,7 @@
 /**
  * DX-4721 - THE ONE PLACE that decides whether a relayed plan-event record is URGENT.
  *
- * Background. `plan_events_wait` hands the caller (the danxbot plugin's relay, or a plan orchestrator's waiter sub-agent) a
+ * Background. `plan_events_wait` hands the caller (the danxbot plugin's relay, or an orchestrator's waiter sub-agent) a
  * stream of records. The caller delivers an ordinary record after the session's running turn ends, and adds an URGENT one to
  * the running turn at once. Which record is which is decided here, by the record's KIND, and nowhere else: every site that
  * creates a record names its source and calls `isUrgent`; none writes an `urgent` literal of its own. The flag is a required

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@thehammer/danx-dashboard-mcp",
-  "version": "0.1.308",
+  "version": "0.1.310",
   "description": "Stdio MCP server fronting danxbot's dashboard API for agents (operator sessions and dispatched workers alike): the generic danxbot_api/danxbot_api_list/danxbot_api_spec tools reach any route the caller's credential may call, plus dedicated agent-specific tools (plan_connect, request_permission, attach_file, and danxbot_slack_reply) (DX-3465, PLN-11 R-25).",
   "license": "MIT",
   "type": "module",