@vellumai/assistant 0.9.0 → 0.10.0-staging.2

package/ARCHITECTURE.md

@@ -343,11 +343,11 @@ The Slack channel provides text-based messaging via Slack's Socket Mode API. Unl
 
 **Control-plane endpoints** (`/v1/integrations/slack/channel/config`):
 
-| Endpoint                                | Method | Description                                                                                                                                                                                                                                                                     |
-| --------------------------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `/v1/integrations/slack/channel/config` | GET    | Returns current config status: `hasBotToken`, `hasAppToken`, `hasUserToken`, `connected`, plus workspace metadata (`teamId`, `teamName`, `botUserId`, `botUsername`)                                                                                                            |
-| `/v1/integrations/slack/channel/config` | POST   | Validates and stores credentials. Body: `{ botToken?: string, appToken?: string, userToken?: string }`                                                                                                                                                                          |
-| `/v1/integrations/slack/channel/config` | DELETE | Clears all Slack channel credentials (bot, app, and user tokens) from secure storage and credential metadata. Surgical user-token-only deletion is exposed internally via `clearSlackUserToken` (used by the credential vault) but is not reachable through this HTTP endpoint. |
+| Endpoint                                | Method | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
+| --------------------------------------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `/v1/integrations/slack/channel/config` | GET    | Returns current config status: `hasBotToken`, `hasAppToken`, `hasUserToken`, `connected`, plus workspace metadata (`teamId`, `teamName`, `botUserId`, `botUsername`)                                                                                                                                                                                                                                                                                              |
+| `/v1/integrations/slack/channel/config` | POST   | Validates and stores credentials. Body: `{ botToken?: string, appToken?: string, userToken?: string }`                                                                                                                                                                                                                                                                                                                                                            |
+| `/v1/integrations/slack/channel/config` | DELETE | Clears all Slack channel credentials (bot, app, and user tokens) from secure storage and credential metadata. The `credentials delete` route handles `slack_channel`/`user_token` like any other credential except that it skips the OAuth teardown, so removing just the user token leaves the channel's connection (run on the bot + app tokens) intact. `clearSlackUserToken` is the surgical user-token-only helper used internally by Slack config handling. |
 
 All endpoints are JWT-authenticated via `Authorization: Bearer <jwt>`.
 
@@ -609,10 +609,9 @@ Audio-to-text conversion occurs in six distinct runtime boundaries, each with it
 | ---------------------------- | ----------------------------------------------------------------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
 | **Telephony (hybrid)**       | Twilio-native ConversationRelay or daemon media-stream (provider-conditional) | Configured STT provider (via `services.stt`) | `src/calls/telephony-stt-routing.ts`                                                                                                                                                                                                                       | `src/calls/twilio-routes.ts`                                                   |
 | **Daemon batch**             | Daemon process (REST API to provider)                                         | Configured STT provider (via `services.stt`) | `src/stt/daemon-batch-transcriber.ts`                                                                                                                                                                                                                      | `src/runtime/routes/inbound-stages/transcribe-audio.ts`                        |
-| **Conversation streaming**   | Daemon process (WebSocket-based)                                              | Configured STT provider (via `services.stt`) | `src/stt/stt-stream-session.ts`, `src/providers/speech-to-text/deepgram-realtime.ts`, `src/providers/speech-to-text/google-gemini-live-stream.ts`, `src/providers/speech-to-text/openai-whisper-stream.ts`, `src/providers/speech-to-text/xai-realtime.ts` | `VoiceInputManager` (macOS conversation) via gateway WS proxy                  |
-| **Live voice channel**       | Assistant process (gateway-authenticated WebSocket)                           | Configured STT provider (via `services.stt`) | `src/runtime/http-server.ts`, `src/live-voice/live-voice-session-manager.ts`, `src/live-voice/live-voice-session.ts`, `src/providers/speech-to-text/resolve.ts`, streaming provider adapters                                                               | `LiveVoiceChannelManager` (macOS voice mode) via `/v1/live-voice`              |
-| **Client service-first**     | macOS via gateway → daemon                                                    | Configured STT provider (via `services.stt`) | `src/runtime/routes/stt-routes.ts`, `clients/shared/Network/STTClient.swift`                                                                                                                                                                               | `VoiceInputManager` (macOS dictation), `OpenAIVoiceService` (macOS voice mode) |
-| **Client-native (fallback)** | macOS on-device                                                               | Apple Speech (`SFSpeechRecognizer`)          | `clients/macos/.../SpeechRecognizerAdapter.swift`                                                                                                                                                                                                          | Fallback when STT service is unconfigured or fails                             |
+| **Conversation streaming**   | Daemon process (WebSocket-based)                                              | Configured STT provider (via `services.stt`) | `src/stt/stt-stream-session.ts`, `src/providers/speech-to-text/deepgram-realtime.ts`, `src/providers/speech-to-text/google-gemini-live-stream.ts`, `src/providers/speech-to-text/openai-whisper-stream.ts`, `src/providers/speech-to-text/xai-realtime.ts` | Web/Electron dictation client via gateway WS proxy                             |
+| **Live voice channel**       | Assistant process (gateway-authenticated WebSocket)                           | Configured STT provider (via `services.stt`) | `src/runtime/http-server.ts`, `src/live-voice/live-voice-session-manager.ts`, `src/live-voice/live-voice-session.ts`, `src/providers/speech-to-text/resolve.ts`, streaming provider adapters                                                               | Web/Electron live voice client via `/v1/live-voice`                            |
+| **Client service-first**     | Web/Electron via gateway → daemon                                            | Configured STT provider (via `services.stt`) | `src/runtime/routes/stt-routes.ts`                                                                                                                                                                                                                         | Web/Electron dictation and voice clients                                       |
 
 **Telephony boundary (hybrid routing):**
 
@@ -679,16 +678,14 @@ Two provider adapters are supported, each implementing the `StreamingTranscriber
 
 **Session lifecycle (client side):**
 
-- `STTStreamingClient` (`clients/shared/Network/STTStreamingClient.swift`) manages the WebSocket session using `URLSessionWebSocketTask`. It builds the gateway WebSocket URL via `GatewayHTTPClient.buildWebSocketRequest(path: "stt/stream", params:)`.
-- `STTProviderRegistry` (`clients/shared/Utilities/STTProviderRegistry.swift`) exposes `isStreamingAvailable` (checks the configured provider's `conversationStreamingMode` from the `GET /v1/stt/providers` API) and `isServiceConfigured` (checks whether any STT provider is set).
-- macOS: `VoiceInputManager.startStreamingSession()` creates a fresh `STTStreamingClient` per recording session. Streaming partials take priority over `SFSpeechRecognizer` partials while the stream is active and healthy. When recording stops, if the stream delivered at least one `final` event (`streamingReceivedFinal`) and has not failed (`streamingFailed`), the streaming final text is used directly. Otherwise, the batch STT path (`STTClient.transcribe()`) provides the fallback.
+The web client streaming dictation client lives at `clients/web/src/domains/chat/voice/dictation-stream.ts`; it opens the gateway WebSocket to `/v1/stt/stream`, parses `partial`/`final` frames, and reports failures so the caller can fall back to batch transcription. Before opening a session the client checks the configured provider's `conversationStreamingMode` from the `GET /v1/stt/providers` API. When the stream delivers at least one `final` event and has not failed, the streaming final text is used directly; otherwise the batch STT path (`clients/web/src/domains/chat/voice/stt-api.ts`) provides the fallback.
 
 **Fallback semantics:**
 
 The conversation streaming path degrades gracefully to the existing batch STT path:
 
-1. **Unsupported provider** (a hypothetical provider with `conversationStreamingMode: "none"`): The client checks `STTProviderRegistry.isStreamingAvailable` before attempting a streaming session. When `false`, recording proceeds with the batch-only flow (no WebSocket is opened). On the daemon side, if a streaming session is somehow opened for an unsupported provider, the session sends an `error` event followed by `closed` and closes the socket with code 1000.
-2. **Connection failure** (network error, gateway down, auth failure): The `STTStreamingClient` reports an `STTStreamFailure` to the client's `onFailure` callback. macOS sets `streamingFailed = true` and falls through to batch STT resolution when recording stops.
+1. **Unsupported provider** (a hypothetical provider with `conversationStreamingMode: "none"`): The client checks streaming availability (the configured provider's `conversationStreamingMode` from `GET /v1/stt/providers`) before attempting a streaming session. When unavailable, recording proceeds with the batch-only flow (no WebSocket is opened). On the daemon side, if a streaming session is somehow opened for an unsupported provider, the session sends an `error` event followed by `closed` and closes the socket with code 1000.
+2. **Connection failure** (network error, gateway down, auth failure): The streaming client reports the failure to its caller, which marks the stream as failed and falls through to batch STT resolution when recording stops.
 3. **Mid-session provider error** (provider WebSocket disconnect, timeout, rate limit): The daemon session emits an `error` event (with a normalized `SttErrorCategory`) followed by `closed`. The client marks the stream as failed and defers to batch STT.
 4. **Missing credentials**: `resolveStreamingTranscriber()` returns `null` when the API key is not configured. The session sends an `error`+`closed` pair and the client falls back to batch.
 
@@ -713,9 +710,8 @@ The conversation streaming path degrades gracefully to the existing batch STT pa
 | `src/providers/speech-to-text/resolve.ts`                   | `resolveStreamingTranscriber()`: credential-aware factory for streaming adapters; `resolveConversationStreamingSttCapability()`: capability validator |
 | `src/runtime/http-server.ts`                                | Runtime WebSocket upgrade handler for `/v1/stt/stream`, session registry (`activeSttStreamSessions`), graceful shutdown                               |
 | `gateway/src/http/routes/stt-stream-websocket.ts`           | Gateway WebSocket proxy: authenticates client, opens upstream WS to daemon with service token                                                         |
-| `clients/shared/Network/STTStreamingClient.swift`           | Shared Swift WebSocket client: `URLSessionWebSocketTask`-based, event parsing, failure reporting                                                      |
-| `clients/shared/Utilities/STTProviderRegistry.swift`        | Client-side provider catalog: `isStreamingAvailable`, `conversationStreamingMode` per provider                                                        |
-| `clients/macos/.../VoiceInputManager.swift`                 | macOS integration: `startStreamingSession()`, streaming/batch priority, fallback on failure                                                           |
+| `clients/web/src/domains/chat/voice/dictation-stream.ts`       | Web streaming dictation client: WebSocket session, event parsing, failure reporting                                                                   |
+| `clients/web/src/domains/chat/voice/voice-recording-store.ts`  | Web voice recording state: streaming/batch priority, fallback on failure                                                                              |
 
 **Live voice channel boundary:**
 
@@ -742,37 +738,25 @@ V1 is local/gateway-scoped. Managed/cloud WebSocket proxy support, cross-region
 
 **Client service-first boundary:**
 
-All product-facing dictation and voice-streaming paths on macOS use a service-first STT strategy. Clients record audio, encode it to WAV via `AudioWavEncoder` (shared utility in `clients/shared/Utilities/AudioWavEncoder.swift`), and POST it through the gateway to the daemon's `POST /v1/stt/transcribe` endpoint via `STTClient` (`clients/shared/Network/STTClient.swift`). The daemon resolves the configured STT provider through `resolveBatchTranscriber()` and returns the transcribed text.
+All product-facing dictation and voice-streaming paths use a service-first STT strategy. Clients record audio, encode it to WAV, and POST it through the gateway to the daemon's `POST /v1/stt/transcribe` endpoint. The daemon resolves the configured STT provider through `resolveBatchTranscriber()` and returns the transcribed text.
 
-- `STTClient` conforms to `STTClientProtocol` and returns a typed `STTResult` enum (`success`, `notConfigured`, `serviceUnavailable`, `error`). Callers pattern-match on the result to deterministically trigger native fallback.
+- The client receives a typed result distinguishing success from `notConfigured`, `serviceUnavailable`, and `error`, so callers can deterministically trigger their fallback path.
 - The gateway proxies the request via assistant-scoped path rewriting: `/v1/assistants/:id/stt/transcribe` is rewritten to `/v1/stt/transcribe` on the daemon.
 - `stt-routes.ts` (`src/runtime/routes/stt-routes.ts`) defines the HTTP endpoint, validates the audio payload, and delegates to `resolveBatchTranscriber()`.
 
-Product-facing flows using service-first STT:
-
-| Flow                          | Client | Entry point                                                                                                                                                                                         |
-| ----------------------------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **Push-to-talk dictation**    | macOS  | `VoiceInputManager.resolveTranscription()` — encodes accumulated PCM buffers to WAV, calls `sttClient.transcribe()`, falls back to native text on failure                                           |
-| **Conversation chat capture** | macOS  | `VoiceInputManager.handleFinalTranscription()` — prefers streaming final when available; falls back to batch `sttClient.transcribe()` when streaming was not used, failed, or produced no finals    |
-| **Voice mode (streaming)**    | macOS  | `OpenAIVoiceService.stopRecordingAndGetTranscription()` — encodes per-turn PCM to WAV, calls `sttClient.transcribe()` for turn-final transcript resolution, falls back to SFSpeechRecognizer result |
-
-**Client-native fallback boundary:**
-
-Apple-native on-device recognition via `SFSpeechRecognizer` serves two roles in all three product-facing flows above: (1) it provides low-latency partial transcriptions for real-time display during recording, and (2) it provides the fallback final transcription when the STT service is unconfigured (HTTP 503), temporarily unavailable (HTTP 5xx), or returns an empty result. The `SpeechRecognizerAdapter` protocols on each platform abstract Apple Speech for **testability and dependency injection**.
-
-The macOS `SpeechRecognizerAdapter` protocol in `clients/macos/vellum-assistant/Features/Voice/SpeechRecognizerAdapter.swift` abstracts `SFSpeechRecognizer` static APIs and instance creation. `AppleSpeechRecognizerAdapter` is the production implementation. `OpenAIVoiceService` and `VoiceInputManager` consume the adapter via dependency injection. **Note:** The protocol leaks Apple Speech types through its surface — `authorizationStatus()` returns `SFSpeechRecognizerAuthorizationStatus` and `makeRecognizer(locale:)` returns `SFSpeechRecognizer?` directly. This means callers depend on the Speech framework at compile time.
+The web client implements these flows in `clients/web/src/domains/chat/voice/`: `stt-api.ts` (batch transcribe), `dictation-stream.ts` (streaming dictation), and `voice-recording-store.ts` (recording state, streaming/batch priority, fallback). Push-to-talk dictation and conversation chat capture prefer a streaming final when available and fall back to batch transcription when streaming was not used, failed, or produced no finals.
 
 **Cross-boundary notes:**
 
 - The `services.stt` config block is the single source of truth for STT provider selection across the daemon batch boundary, the conversation streaming boundary, the client service-first boundary, and the telephony boundary. The batch and streaming resolvers (`resolveBatchTranscriber()`, `resolveStreamingTranscriber()`) both read from `services.stt.provider` and resolve credentials through the same catalog; the telephony boundary uses `resolveTelephonySttRouting()` to determine the Twilio integration strategy. The daemon provider catalog (`src/providers/speech-to-text/provider-catalog.ts`) is the authoritative registry of supported providers. Native clients fetch display metadata via `GET /v1/stt/providers`.
 - Conversation streaming does not replace the client service-first batch path. When streaming is available, it runs concurrently during recording and provides real-time partials and finals. The batch path remains the fallback for providers that do not support streaming, when streaming fails mid-session, or when streaming produces no final transcript.
 - Credential mapping is catalog-driven: `provider-secret-catalog.ts` derives STT API-key provider names from the daemon catalog via `listCredentialProviderNames()`, deduplicating against the LLM/search provider list. Adding a provider to the catalog automatically includes its credential name in `API_KEY_PROVIDERS`.
-- Terminology: "STT" and "transcription" refer to the same operation (converting audio to text). "Speech recognition" is used in client-native contexts where Apple's Speech framework terminology is canonical. All three terms map to the same conceptual operation.
+- Terminology: "STT", "transcription", and "speech recognition" all refer to the same operation (converting audio to text).
 - **Onboarding**: For a step-by-step guide to adding a new STT provider, see `docs/stt-provider-onboarding.md`.
 
 ### On-Demand Home Content Generation
 
-LLM-generated content shown by clients (personalized home greeting, suggested prompts, conversation starters, identity intro) is produced on demand, never at daemon startup or on unconditional timers.
+LLM-generated content shown by clients (personalized home greeting, suggested prompts, conversation starters) is produced on demand, never at daemon startup or on unconditional timers.
 
 **Data flow (home greeting + suggested prompts):**
 

package/bun.lock

@@ -25,6 +25,7 @@
         "@vellumai/twilio-client": "file:../packages/twilio-client",
         "commander": "13.1.0",
         "croner": "10.0.1",
+        "diff": "8.0.4",
         "dotenv": "17.3.1",
         "drizzle-orm": "0.45.2",
         "jszip": "3.10.1",
@@ -1244,17 +1245,13 @@
 
     "@vellumai/ces-client/@types/bun": ["@types/bun@1.2.4", "", { "dependencies": { "bun-types": "1.2.4" } }, "sha512-QtuV5OMR8/rdKJs213iwXDpfVvnskPXY/S0ZiFbsTjQZycuqPbMW8Gf/XhLfwE5njW8sxI2WjISURXPlHypMFA=="],
 
-    "@vellumai/ces-client/@vellumai/service-contracts": ["@vellumai/service-contracts@file:../packages/service-contracts", {}],
+    "@vellumai/ces-client/@vellumai/service-contracts": ["@vellumai/service-contracts@file:../packages/service-contracts", { "dependencies": { "zod": "4.3.6" }, "devDependencies": { "@types/bun": "1.2.4", "typescript": "5.7.3" } }],
 
     "@vellumai/ces-client/typescript": ["typescript@5.7.3", "", { "bin": { "tsc": "bin/tsc", "tsserver": "bin/tsserver" } }, "sha512-84MVSjMEHP+FQRPy3pX9sTVV/INIex71s9TL2Gm5FG/WG1SqXeKyZ0k7/blY/4FdOzI12CBy1vGc4og/eus0fw=="],
 
     "@vellumai/environments/@types/bun": ["@types/bun@1.3.11", "", { "dependencies": { "bun-types": "1.3.11" } }, "sha512-5vPne5QvtpjGpsGYXiFyycfpDF2ECyPcTSsFBMa0fraoxiQyMJ3SmuQIGhzPg2WJuWxVBoxWJ2kClYTcw/4fAg=="],
 
-    "@vellumai/gateway-client/@vellumai/service-contracts": ["@vellumai/service-contracts@file:../packages/service-contracts", {}],
-
-    "@vellumai/service-contracts/@types/bun": ["@types/bun@1.2.4", "", { "dependencies": { "bun-types": "1.2.4" } }, "sha512-QtuV5OMR8/rdKJs213iwXDpfVvnskPXY/S0ZiFbsTjQZycuqPbMW8Gf/XhLfwE5njW8sxI2WjISURXPlHypMFA=="],
-
-    "@vellumai/service-contracts/typescript": ["typescript@5.7.3", "", { "bin": { "tsc": "bin/tsc", "tsserver": "bin/tsserver" } }, "sha512-84MVSjMEHP+FQRPy3pX9sTVV/INIex71s9TL2Gm5FG/WG1SqXeKyZ0k7/blY/4FdOzI12CBy1vGc4og/eus0fw=="],
+    "@vellumai/gateway-client/@vellumai/service-contracts": ["@vellumai/service-contracts@file:../packages/service-contracts", { "dependencies": { "zod": "4.3.6" }, "devDependencies": { "@types/bun": "1.2.4", "typescript": "5.7.3" } }],
 
     "bl/readable-stream": ["readable-stream@3.6.2", "", { "dependencies": { "inherits": "^2.0.3", "string_decoder": "^1.1.1", "util-deprecate": "^1.0.1" } }, "sha512-9u/sniCrY3D5WdsERHzHE4G2YCXqoG5FTHUiCC4SIbr6XcLZBY05ya9EKjYek9O5xOAwjGq+1JdGBAS7Q9ScoA=="],
 
@@ -1342,9 +1339,11 @@
 
     "@vellumai/ces-client/@types/bun/bun-types": ["bun-types@1.2.4", "", { "dependencies": { "@types/node": "*", "@types/ws": "~8.5.10" } }, "sha512-nDPymR207ZZEoWD4AavvEaa/KZe/qlrbMSchqpQwovPZCKc7pwMoENjEtHgMKaAjJhy+x6vfqSBA1QU3bJgs0Q=="],
 
-    "@vellumai/environments/@types/bun/bun-types": ["bun-types@1.3.11", "", { "dependencies": { "@types/node": "*" } }, "sha512-1KGPpoxQWl9f6wcZh57LvrPIInQMn2TQ7jsgxqpRzg+l0QPOFvJVH7HmvHo/AiPgwXy+/Thf6Ov3EdVn1vOabg=="],
+    "@vellumai/ces-client/@vellumai/service-contracts/@types/bun": ["@types/bun@1.3.10", "", { "dependencies": { "bun-types": "1.3.10" } }, "sha512-0+rlrUrOrTSskibryHbvQkDOWRJwJZqZlxrUs1u4oOoTln8+WIXBPmAuCF35SWB2z4Zl3E84Nl/D0P7803nigQ=="],
 
-    "@vellumai/service-contracts/@types/bun/bun-types": ["bun-types@1.2.4", "", { "dependencies": { "@types/node": "*", "@types/ws": "~8.5.10" } }, "sha512-nDPymR207ZZEoWD4AavvEaa/KZe/qlrbMSchqpQwovPZCKc7pwMoENjEtHgMKaAjJhy+x6vfqSBA1QU3bJgs0Q=="],
+    "@vellumai/ces-client/@vellumai/service-contracts/typescript": ["typescript@5.9.3", "", { "bin": { "tsc": "bin/tsc", "tsserver": "bin/tsserver" } }, "sha512-jl1vZzPDinLr9eUt3J/t7V6FgNEw9QjvBPdysz9KfQDD41fQrC2Y4vKQdiaUpFT4bXlb1RHhLpp8wtm6M5TgSw=="],
+
+    "@vellumai/environments/@types/bun/bun-types": ["bun-types@1.3.11", "", { "dependencies": { "@types/node": "*" } }, "sha512-1KGPpoxQWl9f6wcZh57LvrPIInQMn2TQ7jsgxqpRzg+l0QPOFvJVH7HmvHo/AiPgwXy+/Thf6Ov3EdVn1vOabg=="],
 
     "detective-typescript/@typescript-eslint/typescript-estree/@typescript-eslint/project-service": ["@typescript-eslint/project-service@8.61.0", "", { "dependencies": { "@typescript-eslint/tsconfig-utils": "^8.61.0", "@typescript-eslint/types": "^8.61.0", "debug": "^4.4.3" }, "peerDependencies": { "typescript": ">=4.8.4 <6.1.0" } }, "sha512-DV42F7MLJO6Rax7SK1yg43tcnEfGUrurSpSxKuVX+a3RCTzBlH3fuxprrOJXKCJGAaw82xXocikJ0uQaqwXgGA=="],
 

package/docs/activation-funnel-telemetry.md

@@ -1,6 +1,6 @@
 # Activation Funnel Telemetry — Runbook + Analytics Handoff
 
-> **Linear:** JARVIS-1102 (event emission) — gates JARVIS-1092 (10% rollout) and JARVIS-1093 (dashboard).
+> **Linear:** event emission ticket — gates rollout and dashboard tickets.
 > **Funnel version:** `activation_v1_2026_06`
 > **LD flag:** `experiment-activation-flow-2026-06-03`
 > **Cohort arm tag:** `ab_variant = "variant-a"` (treatment); `control` = the no-rail arm.
@@ -50,8 +50,9 @@ Flow, end to end:
      `assistant/src/telemetry/activation-funnel.ts`;
    - emission is best-effort (wrapped in try/catch) and never blocks or alters
      the surface-action flow;
-   - `recordActivationEvent` respects the `getConfig().collectUsageData` opt-out
-     gate (returns `null` / no row when disabled).
+   - `recordActivationEvent` respects the platform `share_analytics` consent gate
+     via `getCachedShareAnalytics()` (returns `null` / no row when the platform
+     user has not consented; default-off when there is no platform session).
 2. **Reporter flushes** every ~5 min: `usage-telemetry-reporter.ts`
    (`REPORT_INTERVAL_MS = 5 * 60 * 1000`, with a one-time
    `INITIAL_FLUSH_DELAY_MS = 30_000` after startup) POSTs unreported onboarding
@@ -172,22 +173,27 @@ When the flag is ON, the web prechat context selects
 `BOOTSTRAP-ACTIVATION-RAIL.md` as the bootstrap template, and the daemon marks
 the conversation in `activation_sessions` on first build of the system prompt.
 
-### 5.2 Confirm usage-data collection is enabled — and do NOT run in dev mode
-
-Two gates must both be satisfied or no rows reach BigQuery:
-
-1. `recordActivationEvent` no-ops when `config.collectUsageData` is false, so the
-   dev build/config must have usage-data collection enabled, or no rows are
-   written to SQLite.
-2. **Dev mode disables the flush entirely.** `assistant/src/daemon/lifecycle.ts`
-   computes the effective setting as `collectUsageData = !isDevMode &&
-config.collectUsageData`, so when the daemon runs in dev mode (`VELLUM_DEV=1`)
-   the `UsageTelemetryReporter` is never started — rows accumulate in SQLite but
-   are never POSTed, and the "wait/restart for flush" steps below will never
-   reach BigQuery. For an end-to-end smoke test, run the daemon **outside dev
-   mode** (so the reporter starts), or explicitly invoke the reporter's
-   `flush()` via a dev hook. The SQLite rows can still be inspected directly in
-   dev mode, but the BigQuery verification (§6) requires a real flush.
+### 5.2 Confirm share_analytics consent is on — and pick the right daemon mode
+
+Two distinct concerns: whether record-time rows reach SQLite (consent gate), and
+whether those rows reach BigQuery (flush gate, dev-disabled).
+
+1. `recordActivationEvent` no-ops when the platform `share_analytics` consent is
+   off (it reads `getCachedShareAnalytics()`), and the consent is **default-off
+   when there is no platform session**. So the dev session must be signed in to
+   the platform with `share_analytics` consent enabled, or no rows are written to
+   SQLite. The consent cache is refreshed by `startConsentRefresh()` in
+   `assistant/src/daemon/lifecycle.ts`, which runs **regardless of dev mode** — so
+   a dev session signed in with `share_analytics` consent enabled writes
+   record-time rows to SQLite, where they can be inspected directly.
+2. **Dev mode disables the flush entirely.** When the daemon runs in dev mode
+   (`VELLUM_DEV=1`), `assistant/src/daemon/lifecycle.ts` never starts the
+   `UsageTelemetryReporter` — rows accumulate in SQLite (consent permitting) but
+   are never POSTed, and the "wait/restart for flush" steps below will never reach
+   BigQuery. For an end-to-end smoke test, run the daemon **outside dev mode** (so
+   the reporter starts), or explicitly invoke the reporter's `flush()` via a dev
+   hook. The SQLite rows can be inspected directly in dev mode, but the BigQuery
+   verification (§6) requires a real flush.
 
 ### 5.3 Start a fresh activation conversation and capture its id
 
@@ -261,9 +267,9 @@ collapses it earliest-wins).
 
 ---
 
-## 7. Canonical handoff blurb (paste-ready for the final JARVIS-1102 PR description)
+## 7. Canonical handoff blurb (paste-ready for the final PR description)
 
-> **Activation funnel telemetry — handoff for JARVIS-1093.** The activation rail
+> **Activation funnel telemetry — handoff for dashboard ticket.** The activation rail
 > now emits five milestone funnel events into the existing onboarding telemetry
 > substrate (`type: "onboarding"` → `/v1/telemetry/ingest/` → GCS NDJSON →
 > `vellum-ai-prod.telemetry.onboarding_raw`), so no new event type, ingest
@@ -290,7 +296,7 @@ collapses it earliest-wins).
 
 ## 8. Notes
 
-- **JARVIS-1102 "naming check" (resolved).** Events fire **deterministically on
+- **"naming check" (resolved).** Events fire **deterministically on
   the real user commit of a `ui_show` surface, not every text turn**. The model
   passively tags the surface for a rail move with `activation_moment`; the daemon
   records the milestone in `handleSurfaceAction` when the user commits that

package/docs/architecture/security.md

@@ -223,35 +223,35 @@ The credential system enforces four security invariants:
 
 ```mermaid
 sequenceDiagram
-    participant Model as LLM
-    participant Vault as credential_store tool
+    participant Model as LLM (assistant credentials prompt)
+    participant Route as credentials prompt route
     participant Prompter as SecretPrompter
     participant HTTP as HTTP Transport
-    participant UI as SecretPromptManager (Swift)
+    participant UI as Secret prompt UI (client)
     participant Store as Credential Store (CES / encrypted file)
 
-    Model->>Vault: action: "prompt", service, field, label
-    Vault->>Prompter: requestSecret(service, field, label, ...)
+    Model->>Route: assistant credentials prompt --service --field --label
+    Route->>Prompter: requestSecretStandalone(service, field, label, ...)
     Prompter->>HTTP: secret_request {requestId, service, field, label, allowOneTimeSend}
-    HTTP->>UI: Show SecretPromptView (floating panel)
-    UI->>UI: User enters value in SecureField
+    HTTP->>UI: Show secret prompt
+    UI->>UI: User enters value in a masked field
     alt Store (default)
         UI->>HTTP: secret_response {requestId, value, delivery: "store"}
         HTTP->>Prompter: resolve(value, "store")
-        Prompter->>Vault: {value, delivery: "store"}
-        Vault->>Store: setSecureKeyAsync("credential/svc/field", value)
-        Vault->>Model: "Credential stored securely" (no value in output)
+        Prompter->>Route: {value, delivery: "store"}
+        Route->>Store: persistPromptedCredential → setSecureKeyAsync("credential/svc/field", value)
+        Route->>Model: "Stored credential ..." (no value in output)
     else One-Time Send (if enabled)
         UI->>HTTP: secret_response {requestId, value, delivery: "transient_send"}
         HTTP->>Prompter: resolve(value, "transient_send")
-        Prompter->>Vault: {value, delivery: "transient_send"}
-        Note over Vault: Hands value to CredentialBroker<br/>for single-use consumption
-        Vault->>Model: "One-time credential provided" (no value in output)
+        Prompter->>Route: {value, delivery: "transient_send"}
+        Note over Route: Hands value to CredentialBroker<br/>for single-use consumption
+        Route->>Model: "One-time credential provided" (no value in output)
     else Cancel
         UI->>HTTP: secret_response {requestId, value: null}
         HTTP->>Prompter: resolve(null)
-        Prompter->>Vault: null
-        Vault->>Model: "User cancelled"
+        Prompter->>Route: null
+        Route->>Model: "User cancelled"
     end
 ```
 
@@ -273,7 +273,7 @@ The `allowOneTimeSend` config gate (default: `false`) enables a secondary "Send
 - The secret value is handed to the `CredentialBroker`, which holds it in memory for the next `consume` or `browserFill` call
 - The value is **not** persisted to the credential store
 - The broker discards the value after a single use
-- The vault tool output confirms delivery without including the secret value — the value is never returned to the model
+- The credentials prompt route output confirms delivery without including the secret value — the value is never returned to the model
 - The config gate must be explicitly enabled by the operator
 
 ### Storage Layout
@@ -286,18 +286,19 @@ The `allowOneTimeSend` config gate (default: `false`) enables a secondary "Send
 
 ### Key Files
 
-| File                                                 | Role                                                                               |
-| ---------------------------------------------------- | ---------------------------------------------------------------------------------- |
-| `assistant/src/tools/credentials/vault.ts`           | `credential_store` tool — store, list, delete, prompt actions                      |
-| `assistant/src/security/secure-keys.ts`              | Async secure key CRUD via CES and encrypted file store                             |
-| `assistant/src/tools/credentials/metadata-store.ts`  | JSON file metadata CRUD for credential records                                     |
-| `assistant/src/tools/credentials/broker.ts`          | Brokered credential access with policy enforcement and transient send              |
-| `assistant/src/tools/credentials/policy-validate.ts` | Policy input validation (allowedTools, allowedDomains)                             |
-| `assistant/src/permissions/secret-prompter.ts`       | HTTP secret_request/secret_response flow                                           |
-| `assistant/src/security/secret-scanner.ts`           | Prefix + shape-based secret regex detection (used by display-time `redactSecrets`) |
-| `assistant/src/security/secret-ingress.ts`           | Prefix-only ingress check on user messages                                         |
-| `assistant/src/util/log-redact.ts`                   | Pino log serializers — prefix-based redaction for logs                             |
-| `clients/macos/.../SecretPromptManager.swift`        | Floating panel UI for secure credential entry                                      |
+| File                                                        | Role                                                                               |
+| ----------------------------------------------------------- | ---------------------------------------------------------------------------------- |
+| `assistant/src/runtime/routes/credential-routes.ts`         | `assistant credentials` CLI — store, list, delete, inspect, reveal handlers        |
+| `assistant/src/credential-execution/prompted-credential.ts` | Persists credentials collected through the secure `credentials prompt` flow        |
+| `assistant/src/security/secure-keys.ts`                     | Async secure key CRUD via CES and encrypted file store                             |
+| `assistant/src/tools/credentials/metadata-store.ts`         | JSON file metadata CRUD for credential records                                     |
+| `assistant/src/tools/credentials/broker.ts`                 | Brokered credential access with policy enforcement and transient send              |
+| `assistant/src/tools/credentials/policy-validate.ts`        | Policy input validation (allowedTools, allowedDomains)                             |
+| `assistant/src/permissions/secret-prompter.ts`              | HTTP secret_request/secret_response flow                                           |
+| `assistant/src/security/secret-scanner.ts`                  | Prefix + shape-based secret regex detection (used by display-time `redactSecrets`) |
+| `assistant/src/security/secret-ingress.ts`                  | Prefix-only ingress check on user messages                                         |
+| `assistant/src/util/log-redact.ts`                          | Pino log serializers — prefix-based redaction for logs                             |
+| `clients/web/src/domains/chat/components/secret-prompt-card.tsx` | UI for secure credential entry                                                    |
 
 ---
 

package/docs/stt-provider-onboarding.md

@@ -72,13 +72,11 @@ Native clients fetch this metadata at launch via `GET /v1/stt/providers`. No sep
 | `google-gemini`  | `gemini`             | shared        |
 | `xai`            | `xai`                | exclusive     |
 
-When the provider ID differs from the credential provider name (e.g. `google-gemini` maps to `gemini`), the key is **shared** with other services that use the same credential. The `sttKeyIsExclusive` / `sttKeyIsShared` helpers in the macOS settings layer derive this automatically from the catalog.
+When the provider ID differs from the credential provider name (e.g. `google-gemini` maps to `gemini`), the key is **shared** with other services that use the same credential.
 
-### macOS settings key behavior
+### Client settings key behavior
 
-**File:** `clients/macos/vellum-assistant/Features/Settings/SettingsStore.swift`
-
-The `sttKeyIsExclusive(for:)` / `sttKeyIsShared(for:)` helpers derive shared-vs-exclusive key behavior from the catalog automatically: if `apiKeyProviderName == id`, the key is exclusive; otherwise it is shared. No new conditionals are needed unless the provider has a non-standard key-ownership model.
+Clients derive shared-vs-exclusive key behavior from the catalog automatically: if `apiKeyProviderName == id`, the key is exclusive; otherwise it is shared. No new conditionals are needed unless the provider has a non-standard key-ownership model. The web settings UI lives in `clients/web/src/domains/settings/ai/speech-to-text-card.tsx`.
 
 ## 7. Verify unified STT architecture
 

package/docs/workflows-testing.md

@@ -2,14 +2,13 @@
 
 This runbook covers the parts of the workflow engine that automated tests do not:
 real provider calls, real journaled resume across a restart, capability
-containment under a live model, flag-off inertness, and persona-leaf voice. Unit
+containment under a live model, and persona-leaf voice. Unit
 and integration coverage lives under `assistant/src/workflows/*.test.ts` and
 `assistant/src/__tests__/`; this is the human-in-the-loop pass that runs **last**,
 on throwaway instances first, and only touches a real inbox or a production
 instance at the very end.
 
-Work through the steps in order. The `workflows` flag is **off by default**, so
-every step that exercises the engine first enables it on a throwaway instance.
+Work through the steps in order, on throwaway instances first.
 
 > **Safety rule:** Nothing in this runbook touches a real inbox, a real workspace,
 > or a production instance until every throwaway-instance step has passed. The
@@ -17,7 +16,7 @@ every step that exercises the engine first enables it on a throwaway instance.
 
 ---
 
-## 1. Hatch a throwaway instance and enable the flag
+## 1. Hatch a throwaway instance
 
 Hatch a disposable Docker instance built from local source:
 
@@ -26,25 +25,14 @@ vellum hatch --remote docker --source .
 ```
 
 Note the instance name it prints (e.g. `vellum-<adjective>-<animal>`). Use it as
-`--assistant <name>` for everything below, or set it active.
-
-Enable the `workflows` flag via that instance's feature-flag override file. The
-override lives in the instance's `protected/feature-flags.json` (overrides here
-win over the registry default — see the feature-flag-overrides gotcha):
-
-```jsonc
-// .../<instance>/protected/feature-flags.json
-{ "workflows": true }
-```
-
-Restart the instance so it re-reads the override, then confirm it is up:
+`--assistant <name>` for everything below, or set it active. Confirm it is up:
 
 ```
 vellum ps
 ```
 
-Sanity-check that the surface is now live: `vellum workflows runs --assistant <name>`
-should return an (empty) table rather than a 404.
+Sanity-check that the workflow surface is live: `vellum workflows runs --assistant <name>`
+should return an (empty) table.
 
 ---
 
@@ -168,27 +156,9 @@ or a send tool, with `capabilities.tools` left empty). Run it and confirm:
 
 ---
 
-## 6. Flag-off inertness
-
-On a **default** instance (no `workflows` override, or set back to `false` and
-restart), confirm the whole surface is gone:
-
-- `run_workflow` and `manage_workflows` are **absent** from the tool set (the
-  assistant cannot call them).
-- The routes 404:
-
-  ```
-  vellum workflows runs --assistant <default-instance>   # request fails (404)
-  ```
-
-- A scheduler `workflow`-mode job is **rejected** (the engine gate throws before
-  any run is launched).
-
----
-
-## 7. Real-data smoke (throwaway TEST account)
+## 6. Real-data smoke (throwaway TEST account)
 
-Only after steps 1–6 pass: run the full path against a **throwaway TEST Google or
+Only after steps 1–5 pass: run the full path against a **throwaway TEST Google or
 Slack account** with about a dozen messages — never a real account. Drive the
 end-to-end flow:
 
@@ -203,17 +173,16 @@ real content, and every side effect was one the manifest declared.
 
 ---
 
-## 8. Production / persona instance — LAST
+## 7. Production / persona instance — LAST
 
-Flip the `workflows` flag on a real (e.g. persona) instance **only after** the
-throwaway instances above pass, and only after the instance is on current code:
+Run on a real (e.g. persona) instance **only after** the throwaway instances
+above pass, and only after the instance is on current code:
 
 1. `git pull` and **restart** the instance so it runs the merged code (a restart
    alone re-runs stale code — see the deploy gotcha).
-2. Enable the flag and restart.
-3. Start with the **smallest real slice** — a few items, dry-run actions where the
+2. Start with the **smallest real slice** — a few items, dry-run actions where the
    tool supports it — before any larger or side-effecting run.
-4. **Human-eval the persona-leaf voice**: read a persona leaf's output and confirm
+3. **Human-eval the persona-leaf voice**: read a persona leaf's output and confirm
    it reads as the assistant, not as a generic worker.
 
 Stop and reassess if any run's `agentsSpawned` approaches `maxAgentsPerRun`, if

package/docs/workflows.md

@@ -8,11 +8,9 @@ from each of a hundred documents, draft-then-verify a batch — and you want the
 results orchestrated deterministically and reported back when the whole run
 finishes.
 
-Workflows are gated behind the `workflows` feature flag (default **off**). The
-`run_workflow` / `manage_workflows` tools are served by the flag-gated `workflows`
+The `run_workflow` / `manage_workflows` tools are served by the `workflows`
 bundled skill rather than as always-on tools — load it with `skill_load` and invoke
-its tools via `skill_execute`. When the flag is off, the skill is absent, the
-management routes 404, and the scheduler rejects `workflow`-mode jobs.
+its tools via `skill_execute`.
 
 - Engine code: `assistant/src/workflows/`
 - Skill (tool surface): `assistant/src/config/bundled-skills/workflows/`
@@ -437,7 +435,7 @@ Reached via the skill (`skill_load` then `skill_execute`), not as always-on tool
   `list_profiles` returns `{ profiles, activeProfile }` — the defined LLM profile
   names plus the workspace active profile, used to pick a valid leaf `profile`.
 
-### Routes (read/abort/resume, all 404 when the flag is off)
+### Routes (read/abort/resume)
 
 | Method | Path                            | Purpose                                                                                              |
 | ------ | ------------------------------- | ---------------------------------------------------------------------------------------------------- |

package/node_modules/@vellumai/ces-client/src/__tests__/ces-client.test.ts

@@ -74,7 +74,11 @@ function createMockTransport(): CesTransport & {
   messages: string[];
   messageHandler: ((msg: string) => void) | null;
   alive: boolean;
+  /** Simulate the transport dying (e.g. a spurious stdout EOF): mark it dead
+   *  and fire the registered close handlers, as the real transports do. */
+  die: () => void;
 } {
+  const closeHandlers: Array<() => void> = [];
   const transport = {
     messages: [] as string[],
     messageHandler: null as ((msg: string) => void) | null,
@@ -88,9 +92,16 @@ function createMockTransport(): CesTransport & {
     isAlive() {
       return transport.alive;
     },
+    onClose(handler: () => void) {
+      closeHandlers.push(handler);
+    },
     close() {
       transport.alive = false;
     },
+    die() {
+      transport.alive = false;
+      for (const handler of closeHandlers) handler();
+    },
   };
   return transport;
 }
@@ -605,6 +616,42 @@ describe("CesRpcClient", () => {
     expect(client.isReady()).toBe(false);
   });
 
+  test("a pending request fails fast when the transport dies (no timeout wait)", async () => {
+    const transport = createMockTransport();
+    const client = createCesRpcClient(transport, {
+      handshakeTimeoutMs: 5000,
+      // Long timeout on purpose: the call must reject from the transport
+      // DEATH, not this timer. Without the fail-fast it would hang 60s.
+      requestTimeoutMs: 60_000,
+    });
+
+    // Handshake
+    const hPromise = client.handshake();
+    const hSent = JSON.parse(transport.messages[0]!);
+    transport.messageHandler!(
+      JSON.stringify({
+        type: "handshake_ack",
+        protocolVersion: CES_PROTOCOL_VERSION,
+        sessionId: hSent.sessionId,
+        accepted: true,
+      }),
+    );
+    await hPromise;
+
+    const callPromise = client.call("list_credentials", {});
+
+    // The transport's read side dies (e.g. a spurious stdout EOF on a CES
+    // bounce) while the request is in flight — the response can never arrive.
+    transport.die();
+
+    try {
+      await callPromise;
+      throw new Error("should have thrown");
+    } catch (err) {
+      expect(err).toBeInstanceOf(CesTransportError);
+    }
+  });
+
   test("subsequent handshake call returns immediately if already ready", async () => {
     const transport = createMockTransport();
     const client = createCesRpcClient(transport, { handshakeTimeoutMs: 5000 });