@vellumai/assistant 0.10.12-dev.202607250047.75b9ec6 → 0.10.12-staging.1

package/README.md

@@ -145,7 +145,7 @@ All approval prompt delivery paths use a **fail-closed** policy -- if the prompt
 
 ### Plain-Text Fallback for Non-Rich Channels
 
-Channels that do not support rich inline approval UI (e.g., inline keyboards) receive plain-text instructions embedded in the message body. The `supportsInlineOptions` channel capability (`channelSupportsInlineOptions()`) determines whether to send the structured `promptText` (for channels whose adapter renders inline buttons like Telegram) or the `plainTextFallback` string (for all other channels). The fallback text includes instructions so the user can respond via text; the conversational approval engine then classifies the free-text response.
+Channels that do not support rich inline approval UI (e.g., inline keyboards) receive plain-text instructions embedded in the message body. The `channelSupportsRichApprovalUI()` check determines whether to send the structured `promptText` (for rich channels like Telegram) or the `plainTextFallback` string (for all other channels). The fallback text includes instructions so the user can respond via text; the conversational approval engine then classifies the free-text response.
 
 ### Key modules
 

package/docs/trusted-contact-access.md

@@ -39,7 +39,7 @@ Design doc defining how unknown users gain access to a Vellum assistant via chan
 
    This ensures unknown inbound access attempts always trigger guardian notification, even when the requester's source channel has no guardian binding.
 
-4. **Guardian decides.** All decisions route through the guardian decision primitive (`applyGuardianDecision`, `approvals/guardian-decision-primitive.ts`) and commit via the gateway's `guardian_requests_decide` IPC op: the status CAS and the decision's ACL outcome execute in ONE gateway transaction, so an `approved` request can never exist without its ACL write. The introduction card supports four outcomes: **approve** (start the verification handshake), **trust** (activate directly, no code — used for workspace-vouched identities), **leave unverified** (the `leave_unverified` action id — park the sender as an `unverified` contact, **silently**: the requester is not notified and only learns if they message again; a later trust-requiring inbound re-fires the flow), and **block** (revoke the sender's channel and notify them their request was declined). Note the `unverified` contact left by "leave unverified" is not a guaranteed keep-out — it is still admitted under the permissive admission floors (`any_contact`, `strangers`); **block** (→ revoked) is the hard keep-out.
+4. **Guardian decides.** All decisions route through the guardian decision primitive (`applyGuardianDecision`, `approvals/guardian-decision-primitive.ts`) and commit via the gateway's `guardian_requests_decide` IPC op: the status CAS and the decision's ACL outcome execute in ONE gateway transaction, so an `approved` request can never exist without its ACL write. The introduction card supports four outcomes: **approve** (start the verification handshake), **trust** (activate directly, no code — used for workspace-vouched identities), **deny** (persist a terminal denial), and **block**.
 5. **On approval the gateway mints a verification session.** The decide op carries a `mint_outbound_session` outcome; inside the decide transaction the gateway (`gateway/src/verification/session-service.ts`) generates a 6-digit code, persists only its SHA-256 hash in `channel_verification_sessions` (identity-bound to the requester, `verificationPurpose: 'trusted_contact'`), and returns the raw secret to the daemon in the decide response for delivery.
 6. **The code is delivered.** The daemon delivers the code to the guardian's verified channel (ephemeral + DM on Slack shared channels so other members never see it). On Slack the code is also DM'd straight to the requester; on other channels the guardian relays it out-of-band (in person, text message, phone call). That out-of-band transfer is the trust anchor: it proves the requester has a real-world relationship with the guardian.
 7. **Requester enters the code** back to the assistant on the same channel. The **gateway** intercepts bare verification codes at ingress (`gateway/src/verification/text-verification.ts`) whenever an interceptable session exists for that channel — the daemon never sees verification code messages.
@@ -52,14 +52,14 @@ Design doc defining how unknown users gain access to a Vellum assistant via chan
 requested -> pending_guardian -> verification_pending -> active | denied | expired
 ```
 
-| State                  | Description                                                                                                        | Store representation                                                                                                                                                                                                                                                                                                                                                       |
-| ---------------------- | ------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `requested`            | Unknown user messaged the assistant and was denied. The system records the access attempt.                         | No member record exists. The inbound is logged in `channel_inbound_events` (assistant DB). A notification signal is emitted via `emitNotificationSignal()`.                                                                                                                                                                                                                |
-| `pending_guardian`     | The guardian has been notified and a decision is pending.                                                          | A `guardian_requests` record (gateway DB) with `status: 'pending'`, `kind: 'access_request'`.                                                                                                                                                                                                                                                                              |
-| `verification_pending` | The guardian approved. A verification session is active with a 6-digit code waiting for the requester to enter.    | Gateway `channel_verification_sessions` record with `status: 'awaiting_response'`, identity-bound to the requester. The guardian request is `status: 'approved'`.                                                                                                                                                                                                          |
-| `active`               | The requester entered the correct code (or the guardian chose direct trust). They are now a trusted contact.       | Gateway `contact_channels` record with `status: 'active'`, `policy: 'allow'`; identity mirrored to the assistant DB. The verification session is `status: 'consumed'`.                                                                                                                                                                                                     |
-| `denied`               | The guardian resolved the request without granting access — `leave_unverified` (park) or `block` (keep-out).       | The guardian request has `status: 'denied'` for both. `leave_unverified` persists an `unverified` contact — a neutral park, so a later trust-requiring inbound **re-fires** the flow; `block` revokes the channel — a durable keep-out, so re-contact is suppressed. Suppression keys off the durable **contact status** (`revoked`/`blocked`), never this request status. |
-| `expired`              | The guardian never responded (approval TTL elapsed) or the requester never entered the code (session TTL elapsed). | Guardian request: `status: 'expired'` (CAS-expired by the gateway via the daemon's expiry sweep). Verification session: expires naturally when `expiresAt < Date.now()`.                                                                                                                                                                                                   |
+| State                  | Description                                                                                                        | Store representation                                                                                                                                                     |
+| ---------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `requested`            | Unknown user messaged the assistant and was denied. The system records the access attempt.                         | No member record exists. The inbound is logged in `channel_inbound_events` (assistant DB). A notification signal is emitted via `emitNotificationSignal()`.              |
+| `pending_guardian`     | The guardian has been notified and a decision is pending.                                                          | A `guardian_requests` record (gateway DB) with `status: 'pending'`, `kind: 'access_request'`.                                                                            |
+| `verification_pending` | The guardian approved. A verification session is active with a 6-digit code waiting for the requester to enter.    | Gateway `channel_verification_sessions` record with `status: 'awaiting_response'`, identity-bound to the requester. The guardian request is `status: 'approved'`.        |
+| `active`               | The requester entered the correct code (or the guardian chose direct trust). They are now a trusted contact.       | Gateway `contact_channels` record with `status: 'active'`, `policy: 'allow'`; identity mirrored to the assistant DB. The verification session is `status: 'consumed'`.   |
+| `denied`               | The guardian explicitly denied the request.                                                                        | The guardian request has `status: 'denied'`. The sender is persisted as an unverified contact and later inbound is suppressed (terminal-deny).                           |
+| `expired`              | The guardian never responded (approval TTL elapsed) or the requester never entered the code (session TTL elapsed). | Guardian request: `status: 'expired'` (CAS-expired by the gateway via the daemon's expiry sweep). Verification session: expires naturally when `expiresAt < Date.now()`. |
 
 ## Identity Binding Rules
 
@@ -112,16 +112,7 @@ Identity binding ensures the verification code can only be consumed by the inten
 | -------------------------------------------------- | ------------------- | ------------------------------------------------------------- |
 | gateway `guardian-request-service.ts` (gateway DB) | `guardian_requests` | Updated to `status: 'denied'`, `decidedByExternalUserId` set. |
 
-No trusted-contact activation happens. The `leave_unverified` outcome persists the sender as an `unverified` contact **and sends no requester notification** (silent park); `block` instead revokes the channel and **does** notify the requester ("Your access request was declined.").
-
-The two outcomes differ on re-contact. Suppression of re-prompting keys off the **durable contact status**, not this `denied` request status:
-
-- `leave_unverified` → `unverified` contact: a neutral park, **not** kept out. If the contact later does something that needs trust — e.g. DMs on a `trusted_contacts` channel — the deny-path flow **re-fires** (self-verify challenge + a fresh guardian card), so the guardian decides afresh. The guardian's way to stop the prompts is to `block`.
-- `block` → `revoked` contact: a durable keep-out. Re-contact is suppressed (no challenge, no guardian notification) on every floor.
-
-The resolved approval card mirrors this distinction on every surface (in-app, Slack): a `leave_unverified` park reads as a neutral **"Left unverified"**, while `block` reads as **"Denied"**. Both share the `denied` request status, so the card presentation is keyed off the decided action, not the status (see `PARK_ACTION_SET` / `isParkAction` in `runtime/channel-approval-types.ts`).
-
-Separately, the admitted-mode introduction **nudge** (for a contact who cleared the floor unclassified) is quieted once the guardian has decided the contact, so a classified contact is not re-nudged across conversations. That is distinct from the deny-path re-fire above.
+No trusted-contact activation happens. The sender is persisted as an unverified contact, and the terminal-deny check suppresses re-prompting the guardian for the same sender.
 
 ### Stage: `expired`
 
@@ -200,15 +191,10 @@ sequenceDiagram
         GW->>A: Forward with allow verdict
         A->>A: Process message normally
 
-    else Guardian leaves unverified
-        G->>A: Leave unverified (inline button / app / plain text)
-        A->>A: Resolver seeds unverified contact (neutral park —<br/>a trust-requiring re-contact re-fires the flow)
-        A-->>U: (No notification — user only learns<br/>if they message again)
-
-    else Guardian blocks
-        G->>A: Block
-        A->>A: Resolver revokes the channel (durable keep-out —<br/>re-contact suppressed)
-        A-->>U: "Your access request was declined."
+    else Guardian denies
+        G->>A: Deny (inline button / app / plain text)
+        A->>A: Resolver persists denial (terminal-deny)
+        A-->>U: (No notification — user only knows<br/>they were denied if they message again)
 
     else Guardian never responds
         Note over A: runGuardianExpirySweep()<br/>runs every 60 seconds
@@ -255,7 +241,7 @@ sequenceDiagram
 
 - If the unknown user messages the assistant multiple times before the guardian responds, each message hits the ACL denial path independently.
 - `notifyGuardianOfAccessRequest()` dedupes on the existing pending guardian request for the same (assistant, channel, requester), and the notification pipeline's `dedupeKey` prevents duplicate notification events.
-- A **durable keep-out** — a `revoked` or `blocked` contact — suppresses re-prompting entirely (`isKeptOutStatus(previousMemberStatus)`). A `leave_unverified` park (`unverified` contact) is **not** a keep-out and re-fires; only `block` stops the prompts. An approval whose verification window is still open also suppresses a fresh request (the sender is told to enter their code instead).
+- A prior terminal deny suppresses re-prompting entirely, and an approval whose verification window is still open suppresses a fresh request (the sender is told to enter their code instead).
 
 ### Requester already has a member record in non-active state
 

package/node_modules/@vellumai/ces-client/node_modules/@vellumai/service-contracts/package.json

@@ -17,7 +17,6 @@
     "./rpc": "./src/rpc.ts",
     "./attachment-naming": "./src/attachment-naming.ts",
     "./redacted-credential": "./src/redacted-credential.ts",
-    "./secret-detection": "./src/secret-detection.ts",
     "./error": "./src/error.ts"
   },
   "scripts": {

package/node_modules/@vellumai/ces-client/node_modules/@vellumai/service-contracts/src/remote-web-pairing.ts

@@ -109,77 +109,12 @@ export type RemoteWebPairingTokenResponse =
 // only) so both Node and browser callers share one implementation.
 
 /** Why a public base URL can't be advertised in a pairing challenge. */
-export type PublicBaseUrlRejection =
-  | "unparseable"
-  | "loopback"
-  | "non-https"
-  | "service-website";
+export type PublicBaseUrlRejection = "unparseable" | "loopback" | "non-https";
 
 export type PublicBaseUrlResult =
   | { ok: true; url: string }
   | { ok: false; reason: PublicBaseUrlRejection };
 
-/**
- * Hosts that are a tunnel/ingress vendor's own website, not a user's assistant
- * endpoint. These are the tunnel vendors our docs mention, and their sites are
- * exactly where a lost user grabs a URL from — e.g. a Tailscale admin invite
- * link (`login.tailscale.com/admin/invite/…`), which is https and non-loopback
- * and so clears every other check. Pairing refuses them with a targeted message
- * rather than minting a challenge the scanning device can never reach.
- */
-export const TUNNEL_PROVIDER_WEBSITE_HOSTS = [
-  "login.tailscale.com",
-  "tailscale.com",
-  "www.tailscale.com",
-  "ngrok.com",
-  "dashboard.ngrok.com",
-  "dash.cloudflare.com",
-  "cloudflare.com",
-  "www.cloudflare.com",
-] as const;
-
-/**
- * A URL whose exact host is a tunnel/ingress vendor's own website (see
- * {@link TUNNEL_PROVIDER_WEBSITE_HOSTS}). Exact-host only: a user's real
- * Tailscale endpoint (`*.ts.net`) or Cloudflare-fronted domain is never a
- * listed host, so a legitimate address is never mistaken for a vendor site.
- */
-export function isTunnelProviderWebsiteUrl(url: string): boolean {
-  let hostname: string;
-  try {
-    // WHATWG URL lowercases the hostname during parsing.
-    hostname = new URL(url).hostname;
-  } catch {
-    return false;
-  }
-  return (TUNNEL_PROVIDER_WEBSITE_HOSTS as readonly string[]).includes(
-    hostname,
-  );
-}
-
-/**
- * The display name of the tunnel/ingress vendor a service-website URL points
- * at (`"Tailscale"` / `"ngrok"` / `"Cloudflare"`), or null when the host is not
- * a known vendor site. Drives the "This is <Name>'s website" pairing guidance.
- */
-export function tunnelProviderWebsiteName(url: string): string | null {
-  let hostname: string;
-  try {
-    hostname = new URL(url).hostname;
-  } catch {
-    return null;
-  }
-  if (
-    !(TUNNEL_PROVIDER_WEBSITE_HOSTS as readonly string[]).includes(hostname)
-  ) {
-    return null;
-  }
-  if (hostname.includes("tailscale")) return "Tailscale";
-  if (hostname.includes("ngrok")) return "ngrok";
-  if (hostname.includes("cloudflare")) return "Cloudflare";
-  return null;
-}
-
 /**
  * A loopback URL — `localhost`, `[::1]`, or `127.x.x.x`. A pairing link that
  * encodes a loopback address is unreachable from the scanning device.
@@ -232,9 +167,6 @@ export function resolvePublicBaseUrl(raw: string): PublicBaseUrlResult {
   if (isLoopbackPublicUrl(normalized)) {
     return { ok: false, reason: "loopback" };
   }
-  if (isTunnelProviderWebsiteUrl(normalized)) {
-    return { ok: false, reason: "service-website" };
-  }
   if (new URL(normalized).protocol !== "https:") {
     return { ok: false, reason: "non-https" };
   }

package/node_modules/@vellumai/gateway-client/node_modules/@vellumai/service-contracts/package.json

@@ -17,7 +17,6 @@
     "./rpc": "./src/rpc.ts",
     "./attachment-naming": "./src/attachment-naming.ts",
     "./redacted-credential": "./src/redacted-credential.ts",
-    "./secret-detection": "./src/secret-detection.ts",
     "./error": "./src/error.ts"
   },
   "scripts": {

package/node_modules/@vellumai/gateway-client/node_modules/@vellumai/service-contracts/src/remote-web-pairing.ts

@@ -109,77 +109,12 @@ export type RemoteWebPairingTokenResponse =
 // only) so both Node and browser callers share one implementation.
 
 /** Why a public base URL can't be advertised in a pairing challenge. */
-export type PublicBaseUrlRejection =
-  | "unparseable"
-  | "loopback"
-  | "non-https"
-  | "service-website";
+export type PublicBaseUrlRejection = "unparseable" | "loopback" | "non-https";
 
 export type PublicBaseUrlResult =
   | { ok: true; url: string }
   | { ok: false; reason: PublicBaseUrlRejection };
 
-/**
- * Hosts that are a tunnel/ingress vendor's own website, not a user's assistant
- * endpoint. These are the tunnel vendors our docs mention, and their sites are
- * exactly where a lost user grabs a URL from — e.g. a Tailscale admin invite
- * link (`login.tailscale.com/admin/invite/…`), which is https and non-loopback
- * and so clears every other check. Pairing refuses them with a targeted message
- * rather than minting a challenge the scanning device can never reach.
- */
-export const TUNNEL_PROVIDER_WEBSITE_HOSTS = [
-  "login.tailscale.com",
-  "tailscale.com",
-  "www.tailscale.com",
-  "ngrok.com",
-  "dashboard.ngrok.com",
-  "dash.cloudflare.com",
-  "cloudflare.com",
-  "www.cloudflare.com",
-] as const;
-
-/**
- * A URL whose exact host is a tunnel/ingress vendor's own website (see
- * {@link TUNNEL_PROVIDER_WEBSITE_HOSTS}). Exact-host only: a user's real
- * Tailscale endpoint (`*.ts.net`) or Cloudflare-fronted domain is never a
- * listed host, so a legitimate address is never mistaken for a vendor site.
- */
-export function isTunnelProviderWebsiteUrl(url: string): boolean {
-  let hostname: string;
-  try {
-    // WHATWG URL lowercases the hostname during parsing.
-    hostname = new URL(url).hostname;
-  } catch {
-    return false;
-  }
-  return (TUNNEL_PROVIDER_WEBSITE_HOSTS as readonly string[]).includes(
-    hostname,
-  );
-}
-
-/**
- * The display name of the tunnel/ingress vendor a service-website URL points
- * at (`"Tailscale"` / `"ngrok"` / `"Cloudflare"`), or null when the host is not
- * a known vendor site. Drives the "This is <Name>'s website" pairing guidance.
- */
-export function tunnelProviderWebsiteName(url: string): string | null {
-  let hostname: string;
-  try {
-    hostname = new URL(url).hostname;
-  } catch {
-    return null;
-  }
-  if (
-    !(TUNNEL_PROVIDER_WEBSITE_HOSTS as readonly string[]).includes(hostname)
-  ) {
-    return null;
-  }
-  if (hostname.includes("tailscale")) return "Tailscale";
-  if (hostname.includes("ngrok")) return "ngrok";
-  if (hostname.includes("cloudflare")) return "Cloudflare";
-  return null;
-}
-
 /**
  * A loopback URL — `localhost`, `[::1]`, or `127.x.x.x`. A pairing link that
  * encodes a loopback address is unreachable from the scanning device.
@@ -232,9 +167,6 @@ export function resolvePublicBaseUrl(raw: string): PublicBaseUrlResult {
   if (isLoopbackPublicUrl(normalized)) {
     return { ok: false, reason: "loopback" };
   }
-  if (isTunnelProviderWebsiteUrl(normalized)) {
-    return { ok: false, reason: "service-website" };
-  }
   if (new URL(normalized).protocol !== "https:") {
     return { ok: false, reason: "non-https" };
   }

package/node_modules/@vellumai/service-contracts/package.json

@@ -17,7 +17,6 @@
     "./rpc": "./src/rpc.ts",
     "./attachment-naming": "./src/attachment-naming.ts",
     "./redacted-credential": "./src/redacted-credential.ts",
-    "./secret-detection": "./src/secret-detection.ts",
     "./error": "./src/error.ts"
   },
   "scripts": {

package/node_modules/@vellumai/service-contracts/src/remote-web-pairing.ts

@@ -109,77 +109,12 @@ export type RemoteWebPairingTokenResponse =
 // only) so both Node and browser callers share one implementation.
 
 /** Why a public base URL can't be advertised in a pairing challenge. */
-export type PublicBaseUrlRejection =
-  | "unparseable"
-  | "loopback"
-  | "non-https"
-  | "service-website";
+export type PublicBaseUrlRejection = "unparseable" | "loopback" | "non-https";
 
 export type PublicBaseUrlResult =
   | { ok: true; url: string }
   | { ok: false; reason: PublicBaseUrlRejection };
 
-/**
- * Hosts that are a tunnel/ingress vendor's own website, not a user's assistant
- * endpoint. These are the tunnel vendors our docs mention, and their sites are
- * exactly where a lost user grabs a URL from — e.g. a Tailscale admin invite
- * link (`login.tailscale.com/admin/invite/…`), which is https and non-loopback
- * and so clears every other check. Pairing refuses them with a targeted message
- * rather than minting a challenge the scanning device can never reach.
- */
-export const TUNNEL_PROVIDER_WEBSITE_HOSTS = [
-  "login.tailscale.com",
-  "tailscale.com",
-  "www.tailscale.com",
-  "ngrok.com",
-  "dashboard.ngrok.com",
-  "dash.cloudflare.com",
-  "cloudflare.com",
-  "www.cloudflare.com",
-] as const;
-
-/**
- * A URL whose exact host is a tunnel/ingress vendor's own website (see
- * {@link TUNNEL_PROVIDER_WEBSITE_HOSTS}). Exact-host only: a user's real
- * Tailscale endpoint (`*.ts.net`) or Cloudflare-fronted domain is never a
- * listed host, so a legitimate address is never mistaken for a vendor site.
- */
-export function isTunnelProviderWebsiteUrl(url: string): boolean {
-  let hostname: string;
-  try {
-    // WHATWG URL lowercases the hostname during parsing.
-    hostname = new URL(url).hostname;
-  } catch {
-    return false;
-  }
-  return (TUNNEL_PROVIDER_WEBSITE_HOSTS as readonly string[]).includes(
-    hostname,
-  );
-}
-
-/**
- * The display name of the tunnel/ingress vendor a service-website URL points
- * at (`"Tailscale"` / `"ngrok"` / `"Cloudflare"`), or null when the host is not
- * a known vendor site. Drives the "This is <Name>'s website" pairing guidance.
- */
-export function tunnelProviderWebsiteName(url: string): string | null {
-  let hostname: string;
-  try {
-    hostname = new URL(url).hostname;
-  } catch {
-    return null;
-  }
-  if (
-    !(TUNNEL_PROVIDER_WEBSITE_HOSTS as readonly string[]).includes(hostname)
-  ) {
-    return null;
-  }
-  if (hostname.includes("tailscale")) return "Tailscale";
-  if (hostname.includes("ngrok")) return "ngrok";
-  if (hostname.includes("cloudflare")) return "Cloudflare";
-  return null;
-}
-
 /**
  * A loopback URL — `localhost`, `[::1]`, or `127.x.x.x`. A pairing link that
  * encodes a loopback address is unreachable from the scanning device.
@@ -232,9 +167,6 @@ export function resolvePublicBaseUrl(raw: string): PublicBaseUrlResult {
   if (isLoopbackPublicUrl(normalized)) {
     return { ok: false, reason: "loopback" };
   }
-  if (isTunnelProviderWebsiteUrl(normalized)) {
-    return { ok: false, reason: "service-website" };
-  }
   if (new URL(normalized).protocol !== "https:") {
     return { ok: false, reason: "non-https" };
   }

package/openapi.yaml

@@ -3,7 +3,7 @@
 openapi: 3.1.0
 info:
   title: Vellum Assistant API
-  version: 0.10.12
+  version: 0.10.11
   description: Auto-generated OpenAPI specification for the Vellum Assistant runtime HTTP server.
 servers:
   - url: http://127.0.0.1:7821
@@ -17480,8 +17480,8 @@ paths:
       summary: Create a memory by remembering a fact
       description:
         Append a user-authored fact to the memory buffer via handleRemember. The fact surfaces in the memory graph
-        immediately as a pending node (its id is returned so clients can navigate to it), and a consolidation run is
-        nudged (deduped, backoff-respecting) so it files into concept pages promptly.
+        immediately as a pending node, and a consolidation run is nudged (deduped, backoff-respecting) so it files into
+        concept pages promptly.
       tags:
         - memory
       requestBody:
@@ -17507,11 +17507,6 @@ paths:
                     type: string
                   success:
                     type: boolean
-                  pendingNodeId:
-                    description:
-                      Graph node id (`buffer:<hash>`) of the pending entry this create appended, for fly-to-node navigation.
-                      Absent when the buffer can't be re-read.
-                    type: string
                 required:
                   - message
                   - success
@@ -19356,12 +19351,6 @@ paths:
                     - low
                     - medium
                     - high
-                bypassSecretCheck:
-                  description:
-                    When true, skip the secret-ingress scan for this message only. Set exclusively when the user explicitly
-                    confirms a client-side blocked send (the composer's "Send anyway" action); it is per-message and
-                    never persisted.
-                  type: boolean
                 hidden:
                   description:
                     "When true, persist the user message but suppress it from the UI transcript (it stays in LLM-side history
@@ -29407,12 +29396,6 @@ paths:
                     description:
                       Guardian-facing reply from the resolver (e.g. verification code for access-request approvals). Present only
                       when applied is true and the resolver produced a reply.
-                  decidedAction:
-                    type: string
-                    description:
-                      The action to present on the resolved card — the resolved outcome, not necessarily the raw button (an
-                      access-request 'reject' resolves to the 'leave_unverified' park). Present only when applied is
-                      true; lets a client completing the card optimistically render the correct tone.
                 required:
                   - ok
                 additionalProperties: false
@@ -32459,10 +32442,8 @@ components:
               anyOf:
                 - type: object
                   properties:
-                    provider:
-                      type: string
-                    model:
-                      type: string
+                    mode:
+                      $ref: "#/components/schemas/ServiceMode"
                   additionalProperties: {}
                 - type: "null"
             inference:
@@ -33273,10 +33254,8 @@ components:
             image-generation:
               type: object
               properties:
-                provider:
-                  type: string
-                model:
-                  type: string
+                mode:
+                  $ref: "#/components/schemas/ServiceMode"
               additionalProperties: {}
             inference:
               type: object

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vellumai/assistant",
-  "version": "0.10.12-dev.202607250047.75b9ec6",
+  "version": "0.10.12-staging.1",
   "license": "MIT",
   "type": "module",
   "exports": {

package/src/__tests__/acp-session.test.ts

@@ -2,7 +2,7 @@ import { beforeEach, describe, expect, mock, test } from "bun:test";
 
 import { VellumAcpClientHandler } from "../acp/client-handler.js";
 import { AcpSessionManager } from "../acp/session-manager.js";
-import type { AssistantEvent } from "../daemon/message-protocol.js";
+import type { ServerMessage } from "../daemon/message-protocol.js";
 import * as pendingInteractions from "../runtime/pending-interactions.js";
 
 // ---------------------------------------------------------------------------
@@ -10,8 +10,8 @@ import * as pendingInteractions from "../runtime/pending-interactions.js";
 // ---------------------------------------------------------------------------
 
 describe("VellumAcpClientHandler", () => {
-  let sent: AssistantEvent[];
-  let sendToVellum: (msg: AssistantEvent) => void;
+  let sent: ServerMessage[];
+  let sendToVellum: (msg: ServerMessage) => void;
   let handler: VellumAcpClientHandler;
 
   beforeEach(() => {

package/src/__tests__/approval-cascade.test.ts

@@ -11,7 +11,7 @@ import { Minimatch } from "minimatch";
 import { CompactionCircuit } from "../agent/compaction-circuit.js";
 import type { AgentEvent } from "../agent/loop.js";
 import type { ConfirmationStateChangedEvent } from "../api/events/confirmation-state-changed.js";
-import type { AssistantEvent } from "../daemon/message-protocol.js";
+import type { ServerMessage } from "../daemon/message-protocol.js";
 import type { Message, ProviderResponse } from "../providers/types.js";
 import type { ConfirmationDetails } from "../runtime/pending-interactions.js";
 
@@ -188,7 +188,7 @@ function makeProvider() {
 }
 
 function makeConversation(
-  sendToClient?: (msg: AssistantEvent) => void,
+  sendToClient?: (msg: ServerMessage) => void,
   conversationId = CONV_ID,
 ): Conversation {
   return new Conversation(
@@ -257,7 +257,7 @@ beforeEach(() => {
 
 describe("approval cascading", () => {
   test("allow (one-time) does NOT cascade", () => {
-    const emitted: AssistantEvent[] = [];
+    const emitted: ServerMessage[] = [];
     const conversationObj = makeConversation(
       (msg) => emitted.push(msg),
       CONV_ID,
@@ -291,7 +291,7 @@ describe("approval cascading", () => {
   });
 
   test("deny (one-time) does NOT cascade", () => {
-    const emitted: AssistantEvent[] = [];
+    const emitted: ServerMessage[] = [];
     const conversationObj = makeConversation(
       (msg) => emitted.push(msg),
       CONV_ID,
@@ -325,7 +325,7 @@ describe("approval cascading", () => {
   });
 
   test("already-resolved request handled gracefully", () => {
-    const emitted: AssistantEvent[] = [];
+    const emitted: ServerMessage[] = [];
     const conversationObj = makeConversation(
       (msg) => emitted.push(msg),
       CONV_ID,

package/src/__tests__/approval-routes-http.test.ts

@@ -7,7 +7,7 @@
 import { beforeEach, describe, expect, mock, test } from "bun:test";
 
 import type { Conversation } from "../daemon/conversation.js";
-import type { AssistantEvent } from "../daemon/message-protocol.js";
+import type { ServerMessage } from "../daemon/message-protocol.js";
 import type { SecretPromptResult } from "../permissions/secret-prompt-types.js";
 
 mock.module("../config/env.js", () => ({
@@ -123,7 +123,7 @@ function makeIdleSession(opts?: {
     runAgentLoop: async (
       _content: string,
       _messageId: string,
-      options?: { onEvent?: (msg: AssistantEvent) => void },
+      options?: { onEvent?: (msg: ServerMessage) => void },
     ) => {
       const onEvent = options?.onEvent ?? (() => {});
       onEvent({ type: "assistant_text_delta", text: "Hello!" });
@@ -186,7 +186,7 @@ function makeConfirmationEmittingSession(opts?: {
     runAgentLoop: async (
       _content: string,
       _messageId: string,
-      options?: { onEvent?: (msg: AssistantEvent) => void },
+      options?: { onEvent?: (msg: ServerMessage) => void },
     ) => {
       const onEvent = options?.onEvent ?? (() => {});
       // Simulate PermissionPrompter.prompt(): self-register in pendingInteractions