@vellumai/assistant 0.11.8 → 0.11.9-staging.2

package/src/cli/commands/platform/connect.ts

@@ -1,6 +1,7 @@
 import type { Command } from "commander";
 
 import { cliIpcCall, exitFromIpcResult } from "../../../ipc/cli-client.js";
+import type { PlatformConnectResponse } from "../../../runtime/routes/platform-routes.js";
 import { subcommand } from "../../lib/cli-command-help.js";
 import { log } from "../../logger.js";
 import { shouldOutputJson, writeOutput } from "../../output.js";
@@ -8,11 +9,10 @@ import { shouldOutputJson, writeOutput } from "../../output.js";
 export function registerPlatformConnectCommand(platform: Command): void {
   subcommand(platform, "connect").action(
     async (_opts: Record<string, unknown>, cmd: Command) => {
-      const r = await cliIpcCall<{
-        alreadyConnected?: boolean;
-        baseUrl?: string;
-        showPlatformLogin?: boolean;
-      }>("platform_connect", {});
+      const r = await cliIpcCall<PlatformConnectResponse>(
+        "platform_connect",
+        {},
+      );
       if (!r.ok) {
         return exitFromIpcResult(
           { ok: false, error: r.error, statusCode: r.statusCode },
@@ -28,6 +28,15 @@ export function registerPlatformConnectCommand(platform: Command): void {
             `Already connected to platform at ${r.result.baseUrl}. ` +
               `Run 'assistant platform disconnect' first to reconnect.`,
           );
+        } else if (r.result?.credentialRejected) {
+          // No client shows a login screen for the daemon's signal, so this
+          // line is what tells the user what replaces the key. A plain sign-in
+          // stops at "already logged in" before the credential pass runs;
+          // --force runs it.
+          log.info(
+            "The stored platform credential was rejected by the platform. " +
+              "Run 'vellum login --force' to sign in again and replace it.",
+          );
         } else {
           log.info(
             "Showing the platform login screen on connected clients. " +

package/src/cli/commands/plugins.help.ts

@@ -10,12 +10,13 @@ import {
 
 export const pluginsHelp: CliCommandHelp = {
   name: "plugins",
-  description: "List, search, install, and manage plugins.",
+  description:
+    "Manage external plugins, which bundle apps, channels, MCPs, skills and more from other Vellum users",
   helpText: `
-Plugins are superpowers: installable extensions that add skills, tools, integrations,
-and so much more from the Vellum Community. When the user asks to set up,
-install, connect, or integrate a product, service, or app, run
-'assistant plugins search <name>' first before searching the web.`,
+Plugins are superpowers: installable extensions that add apps, channels, MCPs,
+skills, tools, integrations, and so much more from other Vellum users. When the
+user asks to set up, install, connect, or integrate a product, service, or app,
+run 'assistant plugins search <name>' first before searching the web.`,
   subcommands: [
     {
       name: "install",

package/src/cli/lib/__tests__/install-from-github.test.ts

@@ -201,14 +201,6 @@ const unusedGitRunner: GitRunner = async (args) => {
   throw new Error(`git should not run for this install: ${args.join(" ")}`);
 };
 
-/**
- * Read the real, committed caveman adapter stub from the repo so the
- * integration test exercises the adapter that ships rather than a fixture
- * copy that could drift from it. Returns every stub file keyed by its
- * Contents-API path (`plugins/caveman/<rel>`) so the fetch fake
- * serves the whole stub — package.json, the adapter, and its templates — to
- * the real postinstall runner. Resolves the stub relative to this test file.
- */
 function readRealCavemanStub(): Record<string, string> {
   const repoRel = "plugins/caveman";
   const stubDir = join(import.meta.dir, "../../../../../", repoRel);

package/src/cli/lib/__tests__/install-from-platform.test.ts

@@ -177,6 +177,7 @@ describe("installPluginFromPlatform — success", () => {
     );
     expect(existsSync(join(target, "README.md"))).toBe(true);
     expect(existsSync(join(target, "skills", "read", "SKILL.md"))).toBe(true);
+    expect(existsSync(join(target, "package.json"))).toBe(true);
 
     // Provenance records the pinned commit and the verified ETag.
     const meta = readInstallMeta(target);
@@ -186,6 +187,77 @@ describe("installPluginFromPlatform — success", () => {
     expect(meta?.etag?.startsWith('"sha256:')).toBe(true);
   });
 
+  test("synthesizes a minimal package.json when the tarball ships none", async () => {
+    const fetchFn = makeInstallFetch({
+      entries: [
+        {
+          name: "skills/keyword-research/SKILL.md",
+          content:
+            "---\nname: keyword-research\ndescription: Discover keyword opportunities.\n---\n",
+        },
+        {
+          name: "mcp.json",
+          content: JSON.stringify({
+            mcpServers: { openseo: { url: "https://app.openseo.so/mcp" } },
+          }),
+        },
+      ],
+      ref: "c".repeat(40),
+      repo: "every-app/open-seo",
+      sourcePath: "plugins/openseo",
+    });
+
+    const result = await installPluginFromPlatform(
+      { name: "openseo" },
+      {
+        fetch: fetchFn,
+        platformBaseUrl: PLATFORM,
+        workspacePluginsDir: pluginsDir,
+      },
+    );
+
+    const target = join(pluginsDir, "openseo");
+    expect(result.fileCount).toBe(2);
+    expect(
+      existsSync(join(target, "skills", "keyword-research", "SKILL.md")),
+    ).toBe(true);
+    const pkg = JSON.parse(readFileSync(join(target, "package.json"), "utf-8"));
+    expect(pkg.name).toBe("openseo");
+    expect(pkg.version).toBe("0.0.0");
+    expect(pkg.peerDependencies["@vellumai/plugin-api"]).toBeDefined();
+  });
+
+  test("leaves an upstream package.json in place", async () => {
+    const fetchFn = makeInstallFetch({
+      entries: [
+        {
+          name: "package.json",
+          content: JSON.stringify({
+            name: "reading-pal",
+            version: "1.2.3",
+            peerDependencies: { "@vellumai/plugin-api": ">=0.8.0" },
+          }),
+        },
+        { name: "README.md", content: "# reading pal" },
+      ],
+    });
+
+    await installPluginFromPlatform(
+      { name: "reading-pal" },
+      {
+        fetch: fetchFn,
+        platformBaseUrl: PLATFORM,
+        workspacePluginsDir: pluginsDir,
+      },
+    );
+
+    const pkg = JSON.parse(
+      readFileSync(join(pluginsDir, "reading-pal", "package.json"), "utf-8"),
+    );
+    expect(pkg.name).toBe("reading-pal");
+    expect(pkg.version).toBe("1.2.3");
+  });
+
   test("sends the API key as an Api-Key Authorization header when present", async () => {
     const captured: { auth: string | null } = { auth: null };
     const fetchFn = makeInstallFetch({

package/src/cli/lib/__tests__/plugin-catalog-local.test.ts

@@ -5,6 +5,8 @@
  * time — no network, no filesystem path resolution.
  */
 
+import { readFileSync } from "node:fs";
+import { join } from "node:path";
 import { describe, expect, test } from "bun:test";
 
 import bundledManifest from "../bundled-marketplace.json" with { type: "json" };
@@ -12,6 +14,15 @@ import {
   buildBundledPluginCatalog,
   readBundledPluginCatalog,
 } from "../plugin-catalog-local.js";
+import { marketplaceManifestSchema } from "../plugin-marketplace.js";
+import { marketplaceMatch } from "../search-plugins.js";
+
+const canonicalManifest = JSON.parse(
+  readFileSync(
+    join(import.meta.dir, "../../../../../plugins/marketplace.json"),
+    "utf8",
+  ),
+) as unknown;
 
 describe("buildBundledPluginCatalog", () => {
   test("yields one match per unique manifest name, sorted alphabetically", () => {
@@ -53,6 +64,28 @@ describe("buildBundledPluginCatalog", () => {
     });
   });
 
+  test("projects the OpenSEO subdirectory pin from the canonical catalog", () => {
+    const parsed = marketplaceManifestSchema.parse(canonicalManifest);
+    const entry = parsed.plugins.find((plugin) => plugin.name === "openseo");
+    expect(entry).toBeDefined();
+    expect(marketplaceMatch(entry!)).toEqual({
+      name: "openseo",
+      path: "github:every-app/open-seo/plugins/openseo@c469a48ae90ab58413b198fe3d1ac1aa90a9b070",
+      description:
+        "Keyword research, competitor analysis, site audits, backlinks, and rank tracking with real SEO data, plus guided workflow skills and the hosted OpenSEO MCP server.",
+      category: "marketing",
+      homepage: "https://openseo.so",
+      license: "MIT",
+      icon: "🔎",
+      source: {
+        kind: "github",
+        repo: "every-app/open-seo",
+        path: "plugins/openseo",
+        ref: "c469a48ae90ab58413b198fe3d1ac1aa90a9b070",
+      },
+    });
+  });
+
   test("throws on a malformed manifest", () => {
     expect(() => buildBundledPluginCatalog({ plugins: [{}] })).toThrow();
   });

package/src/cli/lib/bundled-marketplace.json

@@ -318,6 +318,20 @@
       "license": "MIT",
       "icon": "💳"
     },
+    {
+      "name": "openseo",
+      "source": {
+        "source": "github",
+        "repo": "every-app/open-seo",
+        "path": "plugins/openseo",
+        "ref": "c469a48ae90ab58413b198fe3d1ac1aa90a9b070"
+      },
+      "description": "Keyword research, competitor analysis, site audits, backlinks, and rank tracking with real SEO data, plus guided workflow skills and the hosted OpenSEO MCP server.",
+      "category": "marketing",
+      "homepage": "https://openseo.so",
+      "license": "MIT",
+      "icon": "🔎"
+    },
     {
       "name": "originkit",
       "source": {

package/src/cli/lib/install-from-github.ts

@@ -1134,12 +1134,16 @@ function normalizeInstalledManifest(
  * (`buildPluginFromDir`) hard-requires a `package.json` validated against
  * `PluginPackageJsonSchema` and silently skips the plugin when it's missing.
  *
- * The synthesized manifest carries the install name and the default
- * `@vellumai/plugin-api` peer dependency range. No foreign-ecosystem manifest
- * data is read — the install name is the only identity we trust for an
- * untrusted direct install.
+ * Used by both the GitHub clone path and the platform tarball path. The
+ * synthesized manifest carries the install name and the default
+ * `@vellumai/plugin-api` peer dependency range. No foreign-ecosystem
+ * manifest data is read: the install name is the only identity we trust
+ * when upstream ships no Vellum package.json.
  */
-function synthesizeMinimalPackageJson(name: string, stagingDir: string): void {
+export function synthesizeMinimalPackageJson(
+  name: string,
+  stagingDir: string,
+): void {
   const manifestPath = join(stagingDir, "package.json");
 
   const manifest: PackageManifest = {

package/src/cli/lib/install-from-platform.ts

@@ -8,7 +8,9 @@
  * and extracts it into the plugin's install directory — it does NOT clone the
  * plugin from GitHub itself, and it does NOT emit `plugin_installed` telemetry
  * (hitting this endpoint *is* the recorded install; the server rejects that
- * event type on the usual ingest path).
+ * event type on the usual ingest path). A tarball that ships no
+ * `package.json` gets the same synthesized manifest the GitHub clone path
+ * writes, so the loader still registers the plugin's skills.
  *
  *     GET {PLATFORM_BASE_URL}/v1/plugins/{name}/install/
  *
@@ -42,6 +44,7 @@ import {
   PluginNotFoundError,
   PluginSourceUnavailableError,
   sanitizePluginName,
+  synthesizeMinimalPackageJson,
 } from "./install-from-github.js";
 
 /**
@@ -198,6 +201,14 @@ export async function installPluginFromPlatform(
     throw new PluginNotFoundError(name, meta.ref ?? "", meta.repo ?? name);
   }
 
+  // Same default as the GitHub clone path: a marketplace tarball that
+  // ships skills/mcp.json but no Vellum package.json still has to load.
+  // The loader skips a directory with no manifest, so synthesize one
+  // before the fingerprint and swap.
+  if (!existsSync(join(stagingDir, "package.json"))) {
+    synthesizeMinimalPackageJson(name, stagingDir);
+  }
+
   await confirmStagedOrAbort(name, stagingDir, deps.confirmStaged);
 
   // Record provenance for future update/version UX. The endpoint re-roots the

package/src/config/__tests__/assistant-initiated-threads-gate.test.ts

@@ -0,0 +1,61 @@
+/**
+ * The gate reads a string-valued flag that does not always arrive as a
+ * string.
+ *
+ * The registry and the gateway's persisted store carry the declared `"on"` /
+ * `"off"` strings. The gateway's env-override path does not: its parser
+ * (`feature-flag-env-overrides.ts`) treats `on` as a truthy *word* and
+ * coerces it to boolean `true`, then applies env overrides last — so
+ * `VELLUM_FLAG_ASSISTANT_INITIATED_THREADS=on` reaches the daemon as `true`.
+ *
+ * A strict `=== "on"` therefore read the documented env kill-switch as OFF,
+ * and did it silently: the section just never rendered. That shipped in the
+ * first cut of this gate and cost an afternoon of QA, which is why both
+ * shapes are pinned here rather than only the one the registry emits.
+ */
+
+import { afterEach, describe, expect, mock, test } from "bun:test";
+
+let flagValue: boolean | string = "off";
+
+mock.module("../assistant-feature-flags.js", () => ({
+  getAssistantFeatureFlagValue: () => flagValue,
+}));
+
+const { isAssistantInitiatedThreadsEnabled } = await import(
+  "../assistant-initiated-threads-gate.js"
+);
+
+afterEach(() => {
+  flagValue = "off";
+});
+
+describe("isAssistantInitiatedThreadsEnabled", () => {
+  test('enabled by the declared string "on" (registry / persisted store)', () => {
+    flagValue = "on";
+    expect(isAssistantInitiatedThreadsEnabled()).toBe(true);
+  });
+
+  test("enabled by boolean true (the gateway's env-override coercion)", () => {
+    // The regression. `VELLUM_FLAG_ASSISTANT_INITIATED_THREADS=on` arrives
+    // here as `true`, never as "on".
+    flagValue = true;
+    expect(isAssistantInitiatedThreadsEnabled()).toBe(true);
+  });
+
+  test('disabled by the declared string "off"', () => {
+    flagValue = "off";
+    expect(isAssistantInitiatedThreadsEnabled()).toBe(false);
+  });
+
+  test("disabled by boolean false (env `=off` coercion)", () => {
+    flagValue = false;
+    expect(isAssistantInitiatedThreadsEnabled()).toBe(false);
+  });
+
+  test("fails closed on an unrecognized arm", () => {
+    // A future A/B value this gate has no opinion about must not read as on.
+    flagValue = "variant-b";
+    expect(isAssistantInitiatedThreadsEnabled()).toBe(false);
+  });
+});

package/src/config/assistant-initiated-threads-gate.ts

@@ -0,0 +1,50 @@
+import { getAssistantFeatureFlagValue } from "./assistant-feature-flags.js";
+import type { AssistantConfig } from "./schema.js";
+
+const ASSISTANT_INITIATED_THREADS_FLAG_KEY =
+  "assistant-initiated-threads" as const;
+
+/**
+ * Whether the conversations the assistant started on its own are split into
+ * their own sidebar section instead of sitting in Chats.
+ *
+ * Read through {@link getAssistantFeatureFlagValue} rather than
+ * `isAssistantFeatureFlagEnabled`, because the flag is string-valued: that
+ * helper coerces with `!!`, and `!!"off"` is `true`, so the boolean form would
+ * report the off arm as on.
+ *
+ * A read-side gate only. The rows exist either way — every notification
+ * delivery has always materialized one (`notifications/conversation-pairing.ts`)
+ * — so turning the flag off puts them back in Chats and takes the `assistant`
+ * row out of the section index, with nothing to migrate in either direction.
+ *
+ * This is the *only* gate on the feature, which is why the flag is
+ * assistant-scope rather than `both`. Clients render the section on the
+ * presence of the index row, because that row is what says the daemon has
+ * withheld those conversations from Chats. A second, client-side gate could
+ * only ever hide a section whose rows have already been withheld — losing
+ * those threads rather than reverting the feature — so there deliberately
+ * isn't one.
+ */
+export function isAssistantInitiatedThreadsEnabled(
+  config?: AssistantConfig,
+): boolean {
+  const value = getAssistantFeatureFlagValue(
+    ASSISTANT_INITIATED_THREADS_FLAG_KEY,
+    config,
+  );
+  /* Both shapes are the same answer, and the on arm arrives as either one
+     depending on which layer resolved it.
+
+     The registry and the gateway's persisted store carry the declared string
+     (`"on"`). The gateway's env-override path does not: its parser treats
+     `on` as a truthy word (`TRUTHY = {"true","1","yes","on"}` in
+     `feature-flag-env-overrides.ts`) and coerces it to boolean `true`, then
+     applies env last — so `VELLUM_FLAG_ASSISTANT_INITIATED_THREADS=on`
+     reaches the daemon as `true`, not `"on"`.
+
+     A strict `=== "on"` therefore reads the env kill-switch as OFF, which is
+     the exact opposite of what an operator setting it intends, and it fails
+     silently: the section simply does not render. Accept both. */
+  return value === true || value === "on";
+}

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

@@ -8,12 +8,11 @@ metadata:
     display-name: "ACP"
     category: "development"
     activation-hints:
-      - "User wants to set up, install, configure, authenticate, or connect Claude Code or Codex"
-      - "User asks to use Claude Code or Codex, or delegate a coding task to an ACP agent"
+      - "User names Claude Code or Codex, or wants to set up, install, configure, authenticate, connect, use, or delegate work to them"
       - "User wants an agent to work autonomously and report back later"
       - "User mentions ACP, claude-agent-acp, or codex-acp"
     avoid-when:
-      - "The task is small enough to do inline"
+      - "The task is small enough to do inline and the user did not name Claude Code or Codex"
 ---
 
 ACP agent orchestration - spawn external coding agents (Claude Code, Codex) to work on tasks via the Agent Client Protocol. Each agent runs as its own subprocess speaking ACP over stdio and streams results back into the conversation.
@@ -24,6 +23,14 @@ Use `acp_spawn` to delegate a coding task to an external agent. The agent runs a
 
 Users can refer to agents by natural names: "claude code", "codex cli", and "openai codex" all resolve to the canonical `claude` and `codex` ids (unless the user's config defines an agent literally keyed by that name, which always wins).
 
+## When the user names Claude Code or Codex
+
+If they name Claude Code or Codex without asking you to run it here (for example they say that tool will do the work), offer once, in one short sentence, that you can connect and run it in this conversation. Then continue with whatever they were doing.
+
+- Do not spawn unless they accept.
+- Skip if you already offered this conversation, they declined, or they are already connected.
+- This is not the missing-token card path. Do not invent setup steps.
+
 ## First-time setup
 
 ACP is always available - default profiles for `claude` and `codex` ship out-of-box, so no config edit is needed to start. First-time setup is just making the adapter binary available, then spawning:

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

@@ -1,6 +1,6 @@
 ---
 name: schedule
-description: Recurring and one-shot scheduling - cron, RRULE, or single fire-at time
+description: Reminders, automations, and recurring page, dashboard, or status monitoring (cron, RRULE, or fire-at)
 compatibility: "Designed for Vellum personal assistants"
 metadata:
   emoji: "📅"
@@ -8,17 +8,28 @@ metadata:
     display-name: "Schedule"
     category: "productivity"
     activation-hints:
-      - "User wants to set a reminder for a future time (e.g. 'remind me at 9am tomorrow', 'remind me to take meds at 8pm')"
-      - "User wants to schedule a recurring task or automation (e.g. 'every weekday at 9am', 'every Monday at noon')"
-      - "User wants to schedule a one-time future action the assistant should run autonomously (e.g. 'at 5pm check my email and summarize it')"
-      - "User wants to list, update, cancel, or inspect existing scheduled tasks or reminders"
+      - "User wants a reminder"
+      - "User wants a recurring task or nightly check"
+      - "User wants to monitor a page, dashboard, or status and get alerts"
+      - "User wants a one-time future action"
+      - "User wants to manage existing schedules"
     avoid-when:
-      - "User wants to add something to their task list or queue — use task-list tools instead"
-      - "User wants to act immediately or run a quick command that completes within the conversation — schedule is only for deferred or recurring execution"
+      - "User wants a task-list item"
+      - "User wants a one-off that finishes now. Recurring-job setup still uses this skill"
 ---
 
 Manage scheduled automations. Schedules can be **recurring** (cron or RRULE expression) or **one-shot** (a single `fire_at` timestamp). Schedules support four modes: **execute** (run a message through the assistant), **notify** (send a notification to the user), **script** (run a shell command directly without LLM involvement), and **workflow** (run a saved multi-agent workflow by name).
 
+## Recurring Monitoring
+
+When the user wants something checked on a cadence (a status page, dashboard, site, or similar) and to be told if it is wrong, late, or missing: create a schedule. Do not author a standalone script they have to download, run, or maintain.
+
+- Recurrence, cutoff times, escalation, and notifications are schedule and notification primitives. Do not reimplement them in a workspace file the user has to run.
+- Prefer **execute** mode: the scheduled message browses or fetches the source, applies the user's rules, and notifies on exceptions. Use **script** mode only for a cheap deterministic check against a live source the assistant can already reach (curl an API, read a file in the workspace). A script-mode job is still a schedule, not a file you hand the user.
+- Looking at a page, pasting HTML, or gathering a roster is setup for the schedule, not a reason to skip creating one.
+- If browsing cannot reach the page, still create the schedule. Offer the desktop app (https://www.vellum.ai/download) or the Chrome extension (https://chromewebstore.google.com/detail/vellum-assistant-browser/hphbdmpffeigpcdjkckleobjmhhokpne) so a logged-in browser session can run it. Do not replace the schedule with a parser against a pasted export, and do not assign comparison-run homework before anything is scheduled.
+- Watchers cover Gmail, Google Calendar, GitHub, Linear, and Outlook event polling. An arbitrary web page or status dashboard is this skill, not the watcher skill.
+
 ## Schedule Syntax
 
 ### Cron
@@ -119,6 +130,8 @@ assistant conversations wake "$id" --hint "Summarize the new items" --external-c
 
 **Secrets.** For an OAuth-connected provider (google, slack, notion, …), call its API with `assistant oauth request --provider <p> <url>` — the assistant injects the token, and the script never sees it. For raw secrets with no OAuth provider (PATs, API keys), collect at install time with `assistant credentials prompt --service <s> --field <f> --label "<label>"` (secure input, never printed to chat) and read at runtime with `assistant credentials reveal --service <s> --field <f>`.
 
+When a scheduled or background run is blocked on a missing or stale credential, tell the user in the notification that the credential needs refreshing and ask them to reply in the thread so you can open the secure prompt. Never put a CLI command in the notification or the tick summary. The user cannot run those from their terminal.
+
 ## Inference Profile
 
 Every schedule carries a pinned `inference_profile` (a key from `llm.profiles`), so a recurring task keeps running on the model (and the price) it was created under even when the user later changes their default profile. Creating a schedule without `inference_profile` pins it to the user's current default; pass one explicitly when a task should run on a specific model, e.g. a cost-optimized profile for a high-frequency digest. Passing `inference_profile: null` on update re-pins the schedule to the user's current default rather than unpinning it. The pinned profile is shown on the schedule's details page in settings.
@@ -213,14 +226,15 @@ When `schedule_create` returns, it includes an integration status summary. Cross
 
 - If the task involves **email** (reading, sending, OTP verification): an email integration must be connected (check the "email" category)
 - If the task involves **making calls**: Twilio must be connected
-- If the task involves **web browsing or form-filling**: browser automation must be available (check client type)
+- If the task involves **web browsing or form-filling**: browser automation must be available (check client type). A timeout, auth wall, or missing logged-in browser is a setup gap, not a reason to skip the schedule or to write a standalone script.
 - If the task involves a **multi-step workflow** (e.g., book appointment → read confirmation email), trace the full dependency chain
 
 If any required capability is missing:
 
-1. **Do NOT tell the user the schedule is ready** - instead, explain what's missing and why the schedule won't work yet
-2. Offer to help set up the missing integration first
-3. The schedule is still created (so timing is preserved), but make it clear it won't execute successfully until dependencies are resolved
+1. **Still create the schedule** so timing is preserved. Do not tell the user it is ready to run.
+2. Explain what is missing and why the next fire will fail until that is fixed.
+3. Offer to set up the missing integration first. For a page the assistant cannot reach, offer the desktop app (https://www.vellum.ai/download) or the Chrome extension (https://chromewebstore.google.com/detail/vellum-assistant-browser/hphbdmpffeigpcdjkckleobjmhhokpne) before asking for a screenshot or pasted export.
+4. Do not replace the schedule with a workspace script the user has to run themselves.
 
 ## Delivering Results
 

package/src/config/bundled-skills/schedule/references/SCRIPT_MODE_PATTERNS.md

@@ -56,4 +56,6 @@ fi
 
 ## Tips
 
-Both patterns keep scheduled runs fast and cheap — the script exits immediately when nothing interesting happens, and only reaches for the assistant or notification system when there's something to act on. Use `quiet: true` on the schedule to suppress the per-run completion noise.
+Both patterns keep scheduled runs fast and cheap. The script exits immediately when nothing interesting happens, and only reaches for the assistant or notification system when there's something to act on. Use `quiet: true` on the schedule to suppress the per-run completion noise.
+
+A script-mode schedule is still a schedule the user can see, pause, and edit. Do not hand them a standalone file to run themselves.

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

@@ -123,8 +123,11 @@ export const CALL_SITE_DEFAULTS: Record<LLMCallSite, CallSiteDefaultConfig> = {
     effort: "low",
     thinking: { enabled: false },
   },
+  // The dictation cleanup pass, and nothing else runs on this site. The
+  // caller has already stopped speaking and has nothing on screen until this
+  // answers, so it is priced as a latency call.
   interactionClassifier: {
-    profile: "cost-optimized",
+    profile: "latency-optimized",
     effort: "low",
     thinking: { enabled: false },
   },

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

@@ -36,6 +36,15 @@
       "defaultEnabled": "off",
       "values": ["off", "on"]
     },
+    {
+      "id": "assistant-initiated-threads",
+      "scope": "assistant",
+      "key": "assistant-initiated-threads",
+      "label": "Assistant-Initiated Threads",
+      "description": "Gates the sidebar section collecting the conversations the assistant started on its own: rows stamped `source='assistant_initiated'` at creation by producers that opt a thread in (heartbeat realizations worth the user's time; nothing stamps it yet, so the section starts empty and holds only new threads by construction). Transactional notification trails keep `source='notification'` and stay in Chats and the bell. When on, the daemon emits an `assistant` row from the section index and withholds member conversations from the Chats bucket; when off, they stay in Chats and no `assistant` row is emitted, which is the shipped behavior. Deliberately daemon-scope only: the index row is self-describing, so clients render the section on its presence rather than on a flag of their own. A second client-side gate could only hide a section whose rows the daemon has already withheld from Chats, which would lose those threads instead of reverting the feature. String-valued so future A/B arms can be added as new values.",
+      "defaultEnabled": "off",
+      "values": ["off", "on"]
+    },
     {
       "id": "experiment-activation-flow-2026-06-03",
       "scope": "both",
@@ -189,6 +198,14 @@
       "description": "Show a live HUD in the top-right of the conversation with scroll geometry, velocity, update rate, and anchor-preserver activity. Developer diagnostic for investigating scroll jank.",
       "defaultEnabled": false
     },
+    {
+      "id": "camera-gate-debug-hud",
+      "scope": "client",
+      "key": "camera-gate-debug-hud",
+      "label": "Camera Gate Debug HUD",
+      "description": "Unlock the camera frame gate's tuning readout: the switch in the camera's view options that turns it on, and the live panel over the composer's sight tile and the voice room's viewfinder showing motion, novelty and detail against their thresholds, the check that decided each frame, and sliders that move those thresholds while the camera runs. Staff sessions get it without the flag; the flag is for local gateway sessions, which carry no platform identity and are where the gate is tuned.",
+      "defaultEnabled": false
+    },
     {
       "id": "compaction-playground",
       "scope": "assistant",
@@ -391,11 +408,11 @@
       "values": ["glm-5p3-flash", "glm-5p3", "glm-5p2"]
     },
     {
-      "id": "ios-avatar-app-icon",
+      "id": "android-avatar-app-icon",
       "scope": "client",
-      "key": "ios-avatar-app-icon",
-      "label": "iOS Avatar App Icon",
-      "description": "Shows the App icon picker in Settings -> General, where any user chooses an eyes-on-color home screen icon for iOS, seeds the picker from their assistant's character avatar, or resets to the default. Every change is a press, and iOS confirms each one with an alert of its own. Off hides the picker and leaves the default icon in place.",
+      "key": "android-avatar-app-icon",
+      "label": "Android Avatar App Icon",
+      "description": "Shows the App icon picker in Settings -> General on Android, where any user chooses an eyes-on-color launcher icon, seeds the picker from their assistant's character avatar, or resets to the default. Android applies the change when the app goes to the background, and switching icons can reset a pinned home-screen shortcut. Off hides the picker and leaves the default icon in place.",
       "defaultEnabled": false
     },
     {

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

@@ -144,11 +144,12 @@ export const MemoryV3LearnedEdgesSchema = z
   );
 
 /**
- * Ephemeral section-spotlight tuning: how many of the current turn's selected
+ * Per-turn section-spotlight tuning: how many of the current turn's selected
  * finder hits render their matched section into the `<memory_spotlight>`
  * block, and how many previous turns' spotlight entries are carried along
- * before they age out. The block is strip-and-replaced every turn, so its
- * size is bounded by `n × (windowTurns + 1)` entries.
+ * before they age out. Each turn keeps the block it was sent with. A new
+ * spotlight is added only on the new tail. Size is bounded by
+ * `n × (windowTurns + 1)` entries.
  */
 export const MemoryV3SpotlightSchema = z
   .object({