@thehammer/danx-dashboard-mcp 0.1.330 → 0.1.332

package/dist/plan-events-relay.js

@@ -11,15 +11,18 @@
  *
  * THE WAIT CONTRACT (`wait`). One rule, one reset, and a cursor that is opaque to the caller.
  *   1. ONE RULE, BY ARRIVAL. Every record (a dashboard event, a digest, a notice, a pacing or resume message) is given the next
- *      number of a sequence that only ever increases: its `seq`. Each answered record carries a CURSOR, an opaque string the
- *      caller stores once it has DELIVERED that record and sends back on its next call. A call answers every buffered record
- *      whose seq is above the cursor's (at once when there is one, else when one arrives, else empty at the timeout) and
- *      DROPS every record at or below it, at the call (`acknowledged`, the one predicate). An answer is never a drain: a record
- *      stays buffered until a LATER call's cursor passes it, so a call whose caller went away (a plugin reload) loses nothing.
+ *      number of a sequence that only ever increases: its `seq`. Each answered record carries a CURSOR, an opaque string. The caller
+ *      sends back, on its next call, the cursor of the newest record it has TAKEN (not necessarily delivered; DX-5403 / DX-5398). A call
+ *      answers every buffered record whose seq is above the cursor's (at once when there is one, else when one arrives, else empty
+ *      at the timeout) and DROPS every record at or below it, at the call (`acknowledged`, the one predicate). An answer is never a
+ *      drain: a record stays buffered until a LATER call's cursor passes it, but the server does NOT promise to keep a record the
+ *      caller has already taken. The danxbot plugin keeps its taken-but-undelivered events in its own `relayOutbox` $.state atom, so
+ *      a reload of its hook module loses none (it may repeat one); a new process with no atom resumes from the plugin's stored
+ *      delivered cursor.
  *      The dashboard numbers its events when it INSERTS them but publishes them when it COMMITS, so an event can arrive after
  *      a higher-numbered one; arrival order is the only order the relay can promise, which is why the dashboard's id is never
  *      what is compared.
- *   2. THE CURSOR. `<seq>:<id>,<id>,...`: the record's seq, then the dashboard event ids delivered up to and including it, in
+ *   2. THE CURSOR. `<seq>:<id>,<id>,...`: the record's seq, then the dashboard event ids handed out up to and including it, in
  *      arrival order and bounded to the last `CURSOR_IDS_MAX` (`formatCursor`, `parseCursor`: the seq and every id are base-10
  *      whole numbers with no leading zero, the ids are distinct and positive; anything else is refused loudly). The ids are what
  *      makes a restart exact. After a restart of the MCP server (a resumed session) a fresh relay is presented its caller's
@@ -87,7 +90,7 @@ export function parseCursor(raw) {
     return { seq, ids };
 }
 const boundedIds = (ids) => [...new Set(ids)].slice(-CURSOR_IDS_MAX);
-/** DX-4233: the one rule of the cursor: a record at or below its seq has been delivered. */
+/** DX-4233: the one rule of the cursor: a record at or below the presented cursor's seq has been taken by the caller, so the server drops it. */
 export const acknowledged = (seq, cursor) => cursor !== null && seq <= cursor.seq;
 export class PlanEventRelay {
     deps;

package/dist/session-stats.js

@@ -145,6 +145,7 @@ export class OperatorSessionStats {
             startCursors: stored.sourceCursors,
             onCursorPastEof: (info) => this.usage.recordPastEof(info),
             onSourceDiscovered: (info) => activities.onSourceDiscovered(info),
+            onPollComplete: () => activities.onPollComplete(),
         });
         this.usage.attachCursors(() => watcher.cursorState(), stored.sourceCursors);
         this.usage.setTranscriptPath(path);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@thehammer/danx-dashboard-mcp",
-  "version": "0.1.330",
+  "version": "0.1.332",
   "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",
@@ -33,7 +33,7 @@
   "dependencies": {
     "@danxbot/plugin-sdk": "0.2.1",
     "@modelcontextprotocol/sdk": "1.29.0",
-    "@thehammer/danx-session-telemetry": "0.1.53",
+    "@thehammer/danx-session-telemetry": "0.1.54",
     "zod": "^3.25.76"
   },
   "devDependencies": {