@securecoms/agent-bridge 0.26.3 → 0.26.5

package/dist/ws-server.d.ts

@@ -1,80 +1,3 @@
-/**
- * Agent-facing keepalive WebSocket (/v1/ws).
- *
- * Adds a single persistent bidirectional socket for the AGENT⇄DAEMON hop,
- * modeled on AgentVault's keepalive WS (token in `?token=` query OR
- * `Authorization: Bearer`). This replaces the curl/long-poll loop: the agent
- * receives live inbound messages as JSON frames and sends/reports status over
- * the same socket.
- *
- * Protocol (all frames are JSON text):
- *   Daemon → agent:
- *     { "type":"message", channel_id, message_id, sender_id, text, ts,
- *       authorization:{version,audience,sender_membership,tool_grants} } // inbound, decrypted
- *     { "type":"sent", message_id }                                      // ack of a send
- *     { "type":"ok" }                                                    // ack of a status report
- *     { "type":"error", error, message, detail? }   // canonical codes (see errors.ts):
- *                                                    // channel_pending | rate_limited |
- *                                                    // invalid_request | agent_paused |
- *                                                    // send_forbidden (those two are
- *                                                    // TERMINAL: the in_reply_to message
- *                                                    // is acked by the daemon, no retry) |
- *                                                    // group_superseded (NOT terminal:
- *                                                    // the reply is republished after
- *                                                    // the agent rejoins)
- *   Agent → daemon:
- *     { "type":"send", channel_id, text?, a2a?, idempotency_key?,
- *       in_reply_to? }   // exactly one of text | a2a. SEC-06 #18: in_reply_to
- *                        // and/or idempotency_key make the send idempotent — a
- *                        // deterministic keyed message_id and a durable reply
- *                        // intent written before the publish, so a retry or a
- *                        // redelivery republishes the SAME reply
- *     { "type":"status", channel_id, state, detail? }
- *     { "type":"ack", message_id }   // confirms a delivered `message` was consumed
- *     { "type":"nack", message_id, reason? }  // final-wave I1(b): THIS message's turn
- *                                    // failed — requeued behind a backoff; the
- *                                    // socket and other channels' turns stay up
- *     { "type":"hello", features? }  // → { "type":"hello", features:["nack"] }; a
- *                                    // runtime nacks only after seeing "nack" here
- *     { "type":"action_begin", channel_id }                                   // → { "type":"action_begun", run_id }
- *     { "type":"action_start", run_id, node_type, title, parent_id? }         // → { "type":"action_started", node_id }
- *     { "type":"action_update", run_id, node_id, status?, detail? }           // → { "type":"ok" }
- *     { "type":"action_finish", run_id, node_id, status, detail? }            // → { "type":"ok" }
- *     { "type":"action_settle", run_id, result_message_id? }                  // → { "type":"action_settled", run_id }
- *
- * Inbound delivery is at-least-once. A delivered `message` is held in-flight
- * until the agent sends a matching `ack`; if the socket drops first, the frame
- * is re-buffered and redelivered to the next consumer. The agent dedups by
- * message_id. SEC-06 #18: a redelivered message whose reply already has a
- * durable intent is NOT handed to the agent again; the daemon republishes that
- * reply itself (same message_id), so the model does not run twice.
- *
- * Bounded work (Phase 3):
- *   - F2 ordering: at most ONE message per channel is in flight on a socket;
- *     the next message for that channel is sent only after the previous one is
- *     acked (or retired). A backlog replays in order instead of flooding the
- *     runtime, which used to answer the overflow with a "busy" reply and ack it.
- *   - F1 attempt cap: every delivery is counted durably; a message that
- *     reaches the cap is dead-lettered (content-free log + ack + one
- *     content-free notice to the channel per hour) rather than redelivered
- *     forever, and a channel where the agent is paused is not delivered at
- *     all (no model call).
- *   - Final-wave I1: a FAILED delivery (a `nack`, or the socket closing with
- *     it in flight — older runtimes close on any failed turn) is requeued
- *     behind a 2^attempts × 5 s backoff. A nack fails only its own message.
- *     Messages never handed over (mid-flush close, a failed frame write) go
- *     back without that penalty.
- *   - #842: a delivery still un-acked after INFLIGHT_STALE_AFTER_MS is LOGGED
- *     once (`runtime_inbox.inflight_stale`) and otherwise left alone. There
- *     is deliberately no lease: see INFLIGHT_STALE_AFTER_MS.
- *
- * Single consumer: the daemon serves one agent per process. A new `/v1/ws`
- * connection replaces the prior one (newest wins, mirroring the SSE path); the
- * replaced socket's un-acked in-flight messages are re-buffered.
- *
- * Keepalive uses the ws library's server-side ping (the protocol-level ping
- * frame, not an application message); dead sockets are reaped via pong tracking.
- */
 import type { Server as HttpServer } from "node:http";
 import type { BridgeAgent } from "./bridge-agent.js";
 export interface AgentWebSocketOptions {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@securecoms/agent-bridge",
-  "version": "0.26.3",
+  "version": "0.26.5",
   "type": "module",
   "engines": {
     "node": ">=22.5.0"