@thehammer/danx-session-telemetry 0.1.42 → 0.1.44

package/README.md

@@ -2,7 +2,7 @@
 
 DX-2962 — the shared Claude Code transcript collector, extracted from
 danxbot root's `src/agent/session-log-watcher.ts` so the danxbot worker and
-the `danx-dashboard-mcp` desktop bridge (DX-2954) run **identical** collector
+the `danx-dashboard-mcp` MCP server's plan event relay (DX-2954) run **identical** collector
 code, instead of the worker's copy silently diverging from a re-implementation
 inside the MCP package.
 
@@ -44,7 +44,7 @@ own header comments for the per-file reasoning.
 | Consumer | Mechanism | Why |
 |---|---|---|
 | **danxbot worker** (root repo, `tsx src/index.ts`) | npm **workspace** link (`"workspaces": ["packages/*"]` in root `package.json`, `"@thehammer/danx-session-telemetry"` in root `dependencies`) | The worker and this package always ship from the SAME repo commit — a workspace link means the worker runs whatever source the current commit carries, with zero drift risk and no dependency on registry propagation timing. The Docker image builds `dist/` for it in a dedicated builder stage (alongside `frontend-builder` in `Dockerfile`) since the final image's `npm ci --omit=dev` never installs this package's own `devDependencies` (`typescript`). |
-| **`danx-dashboard-mcp` desktop bridge** (separate npm-published package, DX-2954) | Ordinary npm dependency, **pinned to the exact published version** the worker's commit ships | The bridge is a genuinely separate installable artifact (`npx -y @thehammer/danx-dashboard-mcp`), so it cannot workspace-link into danxbot's own checkout — it needs the real published bytes. Pinning exact (not `^`/`~`) is what makes "worker and MCP run identical collector code for any given release" true: MCP's own version bump is the only thing that ever changes what collector code it runs. |
+| **`danx-dashboard-mcp` MCP server** (separate npm-published package, DX-2954) | Ordinary npm dependency, **pinned to the exact published version** the worker's commit ships | The MCP server is a genuinely separate installable artifact (`npx -y @thehammer/danx-dashboard-mcp`), so it cannot workspace-link into danxbot's own checkout — it needs the real published bytes. Pinning exact (not `^`/`~`) is what makes "worker and MCP run identical collector code for any given release" true: MCP's own version bump is the only thing that ever changes what collector code it runs. |
 | **Dashboard server** (`src/dashboard/*`) | Same npm dependency shape as the worker (the dashboard server's `src/` is root-repo code, so it resolves through the SAME root workspace link as the worker) | An npm dependency resolves through ordinary node_modules lookup, so no `@backend`-style alias is needed. |
 
 ## Release order (DX-2962 AC3)
@@ -52,7 +52,6 @@ own header comments for the per-file reasoning.
 1. Publish this package (`make publish-danx-session-telemetry`).
 2. Publish `danx-dashboard-mcp` (only once it depends on this package — DX-2954).
 3. Deploy the danxbot backend.
-4. Move the plugin's bridge-version pin.
 
 Publishing comes before deploying because the publish-drift gate
 (`src/dispatch/publish-drift-gate.ts`) refuses a finalize whose bumped

package/dist/.source-hash

@@ -1 +1 @@
-f4864e2bc2491a9df2c4f0c3ec86da8a35ad36225049696e9e2ca5b544931859
+a9b13a1f70c9a71a4aafa832d67aadc10e9e2c998beaf0230f13903d39c2d4c4

package/dist/claim-tracker.d.ts

@@ -31,7 +31,7 @@ export interface ClaimState {
 export declare function emptyClaimState(): ClaimState;
 /**
  * The per-process claim tracker: one state per sub-agent source. Fed every
- * transcript line by `DispatchUsage` (operator-bridge mode only — the worker never
+ * transcript line by `DispatchUsage` (`operator-bridge` mode only — the worker never
  * constructs one), seeded from the stored cursor at attach, and snapshotted per
  * source for the stats write.
  */

package/dist/claim-tracker.js

@@ -37,7 +37,7 @@
  *
  * The state is the held set PLUS the transitions whose `tool_use` has been read
  * and whose `tool_result` has not (`pending`). Both are persisted beside the
- * source's read cursor (`dispatch_source_cursors.claims`): a bridge that restarts
+ * source's read cursor (`dispatch_source_cursors.claims`): a relay that restarts
  * resumes at its stored `acked` offset, and a pickup that sits before it is never
  * re-read, so without the state every later reply would go unattributed. The
  * pending half closes the narrow window where the restart lands between a pickup's
@@ -133,7 +133,7 @@ function transitionOf(block) {
 }
 /**
  * The per-process claim tracker: one state per sub-agent source. Fed every
- * transcript line by `DispatchUsage` (operator-bridge mode only — the worker never
+ * transcript line by `DispatchUsage` (`operator-bridge` mode only — the worker never
  * constructs one), seeded from the stored cursor at attach, and snapshotted per
  * source for the stats write.
  */

package/dist/dispatch-usage.d.ts

@@ -37,8 +37,9 @@ export type FlushOutcome = "ok" | "failed" | "refused";
  *     dispatch by refusing the WHOLE batch, which would stall the worker's stats,
  *     token ceiling and spend alert on every resend - so a worker is structurally
  *     unable to send one.
- *   - `"operator-bridge"` - the desktop bridge of an operator session
- *     (`danx-dashboard-mcp`'s `session-stats.ts`), the only path that attributes.
+ *   - `"operator-bridge"` - the plan event relay of an operator session
+ *     (`danx-dashboard-mcp`'s `session-stats.ts`), the only path that attributes. The value keeps its old name on purpose: it is
+ *     this package's published API (the MCP package passes it), so renaming it is a new telemetry release, not a text fix.
  */
 export type DispatchUsageMode = "worker" | "operator-bridge";
 export declare class DispatchUsage {

package/dist/index.d.ts

@@ -6,7 +6,7 @@
  * (small per-reply bookkeeping only, kept in memory for the life of the
  * process — see `session-log-watcher.ts`'s header). Consumed by the
  * danxbot worker (Node, workspace-linked — see the README) and, from
- * DX-2954, the `danx-dashboard-mcp` desktop bridge (Node, npm-installed at
+ * DX-2954, the `danx-dashboard-mcp` MCP server's plan event relay (Node, npm-installed at
  * a pinned exact version).
  *
  * A browser-safe subset with NO `node:` imports lives at the `./browser`

package/dist/index.js

@@ -6,7 +6,7 @@
  * (small per-reply bookkeeping only, kept in memory for the life of the
  * process — see `session-log-watcher.ts`'s header). Consumed by the
  * danxbot worker (Node, workspace-linked — see the README) and, from
- * DX-2954, the `danx-dashboard-mcp` desktop bridge (Node, npm-installed at
+ * DX-2954, the `danx-dashboard-mcp` MCP server's plan event relay (Node, npm-installed at
  * a pinned exact version).
  *
  * A browser-safe subset with NO `node:` imports lives at the `./browser`
@@ -28,7 +28,7 @@ export * from "./ledger-timing.js";
 export * from "./transcript-timing.js";
 export * from "./pricing.js";
 // DX-2954 — the ONE stats collector and its wire, shared by the danxbot worker
-// and the desktop bridge (operator sessions) so both report the same stats the
+// and the MCP server's relay (operator sessions) so both report the same stats the
 // same way (epic DX-2958): the stats payload/response schema and its strict
 // parser, the collector that ships ledger entries + transcript cursors +
 // running-set changes, the transcript-side running-set producer, and the FIFO

package/dist/internal-logger.js

@@ -12,10 +12,10 @@ function emit(level, component, message, error) {
     else if (error !== undefined) {
         entry.error = String(error);
     }
-    // DX-2954 — every level goes to STDERR. The desktop bridge
-    // (`danx-dashboard-mcp bridge`) now runs this collector, and its STDOUT is a
-    // JSON Lines protocol channel the plugin parses record by record; a log line
-    // there would be read as a bridge record. The worker captures both streams.
+    // DX-2954 — every level goes to STDERR. The MCP server's
+    // relay and the one-shot subcommands run this collector; the subcommands' STDOUT is a protocol
+    // channel the plugin parses (and the MCP server's is JSON-RPC), so a log line there
+    // would corrupt it. The worker captures both streams.
     console.error(JSON.stringify(entry));
 }
 export function createLogger(component) {

package/dist/session-log-watcher.d.ts

@@ -3,7 +3,7 @@
  *
  * DX-2962: moved unchanged from danxbot root `src/agent/session-log-watcher.ts`
  * into this shared published package, so the danxbot worker and the
- * `danx-dashboard-mcp` desktop bridge (DX-2954) run identical collector
+ * `danx-dashboard-mcp` MCP server's relay (DX-2954) run identical collector
  * code. Only the imports changed — `../logger.js` -> `./internal-logger.js`
  * (this package's own tiny logging shim, since root's `logger.ts` has ~300
  * unrelated consumers and does not move), `../types.js` -> `./types.js`
@@ -408,7 +408,7 @@ export declare class SessionLogWatcher {
     /**
      * DX-3964 - register a usage-feed consumer: it receives the parsed raw line of every assistant, user,
      * attachment and system line, in file order, with the same `EntryMeta` as `onEntry`. The ONLY subscribers are
-     * the collector's two consumers at each of its two sites (the worker and the operator bridge): `DispatchUsage`
+     * the collector's two consumers at each of its two sites (the worker and the operator session's relay): `DispatchUsage`
      * and, DX-4498, the activity observer, which reads the sub-agent's brief and Claude Code's task notifications,
      * neither of which is an entry. `convertJsonlEntry` and every
      * `onEntry` subscriber keep seeing exactly what they saw before, because human prompts, attachments (tens of

package/dist/session-log-watcher.js

@@ -3,7 +3,7 @@
  *
  * DX-2962: moved unchanged from danxbot root `src/agent/session-log-watcher.ts`
  * into this shared published package, so the danxbot worker and the
- * `danx-dashboard-mcp` desktop bridge (DX-2954) run identical collector
+ * `danx-dashboard-mcp` MCP server's relay (DX-2954) run identical collector
  * code. Only the imports changed — `../logger.js` -> `./internal-logger.js`
  * (this package's own tiny logging shim, since root's `logger.ts` has ~300
  * unrelated consumers and does not move), `../types.js` -> `./types.js`
@@ -624,7 +624,7 @@ export class SessionLogWatcher {
     /**
      * DX-3964 - register a usage-feed consumer: it receives the parsed raw line of every assistant, user,
      * attachment and system line, in file order, with the same `EntryMeta` as `onEntry`. The ONLY subscribers are
-     * the collector's two consumers at each of its two sites (the worker and the operator bridge): `DispatchUsage`
+     * the collector's two consumers at each of its two sites (the worker and the operator session's relay): `DispatchUsage`
      * and, DX-4498, the activity observer, which reads the sub-agent's brief and Claude Code's task notifications,
      * neither of which is an entry. `convertJsonlEntry` and every
      * `onEntry` subscriber keep seeing exactly what they saw before, because human prompts, attachments (tens of

package/dist/stats-wire.d.ts

@@ -121,7 +121,7 @@ export interface ActivityChange {
     /**
      * DX-4508 — the card its spawning `Agent` call names: the first card id in its (redacted) `description`, else the
      * first anywhere in its brief; null when neither names one. The name stays `briefIssueId` (and the column
-     * `brief_issue_id`): renaming a required wire field would make every bridge already published fail the strict parser.
+     * `brief_issue_id`): renaming a required wire field would make every relay already published fail the strict parser.
      */
     briefIssueId: string | null;
 }

package/dist/subagent-live.js

@@ -2,13 +2,13 @@
  * DX-4508 — a LOCAL live view of a session's sub-agents, for the plugin's plan pane.
  *
  * The pane shows one card per sub-agent: what it is, what it is doing, and what it has spent. Its dashboard path
- * (`GET /api/plan-sessions/:id/subagents`) lags about 80s behind the transcript (the bridge's 5s poll, its 15s
+ * (`GET /api/plan-sessions/:id/subagents`) lags about 80s behind the transcript (the relay's 5s poll, its 15s
  * heartbeat flush, the pane's 60s read), so the same facts are also computed here, on the operator's own machine, from
  * the transcript files themselves, and streamed by `danx-dashboard-mcp subagents-live` within a poll of being written.
  *
  * ## One place computes each number
  *
- * Nothing here counts or prices on its own. It consumes the SAME two watcher feeds the bridge wires
+ * Nothing here counts or prices on its own. It consumes the SAME two watcher feeds the relay wires
  * (`onSourceDiscovered`, `onUsageLine`) into the SAME producers:
  *
  * | Snapshot field | Computed by | As the dashboard read derives it from |
@@ -25,7 +25,7 @@
  * ## Where the live view differs from the observer's own stamps
  *
  * `startedAt` and `lastActivityAt` come from the sub-agent's own transcript lines (its first and newest `assistant` /
- * `user` line). The observer stamps a start at the moment its watcher DISCOVERED the file, which is right for the bridge
+ * `user` line). The observer stamps a start at the moment its watcher DISCOVERED the file, which is right for the relay
  * (its first discovery is the real start, and the server keeps the earliest), but this view reads every file from byte
  * 0 each time it starts, so a discovery stamp would show every finished sub-agent as having started, and been active,
  * just now. The discovery stamp is used only for a sub-agent that has written no line yet.

package/dist/usage-ledger.d.ts

@@ -45,7 +45,7 @@ export interface LedgerEntry {
     toolUseIds: string[];
     /**
      * DX-3962 - the card this reply is credited to, or `null`. Fixed by the
-     * reply's FIRST line and never changed by a later one. Only an operator-bridge
+     * reply's FIRST line and never changed by a later one. Only an operator-session
      * collector (`DispatchUsage`, `"operator-bridge"` mode) ever sets it; every
      * other producer of an entry carries `null`.
      */

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@thehammer/danx-session-telemetry",
-  "version": "0.1.42",
-  "description": "Shared Claude Code transcript collector (DX-2962) — incremental JSONL tailing for the danxbot worker and the danx-dashboard-mcp desktop bridge, so both run identical collector code.",
+  "version": "0.1.44",
+  "description": "Shared Claude Code transcript collector (DX-2962) — incremental JSONL tailing for the danxbot worker and the danx-dashboard-mcp MCP server's relay, so both run identical collector code.",
   "license": "MIT",
   "type": "module",
   "main": "dist/index.js",