@vellumai/assistant 0.12.3 → 0.12.4-dev.202609231620.a15f321

package/src/messaging/providers/gmail/client.ts

@@ -33,6 +33,10 @@ export const GMAIL_API_BASE_URL =
  * requests Calendar-only). Resolving against Gmail read access turns a
  * downstream 403 into an actionable "reconnect Google and grant Gmail" error
  * at resolution time when the selected connection cannot read Gmail.
+ *
+ * Managed connections never carry this scope: Vellum's app grants Gmail as
+ * `https://mail.google.com/`, which `scopeDifference` in `oauth/scope-utils.ts`
+ * accepts as covering it.
  */
 export const GMAIL_REQUIRED_SCOPES = [
   "https://www.googleapis.com/auth/gmail.readonly",

package/src/notifications/README.md

@@ -13,7 +13,7 @@ Producer → NotificationSignal → Source-Active Gate → Candidate Generation
 
 ### 1. Signal
 
-A producer calls `emitNotificationSignal()` with a free-form event name, attention hints (urgency, requiresAction, deadlineAt), and a context payload. The signal is persisted as a `notification_events` row.
+A producer calls `emitNotificationSignal()` with a free-form event name, attention hints (urgency, requiresAction, deadlineAt), and a context payload. The signal is persisted as a `notification_events` row. A `dedupeKey` the producer passes is claimed by that row on insert, with no time window: a later signal carrying a key an existing row holds gets no row of its own and returns `deduplicated: true` before anything below runs. See [Choosing `dedupeKey`](#choosing-dedupekey).
 
 Immediately after persistence, a **source-active pre-gate** runs (`checkSourceActiveSuppression`): when `visibleInSourceNow` is set, a hard signal-only invariant the decision engine cannot override, the signal is suppressed and short-circuits here, before candidate generation and the LLM decision. This keeps an always-suppressed signal (e.g. trusted-contact `verification_sent`) from spending an LLM inference whose result would be discarded. The `notification_events` row is still written for the audit trail.
 
@@ -65,7 +65,7 @@ Hard invariants that the LLM cannot override:
 
 - **Schema validity** -- fail-closed if the decision is malformed
 - **Channel availability** -- at least one selected channel must be connected
-- **Deduplication** -- same `dedupeKey` within the dedupe window (1 hour default) is suppressed
+- **Deduplication** -- the decision's `dedupeKey` matches another event row younger than the dedupe window (1 hour default). This is the engine's own key; the producer's key was already checked at event insert in step 1, with no window.
 - **Rendered copy quality** -- fail-closed on empty copy or a fallback leak (body equal to the raw event name)
 
 Source-active suppression depends only on the signal, so it runs earlier — as the pre-decision gate in `emit-signal.ts` (see step 1), not as a pre-send check here.
@@ -470,7 +470,15 @@ Step 1 suppresses on this hint before anything else runs, and nothing downstream
 - **Opt in only when the notification duplicates something that conversation has already rendered, and only behind a flag that names your producer.** `resolveVisibleInSourceNow()` reads `activity-presence-suppression`, which gates the background-activity failure producer alone, so a new producer needs its own flag or an extension of that one before it calls the resolver. Otherwise the flag silently governs a producer its description does not cover. Having a conversation id in scope is not sufficient; the producer must know that _this_ arrival put the announced thing on screen there. `runtime/background-job-runner.ts` is the worked example: one catch block is reached from several directions, and it passes `presenceConversationId` only when the failure carries a `turnFailure`, the one arrival whose conversation is guaranteed to have emitted a `conversation_error` the user can read. A runner timeout leaves the turn still rendering as in progress and a bootstrap throw never reaches the agent loop, so both keep notifying.
 - **Pass a literal `false` for global and infra signals.** Heartbeat, credential health, webhook health, and worker liveness have no source surface to watch, so there is nothing to duplicate.
 - **Never opt in a `guardian.question` producer.** The card _is_ the prompt, so a `true` suppresses the question's only rendering and the tool hangs until the prompt timeout. `runtime/question-request-guardian-bridge.ts` carries the rationale at its hint block, and three regression pins hold the line: `runtime/__tests__/question-request-guardian-bridge.test.ts`, `__tests__/confirmation-request-guardian-bridge.test.ts`, and `__tests__/notification-guardian-path.test.ts`.
-- **A producer running inside the schedule worker cannot read presence at all.** `schedule/worker.ts` is a standalone OS process and the sole runner of schedule execution, while the resolver reads `assistantEventHub` through `isWebConversationFocused()` and that hub's SSE clients exist only in the assistant process. Every presence read from the worker resolves `false`, whatever the user is watching. The trap is in testing: a test that drives the producer and mocks presence in one process passes while the shipped worker suppresses nothing. Tracked as JARVIS-1711.
+- **A producer running outside the main assistant process cannot read presence at all.** The schedule worker (`schedule/worker.ts`) and the memory jobs worker (`plugins/defaults/memory/worker.ts`) are standalone OS processes, while the resolver reads `assistantEventHub` through `isWebConversationFocused()` and that hub's SSE clients exist only in the assistant process. Every presence read from a worker resolves `false`, whatever the user is watching. The trap is in testing: a test that drives the producer and mocks presence in one process passes while the shipped worker suppresses nothing. Tracked as JARVIS-1711. The boundary runs the other way too: a hub publish from a worker is forwarded to the assistant process best-effort (`runtime/assistant-event-hub.ts`, logged rather than thrown on failure). A worker-side producer is therefore guaranteed its event row and nothing past it: the home-feed write is best-effort in every process (`writeHomeFeedItemForSignal` returns `null` for an ineligible signal, a missing summary, or a failed write, and `emit-signal.ts` only logs a rejection), and the live push to open clients depends on the forward as well.
+
+### Choosing `dedupeKey`
+
+There are two keys and they do different jobs. Choose the producer's by what it names, not by how often it fires.
+
+- **The producer's key is a permanent claim, not a rate limit.** `createEvent` refuses a second row for a key any row already holds (`events-store.ts`), however old that row is. Key on a durable identity (a job row, a request id) to attempt a thing at most once ever; key on that identity plus a time bucket to attempt it at most once per bucket. A key with no identity in it silences every later instance for the whole bucket, whether or not it was the same thing. At most once, not exactly once: the claim lands at insert, before the decision and dispatch, so a process that dies between the two leaves the key claimed with nothing announced, and the retry short-circuits `deduplicated: true` and reports success. A producer that must not lose an announcement across a mid-pipeline shutdown (routine during an app update) needs its own record of delivery, not the key.
+- **A failed pipeline releases the claim; a retry re-emits.** When the pipeline fails after the row landed and no channel ran (`hasChannelSideEffect` is false), `emit-signal.ts` writes the key back to `null`, so the same producer can retry the same key. When any channel already ran, the claim stays: releasing it would double-send to those channels. This is what makes a crash retry idempotent against a double send for a producer keyed on a durable row id: `plugins/defaults/memory/skill-update-receipt-job.ts` keys on its job row, so a retry past the event row meets the claim, is reported `deduplicated: true, pipelineFailed: false`, and completes.
+- **The decision's key is windowed.** The engine picks its own key per decision; step 4 checks it against event rows inside the 1-hour window and writes it onto the row only when the producer passed none. A producer never passes the engine's key and never appeals its verdict.
 
 ## Audit Trail
 

package/src/notifications/__tests__/home-feed-side-effect.test.ts

@@ -20,7 +20,7 @@ const messageAppends: Array<{
   conversationId: string;
   role: string;
   content: string;
-  options?: { skipIndexing?: boolean };
+  options?: { skipIndexing?: boolean; skipResurface?: boolean };
 }> = [];
 const messageRewrites: Array<{ messageId: string; content: string }> = [];
 /** messageId -> the conversation it belongs to, for the scoped lookup. */
@@ -86,7 +86,7 @@ mock.module("../../persistence/conversation-crud.js", () => ({
     conversationId: string,
     role: string,
     content: string,
-    options?: { skipIndexing?: boolean },
+    options?: { skipIndexing?: boolean; skipResurface?: boolean },
   ) => {
     if (messageAppendShouldThrow) {
       throw new Error("simulated message write failure");
@@ -1039,6 +1039,88 @@ describe("writeHomeFeedItemForSignal", () => {
     expect(appendCalls).toHaveLength(1);
   });
 
+  // ── skill-update receipts ───────────────────────────────────────────
+
+  const RECEIPT_UPDATES = [
+    {
+      skillId: "skill-a",
+      name: "Skill A",
+      summary: "Changed a step.",
+      conversationId: "conv-source-1",
+    },
+    { skillId: "skill-b", name: "Skill B", summary: "Changed another." },
+  ];
+
+  test("a receipt's entries land as the typed updates, out of metadata, under the list panel", async () => {
+    conversationRow = { conversationType: "background" };
+    const signal = makeSignal({
+      sourceChannel: "assistant_tool",
+      sourceEventName: "activity.complete",
+      contextPayload: {
+        title: "2 skills updated",
+        body: "- Skill A: Changed a step.\n- Skill B: Changed another.",
+        updates: RECEIPT_UPDATES,
+        skillId: "skill-a",
+      },
+    });
+
+    const item = await writeHomeFeedItemForSignal(signal, makeDecision());
+
+    expect(item?.updates).toEqual(RECEIPT_UPDATES);
+    expect(item?.detailPanel).toEqual({ kind: "updatesList" });
+    expect(item?.metadata).not.toHaveProperty("updates");
+    expect(item?.metadata?.skillId).toBe("skill-a");
+  });
+
+  test("a receipt's summary is the payload body, never model copy", async () => {
+    // The pipeline's seed message and body win for every other item; a
+    // paraphrase of a receipt can drop an entry, so the list is kept.
+    conversationRow = { conversationType: "background" };
+    const signal = makeSignal({
+      sourceChannel: "assistant_tool",
+      sourceEventName: "activity.complete",
+      contextPayload: {
+        title: "2 skills updated",
+        body: "- Skill A: Changed a step.\n- Skill B: Changed another.",
+        updates: RECEIPT_UPDATES,
+      },
+    });
+    const decision = makeDecision({
+      selectedChannels: ["vellum"],
+      renderedCopy: {
+        vellum: {
+          title: "Skills refreshed",
+          body: "Two skills were refreshed.",
+          conversationSeedMessage:
+            "The assistant refreshed two of your skills after reviewing recent work.",
+        },
+      },
+    });
+
+    const item = await writeHomeFeedItemForSignal(signal, decision);
+
+    expect(item?.summary).toBe(
+      "- Skill A: Changed a step.\n- Skill B: Changed another.",
+    );
+  });
+
+  test("a malformed or empty updates list leaves the item an ordinary notification", async () => {
+    conversationRow = { conversationType: "background" };
+    for (const updates of [[], [{ name: "no id" }], "not a list"]) {
+      appendCalls.length = 0;
+      const signal = makeSignal({
+        sourceChannel: "assistant_tool",
+        sourceEventName: "activity.complete",
+        contextPayload: { title: "Skill updated", body: "Body", updates },
+      });
+
+      const item = await writeHomeFeedItemForSignal(signal, makeDecision());
+
+      expect(item?.updates).toBeUndefined();
+      expect(item?.detailPanel).toBeUndefined();
+    }
+  });
+
   // ── noteworthy derivation ────────────────────────────────────────────
 
   test("assistant_tool source marks the feed item noteworthy", async () => {
@@ -1264,7 +1346,9 @@ describe("writeHomeFeedItemForSignal", () => {
         conversationId: "conv-source-1",
         role: "assistant",
         content: "Three things today.",
-        options: { skipIndexing: true },
+        // Bookkeeping about the conversation, so it never resurfaces a
+        // chat the user marked Done.
+        options: { skipIndexing: true, skipResurface: true },
       });
       expect(item?.metadata?.notificationConversationMessageId).toBe("msg-1");
       // A client with the conversation open refetches only on the messages

package/src/notifications/conversation-pairing.ts

@@ -61,6 +61,7 @@ import {
   isConversationSeedSane,
 } from "./conversation-seed-composer.js";
 import { isGuardianRequestSignalEvent } from "./guardian-feed-projection.js";
+import { signalMirrorsToHomeFeed } from "./home-feed-mirror.js";
 import type { NotificationSignal } from "./signal.js";
 import type {
   ConversationAction,
@@ -274,7 +275,7 @@ export async function pairDeliveryWithConversation(
       signal.sourceEventName === ASSISTANT_REPLY_EVENT
     ) {
       return {
-        conversationId: resolveSourceConversationId(signal),
+        conversationId: resolveSourceConversation(signal)?.id ?? null,
         messageId: null,
         strategy,
         createdNewConversation: false,
@@ -767,12 +768,15 @@ async function resolveChannelDeliveryHome(params: {
  * Indexing is skipped for parity with the other notification write paths:
  * notification copy is delivery audit, not conversational memory.
  */
-function resolveSourceConversationId(signal: NotificationSignal): string | null {
+function resolveSourceConversation(
+  signal: NotificationSignal,
+): { id: string; conversationType?: string } | null {
   if (!signal.sourceContextId) {
     return null;
   }
   try {
-    return getConversation(signal.sourceContextId)?.id ?? null;
+    const row = getConversation(signal.sourceContextId);
+    return row ? { id: row.id, conversationType: row.conversationType } : null;
   } catch {
     return null;
   }
@@ -783,14 +787,25 @@ async function appendBodyToSourceConversation(
   channel: NotificationChannel,
   messageContent: string,
 ): Promise<{ conversationId: string; messageId: string } | null> {
-  const conversationId = resolveSourceConversationId(signal);
-  if (!conversationId) {
+  const source = resolveSourceConversation(signal);
+  if (!source) {
     return null;
   }
+  const conversationId = source.id;
 
-  const message = await addMessage(conversationId, "assistant", messageContent, {
-    skipIndexing: true,
-  });
+  const message = await addMessage(
+    conversationId,
+    "assistant",
+    messageContent,
+    {
+      skipIndexing: true,
+      // A notification the bell carries is bookkeeping about the
+      // conversation, not activity in it, so it must not bounce a chat the
+      // user just marked Done back into the sidebar. One the bell does not
+      // carry has this transcript as its only home, and the chat resurfaces.
+      skipResurface: signalMirrorsToHomeFeed(signal, source.conversationType),
+    },
+  );
   // `addMessage` projects attention metadata alone, so a client with this
   // conversation open needs the messages tag to refetch the transcript. A
   // notification the user taps through to has every chance of landing on an

package/src/notifications/home-feed-mirror.ts

@@ -0,0 +1,39 @@
+import { isBackgroundConversationType } from "../persistence/conversation-types.js";
+import { readChannelAllowlist } from "./channel-allowlist.js";
+import type { NotificationSignal } from "./signal.js";
+
+/**
+ * Whether the home feed carries a card for `signal`, judged from the signal
+ * and the conversation it names. The feed side effect's mirror decision is
+ * this plus two checks only it can make (a guardian request always mirrors;
+ * a delivery that materialized an assistant-initiated thread never does).
+ *
+ * The one other reader is the passive vellum append: a notification the
+ * bell carries is bookkeeping about the conversation it is appended to, so
+ * that append must not resurface a Done chat, while a notification the bell
+ * does not carry has the transcript as its only home and must.
+ *
+ * `assistant_tool` mirrors unconditionally because the documented
+ * `notifications send` skill (and background-job failure emits) deliberately
+ * target the home feed, unless an exclusive channel allowlist leaves vellum
+ * out; `chat.assistant_reply` follows the same rule. An async-background
+ * hint or a background-typed source conversation mirrors as well.
+ */
+export function signalMirrorsToHomeFeed(
+  signal: NotificationSignal,
+  sourceConversationType: string | undefined,
+): boolean {
+  if (
+    signal.sourceChannel === "assistant_tool" ||
+    signal.sourceEventName === "chat.assistant_reply"
+  ) {
+    const allowlist = readChannelAllowlist(signal.contextPayload);
+    if (!allowlist || allowlist.includes("vellum")) {
+      return true;
+    }
+  }
+  if (signal.attentionHints.isAsyncBackground) {
+    return true;
+  }
+  return isBackgroundConversationType(sourceConversationType);
+}

package/src/notifications/home-feed-side-effect.ts

@@ -15,6 +15,8 @@ import {
   type FeedItemCategory,
   type FeedItemDetailPanelKind,
   feedItemSchema,
+  type FeedItemUpdate,
+  feedItemUpdateSchema,
 } from "../home/feed-types.js";
 import { appendFeedItem } from "../home/feed-writer.js";
 import {
@@ -23,14 +25,11 @@ import {
   getMessageById,
   updateMessageContent,
 } from "../persistence/conversation-crud.js";
-import {
-  ASSISTANT_INITIATED_SOURCE,
-  isBackgroundConversationType,
-} from "../persistence/conversation-types.js";
+import { ASSISTANT_INITIATED_SOURCE } from "../persistence/conversation-types.js";
 import { publishConversationMessagesChanged } from "../runtime/sync/resource-sync-events.js";
 import { getLogger } from "../util/logger.js";
+import { isPlainObject } from "../util/object.js";
 import { normalizeTitle, stripMarkdown } from "../util/short-title.js";
-import { readChannelAllowlist } from "./channel-allowlist.js";
 import { isConversationSeedSane } from "./conversation-seed-composer.js";
 import { deriveTitle } from "./copy-composer.js";
 import {
@@ -39,6 +38,7 @@ import {
   isGuardianRequestSignalEvent,
   receiptGuardianFeedItemIfRequestTerminal,
 } from "./guardian-feed-projection.js";
+import { signalMirrorsToHomeFeed } from "./home-feed-mirror.js";
 import { readPayloadString } from "./notification-utils.js";
 import type { NotificationSignal } from "./signal.js";
 import type {
@@ -65,6 +65,30 @@ const log = getLogger("home-feed-side-effect");
  */
 const CONVERSATION_MESSAGE_ID_KEY = "notificationConversationMessageId";
 
+/**
+ * Payload key a skill-update receipt carries its entries under. Read here
+ * through the wire schema and mapped onto the item's typed `updates`, so the
+ * panel the client opens is decided by the shape, never by copy.
+ */
+const UPDATES_KEY = "updates";
+
+/**
+ * The receipt entries in `contextPayload`, when it carries a non-empty list
+ * that parses as the wire shape; otherwise undefined, and the item renders
+ * as an ordinary notification. A malformed list is dropped rather than
+ * mirrored, since a client would render whatever survived.
+ */
+function readUpdates(contextPayload: unknown): FeedItemUpdate[] | undefined {
+  if (!isPlainObject(contextPayload)) {
+    return undefined;
+  }
+  const parsed = feedItemUpdateSchema
+    .array()
+    .min(1)
+    .safeParse(contextPayload[UPDATES_KEY]);
+  return parsed.success ? parsed.data : undefined;
+}
+
 /**
  * Append a `FeedItem` for the given notification signal when the
  * filter criteria pass.
@@ -106,12 +130,19 @@ export async function writeHomeFeedItemForSignal(
     readPayloadString(signal.contextPayload, "body") ??
     readPayloadString(signal.contextPayload, "requestedMessage");
 
+  // A receipt's summary is the producer's own list of what changed, which
+  // the panel renders from the typed entries and a client without the panel
+  // reads as-is. Model copy is not allowed to rewrite it: a paraphrase can
+  // drop an entry, and the list is the receipt's whole point.
+  const updates = readUpdates(signal.contextPayload);
+
   // Prefer conversationSeedMessage over body for the home feed: the seed
   // message is richer and may contain structured markdown (lists, headers,
   // bold) that the detail panel renders. The popup-oriented `body` is
   // intentionally short (≤ 2 sentences) and loses formatting.
   const seedCandidate = renderedCopy?.conversationSeedMessage;
   const resolvedSummary =
+    (updates ? payloadBody?.trim() : undefined) ||
     (isConversationSeedSane(seedCandidate)
       ? seedCandidate.trim()
       : undefined) ||
@@ -146,7 +177,7 @@ export async function writeHomeFeedItemForSignal(
   const now = new Date().toISOString();
 
   const category = deriveCategory(signal);
-  const panelKind = deriveDetailPanelKind(signal);
+  const panelKind = updates ? "updatesList" : deriveDetailPanelKind(signal);
 
   const baseMetadata =
     signal.contextPayload &&
@@ -157,6 +188,9 @@ export async function writeHomeFeedItemForSignal(
   // Producer payloads reach the card verbatim, and this key addresses a
   // message row for rewriting, so only this module may set it.
   delete baseMetadata?.[CONVERSATION_MESSAGE_ID_KEY];
+  // The entries ride on the item as its typed `updates`, not in the
+  // free-form bag, so a client reads them from one place.
+  delete baseMetadata?.[UPDATES_KEY];
 
   // Link scheduled-run notifications back to their schedule. `notify`-mode
   // jobs put `scheduleId` directly in the context payload; `execute`-mode (and
@@ -205,6 +239,7 @@ export async function writeHomeFeedItemForSignal(
     ...(urgency ? { urgency } : {}),
     ...(sourceConversationId ? { conversationId: sourceConversationId } : {}),
     ...(panelKind ? { detailPanel: { kind: panelKind } } : {}),
+    ...(updates ? { updates } : {}),
     ...(metadata ? { metadata } : {}),
   };
 
@@ -322,6 +357,10 @@ async function appendSummaryToFeedTarget(
   try {
     const message = await addMessage(conversationId, "assistant", summary, {
       skipIndexing: true,
+      // The body is bookkeeping about the conversation, not activity in it:
+      // a receipt for work the conversation already saw must not bounce a
+      // chat the user just marked Done back into the sidebar.
+      skipResurface: true,
     });
     publishConversationMessagesChanged(conversationId);
     log.info(
@@ -553,19 +592,7 @@ function resolveHomeFeedMirror(
   if (isAssistantInitiatedThreadDelivery(fallbackConversationId)) {
     return { mirror: false };
   }
-  if (
-    signal.sourceChannel === "assistant_tool" ||
-    signal.sourceEventName === "chat.assistant_reply"
-  ) {
-    const allowlist = readChannelAllowlist(signal.contextPayload);
-    if (!allowlist || allowlist.includes("vellum")) {
-      return { mirror: true, sourceConversationId, sourceScheduleJobId };
-    }
-  }
-  if (signal.attentionHints.isAsyncBackground) {
-    return { mirror: true, sourceConversationId, sourceScheduleJobId };
-  }
-  if (isBackgroundConversationType(sourceRow?.conversationType)) {
+  if (signalMirrorsToHomeFeed(signal, sourceRow?.conversationType)) {
     return { mirror: true, sourceConversationId, sourceScheduleJobId };
   }
   return { mirror: false };

package/src/oauth/AGENTS.md

@@ -14,6 +14,12 @@ Add an entry to `PROVIDER_SEED_DATA`. Required fields: `provider`, `authorizeUrl
 
 If the provider will support managed mode, set `managedServiceConfigKey` to a slug matching the key you will add to `ServicesSchema` (e.g. `"acme-oauth"`).
 
+#### Scopes: your-own vs. managed
+
+`defaultScopes` here is requested only by the user's own OAuth client. A managed connection authorizes against Vellum's OAuth app, whose defaults live in the platform's `provider_registry.json`. Google shows users warnings or errors for scopes not approved for the app, so the managed start endpoint rejects anything outside the platform registry's `extra_config.allowed_scopes`. Managed Google, for example, grants Gmail only as `https://mail.google.com/`, never `gmail.readonly` / `gmail.modify` / `gmail.send`.
+
+So anything that names scopes for a managed connection (a hardcoded constant, a client hook, `requestedScopes` on an `oauth_connect` surface, a `--scopes` example in a skill) must use scopes from that approved list, not the `defaultScopes` names. A required-scope check that runs against managed grants must accept the approved equivalent: `grantedScopeCoversRequiredScope` in `scope-utils.ts` treats `mail.google.com` as covering `gmail.readonly`. Adding a scope to a managed flow means getting it approved in the provider console and adding it to `allowed_scopes` first.
+
 ### 2. _(managed only)_ Add a service schema — `../config/schemas/services.ts`
 
 Create a schema and export its type:
@@ -98,7 +104,7 @@ A grant is pinned when the caller passed `--account` or the resolved connection
 
 The grant carries one scope for one route, and four checks hold it there:
 
-- **Gateway edge auth** (`gateway/src/http/middleware/auth.ts`) refuses it on every gateway-native route, with no loopback fallback. `isSingleRouteGrant` calls `isNarrowScopeProfile` from `gateway/src/auth/scopes.ts`, and also catches a proxy subject carrying some other profile. The passthrough itself never passes through edge auth: it falls to the runtime-proxy catch-all, which re-mints the grant's own subject and profile for the daemon. That holds whether or not the gateway requires client-facing auth (`gateway.runtimeProxyRequireAuth`, off under `dev:proxy`): a presented grant is validated the same way in both modes and only a caller presenting no valid grant is answered with the gateway's own service token, so the minted URL works in either and neither mode hands the grant more than `oauth.proxy`.
+- **Gateway edge auth** (`gateway/src/http/middleware/auth.ts`) refuses it on every gateway-native route, with no loopback fallback. `isSingleRouteGrant` calls `isNarrowScopeProfile` from `gateway/src/auth/scopes.ts`, and also catches a proxy subject carrying some other profile. The passthrough itself never passes through edge auth: it falls to the runtime-proxy catch-all, which re-mints the grant's own subject and profile for the daemon. That holds whether or not the gateway requires client-facing auth (`gateway.runtimeProxyRequireAuth`): a presented grant is validated the same way in both modes and only a caller presenting no valid grant is answered with the gateway's own service token, so the minted URL works in either and neither mode hands the grant more than `oauth.proxy`.
 - **The gateway's IPC fast path** (`gateway/src/http/routes/ipc-runtime-proxy.ts`) refuses it against any daemon route naming no scope. The daemon's IPC server runs no policy check of its own, so this is the only enforcement an IPC-served request gets.
 - **`enforcePolicy`** (`../runtime/auth/route-policy.ts`) refuses the same on the HTTP path, then applies the route's own scopes. `oauth.proxy` reaches the passthrough and nothing else. It runs wherever `routeRequest` dispatches through the router, which is every `/v1` route and the shareable-pages path bar three groups that earlier branches answer first, each carrying a gate of its own: `GET /v1/audio/:audioId`, deliberately public and served before `authenticateRequest` runs at all because Twilio fetches it directly; the Twilio webhook paths (`TWILIO_WEBHOOK_RE`), also pre-auth and gated on Twilio's request signature; and the WebSocket upgrades in the next bullet, which never reach the route table. A route added anywhere else is covered.
 - **WebSocket upgrades** (`/v1/calls/media-stream`, `/v1/stt/stream`, `/v1/live-voice`, `/v1/watch/stream`) are handled before the route table on both hops, so neither edge auth nor `enforcePolicy` sees them, and each carries its own identity gate. The daemon admits only a private-network peer presenting a gateway service token; at the edge it is an actor principal on `runtime-audio-stream` and `live-voice`, the `speech.relay` scope on the relay, and the relay-token identity on `twilio-media-websocket`.

package/src/permissions/question-prompter.ts

@@ -58,6 +58,14 @@ export interface QuestionPromptEntryResult {
 export interface QuestionPromptResult {
   entries: QuestionPromptEntryResult[];
   overall: "completed" | "closed" | "timed_out" | "aborted";
+  /**
+   * True when the answer arrived as a message typed into the chat while the
+   * card was still open, rather than through the card itself. Only the first
+   * question carries the typed text; the rest stay `skipped`. The
+   * `ask_question` tool says so in the model-facing result, so the model can
+   * map the reply onto the questions itself.
+   */
+  answeredInChat?: boolean;
 }
 
 /**
@@ -178,10 +186,12 @@ export interface QuestionBatchMetadata {
  *
  * The idle timeout is a backstop (`getConfig().timeouts.questionResponseTimeoutSec`,
  * default 30 min), not the primary way a prompt is dismissed. An interactive
- * user who moves on instead of answering enqueues another message, which
- * supersedes the open prompt at the enqueue handler (see conversation-routes.ts);
- * a non-interactive turn resolves immediately at the tool. The backstop only
- * fires when a prompt is left open with no response and no follow-up message.
+ * user who types into the chat instead of using the card settles the prompt at
+ * the enqueue handler: the typed text answers it, or, when it cannot stand in
+ * for an answer, supersedes it (see
+ * `daemon/handlers/conversations.ts`). A non-interactive turn resolves
+ * immediately at the tool. The backstop only fires when a prompt is left open
+ * with no response and no follow-up message.
  */
 export class QuestionPrompter {
   async prompt(params: QuestionPromptParams): Promise<QuestionPromptOutcome> {