@vellumai/assistant 0.8.5 → 0.8.7

package/src/config/assistant-feature-flags.ts

@@ -18,6 +18,12 @@ import { dirname, join } from "node:path";
 
 import { ipcGetFeatureFlags } from "../ipc/gateway-client.js";
 import { getLogger } from "../util/logger.js";
+import {
+  clearCachedOverrides,
+  getCachedOverrides,
+  isCachedFromGateway,
+  setCachedOverrides,
+} from "./feature-flag-cache.js";
 import type { AssistantConfig } from "./schema.js";
 
 const log = getLogger("assistant-feature-flags");
@@ -83,7 +89,7 @@ function loadDefaultsRegistry(): FeatureFlagDefaultsRegistry {
 
 /**
  * Parse the unified registry JSON into a flat key -> default map,
- * filtering to assistant-scope flags only.
+ * filtering to flags the backend consumes (`assistant`- and `both`-scope).
  */
 function parseRegistryToDefaults(parsed: unknown): FeatureFlagDefaultsRegistry {
   if (!parsed || typeof parsed !== "object" || Array.isArray(parsed)) return {};
@@ -95,7 +101,7 @@ function parseRegistryToDefaults(parsed: unknown): FeatureFlagDefaultsRegistry {
   for (const flag of registry.flags) {
     if (!flag || typeof flag !== "object" || Array.isArray(flag)) continue;
     const entry = flag as Record<string, unknown>;
-    if (entry.scope !== "assistant") continue;
+    if (entry.scope !== "assistant" && entry.scope !== "both") continue;
     if (typeof entry.key !== "string") continue;
     if (typeof entry.defaultEnabled !== "boolean") continue;
 
@@ -112,22 +118,10 @@ function parseRegistryToDefaults(parsed: unknown): FeatureFlagDefaultsRegistry {
 // ---------------------------------------------------------------------------
 // Override loading — reads from gateway IPC socket
 // ---------------------------------------------------------------------------
-
-/**
- * Module-level cache of feature flag override values. Populated by
- * `initFeatureFlagOverrides()` at startup, invalidated by
- * `clearFeatureFlagOverridesCache()`.
- */
-let cachedOverrides: Record<string, boolean> | null = null;
-
-/**
- * True when `cachedOverrides` was populated by the gateway IPC fetch or
- * preseeded by a test via `_setOverridesForTesting()`. Guards
- * `initFeatureFlagOverrides()` from clobbering an existing populated cache
- * when called a second time (e.g. by a CLI entry point after the daemon
- * has already initialized).
- */
-let cachedOverridesFromGateway = false;
+//
+// The override cache lives in `feature-flag-cache.ts` (stdlib-only) so test
+// helpers can seed it without dragging the pino logger + gateway IPC client
+// transitively through their import chain. See that file's block comment.
 
 /**
  * Fetch override values from the gateway via IPC (Unix domain socket).
@@ -181,8 +175,9 @@ const DEFAULT_INIT_RETRY_BACKOFFS_MS: readonly number[] = [
  *
  * No-ops when the cache is already populated — callers that want to
  * refresh must call `clearFeatureFlagOverridesCache()` first. This lets
- * tests preseed flag state via `_setOverridesForTesting()` without the
- * gateway IPC call clobbering their setup.
+ * tests preseed flag state via `setOverridesForTesting()` (in
+ * `__tests__/feature-flag-test-helpers.ts`) without the gateway IPC call
+ * clobbering their setup.
  */
 export async function initFeatureFlagOverrides(options?: {
   retryBackoffsMs?: readonly number[];
@@ -194,7 +189,7 @@ export async function initFeatureFlagOverrides(options?: {
    */
   callTimeoutMs?: number;
 }): Promise<void> {
-  if (cachedOverridesFromGateway) return;
+  if (isCachedFromGateway()) return;
 
   const backoffs = options?.retryBackoffsMs ?? DEFAULT_INIT_RETRY_BACKOFFS_MS;
   const callTimeoutMs = options?.callTimeoutMs;
@@ -208,15 +203,14 @@ export async function initFeatureFlagOverrides(options?: {
       const delay = backoffs[attempt - 1]!;
       await new Promise((resolve) => setTimeout(resolve, delay));
       // Re-check after the wait: a concurrent caller (e.g. a test using
-      // `_setOverridesForTesting`) may have populated the cache while we
+      // `setOverridesForTesting`) may have populated the cache while we
       // were sleeping. Bail out so we don't clobber their setup.
-      if (cachedOverridesFromGateway) return;
+      if (isCachedFromGateway()) return;
     }
 
     const gatewayOverrides = await fetchOverridesFromGateway(callTimeoutMs);
     if (Object.keys(gatewayOverrides).length > 0) {
-      cachedOverrides = gatewayOverrides;
-      cachedOverridesFromGateway = true;
+      setCachedOverrides(gatewayOverrides, { fromGateway: true });
       if (attempt > 0) {
         log.info(
           { attempt: attempt + 1 },
@@ -245,18 +239,20 @@ export async function initFeatureFlagOverrides(options?: {
  * called at startup, or an empty record otherwise.
  */
 function loadOverrides(): Record<string, boolean> {
-  return cachedOverrides ?? {};
+  return getCachedOverrides() ?? {};
 }
 
 /**
  * Invalidate the cached overrides so the next call to
  * `isAssistantFeatureFlagEnabled` re-reads from the gateway.
  *
- * Used by tests between cases to reset module state.
+ * Called by `refreshOverridesFromGateway()` when the gateway pushes a
+ * `feature_flags_changed` event, and by tests between cases to reset
+ * module state. (Tests typically call `setOverridesForTesting()` from
+ * `__tests__/feature-flag-test-helpers.ts`, which combines clear + seed.)
  */
 export function clearFeatureFlagOverridesCache(): void {
-  cachedOverrides = null;
-  cachedOverridesFromGateway = false;
+  clearCachedOverrides();
 }
 
 /**
@@ -272,21 +268,6 @@ export async function refreshOverridesFromGateway(): Promise<void> {
   await initFeatureFlagOverrides({ retryBackoffsMs: [] });
 }
 
-/**
- * Directly inject override values into the module-level cache.
- *
- * **Test-only** — bypasses the gateway IPC fetch so unit tests can control
- * flag state without standing up a real gateway. Production code should
- * never call this; use `clearFeatureFlagOverridesCache()` instead and let
- * the resolver re-read from the gateway.
- */
-export function _setOverridesForTesting(
-  overrides: Record<string, boolean>,
-): void {
-  cachedOverrides = { ...overrides };
-  cachedOverridesFromGateway = true;
-}
-
 // ---------------------------------------------------------------------------
 // Public API
 // ---------------------------------------------------------------------------

package/src/config/bundled-skills/app-builder/SKILL.md

@@ -135,13 +135,24 @@ assistant config get llm.activeProfile
 
 If the profile is already `quality-optimized`, skip the rest of this step and proceed to Step 1.
 
-**If the active profile is `balanced`, `cost-optimized`, or any non-quality profile, you MUST ask the user for permission before switching. Do NOT open an inference session without explicit user confirmation.** Use `assistant ui confirm`:
+**If the active profile is `balanced`, `cost-optimized`, or any non-quality profile, you MUST ask the user for permission before switching. Do NOT open an inference session without explicit user confirmation.** Use the `ui_show` tool to present an inline `confirmation` surface and wait for the action. Do not call the shell command `assistant ui confirm`; that CLI-mediated confirmation can block the build flow before the app work starts.
 
 ```
-assistant ui confirm --message "App building works best with a high-quality model — it makes better design decisions, writes cleaner components, and produces more visually polished results. Switch to the quality profile for this build? (You can switch back after.)"
+ui_show({
+  surface_type: "confirmation",
+  title: "Use quality model for this app?",
+  data: {
+    message: "The current model profile is `<profile>`. App building works best with `quality-optimized` because it makes better design decisions, writes cleaner components, and produces more visually polished results.",
+    detail: "Choose whether to switch for this build or keep the current profile and build now.",
+    confirmLabel: "Switch for this build",
+    cancelLabel: "Keep current profile"
+  },
+  display: "inline",
+  await_action: true
+})
 ```
 
-If `assistant ui confirm` isn't available on this binary, ask the user directly in conversation instead. **Either way, wait for the user's answer before proceeding.**
+If `ui_show` is unavailable or the current channel cannot render confirmation surfaces, ask the user directly in conversation as a fallback. Wait for the user's answer before proceeding.
 
 **Only if the user confirms**, open an inference session:
 

package/src/config/bundled-skills/document-editor/SKILL.md

@@ -39,10 +39,14 @@ When the user asks to see, open, or pull up a document:
 
 ## Creating a new document
 
-1. **Create the document**: Call `document_create` with a title (inferred from the request). Call the tool immediately, not after conversational preamble.
+1. **Create the document**: Call `document_create` with a title (inferred from the request). Call the tool immediately, not after conversational preamble. Capture the `surface_id` from the response — every subsequent `document_update` call must reference it.
 2. **Write content in Markdown**: Use proper structure (`#` for titles, `##` for sections), **bold**, _italic_, code blocks, tables, lists, blockquotes as appropriate.
 3. **CRITICAL - Stream content in chunks**: Call `document_update` MULTIPLE times, not just once. Break content into logical chunks (paragraphs, sections, or every 200-300 words). Call `document_update` with `mode: "append"` for EACH chunk separately. The user experiences real-time content appearing as you write.
 
+### Recovering from a failed update
+
+If a `document_update` call fails with an `Invalid input` error (for example because `surface_id` was missing), do NOT call `document_create` again. The `surface_id` you need is in the tool result of the most recent `document_create` call in this turn. Retry `document_update` with that `surface_id` and the same content. Creating a second document with the same title produces a duplicate for the user.
+
 ## Editing an existing document
 
 When the user requests changes to a document:

package/src/config/bundled-skills/media-processing/services/reduce.ts

@@ -195,15 +195,12 @@ async function sendToClaude(
   const { signal, cleanup } = createTimeout(REDUCE_TIMEOUT_MS);
 
   try {
-    const response = await provider.sendMessage(
-      [userMessage(userContent)],
-      [],
-      effectiveSystemPrompt,
-      {
-        config: model ? { model } : {},
-        signal,
-      },
-    );
+    const response = await provider.sendMessage([userMessage(userContent)], {
+      tools: [],
+      systemPrompt: effectiveSystemPrompt,
+      config: model ? { model } : {},
+      signal,
+    });
     cleanup();
 
     const answer = extractAllText(response);

package/src/config/bundled-skills/messaging/tools/messaging-send.ts

@@ -238,8 +238,13 @@ export async function run(
             binding.conversationId,
             "assistant",
             JSON.stringify([{ type: "text", text }]),
-            { automated: true, crossPostedFrom: context.conversationId },
-            { skipIndexing: true },
+            {
+              metadata: {
+                automated: true,
+                crossPostedFrom: context.conversationId,
+              },
+              skipIndexing: true,
+            },
           );
           syncMessageToDisk(
             binding.conversationId,

package/src/config/bundled-skills/schedule/SKILL.md

@@ -94,13 +94,13 @@ The `mode` parameter controls what happens when a schedule fires:
 
 - **execute** (default) - sends the schedule's message to a background assistant conversation for autonomous handling. The assistant processes the message as if the user sent it.
 - **notify** - sends a notification to the user via the notification pipeline. No assistant processing occurs.
-- **script** - runs the `script` field as a shell command directly. No LLM invoked, no conversation created. stdout/stderr are captured in the schedule run record. Exit code 0 = success, non-zero = error. Commands run in the workspace directory with a 60-second timeout.
+- **script** - runs the `script` field as a shell command directly. No LLM invoked, no conversation created. stdout/stderr are captured in the schedule run record. Exit code 0 = success, non-zero = error. Commands run in the workspace directory with a 60-second timeout by default. Override the timeout per schedule with `timeout_ms` (range 1000–1800000 ms) when a script needs more or less time; pass `timeout_ms: null` on update to revert to the default. The guardian can also adjust this from the /assistant/settings/schedules page.
 
 Use `notify` for simple reminders ("remind me to take medicine at 9am"), `execute` for tasks that need assistant action ("check my calendar at 8am and send me a digest"), and `script` for lightweight shell automations that don't need LLM involvement ("refresh a cache", "poll an API", "rotate logs").
 
 ## Conversation Reuse
 
-By default, each schedule run creates a new conversation. For recurring schedules that benefit from accumulating context across runs (e.g. polling-style jobs, daily digests that reference prior results), set `reuse_conversation: true`. When enabled, subsequent runs reuse the conversation from the last successful run instead of creating a new one.
+Recurring schedules reuse the same conversation across runs by default — subsequent runs continue the conversation from the last successful run, preserving context and channel thread continuity. Set `reuse_conversation: false` explicitly if each run should start with a fresh conversation (e.g. independent reports that shouldn't accumulate prior context). One-shot schedules always create a fresh conversation.
 
 - Only applies to **recurring** schedules; ignored for one-shot schedules.
 - If the prior conversation has been deleted, a new one is created automatically.

package/src/config/bundled-skills/schedule/TOOLS.json

@@ -62,7 +62,7 @@
           },
           "reuse_conversation": {
             "type": "boolean",
-            "description": "When true, reuse the same conversation across recurring schedule runs instead of creating a new one each time. Useful for polling-style schedules that accumulate context over time. Ignored for one-shot schedules. Defaults to false."
+            "description": "When true, reuse the same conversation across recurring schedule runs instead of creating a new one each time. Defaults to true for recurring schedules, false for one-shot. Set to false explicitly if each run should start fresh."
           },
           "max_retries": {
             "type": "integer",
@@ -71,6 +71,10 @@
           "retry_backoff_ms": {
             "type": "integer",
             "description": "Base backoff delay in milliseconds between retries. Exponential backoff is applied. Defaults to 60000."
+          },
+          "timeout_ms": {
+            "type": "integer",
+            "description": "For script mode: maximum time in milliseconds the shell command may run before it is killed. Defaults to 60000 (60s). Allowed range: 1000 to 1800000."
           }
         },
         "required": ["name"]
@@ -161,7 +165,7 @@
           },
           "reuse_conversation": {
             "type": "boolean",
-            "description": "When true, reuse the same conversation across recurring schedule runs instead of creating a new one each time. Useful for polling-style schedules that accumulate context over time. Ignored for one-shot schedules."
+            "description": "When true, reuse the same conversation across recurring schedule runs instead of creating a new one each time. Defaults to true for recurring schedules. Set to false explicitly if each run should start fresh."
           },
           "max_retries": {
             "type": "integer",
@@ -170,6 +174,10 @@
           "retry_backoff_ms": {
             "type": "integer",
             "description": "Base backoff delay in milliseconds between retries. Exponential backoff is applied. Defaults to 60000."
+          },
+          "timeout_ms": {
+            "type": ["integer", "null"],
+            "description": "For script mode: maximum time in milliseconds the shell command may run before it is killed (default 60000, range 1000 to 1800000). Pass null to clear a custom timeout and revert to the default."
           }
         },
         "required": ["job_id"]

package/src/config/bundled-skills/settings/tools/open-system-settings.ts

@@ -42,6 +42,7 @@ export async function run(
     context.sendToClient({
       type: "open_url",
       url: meta.url,
+      conversationId: context.conversationId,
     });
   }
 

package/src/config/call-site-defaults.ts

@@ -23,9 +23,11 @@ export const CALL_SITE_DEFAULTS: Record<LLMCallSite, CallSiteDefaultConfig> = {
   emptyStateGreeting: { profile: "balanced" },
 
   memoryRouter: {
-    profile: "balanced",
+    profile: "cost-optimized",
     contextWindow: { maxInputTokens: 1000000 },
   },
+  memoryV3RouteL1: { profile: "balanced", temperature: 0 },
+  memoryV3SelectL2: { profile: "balanced", temperature: 0 },
   recall: {
     profile: "balanced",
     maxTokens: 4096,
@@ -47,13 +49,6 @@ export const CALL_SITE_DEFAULTS: Record<LLMCallSite, CallSiteDefaultConfig> = {
   memoryV2Migration: { profile: "cost-optimized" },
   memoryV2Sweep: { profile: "cost-optimized" },
   memoryV2Consolidation: { profile: "balanced" },
-  // memory v3: cheap filter + descent, capable gate. All three are
-  // selection/classification calls, not generation — pin temperature to 0 so
-  // the same candidate set yields the same keep/descend/select decision instead
-  // of sampling-driven variance.
-  memoryV3Filter: { profile: "cost-optimized", temperature: 0 },
-  memoryV3Descent: { profile: "cost-optimized", temperature: 0 },
-  memoryV3Gate: { profile: "balanced", temperature: 0 },
   conversationSummarization: { profile: "cost-optimized" },
   conversationTitle: { profile: "cost-optimized" },
   approvalCopy: { profile: "cost-optimized" },

package/src/config/feature-flag-cache.ts

@@ -0,0 +1,86 @@
+/**
+ * Module-level cache for resolved feature flag override values.
+ *
+ * Lives in its own module (rather than alongside the resolver in
+ * `assistant-feature-flags.ts`) so test code can read/write the cache
+ * without going through `assistant-feature-flags.ts` — which transitively
+ * pulls `util/logger.js` (pino) and the gateway IPC client. Stdlib-only
+ * by design: this file must remain safe to import from the test
+ * preload's load-time chain, where a broken `node_modules` symlink has
+ * historically tripped the env override (see DB ghost #3,
+ * /workspace/journal/2026-05-25-db-ghost-3-recovery.md).
+ *
+ * State is held on `globalThis.vellumAssistant.featureFlagCache` so test
+ * helpers in `__tests__/` can read/write it WITHOUT importing this
+ * module — they declare the same slot shape locally and access the
+ * globalThis namespace directly. See
+ * `__tests__/feature-flag-test-helpers.ts` for the test-side mirror;
+ * the slot shape MUST stay in sync between the two.
+ *
+ * Both `overrides` and `fromGateway` were previously module-level `let`
+ * bindings inside `assistant-feature-flags.ts`. The semantics are
+ * preserved exactly: `overrides === null` means "no fetch has populated
+ * the cache yet"; `fromGateway === true` means "the cache is
+ * authoritative — `initFeatureFlagOverrides()` should not clobber it".
+ *
+ * Consumers:
+ *   - `assistant-feature-flags.ts` (resolver — reads/writes via gateway fetch)
+ *   - `__tests__/feature-flag-test-helpers.ts` (seeds for tests, via globalThis)
+ */
+
+type FlagSlot = {
+  overrides: Record<string, boolean> | null;
+  fromGateway: boolean;
+};
+
+type VellumAssistantNamespace = {
+  featureFlagCache?: FlagSlot;
+};
+
+function slot(): FlagSlot {
+  const g = globalThis as { vellumAssistant?: VellumAssistantNamespace };
+  const ns = (g.vellumAssistant ??= {});
+  return (ns.featureFlagCache ??= { overrides: null, fromGateway: false });
+}
+
+/** Read the current override cache. `null` means not yet populated. */
+export function getCachedOverrides(): Record<string, boolean> | null {
+  return slot().overrides;
+}
+
+/**
+ * True when the cache was populated by either a gateway IPC fetch or by a
+ * test helper. Used by `initFeatureFlagOverrides()` to short-circuit a
+ * second fetch (e.g. when a CLI entry point runs after the daemon has
+ * already initialized) and by tests to prevent the retry loop from
+ * clobbering preseeded state.
+ */
+export function isCachedFromGateway(): boolean {
+  return slot().fromGateway;
+}
+
+/**
+ * Replace the cache with a clone of `overrides`. The `fromGateway` flag
+ * is set by the caller — production callers pass `true` after a
+ * successful gateway fetch; test helpers also pass `true` so subsequent
+ * `initFeatureFlagOverrides()` calls are no-ops.
+ */
+export function setCachedOverrides(
+  overrides: Record<string, boolean>,
+  options: { fromGateway: boolean },
+): void {
+  const s = slot();
+  s.overrides = { ...overrides };
+  s.fromGateway = options.fromGateway;
+}
+
+/**
+ * Drop the cache. The next `loadOverrides()` returns an empty record (so
+ * flag checks fall through to registry defaults) and the next
+ * `initFeatureFlagOverrides()` re-fetches from the gateway.
+ */
+export function clearCachedOverrides(): void {
+  const s = slot();
+  s.overrides = null;
+  s.fromGateway = false;
+}

package/src/config/feature-flag-registry.json

@@ -25,6 +25,14 @@
       "description": "Enable user-hosted onboarding flow",
       "defaultEnabled": false
     },
+    {
+      "id": "prechat-onboarding-condensed-flow",
+      "scope": "client",
+      "key": "prechat-onboarding-condensed-flow",
+      "label": "Condensed Pre-chat Onboarding",
+      "description": "Enable the condensed pre-chat onboarding flow for a standard LaunchDarkly percentage rollout.",
+      "defaultEnabled": false
+    },
     {
       "id": "local-docker-enabled",
       "scope": "client",
@@ -41,14 +49,6 @@
       "description": "Enable the A2A (Agent-to-Agent) channel for inter-assistant communication via the open A2A protocol",
       "defaultEnabled": false
     },
-    {
-      "id": "email-channel",
-      "scope": "assistant",
-      "key": "email-channel",
-      "label": "Email Channel",
-      "description": "Enable the entire email integration: email CLI commands, email channel, domain registration, sequences, email readiness probes, invite adapters, and the email-setup skill",
-      "defaultEnabled": false
-    },
     {
       "id": "settings-developer-nav",
       "scope": "assistant",
@@ -190,7 +190,7 @@
       "scope": "assistant",
       "key": "fast-mode",
       "label": "Fast Mode",
-      "description": "Enable Anthropic fast mode for Opus models (4.6, 4.7), delivering up to 2.5x higher output tokens per second at premium pricing",
+      "description": "Enable Anthropic fast mode for Opus models (4.6, 4.7, 4.8), delivering up to 2.5x higher output tokens per second at premium pricing",
       "defaultEnabled": false
     },
     {
@@ -281,14 +281,6 @@
       "description": "Expose the developer-only Compaction Playground tab in macOS Settings and enable the /playground/* HTTP endpoints for exercising compaction conditions. Dev-only; default off.",
       "defaultEnabled": false
     },
-    {
-      "id": "safe-storage-limits",
-      "scope": "assistant",
-      "key": "safe-storage-limits",
-      "label": "Safe Storage Limits",
-      "description": "Enable disk pressure protection flows that block background work and remote actors while storage is critically low.",
-      "defaultEnabled": false
-    },
     {
       "id": "account-deletion",
       "scope": "assistant",
@@ -313,14 +305,6 @@
       "description": "Show the 'Analyze' / 'Analyze conversation' option in conversation context menus and the conversation title actions dropdown.",
       "defaultEnabled": false
     },
-    {
-      "id": "pro-plan-adjust",
-      "scope": "client",
-      "key": "pro-plan-adjust",
-      "label": "Pro Plan Adjust",
-      "description": "Show the rich Plan card (current plan, features, Manage/Upgrade CTA) at the top of the macOS Settings \u2192 Billing tab.",
-      "defaultEnabled": false
-    },
     {
       "id": "external-plugins",
       "scope": "assistant",
@@ -379,7 +363,7 @@
     },
     {
       "id": "home-page",
-      "scope": "client",
+      "scope": "both",
       "key": "home-page",
       "label": "Home Page",
       "description": "Enable the Home page as the default landing view.",
@@ -440,6 +424,38 @@
       "label": "Memory Router Playground",
       "description": "Expose the developer-only Memory Router Playground tab in macOS Settings and the /assistant/memory-router-playground web page for dry-running v4 router config overrides against the live page index. Dev-only; default off.",
       "defaultEnabled": false
+    },
+    {
+      "id": "platform-features-in-local-mode",
+      "scope": "assistant",
+      "key": "platform-features-in-local-mode",
+      "label": "Platform Features in Local Mode",
+      "description": "When enabled, the assistant can call the Vellum platform API from local mode. When disabled, all platform API clients in the daemon, gateway, CES, and web UI no-op with a debug log instead of making outbound requests.",
+      "defaultEnabled": true
+    },
+    {
+      "id": "memory-v3-shadow",
+      "scope": "assistant",
+      "key": "memory-v3-shadow",
+      "label": "Memory v3 Shadow",
+      "description": "When on, runs the new memory-v3 topic-tree retrieval alongside v2 in shadow mode: logs selections to memory_v3_selections, does not modify injected context. Off by default.",
+      "defaultEnabled": false
+    },
+    {
+      "id": "memory-v3-live",
+      "scope": "assistant",
+      "key": "memory-v3-live",
+      "label": "Memory v3 Live",
+      "description": "When on, memory-v3 topic-tree retrieval becomes the live injected memory source (suppressing v2 injection). Off by default; only enable after shadow telemetry validates the design.",
+      "defaultEnabled": false
+    },
+    {
+      "id": "self-intro-greeting",
+      "scope": "assistant",
+      "key": "self-intro-greeting",
+      "label": "Self-intro first message",
+      "description": "On the first conversation, send a natural self-introduction (e.g. \"Hi Vela, I'm alex. Nice to meet you.\") on the user's behalf and route it through real LLM inference, instead of serving the canned first greeting. Names come from the onboarding context; falls back to the canned greeting when no name is known. See assistant/src/daemon/first-greeting.ts (buildSelfIntroMessage).",
+      "defaultEnabled": false
     }
   ]
 }

package/src/config/llm-context-resolution.ts

@@ -27,12 +27,21 @@ export function resolveEffectiveContextWindow({
   llm,
   callSite,
   overrideProfile,
+  selectionSeed,
 }: {
   llm: LLMConfig;
   callSite: LLMCallSite;
   overrideProfile?: string;
+  /**
+   * Per-conversation mix seed (the conversation id). Threaded so context-window
+   * sizing for a mix profile reflects the same arm the dispatch path picks.
+   */
+  selectionSeed?: string;
 }): EffectiveContextWindow {
-  const resolved = resolveCallSiteConfig(callSite, llm, { overrideProfile });
+  const resolved = resolveCallSiteConfig(callSite, llm, {
+    overrideProfile,
+    selectionSeed,
+  });
   const catalogModel = PROVIDER_CATALOG.find(
     (provider) => provider.id === resolved.provider,
   )?.models.find((model) => model.id === resolved.model);