@vellumai/assistant 0.11.2 → 0.11.3-staging.2

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

@@ -22,33 +22,50 @@ Subagent orchestration -- spawn background agents to work on tasks in parallel.
 
 Subagents follow this status flow: `pending` -> `running` -> `completed` / `failed` / `aborted`
 
-- **Spawn**: Use `subagent_spawn` with a label, objective, and role. The subagent runs autonomously.
+- **Spawn**: Use `subagent_spawn` with a label, objective, and type. The subagent runs autonomously.
 - **Mid-run communication**: Subagents can send notifications to the parent via `notify_parent` while still running -- useful for sharing interim findings or signaling that they are blocked.
 - **Auto-notification**: The parent conversation is automatically notified when a subagent reaches a terminal status (completed/failed/aborted). Do NOT poll `subagent_status`.
 - **Read output**: Use `subagent_read` after the subagent reaches a terminal status to retrieve its full output.
 
-## Roles
+## Types
 
-Each subagent is spawned with a role that determines its tool access. Choose the most restrictive role that can accomplish the task.
+There are three subagent types. Pick one with two questions: **does it need to change anything**, and **do you need its answer before you can continue?**
 
 `recall` is local information search across memory, the personal knowledge base, past conversations, and workspace files. Use it when a subagent needs prior context that is not already in the prompt.
 
-| Role | Tools | When to use |
-|---|---|---|
-| `general` | Full tool access | Task genuinely needs unrestricted capabilities (rare -- prefer a specialized role) |
-| `researcher` | `web_search`, `web_fetch`, `file_read`, `file_list`, `recall`, `notify_parent` | Information gathering, web research, codebase exploration, reading documentation |
-| `coder` | `bash`, `file_read`, `file_write`, `file_edit`, `web_search`, `recall`, `notify_parent` | Code changes, file editing, running commands, build/test tasks |
-| `planner` | `file_read`, `file_list`, `web_search`, `web_fetch`, `recall`, `notify_parent` | Analysis, planning, synthesizing information, reviewing approaches |
-| `investigator` | `code_search`, `file_read`, `file_list`, `web_search`, `web_fetch`, `recall`, `notify_parent` | Root-cause analysis: debugging, log forensics, tracing behavior across many files. Read-only search/read tools only (no shell): use `code_search` to grep file contents across directories, `file_list` to enumerate paths, `file_read` to read whole files and logs; returns a compact root-cause report |
-| `advisor` | None (tool-less) | Read-only senior-advisor consult. Runs on a stronger model, inherits full parent context, and BLOCKS until it returns guidance |
+| Type | Changes things? | You wait? | Tools | When to use |
+|---|---|---|---|---|
+| `researcher` | No | No | `web_search`, `web_fetch`, `file_read`, `file_list`, `code_search`, `recall`, `skill_execute`, `notify_parent` | Web research, codebase exploration, reading documentation, root-cause investigation, reviewing an approach against the code |
+| `builder` | Yes | No | Your whole tool surface, unrestricted: shell, file writes and edits, and every connector, MCP, and browser tool you can reach | Code changes, file output, build/test runs, anything that must run a command or act on an outside system |
+| `advisor` | No | Yes | Read-only fact checking in the workspace: `file_read`, `file_list`, `code_search` | Read-only senior-advisor consult. Runs on a stronger model, inherits full parent context, and BLOCKS until it returns guidance |
 
-All specialized roles (`researcher`, `coder`, `planner`) include `notify_parent` for mid-run communication with the parent.
+Both background types can call `notify_parent` for mid-run communication with the parent.
 
-Read-only roles (`researcher`, `planner`, `investigator`, `advisor`) cannot write or edit files, run commands, or otherwise persist output. If the task must **produce a file, save results, or run a command**, use `coder` (or `general`) — a read-only role finishes without producing anything, and the delegated write silently no-ops.
+A `researcher` is scoped to the fixed read-only list above: it cannot write or edit files, run commands, reach a connector, or otherwise persist output. If the task must **produce a file, save results, run a command, or act on an outside system**, spawn a `builder`: a researcher finishes without producing anything, and the delegated write silently no-ops.
+
+**Model tier is a separate knob.** Use `inference_profile` to run any type on a stronger or cheaper model. **A persona is not a type**: see the fallback below.
+
+### Legacy names and unknown roles
+
+The older role names still work: `planner` and `investigator` run as a `researcher`, `coder` and `general` run as a `builder`. The spawn result names the type that actually ran.
+
+Any other `role` text is treated as a persona, not a type. The subagent runs as a **`researcher`** (read-only) with that text framing how it approaches the task, and the spawn result says so. That is deliberate least privilege: an invented or misspelled role must never silently hand out write access. If the task genuinely needed to write, the subagent reports that it cannot, and you re-spawn it with `role: "builder"`.
+
+Omitting `role` entirely runs a `builder`, so a spawn that names no type keeps your full tool surface.
+
+### Verification
+
+Checking that something is actually done is not a fourth type. It is a `researcher` with `output_contract: "verdict"`.
+
+A verdict subagent returns, for each criterion in the objective, `PASS` or `FAIL` plus the exact evidence (file path, line, value, or quote), `CANNOT VERIFY` where the evidence is missing, and nothing else. Give it the criteria explicitly in the objective; a vague "check the work" gets you a vague list.
+
+It runs on a cheaper model by default, because checking a claim against evidence that already exists is mechanical work, not investigation. An explicit `inference_profile` still wins if a check genuinely needs a stronger model, and so does a profile pinned on the `subagentSpawn` call site in config (see Inference Profile below).
+
+The other contracts: `output_contract: "artifact"` tells a `builder` that the deliverable is the thing produced and to end by listing the exact files it created or modified. `"report"` is the default and asks for nothing extra. A contract that does not match the type is rejected rather than quietly changed, and the `advisor` takes no contract (it has its own framing).
 
 ## Consulting the Advisor
 
-The `advisor` role is the one role you spawn on your own judgment, unprompted — you do NOT wait for the user to ask for a subagent. The other roles (`researcher`, `coder`, `planner`, `investigator`, `general`) stay delegation-driven: reach for them to offload work, typically when the user's request calls for it. The advisor is different: proactively consult it whenever the conditions below are met.
+The `advisor` is the one type you spawn on your own judgment, unprompted: you do NOT wait for the user to ask for a subagent. The background types (`researcher`, `builder`) stay delegation-driven: reach for them to offload work, typically when the user's request calls for it. The advisor is different: proactively consult it whenever the conditions below are met.
 
 Orient yourself first (read the relevant files, understand the task), then consult the advisor:
 
@@ -58,7 +75,7 @@ Orient yourself first (read the relevant files, understand the task), then consu
 
 The consult is synchronous and read-only: spawning an `advisor` subagent BLOCKS until it returns guidance. It runs on a stronger model and inherits your full context, so it sees the task, your tool calls, and their results without you re-explaining. It also receives a snapshot of your environment (the tools available to you this turn, the full skill catalog, and your workspace) so its guidance can point you at existing platform capabilities by name. Give its guidance serious weight; only override it when primary-source evidence contradicts a specific claim, and say so when you do.
 
-Beyond that snapshot, the advisor sees only what is in this conversation. It cannot read files, other conversations, or external systems on its own. If you want it to weigh specific evidence (a file's contents, a command's output, results gathered elsewhere), surface that evidence in the conversation or the spawn objective before consulting.
+The advisor has read-only workspace tools (`file_read`, `file_list`, `code_search`) so it can open a file or search the code when a decisive fact would change its advice. It uses them sparingly, for verification rather than exploration, and it cannot change anything or persist output. It has no memory search and cannot see other conversations or external systems, and every lookup it has to make delays your answer, so surface the evidence you already have (a file's contents, a command's output, results gathered elsewhere) in the conversation or the spawn objective before consulting.
 
 Spawn the advisor **alone** — do NOT batch the consult in the same turn as other tool calls (especially file edits, shell commands, or anything destructive or expensive). Tool calls you issue in the same turn run concurrently with the consult, so they would execute before you see its guidance. Consult the advisor by itself, read its guidance, then act.
 
@@ -90,15 +107,29 @@ Only the parent conversation that spawned a subagent can interact with it (check
 
 Set `send_result_to_user: false` when spawning a subagent whose result is for internal processing only. The parent will still be notified on completion, but the notification will instruct it to read the result without presenting it to the user.
 
+## Repeat Spawns
+
+Spawning an objective that several near-identical subagents have already completed in the last day can come back as a message about those earlier runs instead of a new subagent. Read what the earlier run produced with `subagent_read`, or narrow the objective to what is actually still missing.
+
+A second message covers the other shape: near-identical copies that are still running and have returned nothing yet. There is nothing to read in that case, so wait for the running ones to report back, or narrow the objective to the part they are not covering.
+
+Either way it is advisory, not a block: pass `confirm_repeat: true` to spawn anyway. An `advisor` consult is never held this way.
+
 ## Inference Profile
 
-Set `inference_profile` to an `llm.profiles` key when a subagent should run under a specific model profile. When omitted, the subagent inherits the parent turn's active profile if one exists; otherwise it uses the `subagentSpawn` call site's default model selection.
+Set `inference_profile` to an `llm.profiles` key when a subagent should run under a specific model profile.
+
+When it is omitted, the subagent takes the `subagentSpawn` call site's default model selection. It does not pick up the profile the spawning turn is running on: a profile pinned on a conversation is a choice about that conversation, and it does not follow the work that conversation delegates.
+
+An `inference_profile` you name explicitly wins, unless the model catalog does not report it as tool-capable, in which case it is replaced by the `subagentSpawn` default with a note on the spawn result. An `advisor` consult applies that same fallback, with the note alongside its guidance.
+
+`output_contract: "verdict"` takes a cheaper profile, so a verdict runs cheap unless you name an `inference_profile` yourself. A profile pinned on the `subagentSpawn` call site in config also beats the cheap preset, so an operator can decide what checks run on.
 
 ## Fork Mode
 
 Forks are sub-agents that inherit the parent's full context -- messages, system prompt, and memory -- sharing the KV cache for near-free context inheritance. Use forks when the task benefits from knowing what you've been discussing; use a regular sub-agent when the task is self-contained.
 
-**Key behaviors:** Forks default to `general` role (the `role` parameter is ignored for forks), except the special `advisor` role, which is honored even as a fork. `send_result_to_user` defaults to `false`. Read fork output with `last_n: 1` to get only the final synthesis.
+**Key behaviors:** A fork honors the type you name, so `role: "researcher"` gives a read-only fork. A fork that names no type runs as a `builder` and so keeps your full tool surface, which is what the system prompt it inherits describes. A persona reaches a fork through its task framing rather than its prompt, since the prompt is yours verbatim. `send_result_to_user` defaults to `false`. Read fork output with `last_n: 1` to get only the final synthesis.
 
 **When to fork vs regular sub-agent:**
 
@@ -110,17 +141,17 @@ Forks are sub-agents that inherit the parent's full context -- messages, system
 | Comparing multiple sources against what was discussed | Parallel forks |
 | Self-contained task with a clear objective | Regular sub-agent |
 
-Rule of thumb: "Does this task need to know what we've been talking about?" If yes, fork. If the objective is fully self-describing, use a regular sub-agent with a scoped role.
+Rule of thumb: "Does this task need to know what we've been talking about?" If yes, fork. If the objective is fully self-describing, use a regular sub-agent with a scoped type.
 
 ## Tips
 
 - Do NOT poll `subagent_status` in a loop. You will be notified automatically when a subagent completes.
-- Use roles to scope tool access and minimize blast radius. Default to the most restrictive role that works.
-- Spawn a `researcher` and `coder` in parallel for research-then-implement workflows -- the researcher gathers context while the coder starts on the known parts.
+- Prefer `researcher` unless the task has to change something. Read-only is the smaller blast radius, and most delegated work is reading.
+- Spawn a `researcher` and a `builder` in parallel for research-then-implement workflows -- the researcher gathers context while the builder starts on the known parts.
 - Use `notify_parent` for interim findings instead of waiting for completion. This lets the parent act on partial results early.
 - Use `subagent_message` to send follow-up instructions to a running subagent.
 - Use `subagent_abort` to cancel a subagent that is no longer needed.
 - Default to spawning subagents for any task that involves web research, multi-file exploration, or independent coding work. Serial execution should be the exception, not the rule.
-- Delegate root-cause investigations ("why is X happening?", debugging, log forensics) to an `investigator` instead of grepping inline. A long investigation done inline floods your own context with file slices and grep output, crowding out the conversation; the investigator does the digging in its own context and returns a compact root-cause report.
+- Delegate root-cause investigations ("why is X happening?", debugging, log forensics) to a `researcher` instead of grepping inline. A long investigation done inline floods your own context with file slices and grep output, crowding out the conversation; the researcher does the digging in its own context and returns a compact root-cause report.
 - When a user request has both an information-gathering component and an action component, spawn a researcher immediately rather than doing the research inline yourself.
-- Prefer spawning 2-3 focused subagents over one large general-purpose subagent. Smaller scopes finish faster and fail more gracefully.
+- Prefer spawning 2-3 focused subagents over one broad one. Smaller scopes finish faster and fail more gracefully.

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

@@ -3,7 +3,7 @@
   "tools": [
     {
       "name": "subagent_spawn",
-      "description": "Spawn an independent subagent to work on a task in parallel. The subagent runs autonomously and its results are reported back when complete.\n\nTwo modes:\n- **Regular sub-agent** (fork: false or omitted): Gets only the objective + context fields. Use for self-contained tasks with clear objectives. Can use scoped roles (researcher, coder, planner).\n- **Fork** (fork: true): Inherits full parent context (messages, system prompt, memory). Shares KV cache for near-free context inheritance. Use when the task benefits from knowing what you've been discussing. Defaults to general role (the 'advisor' role is the exception: it is honored as a fork). Results are internal by default (send_result_to_user: false). Read with last_n: 1 to get only the final synthesis.\n\nDecision heuristic: Does the task need to know what we've been talking about? Fork. Is it self-contained? Regular sub-agent.\n\nThe 'advisor' role is a synchronous, read-only \"consult a stronger advisor\" mode: it inherits your full context plus a snapshot of your environment (available tools, skill catalog, workspace), has no tools of its own, and BLOCKS until it returns focused strategic guidance in a single response.",
+      "description": "Spawn an independent subagent to work on a task in parallel. The subagent runs autonomously and its results are reported back when complete.\n\nTwo modes:\n- **Regular sub-agent** (fork: false or omitted): Gets only the objective + context fields. Use for self-contained tasks with clear objectives. Pick its type with role: 'researcher' (read-only, fixed tool list) or 'builder' (write-capable, your whole tool surface).\n- **Fork** (fork: true): Inherits full parent context (messages, system prompt, memory). Shares KV cache for near-free context inheritance. Use when the task benefits from knowing what you've been discussing. A fork that names a role runs scoped to it; a fork that names none keeps your full tool surface. Results are internal by default (send_result_to_user: false). Read with last_n: 1 to get only the final synthesis.\n\nDecision heuristic: Does the task need to know what we've been talking about? Fork. Is it self-contained? Regular sub-agent.\n\nThe 'advisor' role is a synchronous, read-only \"consult a stronger advisor\" mode: it inherits your full context plus a snapshot of your environment (available tools, skill catalog, workspace), has read-only workspace tools for checking a decisive fact (file_read, file_list, code_search), and BLOCKS until it returns focused strategic guidance in a single response. It cannot change anything, persist output, or see other conversations.",
       "category": "orchestration",
       "risk": "low",
       "input_schema": {
@@ -23,7 +23,7 @@
           },
           "fork": {
             "type": "boolean",
-            "description": "When true, the subagent inherits the parent's full context (messages, system prompt, memory) instead of receiving only the objective + context fields. Fork mode defaults to 'general' role (the role parameter is ignored for forks), except the special 'advisor' role which is honored even as a fork, and defaults send_result_to_user to false. Use for tasks that benefit from the full conversational context."
+            "description": "When true, the subagent inherits the parent's full context (messages, system prompt, memory) instead of receiving only the objective + context fields. A fork honors the role you name; naming none keeps this conversation's full tool surface, since the inherited system prompt describes those tools. Forks default send_result_to_user to false. Use for tasks that benefit from the full conversational context."
           },
           "send_result_to_user": {
             "type": "boolean",
@@ -31,19 +31,20 @@
           },
           "role": {
             "type": "string",
-            "enum": [
-              "general",
-              "researcher",
-              "coder",
-              "planner",
-              "investigator",
-              "advisor"
-            ],
-            "description": "Agent specialization that controls tool access. 'researcher': read-only (web, files, memory). 'coder': file and bash access. 'planner': read-only analysis. 'investigator': root-cause analysis: debugging, log forensics, tracing behavior across many files; uses read-only search/read tools (code_search, file_read, file_list) with no shell access and returns a compact root-cause report. 'advisor': synchronous, read-only \"consult a stronger advisor\": inherits full context plus a snapshot of your environment (available tools, skill catalog, workspace), has no tools of its own, and blocks until it returns focused strategic guidance. 'general': full access (default). The read-only roles (researcher, planner, investigator, advisor) cannot persist output; use 'coder' or 'general' for any objective that must write files or run commands, or a read-only subagent will finish without producing anything. Non-advisor roles are ignored when fork: true (forks default to general); the advisor role is honored even as a fork."
+            "description": "Which of the three subagent types to run, chosen by two questions: does it need to change anything, and do you need the answer before you can continue? 'researcher': changes nothing, runs in the background, scoped to a fixed read-only list (web_search, web_fetch, file_read, file_list, code_search, recall, skill_execute) for research, exploration, root-cause investigation, and review. 'builder': changes things, runs in the background on this conversation's whole tool surface (shell, file writes and edits, plus every connector, MCP, and browser tool you can reach) for code changes, file output, and anything that must run a command or act on an outside system. 'advisor': changes nothing and BLOCKS your turn until it answers; inherits your full context plus a snapshot of your environment (available tools, skill catalog, workspace), can read files and search code (file_read, file_list, code_search) to check a decisive fact, and returns focused strategic guidance. Default when omitted: 'builder', so a spawn that names no type keeps the full tool surface. The older names are still accepted as aliases ('planner' and 'investigator' run as researcher, 'coder' and 'general' run as builder). Any other text is not a type: the subagent runs as a researcher with that text as its persona, so if the task must write files or run commands, name 'builder' explicitly. A read-only subagent asked to produce a file finishes without producing anything. Roles apply to forks too; a fork that names no role runs as a builder and keeps this conversation's full tool surface, and a fork's persona reaches it through its task framing."
           },
           "inference_profile": {
             "type": "string",
-            "description": "Optional llm.profiles key this subagent should run under. When omitted, the subagent inherits the parent turn's profile when one is active; otherwise it uses the subagentSpawn call site's default model selection."
+            "description": "Optional llm.profiles key this subagent should run under. When omitted, the subagent takes the subagentSpawn call site's default model selection, never the profile your own turn is running on: a profile pinned on this conversation is a choice about this conversation and does not follow the work you delegate. A profile you name here that the model catalog does not report as tool-capable is replaced by that same default, with a note on the result. An output_contract of 'verdict' takes a cheaper profile unless you name a profile here, or unless the subagentSpawn call site has its own profile pinned in config, which also beats the cheaper preset."
+          },
+          "confirm_repeat": {
+            "type": "boolean",
+            "description": "Set true to spawn anyway when the repeat-spawn guard reports that this objective already completed several times in the last day, or that near-identical copies of it are still running with nothing returned yet."
+          },
+          "output_contract": {
+            "type": "string",
+            "enum": ["report", "verdict", "artifact"],
+            "description": "What the subagent owes back. 'report' (default): prose answering the objective. 'verdict': per-criterion PASS or FAIL with the exact evidence (file path, line, value, or quote), CANNOT VERIFY where evidence is missing, and no prose beyond that list; researcher-only, and it defaults to a cheaper model because checking is mechanical. Use it for completion checks and audits instead of spawning a premium investigator. 'artifact': the deliverable is the thing produced, ending with the exact files created or modified; builder-only. A contract that does not match the role is rejected rather than coerced, and the advisor takes no contract at all."
           }
         },
         "required": ["label", "objective"]
@@ -123,7 +124,7 @@
     },
     {
       "name": "subagent_read",
-      "description": "Read the full conversation output from a subagent. Use this after a subagent completes to retrieve its full work product.",
+      "description": "NOT a file reader: this returns a subagent's conversation output, addressed by subagent_id or label. To read a file from disk use file_read instead. Use this after a subagent completes to retrieve its full work product; while it is still running you will be notified automatically when it finishes, so there is no need to poll.",
       "category": "orchestration",
       "risk": "low",
       "input_schema": {

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

@@ -67,7 +67,7 @@ Semantic tokens flip automatically between light and dark. Use them for every su
 - Surfaces: --surface-base (page), --surface-lift (card), --surface-overlay, --surface-sunken (recessed tile), --surface-hover, --surface-active.
 - Text, strongest to faintest: --content-emphasised, --content-strong, --content-default (body), --content-secondary (labels and any text under 14px), --content-tertiary (14px and up only), --content-quiet, --content-faint, --content-disabled, --content-inset (on inverted fills). Text at 11 to 13px always takes --content-secondary or stronger.
 - Borders: --border-base (hairline), --border-subtle, --border-element (visible control edge), --border-hover, --border-active, --border-disabled.
-- Status pairs: --system-positive-strong/-weak, --system-negative-strong/-weak (and --system-negative-hover), --system-mid-strong/-weak, --system-info-strong/-weak.
+- Status pairs: --system-positive-strong/-weak, --system-negative-strong/-weak (and --system-negative-hover), --system-mid-strong/-weak, --system-info-strong/-weak. A non-text glyph sitting on its own -weak fill takes --system-positive-on-weak or --system-negative-on-weak; those clear the 3:1 that non-text indicators need, which --system-negative-strong misses on --system-negative-weak in the dark theme. Text on a -weak fill needs 4.5:1 and takes --content-default or stronger; --content-tertiary misses that on both fills in the light and dark themes, and --content-secondary misses it on the negative fill in light.
 - Type: --font-sans (default), --font-mono (identifiers, code, tabular numbers only), --font-serif (editorial pull-quotes only).
 - Radius: --radius-xs 2, --radius-sm 4, --radius-md 8, --radius-lg 12, --radius-xl 16, --radius-xxl 20, --radius-pill 999.
 

package/src/config/default-profile-catalog.ts

@@ -135,7 +135,11 @@ const VELLUM_PROFILE_IMPLS: ProfileImpls = {
     label: "Speed",
     description: "Fastest responses, with reasoning turned off",
     maxTokens: 8192,
-    effort: "low",
+    // Explicit reasoning opt-out, matching `cost-optimized` above: this
+    // profile advertises reasoning as off, and OpenAI-compat APIs default
+    // reasoning to "medium" when the field is omitted, so the opt-out has to
+    // be stated rather than implied.
+    effort: "none",
     thinking: { enabled: false, streamThinking: false },
     contextWindow: {
       maxInputTokens: DEFAULT_CONTEXT_WINDOW_MAX_INPUT_TOKENS,
@@ -194,7 +198,7 @@ const BYOK_PROFILE_IMPLS: Record<
     label: "Speed",
     description: "Fastest responses, with reasoning turned off",
     maxTokens: 8192,
-    effort: "low",
+    effort: "none",
     thinking: { enabled: false, streamThinking: false },
     contextWindow: { maxInputTokens: DEFAULT_CONTEXT_WINDOW_MAX_INPUT_TOKENS },
   },

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

@@ -101,6 +101,14 @@
       "description": "Enable the Quick Input popover on right-click of the menu bar icon",
       "defaultEnabled": false
     },
+    {
+      "id": "companion-surface",
+      "scope": "client",
+      "key": "companion-surface",
+      "label": "Companion Surface",
+      "description": "Show the macOS companion surface: the floating avatar that carries Talk, Type and the running call, and its tray item. Read in the Electron main process, which decides whether the window opens at all",
+      "defaultEnabled": false
+    },
     {
       "id": "expand-completed-steps",
       "scope": "client",
@@ -197,14 +205,6 @@
       "description": "Show the Velvet theme option in the macOS appearance settings. Velvet is a dark-mode variant with red/pink accent colors.",
       "defaultEnabled": false
     },
-    {
-      "id": "queue-steering",
-      "scope": "assistant",
-      "key": "queue-steering",
-      "label": "Queue Steering",
-      "description": "Enable the 'Push to agent' button on queued messages, allowing users to steer the assistant to a specific queued message by aborting the current generation and promoting the message to the head of the queue.",
-      "defaultEnabled": false
-    },
     {
       "id": "chat-pull-to-refresh-enabled",
       "scope": "client",
@@ -213,14 +213,6 @@
       "description": "Enable pull-to-refresh gesture in the chat view.",
       "defaultEnabled": false
     },
-    {
-      "id": "platform-notifications",
-      "scope": "client",
-      "key": "platform-notifications",
-      "label": "Platform Notifications",
-      "description": "Enable the Notifications tab in settings.",
-      "defaultEnabled": false
-    },
     {
       "id": "centralized-assistant-status",
       "scope": "client",
@@ -346,7 +338,7 @@
       "scope": "client",
       "key": "assistant-switcher",
       "label": "Assistant Switcher",
-      "description": "Show the Switch Assistant section in General settings (local mode only), linking to the assistant chooser.",
+      "description": "Show the Switch Assistant section in General settings, linking to the assistant chooser. Covers local clients, signed-in cloud-hub users, remote-gateway origins, and native mobile shells; remote-gateway desktop browsers hand off to the hub chooser with a self-registration param. Also makes the chooser's selection authoritative for the app's active assistant on every surface including the platform hub, a job that previously belonged to multi-platform-assistant alone.",
       "defaultEnabled": false
     },
     {
@@ -364,6 +356,22 @@
       "label": "Assistant Reply Push",
       "description": "Gates the `chat.assistant_reply` push notification the assistant sends at the end of a user-initiated turn whose reply the user has not seen. On by default; turn it off to silence the push without disabling the rest of the notification pipeline.",
       "defaultEnabled": true
+    },
+    {
+      "id": "desktop-presence-suppression",
+      "scope": "assistant",
+      "key": "desktop-presence-suppression",
+      "label": "Desktop Presence Suppression",
+      "description": "Gates whether a `chat.assistant_reply` push is suppressed while a Mac desktop client reports itself attended. On by default; turn it off to restore unconditional reply pushes.",
+      "defaultEnabled": true
+    },
+    {
+      "id": "plugin-schedules",
+      "scope": "assistant",
+      "key": "plugin-schedules",
+      "label": "Plugin Schedules",
+      "description": "Plugins declare recurring schedules as files that register and run automatically",
+      "defaultEnabled": false
     }
   ]
 }

package/src/config/llm-resolver.ts

@@ -40,7 +40,7 @@ import {
  *   3. `llm.callSites[callSite].profile` (the call site's named profile)
  *   4. `CALL_SITE_DEFAULTS[callSite].profile` intent resolved through
  *      `llm.defaultProvider`
- *   5. balanced intent through `llm.defaultProvider` — the code-owned anchor
+ *   5. balanced intent through `llm.defaultProvider`: the code-owned anchor
  *      for profileless call sites, or when nothing above is usable
  *
  * A winner must carry its own `provider` AND `model`: the base layer's schema
@@ -157,9 +157,11 @@ export function resolveCallSiteConfig(
 //
 // The request config is the base + winner + site-tweak composition:
 // code-owned schema defaults, then the single winning profile, then the call
-// site's own tuning fragment. Selection is pure either/or — no profile ever
-// contributes a field to another profile; `deepMerge` here only makes nested
-// tweaks (`thinking.enabled`) combine leaf-wise instead of wiping siblings.
+// site's own tuning fragment (its shipped `CALL_SITE_DEFAULTS` tuning with
+// the workspace `llm.callSites` entry layered over it, field by field).
+// Selection is pure either/or: no profile ever contributes a field to
+// another profile, and `deepMerge` only makes nested tweaks
+// (`thinking.enabled`) combine leaf-wise instead of wiping siblings.
 // `temperature`/`topP` come from the winner (or an explicit tweak);
 // `logitBias` only ever from the winner.
 // `forceOverrideProfile` is a no-op here (the override is already first).
@@ -221,8 +223,9 @@ export function selectWinningProfile(
   }
   // Anchor: profileless call sites (`vision`, `workflowLeaf`) and any
   // resolution whose every named rung was unusable land on balanced intent
-  // through the default provider. `profileName` stays null — the anchor is
-  // not a selection.
+  // through the default provider, bottoming out on the code-owned catalog,
+  // so it always resolves. `profileName` stays null on the catalog path:
+  // the anchor itself is not a selection.
   return {
     profileName: null,
     source: "default",
@@ -380,15 +383,10 @@ function resolveOverrideOrDefault(
   const winnerFragment: Mergeable =
     selection.entry == null ? {} : winnerConfigFragment(selection.entry);
 
-  // The call site's own tweak fragment: the workspace override replaces the
-  // code default wholesale. `profile` is the selection discriminator and
-  // `logitBias` is winner-owned, so neither enters the merge.
-  const site = llm.callSites?.[callSite] ?? CALL_SITE_DEFAULTS[callSite];
-  const {
-    profile: _siteProfile,
-    logitBias: _siteBias,
-    ...tweak
-  } = (site ?? {}) as Record<string, unknown>;
+  const tweak = composeCallSiteTweak(
+    CALL_SITE_DEFAULTS[callSite] as Mergeable | undefined,
+    llm.callSites?.[callSite] as Mergeable | undefined,
+  );
 
   // Direct call-site model overrides are fragments by design: when the tweak
   // pins a model the winner's provider does not serve, stamp the catalog
@@ -471,6 +469,38 @@ function winnerConfigFragment(entry: ProfileEntry): Mergeable {
 
 type Mergeable = Record<string, unknown>;
 
+/**
+ * The call site's tuning fragment: its shipped `CALL_SITE_DEFAULTS` tuning
+ * with the workspace `llm.callSites` entry layered over it, field by field.
+ * An entry that only names a profile therefore repoints the selection while
+ * the tuning the call site ships with still applies, and a field the entry
+ * sets wins for that field alone.
+ *
+ * `profile` is the selection discriminator and `logitBias` is winner-owned,
+ * so neither survives into the fragment. A workspace entry also owns the
+ * selection for its own call site: when one exists the shipped layer
+ * contributes tuning only, so a shipped `provider`/`model` pin can never
+ * override the profile or the custom model the user chose there. With no
+ * workspace entry the shipped fragment applies whole, pin included.
+ */
+export function composeCallSiteTweak(
+  shipped: Mergeable | undefined,
+  workspace: Mergeable | undefined,
+): Mergeable {
+  const {
+    provider: _shippedProvider,
+    model: _shippedModel,
+    ...shippedTuning
+  } = shipped ?? {};
+  const shippedLayer = workspace == null ? (shipped ?? {}) : shippedTuning;
+  const {
+    profile: _siteProfile,
+    logitBias: _siteBias,
+    ...tweak
+  } = deepMerge(shippedLayer, workspace ?? {});
+  return tweak;
+}
+
 /**
  * FNV-1a 32-bit string hash → unit float in [0, 1). Deterministic and stable
  * across runtimes — the mix-pick contract depends on identical output for

package/src/config/loader.ts

@@ -1,12 +1,13 @@
 import {
   existsSync,
   mkdirSync,
+  readdirSync,
   readFileSync,
   renameSync,
   rmSync,
   writeFileSync,
 } from "node:fs";
-import { dirname, join } from "node:path";
+import { basename, dirname, join } from "node:path";
 
 import { safeStatSync } from "../util/fs.js";
 import { getLogger } from "../util/logger.js";
@@ -319,6 +320,53 @@ function writeQuarantineNotice(
   }
 }
 
+/**
+ * Whether the newest quarantined config next to `configPath`
+ * (`config.json.corrupt-*.json`, written by {@link quarantineCorruptConfig})
+ * carried `memory.v3.live: true`. Quarantine filenames embed a
+ * filesystem-safe ISO timestamp, so a lexicographic sort is chronological.
+ *
+ * The first-launch seed asks this so a quarantine-reseed carries the memory
+ * tier forward: without it, reseeding an existing memory-v3 assistant
+ * silently demotes it to v2: the reseeded file records no `live` decision,
+ * migration 105 is already checkpointed on an existing workspace and never
+ * re-runs, and the schema default is `false`. Only `true` is ever salvaged:
+ * carrying `false` forward would re-pin a workspace to the schema default,
+ * the exact bug the seed's absent-leaf contract exists to prevent.
+ *
+ * A quarantined file usually fails `JSON.parse` (that is why it was
+ * quarantined); every config writer serializes via
+ * `JSON.stringify(config, null, 2)` and `memory.v3.live` is the only config
+ * key named `"live"`, so a literal `"live": true` match on the raw text is
+ * an unambiguous fallback for truncated files.
+ */
+function quarantinedConfigSaidMemoryV3Live(configPath: string): boolean {
+  try {
+    const dir = dirname(configPath);
+    const prefix = `${basename(configPath)}.corrupt-`;
+    const quarantines = readdirSync(dir)
+      .filter((name) => name.startsWith(prefix) && name.endsWith(".json"))
+      .sort();
+    const newest = quarantines[quarantines.length - 1];
+    if (!newest) {
+      return false;
+    }
+    const raw = readFileSync(join(dir, newest), "utf-8");
+    try {
+      const parsed: unknown = JSON.parse(raw);
+      if (!isPlainObject(parsed) || !isPlainObject(parsed.memory)) {
+        return false;
+      }
+      const v3 = parsed.memory.v3;
+      return isPlainObject(v3) && v3.live === true;
+    } catch {
+      return /"live"\s*:\s*true/.test(raw);
+    }
+  } catch {
+    return false;
+  }
+}
+
 /** Minimal structural view of the Zod issues the recovery ladder consumes. */
 type ValidationIssue = { path: PropertyKey[]; message: string };
 
@@ -1137,6 +1185,27 @@ export function loadConfig(): AssistantConfig {
         // `memory.v3.live=false` override still wins by merging after
         // migrations.
         seed.memory.v3 = {} as (typeof seed.memory)["v3"];
+        // Exception: a quarantine-reseed carries the memory tier forward.
+        // When the missing config.json is explained by a quarantined
+        // predecessor that had `live: true`, this is an EXISTING memory-v3
+        // assistant being reseeded, not a first launch: migration 105 is
+        // already checkpointed here and never re-runs, so leaving the leaf
+        // absent would silently demote the assistant to v2. Persist the
+        // carried value and apply it to this load's effective config so the
+        // current boot already runs v3.
+        if (quarantinedConfigSaidMemoryV3Live(configPath)) {
+          seed.memory.v3 = { live: true } as (typeof seed.memory)["v3"];
+          config.memory.v3.live = true;
+          // Refresh the last-known-good safety net (mirrors the
+          // deployment-context refresh above): its snapshot was taken before
+          // the carry, so a later in-process validation recovery would
+          // otherwise restore live=false and demote the assistant in memory
+          // despite the reseeded file on disk carrying true.
+          lastKnownGoodConfig = structuredClone(config);
+          log.info(
+            "Carried memory.v3.live=true forward from the quarantined config",
+          );
+        }
         // Strip dataDir (runtime-derived) from the persisted config
         const { dataDir: _, ...persistable } = seed;
         writeFileSync(configPath, JSON.stringify(persistable, null, 2) + "\n");

package/src/config/profile-tool-support.ts

@@ -0,0 +1,110 @@
+import type { z } from "zod";
+
+import { PROVIDER_CATALOG } from "../providers/model-catalog.js";
+import { resolveDefaultProfileForProvider } from "./default-profile-catalog.js";
+import { selectWinningProfile } from "./llm-resolver.js";
+import type { AssistantConfig } from "./schema.js";
+import type { LLMSchema } from "./schemas/llm.js";
+
+/**
+ * Whether a named inference profile is KNOWN to support tool calling.
+ *
+ * Tri-state on purpose. The model catalog is not exhaustive: BYOK installs
+ * point profiles at models the catalog has never heard of, and a
+ * `supportsToolUse` flag it does not carry is not evidence of anything. So
+ * only `false` is a verdict:
+ *   - `true`  the catalog states the model supports tool use
+ *   - `false` the catalog states the model does NOT support tool use
+ *   - `undefined` the model is unknown to the catalog, or the catalog entry
+ *     is silent on tool use
+ *
+ * A `mix` profile is answered across ALL of its arms rather than by expanding
+ * it, because the arm a mix lands on is a function of the running
+ * conversation's `selectionSeed` and no such conversation exists at probe
+ * time. A verdict is only returned when it holds for every arm: all-denied is
+ * `false`, all-capable is `true`, and a mix of the two is `undefined` (which
+ * arm runs is unknowable here, so there is no honest verdict).
+ *
+ * Callers gate on `=== false` so an unknown model is never punished (fail
+ * open).
+ */
+export function profileSupportsTools(
+  profileKey: string,
+  config: AssistantConfig,
+): boolean | undefined {
+  const arms = mixArms(profileKey, config.llm);
+  if (arms == null) {
+    return concreteProfileSupportsTools(profileKey, config);
+  }
+  const verdicts = arms.map((arm) => concreteProfileSupportsTools(arm, config));
+  if (verdicts.length === 0) {
+    return undefined;
+  }
+  if (verdicts.every((verdict) => verdict === false)) {
+    return false;
+  }
+  if (verdicts.every((verdict) => verdict === true)) {
+    return true;
+  }
+  return undefined;
+}
+
+/** The arm profile names of a `mix` profile, or `undefined` if not a mix. */
+function mixArms(
+  profileKey: string,
+  llm: z.infer<typeof LLMSchema>,
+): string[] | undefined {
+  const entry = resolveDefaultProfileForProvider(
+    llm.profiles,
+    profileKey,
+    llm.defaultProvider ?? null,
+  );
+  return entry?.mix?.map((arm) => arm.profile);
+}
+
+/**
+ * Verdict for a profile expected to name one concrete model. A key that is
+ * itself a mix yields no verdict: `LLMSchema.superRefine` forbids nesting, so
+ * this is only reachable from a hand-written config that never went through
+ * the schema, and expanding it would reintroduce the unseeded random pick.
+ */
+function concreteProfileSupportsTools(
+  profileKey: string,
+  config: AssistantConfig,
+): boolean | undefined {
+  if (mixArms(profileKey, config.llm) != null) {
+    return undefined;
+  }
+  // Run the profile through the real resolver so a catalog default and a
+  // workspace shadow alike yield the model the child would actually run on.
+  // Feeding the key in as the override rung means a profile the resolver
+  // cannot use falls through to a different rung, and a non-`override` winner
+  // tells us the key never resolved: unknown, so no verdict.
+  const winner = selectWinningProfile("subagentSpawn", config.llm, {
+    overrideProfile: profileKey,
+  });
+  if (winner.source !== "override") {
+    return undefined;
+  }
+  const model = winner.entry?.model;
+  return model == null ? undefined : modelSupportsTools(model);
+}
+
+/**
+ * Look a model id up across every catalog provider. A model offered by more
+ * than one provider (e.g. the same id direct and through OpenRouter) is
+ * matched several times; any entry claiming tool support settles it, keeping
+ * the answer on the fail-open side.
+ */
+function modelSupportsTools(modelId: string): boolean | undefined {
+  const matches = PROVIDER_CATALOG.flatMap((provider) =>
+    provider.models.filter((model) => model.id === modelId),
+  );
+  if (matches.some((model) => model.supportsToolUse === true)) {
+    return true;
+  }
+  if (matches.some((model) => model.supportsToolUse === false)) {
+    return false;
+  }
+  return undefined;
+}