@vellumai/assistant 0.4.44 → 0.4.45

package/src/notifications/README.md

@@ -7,7 +7,7 @@ Signal-driven notification architecture where producers emit free-form events an
 ```
 Producer → NotificationSignal → Candidate Generation → Decision Engine (LLM) → Deterministic Checks → Broadcaster → Conversation Pairing → Adapters → Delivery
                                                               ↑                                                            ↓
-                                                      Preference Summary                                    notification_thread_created IPC
+                                                      Preference Summary                                    notification_thread_created SSE event
                                                       Thread Candidates                                     (creation-only — not emitted on reuse)
 ```
 
@@ -71,7 +71,7 @@ Hard invariants that the LLM cannot override:
 
 ### 6. Broadcast, Conversation Pairing, and Delivery
 
-The broadcaster (`broadcaster.ts`) iterates over selected channels (vellum first for fast IPC push), resolves destinations via `destination-resolver.ts`, pairs each delivery with a conversation via `conversation-pairing.ts`, pulls rendered copy from the decision (falling back to `copy-composer.ts` templates), and dispatches through channel adapters. Each delivery attempt is recorded in `notification_deliveries` with `conversation_id`, `message_id`, and `conversation_strategy` columns.
+The broadcaster (`broadcaster.ts`) iterates over selected channels (vellum first for fast SSE push), resolves destinations via `destination-resolver.ts`, pairs each delivery with a conversation via `conversation-pairing.ts`, pulls rendered copy from the decision (falling back to `copy-composer.ts` templates), and dispatches through channel adapters. Each delivery attempt is recorded in `notification_deliveries` with `conversation_id`, `message_id`, and `conversation_strategy` columns.
 
 ## Channel Policy Registry
 
@@ -183,27 +183,27 @@ Take out the trash
 Reminder. Take out the trash. Action required.
 ```
 
-## Thread Surfacing via `notification_thread_created` IPC (Creation-Only)
+## Thread Surfacing via `notification_thread_created` Event (Creation-Only)
 
-The `notification_thread_created` IPC event is emitted **only when a brand-new conversation is actually created** by the broadcaster. Reused threads do not trigger this event — the macOS/iOS client already knows about the conversation from the original creation.
+The `notification_thread_created` SSE event is emitted **only when a brand-new conversation is actually created** by the broadcaster. Reused threads do not trigger this event — the macOS/iOS client already knows about the conversation from the original creation.
 
-This is enforced in `broadcaster.ts` by gating the IPC emission on `pairing.createdNewConversation === true`:
+This is enforced in `broadcaster.ts` by gating the event emission on `pairing.createdNewConversation === true`:
 
 ```ts
 // Emit notification_thread_created only when a NEW conversation was
-// actually created. Reusing an existing thread should not fire the IPC
+// actually created. Reusing an existing thread should not fire the SSE
 // event — the client already knows about the conversation.
 if (
   pairing.createdNewConversation &&
   pairing.strategy === "start_new_conversation"
 ) {
-  // ... emit IPC event
+  // ... emit SSE event
 }
 ```
 
-When a vellum notification thread **is** newly created (strategy `start_new_conversation`), the broadcaster emits the IPC event **immediately**, before waiting for slower channel deliveries (e.g. Telegram). This avoids a race where a slow Telegram delivery delays the IPC push past the macOS deep-link retry window.
+When a vellum notification thread **is** newly created (strategy `start_new_conversation`), the broadcaster emits the SSE event **immediately**, before waiting for slower channel deliveries (e.g. Telegram). This avoids a race where a slow Telegram delivery delays the broadcast past the macOS deep-link retry window.
 
-The IPC event payload:
+The SSE event payload:
 
 ```ts
 {
@@ -223,39 +223,40 @@ The macOS/iOS client listens for this event and surfaces the thread in the sideb
 **Important distinction between the two callbacks:**
 
 - **Per-dispatch `options.onThreadCreated`**: Fires for **both** new and reused vellum conversation pairings. Callers like `dispatchGuardianQuestion` rely on this to create delivery bookkeeping rows before `emitNotificationSignal()` returns, regardless of whether the conversation was newly created or reused.
-- **Class-level `this.onThreadCreated` (IPC)**: Fires **only** when a brand-new conversation is created (`createdNewConversation === true && strategy === 'start_new_conversation'`). This emits the `notification_thread_created` IPC event so macOS/iOS clients surface the new thread in the sidebar. Reused threads do not trigger this event because the client already knows about the conversation.
+- **Class-level `this.onThreadCreated` (SSE broadcast)**: Fires **only** when a brand-new conversation is created (`createdNewConversation === true && strategy === 'start_new_conversation'`). This emits the `notification_thread_created` SSE event so macOS/iOS clients surface the new thread in the sidebar. Reused threads do not trigger this event because the client already knows about the conversation.
 
-## Reminder Routing Metadata and Trigger-Time Enforcement
+## Schedule Routing Metadata and Trigger-Time Enforcement
 
-Reminders carry optional routing metadata that controls how notifications fan out across channels when the reminder fires. This enables a single reminder to produce multi-channel delivery without requiring the user to create duplicate reminders per channel.
+Schedules (both recurring and one-shot) carry optional routing metadata that controls how notifications fan out across channels when the schedule fires in `notify` mode. This enables a single schedule to produce multi-channel delivery without requiring the user to create duplicate schedules per channel.
 
 ### Routing Intent Model
 
-The `routing_intent` field on each reminder row specifies the desired channel coverage:
+The `routing_intent` field on each `schedule_jobs` row specifies the desired channel coverage:
 
-| Intent           | Behavior                                              | When to use                                                         |
-| ---------------- | ----------------------------------------------------- | ------------------------------------------------------------------- |
-| `single_channel` | Default LLM-driven routing (no override)              | Standard reminders where the decision engine picks the best channel |
-| `multi_channel`  | Ensures delivery on 2+ channels when 2+ are connected | Important reminders the user wants on both desktop and phone        |
-| `all_channels`   | Forces delivery on every connected channel            | Critical reminders that must reach the user everywhere              |
+| Intent           | Behavior                                              | When to use                                                          |
+| ---------------- | ----------------------------------------------------- | -------------------------------------------------------------------- |
+| `single_channel` | Default LLM-driven routing (no override)              | Standard schedules where the decision engine picks the best channel  |
+| `multi_channel`  | Ensures delivery on 2+ channels when 2+ are connected | Important schedules the user wants on both desktop and phone         |
+| `all_channels`   | Forces delivery on every connected channel            | Critical schedules that must reach the user everywhere               |
 
-The default is `single_channel`, preserving backward compatibility. Routing intent is persisted in the `reminders` table (`routing_intent` column) and carried through the notification signal as `routingIntent`.
+The default is `all_channels`. Routing intent is persisted in the `schedule_jobs` table (`routing_intent` column) and carried through the notification signal as `routingIntent`.
 
 ### Routing Hints
 
-The `routing_hints` field is free-form JSON metadata passed alongside the routing intent. It flows through the signal as `routingHints` and is included in the decision engine prompt, allowing producers to communicate channel preferences or contextual hints without requiring schema changes.
+The `routing_hints_json` field is free-form JSON metadata passed alongside the routing intent. It flows through the signal as `routingHints` and is included in the decision engine prompt, allowing producers to communicate channel preferences or contextual hints without requiring schema changes.
 
 ### Trigger-Time Enforcement Flow
 
-When a reminder fires, the routing metadata flows through the notification pipeline with a post-decision enforcement step:
+When a schedule fires in `notify` mode, the routing metadata flows through the notification pipeline with a post-decision enforcement step:
 
 ```
-Reminder fires (scheduler)
-  → emitNotificationSignal({ routingIntent, routingHints })
-    → Decision Engine (LLM selects channels)
-      → enforceRoutingIntent() (post-decision guard)
-        → Deterministic Checks
-          → Broadcaster → Adapters → Delivery
+Schedule fires (scheduler.ts: notify mode)
+  → notifyScheduleOneShot callback (lifecycle.ts)
+    → emitNotificationSignal({ routingIntent, routingHints })
+      → Decision Engine (LLM selects channels)
+        → enforceRoutingIntent() (post-decision guard)
+          → Deterministic Checks
+            → Broadcaster → Adapters → Delivery
 ```
 
 The `enforceRoutingIntent()` function in `decision-engine.ts` runs after the LLM produces its channel selection but before deterministic checks. It overrides the decision's `selectedChannels` based on the routing intent:
@@ -266,16 +267,16 @@ The `enforceRoutingIntent()` function in `decision-engine.ts` runs after the LLM
 
 When enforcement changes the decision, the updated channel selection is re-persisted to the `notification_decisions` table so the stored decision matches what was actually dispatched. The `reasoningSummary` is annotated with the enforcement action (e.g. `[routing_intent=all_channels enforced: vellum, telegram]`).
 
-### Single-Reminder Fanout
+### Single-Schedule Fanout
 
-A key design principle: **one reminder produces one notification signal that fans out to multiple channels**. The user never needs to create separate reminders for each channel. The routing intent metadata on the single reminder controls the fanout behavior, and the notification pipeline handles per-channel copy rendering, conversation pairing, and delivery through the existing adapter infrastructure.
+A key design principle: **one schedule produces one notification signal that fans out to multiple channels**. The user never needs to create separate schedules for each channel. The routing intent metadata on the single schedule controls the fanout behavior, and the notification pipeline handles per-channel copy rendering, conversation pairing, and delivery through the existing adapter infrastructure.
 
 ### Data Flow
 
 ```
-reminders table (routing_intent, routing_hints_json)
-  → scheduler.ts: claimDueReminders() reads routing metadata
-    → lifecycle.ts: notifyReminder({ routingIntent, routingHints })
+schedule_jobs table (routing_intent, routing_hints_json)
+  → scheduler.ts: claimDueSchedules() reads routing metadata
+    → lifecycle.ts: notifyScheduleOneShot({ routingIntent, routingHints })
       → emitNotificationSignal({ routingIntent, routingHints })
         → signal.ts: NotificationSignal.routingIntent / routingHints
           → decision-engine.ts: evaluateSignal() → enforceRoutingIntent()
@@ -288,7 +289,7 @@ The notification system delivers to three channel types:
 
 ### Vellum (always connected)
 
-Local IPC via the daemon's broadcast mechanism. The `VellumAdapter` emits a `notification_intent` message containing:
+Local SSE via the daemon's broadcast mechanism. The `VellumAdapter` emits a `notification_intent` message containing:
 
 - `sourceEventName` -- the event that triggered the notification
 - `title` and `body` -- rendered notification copy
@@ -304,7 +305,7 @@ HTTP POST to the gateway's `/deliver/telegram` endpoint. The `TelegramAdapter` s
 
 Connected channels are resolved at signal emission time by `getConnectedChannels()` in `emit-signal.ts`:
 
-- **Vellum** is always considered connected (IPC socket is always available when the daemon is running)
+- **Vellum** is always considered connected (HTTP transport is always available when the daemon is running)
 - **Telegram** is considered connected only when an active guardian binding exists for the assistant (checked via `getActiveBinding()`)
 
 ## Conversation Materialization
@@ -319,7 +320,7 @@ Guardian dispatch follows this same path and uses the optional `onThreadCreated`
 
 ### Conversation Pairing Invariant
 
-For notification flows that create conversations, the conversation must be created **before** the IPC event is emitted. This ensures the macOS client can immediately fetch the conversation contents when it receives the thread-created event.
+For notification flows that create conversations, the conversation must be created **before** the SSE event is emitted. This ensures the macOS client can immediately fetch the conversation contents when it receives the thread-created event.
 
 ## Thread Decision Audit Trail
 
@@ -405,29 +406,29 @@ All disambiguation messages are generated through `composeGuardianActionMessageG
 
 ## Key Files
 
-| File                      | Purpose                                                                                        |
-| ------------------------- | ---------------------------------------------------------------------------------------------- |
-| `../channels/config.ts`   | Channel policy registry -- single source of truth for per-channel notification behavior        |
-| `emit-signal.ts`          | Single entry point for producers; orchestrates the full pipeline                               |
-| `signal.ts`               | `NotificationSignal` and `AttentionHints` type definitions                                     |
-| `types.ts`                | Channel adapter interfaces, delivery types, decision output contract, `ThreadAction` union     |
-| `thread-candidates.ts`    | Builds per-channel candidate set of recent notification conversations for the decision engine  |
-| `conversation-pairing.ts` | Materializes conversation + message per delivery based on channel strategy                     |
-| `decision-engine.ts`      | LLM-based routing with forced tool_choice; deterministic fallback                              |
-| `deterministic-checks.ts` | Pre-send gate checks (dedupe, source-active, channel availability)                             |
-| `runtime-dispatch.ts`     | Dispatch gating (no-op decisions, empty channels)                                              |
+| File                      | Purpose                                                                                              |
+| ------------------------- | ---------------------------------------------------------------------------------------------------- |
+| `../channels/config.ts`   | Channel policy registry -- single source of truth for per-channel notification behavior              |
+| `emit-signal.ts`          | Single entry point for producers; orchestrates the full pipeline                                     |
+| `signal.ts`               | `NotificationSignal` and `AttentionHints` type definitions                                           |
+| `types.ts`                | Channel adapter interfaces, delivery types, decision output contract, `ThreadAction` union           |
+| `thread-candidates.ts`    | Builds per-channel candidate set of recent notification conversations for the decision engine        |
+| `conversation-pairing.ts` | Materializes conversation + message per delivery based on channel strategy                           |
+| `decision-engine.ts`      | LLM-based routing with forced tool_choice; deterministic fallback                                    |
+| `deterministic-checks.ts` | Pre-send gate checks (dedupe, source-active, channel availability)                                   |
+| `runtime-dispatch.ts`     | Dispatch gating (no-op decisions, empty channels)                                                    |
 | `broadcaster.ts`          | Fan-out to channel adapters with delivery audit trail; emits `notification_thread_created` SSE event |
-| `copy-composer.ts`        | Template-based fallback notification copy when LLM copy is unavailable                              |
-| `thread-seed-composer.ts` | Surface-aware thread seed generation (richer than notification copy)                                |
-| `destination-resolver.ts` | Resolves per-channel endpoints (vellum SSE, Telegram chat ID)                                       |
-| `adapters/macos.ts`       | Vellum adapter -- broadcasts `notification_intent` via SSE with deep-link metadata                  |
-| `adapters/telegram.ts`    | Telegram adapter -- POSTs to gateway `/deliver/telegram`                                       |
-| `preference-extractor.ts` | Detects notification preferences in conversation messages                                      |
-| `preference-summary.ts`   | Builds preference context string for the decision engine prompt                                |
-| `preferences-store.ts`    | CRUD for `notification_preferences` table                                                      |
-| `events-store.ts`         | CRUD for `notification_events` table                                                           |
-| `decisions-store.ts`      | CRUD for `notification_decisions` table                                                        |
-| `deliveries-store.ts`     | CRUD for `notification_deliveries` table                                                       |
+| `copy-composer.ts`        | Template-based fallback notification copy when LLM copy is unavailable                               |
+| `thread-seed-composer.ts` | Surface-aware thread seed generation (richer than notification copy)                                 |
+| `destination-resolver.ts` | Resolves per-channel endpoints (vellum SSE, Telegram chat ID)                                        |
+| `adapters/macos.ts`       | Vellum adapter -- broadcasts `notification_intent` via SSE with deep-link metadata                   |
+| `adapters/telegram.ts`    | Telegram adapter -- POSTs to gateway `/deliver/telegram`                                             |
+| `preference-extractor.ts` | Detects notification preferences in conversation messages                                            |
+| `preference-summary.ts`   | Builds preference context string for the decision engine prompt                                      |
+| `preferences-store.ts`    | CRUD for `notification_preferences` table                                                            |
+| `events-store.ts`         | CRUD for `notification_events` table                                                                 |
+| `decisions-store.ts`      | CRUD for `notification_decisions` table                                                              |
+| `deliveries-store.ts`     | CRUD for `notification_deliveries` table                                                             |
 
 ## How to Add a New Notification Producer
 
@@ -479,7 +480,7 @@ Three SQLite tables form the audit chain:
 
 ### Client Delivery Ack
 
-For vellum (macOS/iOS) deliveries, the audit trail now extends past the IPC broadcast to the actual OS notification post. The `notification_intent` message carries an optional `deliveryId` that the client echoes back in a `notification_intent_result` ack after `UNUserNotificationCenter.add()` completes (or fails).
+For vellum (macOS/iOS) deliveries, the audit trail now extends past the SSE broadcast to the actual OS notification post. The `notification_intent` message carries an optional `deliveryId` that the client echoes back in a `notification_intent_result` ack after `UNUserNotificationCenter.add()` completes (or fails).
 
 The ack populates three columns on `notification_deliveries`:
 

package/src/notifications/adapters/macos.ts

@@ -1,6 +1,6 @@
 /**
  * Vellum channel adapter — delivers notifications to connected desktop
- * and mobile clients via the daemon's IPC broadcast mechanism.
+ * and mobile clients via the daemon's event broadcast mechanism.
  *
  * The adapter broadcasts a `notification_intent` message that the Vellum
  * client can use to display a native notification (e.g. NSUserNotification

package/src/notifications/broadcaster.ts

@@ -79,8 +79,8 @@ export class NotificationBroadcaster {
   ): Promise<NotificationDeliveryResult[]> {
     const destinations = resolveDestinations(decision.selectedChannels);
 
-    // Ensure vellum is processed first so the notification_thread_created IPC
-    // push fires immediately, before slower channel sends (e.g. Telegram 30s
+    // Ensure vellum is processed first so the notification_thread_created
+    // event fires immediately, before slower channel sends (e.g. Telegram 30s
     // timeout) can delay it past the macOS deep-link retry window.
     const orderedChannels = [...decision.selectedChannels].sort((a, b) => {
       if (a === "vellum") return -1;
@@ -242,10 +242,10 @@ export class NotificationBroadcaster {
           }
         }
 
-        // Emit notification_thread_created IPC event only when a NEW
+        // Emit notification_thread_created event only when a NEW
         // conversation was actually created. Reusing an existing thread
-        // should not fire the IPC event — the client already knows about
-        // the conversation.
+        // should not fire the event — the client already knows about the
+        // conversation.
         if (
           pairing.createdNewConversation &&
           pairing.strategy === "start_new_conversation"

package/src/notifications/copy-composer.ts

@@ -233,7 +233,7 @@ export function buildAccessRequestContractText(
 
 // Templates keyed by dot-separated sourceEventName strings matching producers.
 const TEMPLATES: Partial<Record<NotificationSourceEventName, CopyTemplate>> = {
-  "reminder.fired": (payload) => ({
+  "schedule.notify": (payload) => ({
     title: "Reminder",
     body: str(payload.message, str(payload.label, "A reminder has fired")),
   }),

package/src/notifications/decision-engine.ts

@@ -293,7 +293,7 @@ function buildFallbackDecision(
     signal.attentionHints.urgency === "high" &&
     signal.attentionHints.requiresAction;
 
-  // Always include the vellum channel in the fallback — it's a local IPC
+  // Always include the vellum channel in the fallback — it's a local
   // broadcast with no cost, so desktop notifications should never be lost
   // when the LLM is unavailable. External channels (e.g. Telegram) are
   // only included for high-urgency actionable signals.
@@ -320,7 +320,7 @@ function buildFallbackDecision(
     selectedChannels,
     reasoningSummary: isHighUrgencyAction
       ? "Fallback: high urgency + requires action — all channels"
-      : "Fallback: vellum-only (local IPC, always delivered)",
+      : "Fallback: vellum-only (local, always delivered)",
     renderedCopy: copy,
     dedupeKey: `fallback:${signal.sourceEventName}:${signal.sourceSessionId}:${signal.createdAt}`,
     confidence: 0.3,

package/src/notifications/destination-resolver.ts

@@ -3,7 +3,7 @@
  *
  * Reads guardian delivery info from the contacts table.
  *
- * - Vellum: no external endpoint needed — delivery goes through the IPC
+ * - Vellum: no external endpoint needed — delivery goes through the event
  *   broadcast mechanism to connected desktop/mobile clients. The
  *   guardianPrincipalId is included in metadata so downstream adapters
  *   can scope guardian-sensitive notifications to bound guardian devices.
@@ -40,7 +40,7 @@ export function resolveDestinations(
     // guard, so we narrow with a switch over known deliverable values.
     switch (channel as NotificationChannel) {
       case "vellum": {
-        // Vellum delivery is local IPC — no external endpoint required.
+        // Vellum delivery is local — no external endpoint required.
         // Include the guardianPrincipalId so the adapter can annotate
         // guardian-sensitive notifications for scoped delivery.
         const guardianResult = findGuardianForChannel("vellum");

package/src/notifications/emit-signal.ts

@@ -49,9 +49,9 @@ let broadcasterInstance: NotificationBroadcaster | null = null;
 let registeredBroadcastFn: BroadcastFn | null = null;
 
 /**
- * Register the IPC broadcast function so the vellum adapter can deliver
- * notifications through the daemon's IPC socket. Must be called once
- * during daemon startup (before any signals are emitted).
+ * Register the broadcast function so the vellum adapter can deliver
+ * notifications to connected clients. Must be called once during
+ * daemon startup (before any signals are emitted).
  */
 export function registerBroadcastFn(fn: BroadcastFn): void {
   registeredBroadcastFn = fn;
@@ -69,7 +69,7 @@ function getBroadcaster(): NotificationBroadcaster {
 
     // Wire the thread-created callback so the macOS client is notified
     // immediately when a vellum notification thread is paired — before
-    // slower channel deliveries (e.g. Telegram) delay the IPC push.
+    // slower channel deliveries (e.g. Telegram) delay the push.
     if (registeredBroadcastFn) {
       const broadcastFn = registeredBroadcastFn;
       broadcasterInstance.setOnThreadCreated((info) => {
@@ -104,8 +104,8 @@ function getConnectedChannels(): NotificationChannel[] {
   for (const channel of getDeliverableChannels()) {
     switch (channel) {
       case "vellum":
-        // Vellum is always considered connected (IPC socket is always
-        // available when the daemon is running).
+        // Vellum is always considered connected (the local transport is
+        // always available when the daemon is running).
         channels.push(channel);
         break;
       case "telegram": {
@@ -144,7 +144,7 @@ function getConnectedChannels(): NotificationChannel[] {
 // ── Public API ─────────────────────────────────────────────────────────
 
 export interface EmitSignalParams<TEventName extends string = string> {
-  /** Free-form event name, e.g. 'reminder.fired', 'schedule.complete'. */
+  /** Free-form event name, e.g. 'schedule.notify', 'schedule.complete'. */
   sourceEventName: TEventName;
   /** Source channel that produced the event — must be a registered channel. */
   sourceChannel: NotificationSourceChannel;
@@ -320,7 +320,7 @@ export async function emitNotificationSignal<TEventName extends string>(
     }
 
     // Step 4: Dispatch through the broadcaster
-    // Note: notification_thread_created IPC events are emitted eagerly inside
+    // Note: notification_thread_created events are emitted eagerly inside
     // the broadcaster as soon as vellum conversation pairing succeeds, rather
     // than after all channel deliveries complete. This avoids a race where
     // slow Telegram delivery delays the push past the macOS deep-link retry.

package/src/notifications/signal.ts

@@ -37,7 +37,7 @@ export const NOTIFICATION_SOURCE_EVENT_NAMES = [
     id: "user.send_notification",
     description: "User-initiated notification via assistant tool",
   },
-  { id: "reminder.fired", description: "Scheduled reminder triggered" },
+  { id: "schedule.notify", description: "Scheduled notification triggered (one-shot or recurring)" },
   { id: "schedule.complete", description: "Scheduled task finished running" },
   {
     id: "guardian.question",

package/src/notifications/thread-seed-composer.ts

@@ -73,7 +73,7 @@ export function isThreadSeedSane(value: unknown): value is string {
 /**
  * Build a human-readable label from a dot-delimited event name.
  *
- * e.g. "reminder.fired" → "Reminder fired", "guardian.question" → "Guardian question"
+ * e.g. "schedule.notify" → "Schedule notify", "guardian.question" → "Guardian question"
  */
 function humanizeEventName(eventName: string): string {
   const words = eventName.replace(/[._]/g, " ").trim();

package/src/oauth/connect-orchestrator.ts

@@ -47,7 +47,7 @@ export interface OAuthConnectOptions {
   isInteractive: boolean;
   /** Open a URL in the user's browser (interactive path). */
   openUrl?: (url: string) => void;
-  /** Send a message to the client (e.g. open_url IPC). */
+  /** Send a message to the client (e.g. open_url). */
   sendToClient?: (msg: { type: string; [key: string]: unknown }) => void;
   /** Tools allowed to use the resulting credential. */
   allowedTools?: string[];

package/src/oauth/token-persistence.ts

@@ -37,7 +37,7 @@ export interface StoreOAuth2TokensParams {
   userinfoUrl?: string;
   allowedTools?: string[];
   wellKnownInjectionTemplates?: CredentialInjectionTemplate[];
-  /** Fallback account info from an identity verifier (e.g. Twitter @username). */
+  /** Fallback account info from an identity verifier (e.g. @username, email). */
   identityAccountInfo?: string;
 }
 

package/src/permissions/checker.ts

@@ -540,6 +540,17 @@ async function classifyRiskUncached(
   if (toolName === "network_request") return RiskLevel.Medium;
   if (toolName === "skill_load") return RiskLevel.Low;
 
+  // Skill mutation tools are always High risk — they write or delete persistent
+  // skill source code. These tools moved from core tool registry to bundled
+  // skills, but their security classification must remain High regardless of
+  // whether they appear in the tool registry.
+  if (
+    toolName === "scaffold_managed_skill" ||
+    toolName === "delete_managed_skill"
+  ) {
+    return RiskLevel.High;
+  }
+
   // Escalate host file mutations targeting skill source paths to High risk.
   // The host variants fall through to the tool registry (Medium) by default,
   // but writing to skill source code is a privilege-escalation vector.
@@ -576,7 +587,7 @@ async function classifyRiskUncached(
 
       if (prog === "rm") {
         // Only downgrade rm of known safe workspace files for sandboxed bash.
-        // host_bash has a global allow rule that would auto-approve Medium-risk
+        // host_bash has a global ask rule that would prompt Medium-risk
         // commands, so rm on the host must always require explicit approval.
         if (toolName === "bash" && isRmOfKnownSafeFile(seg.args)) {
           maxRisk = RiskLevel.Medium;

package/src/permissions/defaults.ts

@@ -21,8 +21,6 @@ const HOST_FILE_TOOLS = [
 ] as const;
 const COMPUTER_USE_TOOLS = [
   "computer_use_click",
-  "computer_use_double_click",
-  "computer_use_right_click",
   "computer_use_type_text",
   "computer_use_key",
   "computer_use_scroll",
@@ -209,6 +207,15 @@ export function getDefaultRuleTemplates(): DefaultRuleTemplate[] {
     priority: 100,
   };
 
+  const skillExecuteRule: DefaultRuleTemplate = {
+    id: "default:allow-skill_execute-global",
+    tool: "skill_execute",
+    pattern: "skill_execute:*",
+    scope: "everywhere",
+    decision: "allow",
+    priority: 100,
+  };
+
   // Browser tools were previously core-registered with RiskLevel.Low (auto-allowed).
   // After migration to skill-provided tools, default allow rules preserve the
   // same frictionless UX so they don't trigger permission prompts.
@@ -267,17 +274,6 @@ export function getDefaultRuleTemplates(): DefaultRuleTemplate[] {
     }),
   );
 
-  // view_image is a read-only sandbox tool — always allow without prompting.
-  // Candidates contain "/" (absolute paths), so use "/**" globstar.
-  const viewImageRule: DefaultRuleTemplate = {
-    id: "default:allow-view_image-global",
-    tool: "view_image",
-    pattern: "view_image:/**",
-    scope: "everywhere",
-    decision: "allow",
-    priority: 100,
-  };
-
   // memory_recall is a read-only tool — always allow without prompting.
   const memoryRecallRule: DefaultRuleTemplate = {
     id: "default:allow-memory_recall-global",
@@ -299,10 +295,10 @@ export function getDefaultRuleTemplates(): DefaultRuleTemplate[] {
     updatesDeleteRule,
     ...skillSourceMutationRules,
     skillLoadRule,
+    skillExecuteRule,
     browserNavigateRule,
     ...browserToolRules,
     ...uiSurfaceRules,
-    viewImageRule,
     memoryRecallRule,
   ];
 }

package/src/permissions/trust-store.ts

@@ -217,11 +217,48 @@ function backfillDefaults(rules: TrustRule[]): boolean {
   return changed;
 }
 
+function getLegacyTrustPath(): string {
+  return join(getRootDir(), "trust.json");
+}
+
 function loadFromDisk(): TrustRule[] {
   const path = getTrustPath();
   let rules: TrustRule[] = [];
   let needsSave = false;
 
+  // Migrate legacy trust file from root dir to protected subdir.
+  // Only migrate when the protected path does not yet exist.
+  if (!existsSync(path)) {
+    const legacyPath = getLegacyTrustPath();
+    if (existsSync(legacyPath)) {
+      try {
+        mkdirSync(dirname(path), { recursive: true });
+        renameSync(legacyPath, path);
+        chmodSync(path, 0o600);
+        log.info(
+          { from: legacyPath, to: path },
+          "Migrated legacy trust file to protected path",
+        );
+      } catch (err) {
+        log.warn(
+          { err },
+          "Failed to migrate legacy trust file; reading from legacy path",
+        );
+        // Fall back: copy content so the normal read path picks it up.
+        try {
+          const content = readFileSync(legacyPath, "utf-8");
+          mkdirSync(dirname(path), { recursive: true });
+          writeFileSync(path, content, { mode: 0o600 });
+        } catch (copyErr) {
+          log.warn(
+            { copyErr },
+            "Failed to copy legacy trust file to protected path",
+          );
+        }
+      }
+    }
+  }
+
   if (existsSync(path)) {
     try {
       const raw = readFileSync(path, "utf-8");

package/src/permissions/workspace-policy.ts

@@ -79,7 +79,6 @@ const HOST_TOOLS = new Set([
 /** Safe local-only tools that are always workspace-scoped. */
 const ALWAYS_SCOPED_TOOLS = new Set([
   "skill_load",
-  "view_image",
   "memory_recall",
   "ui_update",
   "ui_dismiss",

package/src/prompts/__tests__/build-cli-reference-section.test.ts

@@ -32,6 +32,17 @@ describe("buildCliReferenceSection", () => {
     expect(result).toContain("available via `bash`");
   });
 
+  test("routes account and auth work through documented assistant CLI commands", () => {
+    const result = buildCliReferenceSection();
+    expect(result).toContain(
+      "prefer real `assistant` CLI workflows over any legacy account-record abstraction",
+    );
+    expect(result).toContain("assistant credentials");
+    expect(result).toContain("assistant oauth token <service>");
+    expect(result).toContain("assistant mcp auth <name>");
+    expect(result).toContain("assistant platform status");
+  });
+
   test("result is cached — calling twice returns the same string", () => {
     const first = buildCliReferenceSection();
     const second = buildCliReferenceSection();

package/src/prompts/computer-use-prompt.ts

@@ -36,7 +36,7 @@ Before every action, ask yourself: "Can I do this with AppleScript or a direct r
 
 You will receive the current screen state as an accessibility tree. Each interactive element has an [ID] number like [3] or [17]. Use these IDs with element_id to target elements \u2014 this is much more reliable than pixel coordinates.
 
-YOUR AVAILABLE TOOLS ARE: computer_use_click, computer_use_double_click, computer_use_right_click, computer_use_type_text, computer_use_key, computer_use_scroll, computer_use_drag, computer_use_wait, computer_use_open_app, computer_use_run_applescript, computer_use_done, computer_use_respond, ui_show, ui_update, ui_dismiss.
+YOUR AVAILABLE TOOLS ARE: computer_use_click (with click_type: "single" | "double" | "right"), computer_use_type_text, computer_use_key, computer_use_scroll, computer_use_drag, computer_use_wait, computer_use_open_app, computer_use_run_applescript, computer_use_done, computer_use_respond, ui_show, ui_update, ui_dismiss.
 You MUST only call one tool per turn.
 
 UI SURFACES: When the user asks you to build, create, or display something (an app, dashboard, tracker, etc.), use ui_show with surface_type "dynamic_page" to render custom HTML directly instead of trying to build it with computer-use tools. This is your primary way to create visual applications for the user. After calling ui_show, call computer_use_done immediately — the surface is already displayed to the user.