@byok-sdk/client 0.4.0 → 0.4.2

package/dist/daemon/connection-manager.d.ts

@@ -159,25 +159,24 @@ export declare class ConnectionManager {
      */
     private cancelPendingDrainRetry;
     /**
-     * The capabilities the CURRENTLY connected server advertised in its
-     * `conn.ack` — untyped `string[]` (forward-compat: a server may advertise
-     * a flag this build doesn't recognize yet), populated by {@link onAcked}
-     * and read by {@link getServerCapabilities}. Empty until the very first
-     * successful handshake.
+     * The capabilities the CURRENT transport's server advertised — untyped
+     * `string[]` for forward compatibility. WS populates it from `conn.ack`;
+     * long-poll populates it from each successful events response. Empty until
+     * the active transport supplies an advertisement.
      *
      * Finding R2 (cross-model re-review — was P1): strictly PER-CONNECTION,
      * not per-daemon-lifetime. Cleared to `[]` the instant the acked WS
      * connection ends for ANY reason — an ordinary disconnect (`onWsOutcome`'s
      * `acked` branch), `stop()`, or a transport switch to long-poll
-     * (`enterLongPoll`) — and only ever repopulated by a FRESH `conn.ack`.
+     * (`enterLongPoll`) — and only repopulated by a fresh advertisement from
+     * the transport that is still current.
      * The previous version of this doc comment claimed long-poll mode simply
      * "stays at whatever the last real WS `conn.ack` said" — that was the bug:
      * a daemon that once learned e.g. `approval_resolved` from an earlier WS
      * session kept believing it applied to whatever it's connected to NOW,
      * even after a disconnect/degrade where nothing has actually confirmed
      * that's still true (a reconnect could land on a DIFFERENT server behind a
-     * load balancer; long-poll fallback itself never performs an equivalent
-     * handshake at all). Concretely, `TaskRunner.sendApprovalResolved` gates
+     * load balancer). Concretely, `TaskRunner.sendApprovalResolved` gates
      * `task.approval_resolved` on this list — sending it to a server that
      * doesn't actually understand it over the long-poll path would get a
      * batch-level 400 from `MessagesSendRequestSchema` (protocol §8.2), which
@@ -242,13 +241,10 @@ export declare class ConnectionManager {
     private drainRetryDelay;
     isTransportDegraded(): boolean;
     /**
-     * The capabilities the CURRENTLY connected server advertised in its
-     * `conn.ack` — e.g. lets a caller gate a daemon->server message on whether
-     * THIS server understands it before sending (see `task-runner.ts`'s
-     * `sendApprovalResolved`, gated on `approval_resolved`). Empty before the
-     * first handshake completes, AND (finding R2) once again empty after any
-     * disconnect/degrade — see `serverCapabilities`'s own doc comment for why
-     * this is strictly per-connection rather than "sticky" across one.
+     * The capabilities the CURRENT transport's server advertised: from
+     * `conn.ack` on WS, or the latest successful `GET /byok/events` response
+     * on long-poll. Empty before either transport has supplied its current
+     * advertisement, and cleared across disconnect/switch boundaries.
      */
     getServerCapabilities(): readonly string[];
     isConnected(): boolean;

package/dist/daemon/long-poll-transport.d.ts

@@ -5,6 +5,12 @@ export interface LongPollClientOptions {
     auth: AuthManager;
     getCursor: () => number | undefined;
     onEnvelope: (envelope: Envelope) => void;
+    /**
+     * Capabilities advertised by the server that produced the current poll
+     * response. Called before any envelopes from that response are delivered.
+     * An older responder omitting the additive field is reported as `[]`.
+     */
+    onServerCapabilities?: (capabilities: string[]) => void;
     /** Called once the device is found to be revoked (401 surfaced through {@link AuthManager}) — the loop stops itself rather than retrying. */
     onRevoked?: () => void;
     /**

package/dist/daemon/task-runner.d.ts

@@ -264,9 +264,10 @@ export interface TaskRunnerDeps {
      */
     maxTaskOutputBytes?: number;
     /**
-     * M4 (additive-minor, `task.approval_resolved`): the negotiated
-     * `conn.ack.capabilities` of the CURRENTLY (or most recently) connected
-     * server — read fresh at call time (mirrors `getCursor`/`getToken`'s own
+     * M4 (additive-minor, `task.approval_resolved`): the capabilities advertised
+     * by the CURRENT transport's server (`conn.ack` on WS, the latest successful
+     * events response on long-poll) — read fresh at call time (mirrors
+     * `getCursor`/`getToken`'s own
      * "read fresh, not captured once" convention elsewhere in this codebase),
      * since the capability is learned asynchronously, after this `TaskRunner`
      * is already constructed (`create-daemon.ts`'s `start()` builds `deps`
@@ -935,9 +936,9 @@ export declare class TaskRunner {
     /**
      * Whether the CURRENTLY connected server advertised `result-document` —
      * read fresh on every call, never captured, because the answer changes
-     * across a reconnect (`ConnectionManager.getServerCapabilities` returns
-     * `[]` from the moment an acked connection closes until a fresh
-     * `conn.ack` repopulates it). An absent `getServerCapabilities` seam is
+     * across a reconnect or transport switch (`ConnectionManager` clears the
+     * old advertisement at the boundary, then repopulates it from a fresh WS
+     * ack or successful poll response). An absent `getServerCapabilities` seam is
      * "no capabilities", the fail-closed reading.
      */
     private hasResultDocumentCapability;