@vellumai/assistant 0.12.1-dev.202609141913.5e16607 → 0.12.1-staging.2

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

@@ -1,6 +1,7 @@
 import { readFile } from "node:fs/promises";
 import { basename } from "node:path";
 
+import { isChannelId } from "../../../../channels/types.js";
 import type { OutboundAttachment } from "../../../../messaging/provider-types.js";
 import {
   createDraft,
@@ -15,10 +16,11 @@ import {
   toOutlookFileAttachments,
 } from "../../../../messaging/providers/outlook/client.js";
 import type { OutlookDraftMessage } from "../../../../messaging/providers/outlook/types.js";
-import {
-  isProactivelyAddressable,
-  sendChannelText,
-} from "../../../../runtime/channel-send.js";
+import { resolveProactiveHomeConversation } from "../../../../notifications/conversation-pairing.js";
+import { recordDeliveredChannelPost } from "../../../../notifications/delivered-post-record.js";
+import { getConversation } from "../../../../persistence/conversation-crud.js";
+import { syncMessageToDisk } from "../../../../persistence/conversation-disk-view.js";
+import { normalizeExternalThreadId } from "../../../../persistence/external-conversation-store.js";
 import {
   isAbortLikeError,
   throwIfCancelled,
@@ -27,6 +29,7 @@ import type {
   ToolContext,
   ToolExecutionResult,
 } from "../../../../tools/types.js";
+import { getLogger } from "../../../../util/logger.js";
 import { guessMimeType } from "../../../../util/mime-type.js";
 import {
   err,
@@ -39,6 +42,8 @@ import {
   resolveProvider,
 } from "./shared.js";
 
+const log = getLogger("messaging-send");
+
 /** Read attachment files from disk into in-memory parts for outbound sending. */
 async function readAttachments(paths: string[]): Promise<OutboundAttachment[]> {
   return Promise.all(
@@ -53,6 +58,123 @@ async function readAttachments(paths: string[]): Promise<OutboundAttachment[]> {
 /** Email providers that accept file attachments on outbound sends. */
 const ATTACHMENT_CAPABLE_PLATFORMS = new Set(["gmail", "outlook"]);
 
+/**
+ * Record a message the provider just accepted where the chat's proactive
+ * posts live, so the chat's own conversation and `recall` can see what was
+ * sent from elsewhere (a scheduled run, another conversation).
+ *
+ * Only channel providers have such a home; an email send is tool-mediated
+ * and has no chat conversation. The row is written after the provider
+ * returned the message id, never before, and carries that id on its
+ * envelope and in `channel_outbound_posts` like every other post the daemon
+ * makes.
+ *
+ * A send into the sending turn's own chat writes no row: its tool call and
+ * result already sit in that conversation's history, and a second assistant
+ * row beside the tool pair would break history repair. Whether the send is
+ * "its own" is decided by the delivered target against the turn, not by the
+ * home: the turn arrived on a channel, in a chat, in a thread (the turn-local
+ * snapshot on the tool context), and a post the provider delivered to exactly
+ * that place is a same-conversation send even when the chat's home resolves
+ * elsewhere. The delivered thread is the one the provider reports, not the
+ * one requested: a provider that ignores the request lands the post in the
+ * thread-less chat, and the record must say so; a post into a thread is
+ * recorded in the thread's own conversation, where its replies arrive. The home
+ * comparison stays as the second test, for a sender that arrived through no
+ * channel but is the home. The post is then in the outbound index only
+ * through no path, which is the same class as a raw API send and is deferred
+ * with it.
+ *
+ * Failures here never fail the send: the message is already out.
+ */
+async function recordSentChannelPost(params: {
+  providerId: string;
+  externalChatId: string;
+  /** The thread the provider delivered into, as it reported it. */
+  deliveredThreadId: string | undefined;
+  text: string;
+  providerMessageId: string;
+  sender: ToolContext;
+}): Promise<void> {
+  const { providerId, externalChatId, sender } = params;
+  if (!isChannelId(providerId) || !params.providerMessageId) {
+    return;
+  }
+  try {
+    if (
+      isSendIntoOwnChat(
+        sender,
+        providerId,
+        externalChatId,
+        params.deliveredThreadId,
+      )
+    ) {
+      return;
+    }
+    const home = await resolveProactiveHomeConversation({
+      sourceChannel: providerId,
+      externalChatId,
+      threadId: params.deliveredThreadId,
+      source: "notification",
+      conversationType: "background",
+      title: `Messages to ${externalChatId}`,
+    });
+    if (home.conversationId === sender.conversationId) {
+      return;
+    }
+    const recorded = await recordDeliveredChannelPost({
+      conversationId: home.conversationId,
+      channel: providerId,
+      externalChatId,
+      ...(params.deliveredThreadId
+        ? { threadId: params.deliveredThreadId }
+        : {}),
+      text: params.text,
+      providerMessageId: params.providerMessageId,
+      crossPostedFrom: sender.conversationId,
+    });
+    const homeConversation = getConversation(home.conversationId);
+    if (homeConversation) {
+      syncMessageToDisk(
+        home.conversationId,
+        recorded.messageId,
+        homeConversation.createdAt,
+      );
+    }
+  } catch (e) {
+    log.warn(
+      { err: e, provider: providerId, externalChatId },
+      "Failed to record the sent message in the chat's conversation",
+    );
+  }
+}
+
+/**
+ * True when the delivered chat and thread are the ones the sending turn
+ * arrived in. Reads the turn-local snapshot the tool context carries
+ * (`executionChannel`, `requesterChatId`, `sourceThreadId`), never the live
+ * binding, which a concurrent inbound can rewrite while this call runs.
+ * Thread ids compare in the binding store's normalized form, so an absent
+ * thread on both sides matches and a thread-less delivery never matches a
+ * turn that arrived in a thread.
+ */
+function isSendIntoOwnChat(
+  sender: ToolContext,
+  channel: string,
+  externalChatId: string,
+  deliveredThreadId: string | undefined,
+): boolean {
+  if (!sender.executionChannel || !sender.requesterChatId) {
+    return false;
+  }
+  return (
+    sender.executionChannel === channel &&
+    sender.requesterChatId === externalChatId &&
+    normalizeExternalThreadId(sender.sourceThreadId) ===
+      normalizeExternalThreadId(deliveredThreadId)
+  );
+}
+
 export async function run(
   input: Record<string, unknown>,
   context: ToolContext,
@@ -75,62 +197,9 @@ export async function run(
   throwIfCancelled(context);
 
   try {
-    // A channel whose transport can be addressed from a named chat is sent
-    // through the transport, which is the one send implementation for that
-    // channel, records what it sent, and reaches channels with no messaging
-    // provider at all. A platform named outright is checked first; one
-    // auto-detected from the connected providers is checked the same way.
-    const namedChannel =
-      platform && isProactivelyAddressable(platform) ? platform : undefined;
-    const provider = namedChannel ? undefined : await resolveProvider(platform);
-    const channel =
-      namedChannel ??
-      (provider && isProactivelyAddressable(provider.id)
-        ? provider.id
-        : undefined);
-
-    if (channel) {
-      if (attachmentPaths?.length) {
-        return err("Attachments are only supported on Gmail and Outlook.");
-      }
-      // A channel's transport sends as the channel's one bot identity, so an
-      // account cannot select where the send goes out from. Refusing is
-      // safer than silently sending from the default account.
-      if (input.account) {
-        return err(
-          `account does not apply to ${channel}: a channel send goes out as the channel's own bot.`,
-        );
-      }
-      // Recheck: provider resolution above is an await, and this posts to
-      // the channel.
-      throwIfCancelled(context);
-      const sent = await sendChannelText({
-        channel,
-        target: {
-          kind: "chat",
-          chatId: conversationId,
-          ...(threadId ? { threadId } : {}),
-        },
-        text,
-        renderRichly: true,
-        assistantId: context.assistantId,
-        sender: {
-          conversationId: context.conversationId,
-          executionChannel: context.executionChannel,
-          requesterChatId: context.requesterChatId,
-          sourceThreadId: context.sourceThreadId,
-        },
-      });
-      const threadSuffix = sent.threadId
-        ? `, "thread_id": "${sent.threadId}"`
-        : "";
-      return ok(`Message sent (ID: ${sent.lastMessageId}${threadSuffix}).`);
-    }
-    if (!provider) {
-      throw new Error(`Messaging provider "${platform}" not found.`);
-    }
+    const provider = await resolveProvider(platform);
 
-    // Reject attachments on platforms that can't carry them.
+    // Reject attachments on platforms that can't carry them (e.g. Telegram, WhatsApp).
     if (
       attachmentPaths?.length &&
       !ATTACHMENT_CAPABLE_PLATFORMS.has(provider.id)
@@ -357,14 +426,7 @@ export async function run(
       );
     }
 
-    // A provider with a send of its own and no direct transport (a plugin's,
-    // for instance). Its send is tool-mediated and has no chat conversation
-    // to record in.
-    if (!provider.sendMessage) {
-      return err(
-        `${provider.displayName} cannot send from here: it has no send of its own and no channel transport to address.`,
-      );
-    }
+    // Non-email platforms
     const attachments = attachmentPaths?.length
       ? await readAttachments(attachmentPaths)
       : undefined;
@@ -380,6 +442,16 @@ export async function run(
     const threadSuffix = result.threadId
       ? `, "thread_id": "${result.threadId}"`
       : "";
+
+    await recordSentChannelPost({
+      providerId: provider.id,
+      externalChatId: conversationId,
+      deliveredThreadId: result.threadId,
+      text,
+      providerMessageId: result.id,
+      sender: context,
+    });
+
     return ok(`Message sent (ID: ${result.id}${threadSuffix}).`);
   } catch (e) {
     // A cancelled turn is not a send failure: let it reach the executor's

package/src/config/bundled-skills/phone-calls/references/TRANSCRIPTS.md

@@ -23,7 +23,7 @@ sqlite3 "$VELLUM_WORKSPACE_DIR/data/db/assistant.db" \
 
 This returns all messages in chronological order with:
 
-- `role: "user"` - caller speech and system events
+- `role: "user"` - caller speech (prefixed with `[SPEAKER]` tags) and system events
 - `role: "assistant"` - assistant responses, including `text` content and any `tool_use`/`tool_result` blocks
 
 ## Quick one-liner for the most recent call

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

@@ -209,6 +209,7 @@ When you mention a schedule or a conversation it owns in Vellum chat, write a ma
 
 Use these paths only in Vellum chat. Do not use them in Slack, Telegram, Discord, email, or notifications. Those surfaces cannot navigate `/assistant/...` routes.
 
+
 ### Anchored & Ambiguous Relative Time
 
 Phrases like "at the 45 minute mark", "at the top of the hour", "at noon", or "20 minutes in" are **clock-position or anchored relative time** expressions. Do NOT treat them as offsets from now.
@@ -255,13 +256,13 @@ Write the delivery step into the `message` when you create the schedule — not
 
 A schedule whose message has no delivery step is not finished. Before calling `schedule_create` in `execute` mode, read your own message back and check that it says where the output goes.
 
-There is a safety net, and it is not a substitute for the above. When an execute-mode run finishes with user-facing output and nothing delivered it, the assistant sends a notification carrying the run's final reply, so a schedule can no longer run and leave no trace. `messaging_send` counts as a delivery only when the call reported success, and `assistant notifications send` once the notification pipeline has taken it: a send the channel refused, or one that never reported at all, leaves the run eligible for the net, so the failure reaches you instead of vanishing into a conversation nobody has open. A Slack `chat.postMessage` never counts, because Slack refuses a call with a successful HTTP status and `ok: false` in the body, so the command succeeding proves nothing; a run that posts Block Kit that way also gets the net's notification. It fires on the raw reply, whatever the run happened to end on, at whatever length. An authored delivery step gets a title and body you chose, sent at the moment you chose. Rely on the net and you get the machine's guess instead.
+There is a safety net, and it is not a substitute for the above. When an execute-mode run finishes with user-facing output and delivered nothing — no `assistant notifications send`, no `messaging_send`, no Slack `chat.postMessage` — the assistant sends a notification carrying the run's final reply, so a schedule can no longer run and leave no trace. It fires on the raw reply — whatever the run happened to end on, at whatever length. An authored delivery step gets a title and body you chose, sent at the moment you chose. Rely on the net and you get the machine's guess instead.
 
 Choose the right delivery tool based on the content:
 
-- **Rich content** (digests, summaries, reports): Use `messaging_send` with the target platform and conversation ID. It reaches Gmail or Outlook as a draft, and posts to a Slack, Telegram, or Discord chat through that channel's own transport, where the post is recorded and can be found again afterwards. Reach for `chat.postMessage` through `assistant oauth request` only for a Block Kit shape `messaging_send` cannot carry, with the provider the **slack** skill says to pass for posting on this workspace (`slack_channel` when the bot is set up; where only the `slack` integration exists, the skill says to tell the user before posting as them), never through `curl` or a revealed token. Either way the full content posts directly.
+- **Rich content** (digests, summaries, reports): For Gmail, use `messaging_send` with the target platform and conversation ID. For Slack, call `chat.postMessage` through `assistant oauth request`, with the provider the **slack** skill says to pass for posting on this workspace (`slack_channel` when the bot is set up; where only the `slack` integration exists, the skill says to tell the user before posting as them), never through `curl` or a revealed token. This preserves the full content and posts directly.
 - **Short alerts** (status updates, completion notices): Use `assistant notifications send` via `bash` to let the notification router pick the best channel. Note: the router's decision engine rewrites content into short alerts, so it is not suitable for rich content.
 
 Example schedule message for a Slack digest:
 
-> "Scan my Slack channels for the last 24 hours using `assistant oauth request` for every Slack Web API read, with the provider the slack skill names for this workspace, then post the summary to the channel the user named with `messaging_send`, passing `platform: \"slack\"` and that channel's ID."
+> "Scan my Slack channels for the last 24 hours using `assistant oauth request` for every Slack Web API call, with the provider the slack skill names for this workspace, then post the summary with `chat.postMessage` through the same command to the channel the user named."

package/src/config/bundled-skills/screen-annotation/SKILL.md

@@ -124,14 +124,7 @@ their ear. Silence is the cue that it is their turn.
 
 **Advance on evidence, not on time.** Move to the next step when a fresh
 picture shows this one done, or when they tell you it is. Do not move on
-because a plausible amount of time has passed.
-
-The most direct telling is automatic. When the user clicks the control an
-arrow is pointing at, a message arrives as their turn saying they clicked it,
-by name, and that mark comes down on its own. Treat it as the step done: say
-what comes next and point at it. Nothing arrives for a click anywhere else,
-and nothing arrives for a ring, so for those the picture and their words are
-still the evidence. If the next picture shows the
+because a plausible amount of time has passed. If the next picture shows the
 step not done, or done to the wrong thing, point at the same place again with
 a shorter caption and say what you saw. Pointing at the next step while the
 previous one is still open is how someone ends up two steps behind a mark.

package/src/config/bundled-skills/screen-annotation/tools/screen-annotation.test.ts

@@ -53,10 +53,7 @@ describe("screen_point_at", () => {
     );
 
     expect(result.isError).toBe(true);
-    expect(result.content).toContain(
-      "The Vellum desktop app is needed to view or control your screen",
-    );
-    expect(result.content).toContain("https://www.vellum.ai/downloads");
+    expect(result.content).toContain("connected desktop client");
   });
 
   /** Drawing on the user's screen is a side effect a stopped turn must not have. */

package/src/config/bundled-skills/skill-management/TOOLS.json

@@ -3,7 +3,7 @@
   "tools": [
     {
       "name": "scaffold_managed_skill",
-      "description": "Create or update a managed skill in {workspaceDir}/skills. The skill becomes available for skill_load when a valid top-level SKILL.md is written under the skill directory. Never persist a skill without explicit user consent. Before persisting, test the snippet: write to a temp file with bash and run with `bun run /tmp/vellum-eval/snippet.ts`. Iterate up to 3 attempts, then ask the user. Clean up temp files after. Do not use file_write for temp files outside the working directory.",
+      "description": "Create or update a managed skill in {workspaceDir}/skills. The skill becomes available for skill_load when a valid top-level SKILL.md is written under the skill directory. Never persist a skill without explicit user consent. Before persisting, test the snippet: write to a temp file with bash and run with `bun run /tmp/vellum-eval/snippet.ts`. Iterate up to 3 attempts, then ask the user. Clean up temp files after. Do not use file_write for temp files outside the working directory. After a skill is written, the next turn may run in a recreated conversation due to file-watcher eviction - continue normally.",
       "category": "skills",
       "risk": "high",
       "input_schema": {
@@ -92,7 +92,7 @@
     },
     {
       "name": "delete_managed_skill",
-      "description": "Delete a managed skill directory from {workspaceDir}/skills. Never delete a skill without explicit user confirmation.",
+      "description": "Delete a managed skill directory from {workspaceDir}/skills. Never delete a skill without explicit user confirmation. After deletion, the next turn may run in a recreated conversation due to file-watcher eviction - continue normally.",
       "category": "skills",
       "risk": "high",
       "input_schema": {

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

@@ -137,7 +137,7 @@ const VELLUM_PROFILE_IMPLS: ProfileImpls = {
     // The managed latency class, also what the live-voice front model runs on.
     // Its leading tokens are the turn-taking verdict, so what this profile
     // optimizes is the tail of time-to-first-token rather than the median: a
-    // verdict slower than `voice.frontModel.endpointDecisionTimeoutMs`
+    // verdict slower than `liveVoice.frontModel.endpointDecisionTimeoutMs`
     // trips the speculative fail-open commit in live-voice-session.ts, which
     // is audible dead air.
     //

package/src/config/env.ts

@@ -229,8 +229,8 @@ export function setPlatformAssistantId(value: string | undefined): void {
  * Platform assistant ID — UUID of this assistant on the platform.
  *
  * Resolved from the in-memory override (populated by providers-setup
- * rehydration via platform validate, or by secret-routes when the
- * platform pushes the value).
+ * rehydration from the credential store at daemon startup, or by
+ * secret-routes when the platform pushes the value).
  */
 export function getPlatformAssistantId(): string {
   return _platformAssistantIdOverride ?? "";

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

@@ -29,6 +29,18 @@
       "description": "Enable user-hosted onboarding flow",
       "defaultEnabled": false
     },
+    {
+      "id": "proactive-tips",
+      "scope": "client",
+      "key": "proactive-tips",
+      "label": "Proactive Tips",
+      "description": "Gates the dismissible proactive tip card in the web sidebar. String-valued so future A/B arms can be added as new values.",
+      "defaultEnabled": "off",
+      "values": [
+        "off",
+        "on"
+      ]
+    },
     {
       "id": "vision-mode",
       "scope": "client",
@@ -442,14 +454,6 @@
       "description": "Native notifications show the assistant's avatar as the icon with the assistant's name on line one. Same key the platform reads for APNs/FCM sender blocks.",
       "defaultEnabled": false
     },
-    {
-      "id": "local-notification-avatar",
-      "scope": "client",
-      "key": "local-notification-avatar",
-      "label": "Local Notification Avatar",
-      "description": "Shows the assistant name and avatar in notifications posted locally by native clients and supported browsers. Independent of remote push avatar presentation.",
-      "defaultEnabled": false
-    },
     {
       "id": "channel-conversation-sidecar",
       "scope": "client",
@@ -474,14 +478,6 @@
       "description": "Gates the seeded Figma OAuth provider. When off, the provider is hidden from GET /v1/oauth/providers, its get-by-id route, and the connect/update routes, so it cannot be listed or connected from the CLI, gateway, or web integrations list. The row is still seeded into oauth_providers on startup, and existing connections keep injecting credentials; only its visibility changes.",
       "defaultEnabled": false
     },
-    {
-      "id": "shopify-oauth",
-      "scope": "assistant",
-      "key": "shopify-oauth",
-      "label": "Shopify Integration",
-      "description": "Gates the seeded Shopify OAuth provider. When off, the provider is hidden from GET /v1/oauth/providers, its get-by-id route, and the connect/update routes, so it cannot be listed or connected from the CLI, gateway, or web integrations list. The row is still seeded into oauth_providers on startup, and existing connections keep injecting credentials; only its visibility changes. Off by default because Shopify is the first per-tenant provider: connecting needs the merchant's myshopify.com domain, and the shop-domain input in the clients ships separately from the seed.",
-      "defaultEnabled": false
-    },
     {
       "id": "chatgpt-device-code-login",
       "scope": "client",
@@ -527,14 +523,6 @@
       "label": "Send User Message Tool",
       "description": "Route all user-facing assistant text through the send_user_message tool instead of streamed assistant text",
       "defaultEnabled": false
-    },
-    {
-      "id": "assistant-desktop",
-      "scope": "assistant",
-      "key": "assistant-desktop",
-      "label": "Assistant Desktop",
-      "description": "Streams an interactive desktop from a containerized assistant pod to the web client over /v1/desktop/stream. Off: no desktop affordance is rendered. On: the chat header offers a desktop panel that views and controls the pod's display.",
-      "defaultEnabled": false
     }
   ]
 }

package/src/config/loader.ts

@@ -180,7 +180,6 @@ export function getDeploymentContextDefaults(): Record<string, unknown> {
       "discord-oauth": managed,
       "hubspot-oauth": managed,
       "monday-oauth": managed,
-      "shopify-oauth": managed,
       "stripe-link-oauth": managed,
       "figma-oauth": managed,
       "eventbrite-oauth": managed,

package/src/config/memory-v3-gate.test.ts

@@ -6,7 +6,6 @@ import {
   isMemoryV1Active,
   isMemoryV2ExplicitlyDisabled,
   isMemoryV3Live,
-  isSkillImprovementActive,
   isV2InjectionEngineActive,
   isV3TierActive,
   usesConceptPageMemory,
@@ -56,16 +55,12 @@ function makeConfig(
   enabled: TriState,
   v2Enabled: TriState,
   v3Live: TriState,
-  skillImprovement?: boolean,
 ): AssistantConfig {
   return {
     memory: {
       ...(enabled === undefined ? {} : { enabled }),
       ...(v2Enabled === undefined ? {} : { v2: { enabled: v2Enabled } }),
       ...(v3Live === undefined ? {} : { v3: { live: v3Live } }),
-      ...(skillImprovement === undefined
-        ? {}
-        : { retrospective: { skillImprovement } }),
     },
   } as AssistantConfig;
 }
@@ -301,32 +296,6 @@ describe("v1-staleness guard is one condition", () => {
  * proc-to-skills alias of `isMemoryV3Live` (which did not). One predicate now
  * answers for both features.
  */
-describe("skill improvement gate", () => {
-  test("defaults on for a live v3 tier", () => {
-    expect(isSkillImprovementActive(makeConfig(true, undefined, true))).toBe(
-      true,
-    );
-    expect(isSkillImprovementActive(makeConfig(undefined, undefined, true))).toBe(
-      true,
-    );
-  });
-
-  test("explicit opt-out disables skill improvement without disabling v3", () => {
-    const config = makeConfig(true, undefined, true, false);
-
-    expect(isV3TierActive(config)).toBe(true);
-    expect(isSkillImprovementActive(config)).toBe(false);
-  });
-
-  test("requires the live v3 tier even when explicitly enabled", () => {
-    const v2Config = makeConfig(true, true, false, true);
-    const memoryOffConfig = makeConfig(false, undefined, true, true);
-
-    expect(isSkillImprovementActive(v2Config)).toBe(false);
-    expect(isSkillImprovementActive(memoryOffConfig)).toBe(false);
-  });
-});
-
 describe("v3 tier is one condition", () => {
   test("memory off suppresses the v3 tier even with memory.v3.live set", () => {
     const config = makeConfig(false, undefined, true);

package/src/config/memory-v3-gate.ts

@@ -81,32 +81,28 @@ export function isMemoryV3Live(config: AssistantConfig): boolean {
  * FEATURE asks this predicate; only the injection-suppression checks that must
  * mirror the raw `memory.v3.live` key ask {@link isMemoryV3Live} directly.
  *
- * The memory concept graph is gated on it: both `GET /memory-graph`
- * (`supported`) and the cheap `graph_supported` bit on `GET /memory/stats`
- * must agree with whether the graph can build from the v3 concept-page
- * substrate.
+ * The two features gated on it, and why they must agree:
  *
- * Retrospective skill improvement is a separate optional v3-tier feature.
- * Ask {@link isSkillImprovementActive} for it so an operator can stop managed
- * skill authoring without turning off ordinary retrospective memory capture.
+ * - The memory concept graph — the single source of truth for both
+ *   `GET /memory-graph` (`supported`) and the cheap `graph_supported` bit on
+ *   `GET /memory/stats`, so the advertised capability and the actual build can
+ *   never drift. The graph builds off the v3 concept-page substrate.
+ * - Procedural-memory-as-skills — the retrospective's skill-authoring step and
+ *   its permission grant. Scoped to the v3 tier because skill retrieval rides
+ *   the v3 lanes and the usage-prune stage lives in the v3 maintain job. That
+ *   prune ships observe-first: with `memory.maintenance.skillPruneDays` at its
+ *   default (`null`) it reports stale assistant-authored skills
+ *   (`prunableSkills`) but deletes none — so a v3-tier assistant authors skills
+ *   without an automatic retirement bound until a positive `skillPruneDays` is
+ *   configured.
+ *
+ * Both write into memory on the user's behalf, so both honor the Memory
+ * opt-out identically: one predicate, one answer.
  */
 export function isV3TierActive(config: AssistantConfig): boolean {
   return isMemoryEnabled(config) && isMemoryV3Live(config);
 }
 
-/**
- * Whether a retrospective may turn observed procedures into managed skills.
- * This requires the v3 tier because skills are retrieved through its memory
- * substrate, and it honors the retrospective-specific opt-out without
- * disabling ordinary retrospective fact retention.
- */
-export function isSkillImprovementActive(config: AssistantConfig): boolean {
-  return (
-    isV3TierActive(config) &&
-    config.memory?.retrospective?.skillImprovement !== false
-  );
-}
-
 /**
  * Minimal structural view of the memory config the concept-page gate reads.
  * Accepting the shape (rather than the full `MemoryConfig`) lets call sites

package/src/config/platform-rehydration.ts

@@ -1,5 +1,6 @@
 /**
- * Rehydrate the in-memory platform identity/URL overrides at process startup.
+ * Rehydrate the in-memory platform identity/URL overrides from the credential
+ * store at process startup.
  *
  * These overrides (`setPlatformBaseUrl` and the platform ID setters in
  * `config/env.ts`) are normally only populated at runtime by the secret-routes
@@ -9,17 +10,18 @@
  * environment default (e.g. dev-platform) while the credential store holds the
  * real production values, and requests are sent to the wrong environment.
  *
- * Bound platform ids come from `POST /v1/internal/assistants/validate/`,
- * which trades the assistant API key for assistant/organization/user ids.
- *
  * Each field is best-effort: a credential-store read failure is logged and
  * skipped so a single missing value never blocks startup.
  */
 import { credentialKey } from "../security/credential-key.js";
 import { getSecureKeyAsync } from "../security/secure-keys.js";
 import { getLogger } from "../util/logger.js";
-import { setPlatformBaseUrl } from "./env.js";
-import { ensurePlatformIdentityIds } from "./platform-identity.js";
+import {
+  setPlatformAssistantId,
+  setPlatformBaseUrl,
+  setPlatformOrganizationId,
+  setPlatformUserId,
+} from "./env.js";
 
 const log = getLogger("platform-rehydration");
 
@@ -45,16 +47,30 @@ async function rehydrateField(
 
 /**
  * Rehydrate the platform base URL and the related platform IDs (assistant,
- * organization, user). Safe to call more than once.
+ * organization, user) from the credential store into their in-memory
+ * overrides. Safe to call more than once.
  */
 export async function rehydratePlatformCredentials(): Promise<void> {
-  // Base URL first so managed proxy activation and identity validate resolve
-  // the correct environment for every request that follows.
+  // Base URL first so managed proxy activation resolves the correct
+  // environment for the ID lookups and every request that follows.
   await rehydrateField(
     "platform_base_url",
     setPlatformBaseUrl,
     "platform base URL",
   );
-
-  await ensurePlatformIdentityIds();
+  await rehydrateField(
+    "platform_assistant_id",
+    setPlatformAssistantId,
+    "platform assistant ID",
+  );
+  await rehydrateField(
+    "platform_organization_id",
+    setPlatformOrganizationId,
+    "platform organization ID",
+  );
+  await rehydrateField(
+    "platform_user_id",
+    setPlatformUserId,
+    "platform user ID",
+  );
 }

package/src/config/schema.ts

@@ -41,6 +41,7 @@ import {
   AuditLogConfigSchema,
   LogFileConfigSchema,
 } from "./schemas/logging.js";
+import { McpConfigSchema } from "./schemas/mcp.js";
 import { MemoryConfigSchema } from "./schemas/memory.js";
 import { MigrationsConfigSchema } from "./schemas/migrations.js";
 import { MonitoringConfigSchema } from "./schemas/monitoring.js";
@@ -61,7 +62,6 @@ import {
 } from "./schemas/timeouts.js";
 import { ToolsConfigSchema } from "./schemas/tools.js";
 import { UserRoutesConfigSchema } from "./schemas/user-routes.js";
-import { VoiceConfigSchema } from "./schemas/voice.js";
 import { WorkflowsConfigSchema } from "./schemas/workflows.js";
 import { WorkspaceGitConfigSchema } from "./schemas/workspace-git.js";
 
@@ -108,6 +108,7 @@ export const AssistantConfigSchema = z.object({
   ),
   journal: JournalConfigSchema.default(JournalConfigSchema.parse({})),
   backup: BackupConfigSchema.default(BackupConfigSchema.parse({})),
+  mcp: McpConfigSchema.default(McpConfigSchema.parse({})),
   acp: AcpConfigSchema.default(AcpConfigSchema.parse({})),
   skills: SkillsConfigSchema.default(SkillsConfigSchema.parse({})),
   workspaceGit: WorkspaceGitConfigSchema.default(
@@ -118,7 +119,6 @@ export const AssistantConfigSchema = z.object({
   twilio: TwilioConfigSchema.default(TwilioConfigSchema.parse({})),
   calls: CallsConfigSchema.default(CallsConfigSchema.parse({})),
   liveVoice: LiveVoiceConfigSchema.default(LiveVoiceConfigSchema.parse({})),
-  voice: VoiceConfigSchema.default(VoiceConfigSchema.parse({})),
   sight: SightConfigSchema.default(SightConfigSchema.parse({})),
   whatsapp: WhatsAppConfigSchema.default(WhatsAppConfigSchema.parse({})),
   telegram: TelegramConfigSchema.default(TelegramConfigSchema.parse({})),