agent-comms 3.32.0 → 3.32.1

package/.claude-plugin/marketplace.json

@@ -15,7 +15,7 @@
         "url": "https://github.com/ExaDev/agent-comms.git"
       },
       "description": "Cross-harness LLM agent communication mesh — rooms, DMs, and presence",
-      "version": "3.32.0"
+      "version": "3.32.1"
     }
   ]
 }

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "agent-comms",
   "description": "Cross-harness LLM agent communication mesh — rooms, DMs, and presence",
-  "version": "3.32.0",
+  "version": "3.32.1",
   "author": {
     "name": "ExaDev"
   },

package/README.md

@@ -2,7 +2,7 @@
 
 [![GitHub](https://img.shields.io/badge/GitHub-181717?logo=github&logoColor=white)](https://github.com/ExaDev/agent-comms)
 [![npm](https://img.shields.io/badge/npm-CB3837?logo=npm&logoColor=white)](https://www.npmjs.com/package/agent-comms)
-[![version](https://img.shields.io/badge/version-3.32.0-blue)](https://github.com/ExaDev/agent-comms/releases/tag/v3.32.0)
+[![version](https://img.shields.io/badge/version-3.32.1-blue)](https://github.com/ExaDev/agent-comms/releases/tag/v3.32.1)
 [![CI](https://img.shields.io/github/actions/workflow/status/ExaDev/agent-comms/ci.yml?branch=main)](https://github.com/ExaDev/agent-comms/actions)
 
 Cross-harness communication mesh for LLM agents: rooms, DMs, presence, and visibility over TCP with zero filesystem dependencies.
@@ -256,6 +256,8 @@ Two independent transports sit inside that dashboard, both built on [oRPC](https
 
 Both legs are independently resumable: each side of the worker keeps its own buffered, replayable event stream tagged with event ids, so a tab that briefly loses its `MessagePort` connection, or a worker whose upstream WebSocket drops, picks back up from its own last-seen event rather than missing whatever happened while it was disconnected. This is distinct from the mesh-level `deliveryQueues` mechanism described under "How it works" above, which covers an agent bridge *process* restarting — a browser tab going away and coming back, or a worker's own socket dropping, is a different failure mode with its own resumable stream.
 
+Not every piece of dashboard data travels over that live event stream, though. Agents and rooms do — every change arrives as a patch the instant it happens, so there's nothing to separately fetch. Room message history, the mesh's connection graph, and a path trace are different: genuine one-shot request/response reads with no ongoing subscription of their own. Those three go through [TanStack Query](https://tanstack.com/query), wired up via [oRPC's own TanStack Query integration](https://orpc.unnoq.com/docs/integrations/tanstack-query) over the same tab-to-worker oRPC client described above — caching, request de-duplication, and cache invalidation on the same events that already drive the live side of the dashboard.
+
 ## Alternate UI: wire-mesh's web-console
 
 An agent-comms node is, underneath, already a [wire-mesh](https://github.com/ExaDev/wire-mesh) node, so it can optionally also serve wire-mesh's own generic, protocol-level `web-console` alongside its own richer dashboard — useful for anyone who wants the reference-client view of their mesh rather than agent-comms' own product UI.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-comms",
-  "version": "3.32.0",
+  "version": "3.32.1",
   "description": "Cross-harness communication mesh for LLM agents — rooms, DMs, presence, and real-time push delivery over TCP",
   "type": "module",
   "packageManager": "pnpm@12.4.1+sha512.2e81e399d73fe8390dab25e06aa788ab7a5908248d2f5a370f82b481147a6a7a367bf8048f9a6fdb6460f21a66f0542dedb8b94ca2c8723596741920b1656d4c",