@vellumai/assistant 0.3.13 → 0.3.15

package/src/__tests__/reminder-store.test.ts

@@ -51,22 +51,6 @@ describe('reminder-store', () => {
     expect(r.updatedAt).toBeGreaterThan(0);
   });
 
-  test('insertReminder defaults routingIntent to single_channel when omitted', () => {
-    const r = insertReminder({
-      label: 'No routing',
-      message: 'Should default',
-      fireAt: Date.now() + 60_000,
-      mode: 'notify',
-    });
-
-    expect(r.routingIntent).toBe('single_channel');
-    expect(r.routingHints).toEqual({});
-
-    const fetched = getReminder(r.id);
-    expect(fetched!.routingIntent).toBe('single_channel');
-    expect(fetched!.routingHints).toEqual({});
-  });
-
   test('insertReminder persists routing metadata', () => {
     const r = insertReminder({
       label: 'Multi-channel',
@@ -85,6 +69,22 @@ describe('reminder-store', () => {
     expect(fetched!.routingHints).toEqual({ preferred: ['telegram', 'sms'] });
   });
 
+  test('insertReminder defaults routingIntent to single_channel when omitted', () => {
+    const r = insertReminder({
+      label: 'No routing',
+      message: 'Should default',
+      fireAt: Date.now() + 60_000,
+      mode: 'notify',
+    });
+
+    expect(r.routingIntent).toBe('single_channel');
+    expect(r.routingHints).toEqual({});
+
+    const fetched = getReminder(r.id);
+    expect(fetched!.routingIntent).toBe('single_channel');
+    expect(fetched!.routingHints).toEqual({});
+  });
+
   // ── getReminder ─────────────────────────────────────────────────────
 
   test('getReminder returns null for nonexistent ID', () => {
@@ -157,9 +157,9 @@ describe('reminder-store', () => {
 
   // ── claimDueReminders ──────────────────────────────────────────────
 
-  test('claimDueReminders claims reminders where fireAt <= now', () => {
+  test('claimDueReminders claims reminders where fireAt <= now and preserves routing', () => {
     const now = Date.now();
-    insertReminder({ label: 'Past', message: 'x', fireAt: now - 5000, mode: 'notify' });
+    insertReminder({ label: 'Past', message: 'x', fireAt: now - 5000, mode: 'notify', routingIntent: 'all_channels', routingHints: { foo: 'bar' } });
     insertReminder({ label: 'Future', message: 'y', fireAt: now + 60_000, mode: 'notify' });
 
     const claimed = claimDueReminders(now);
@@ -167,6 +167,8 @@ describe('reminder-store', () => {
     expect(claimed[0].label).toBe('Past');
     expect(claimed[0].status).toBe('firing');
     expect(claimed[0].firedAt).toBe(now);
+    expect(claimed[0].routingIntent).toBe('all_channels');
+    expect(claimed[0].routingHints).toEqual({ foo: 'bar' });
   });
 
   test('claimDueReminders skips already-fired reminders', () => {

package/src/__tests__/reminder.test.ts

@@ -246,13 +246,14 @@ describe('reminder tool', () => {
       fire_at: future,
       label: 'Test reminder',
       message: 'Test message',
+      routing_intent: 'all_channels',
     });
 
     const result = executeReminderList();
     expect(result.isError).toBe(false);
     expect(result.content).toContain('Test reminder');
     expect(result.content).toContain('pending');
-    expect(result.content).toContain('routing: single_channel');
+    expect(result.content).toContain('routing: all_channels');
   });
 
   // ── cancel ──────────────────────────────────────────────────────────

package/src/channels/config.ts

@@ -35,7 +35,7 @@ const CHANNEL_POLICIES = {
   },
   sms: {
     notification: {
-      deliveryEnabled: false,
+      deliveryEnabled: true,
       conversationStrategy: 'continue_existing_conversation',
     },
   },

package/src/config/bundled-skills/phone-calls/SKILL.md

@@ -364,17 +364,7 @@ No additional configuration is needed beyond the standard Twilio setup (Steps 1-
 
 ### Guardian voice verification for inbound calls
 
-To link the user's phone number as the trusted voice guardian, install and load the **guardian-verify-setup** skill. This skill handles the full outbound verification flow:
-
-- Call `vellum_skills_catalog` with `action: "install"` and `skill_id: "guardian-verify-setup"`.
-- Then call `skill_load` with `skill: "guardian-verify-setup"`.
-
-When invoked for the `voice` channel, the guardian-verify-setup skill:
-1. Collects the user's phone number as the destination
-2. Starts an outbound verification session via `POST /v1/integrations/guardian/outbound/start` with `channel: "voice"`
-3. The API initiates a phone call to the user's number. The response includes a `secret` field with the verification code -- the code is shared with the user BEFORE the call connects so they know what to enter
-4. When the user answers, they enter the verification code via their phone's keypad (DTMF)
-5. If the code matches, a guardian binding is created for the voice channel
+For guardian verification setup, first install the skill via `vellum_skills_catalog` with `action: "install"` and `skill_id: "guardian-verify-setup"`, then load it with `skill_load` using `skill: "guardian-verify-setup"`. This skill handles the full outbound verification flow; `phone-calls` does not orchestrate it inline.
 
 Once a guardian binding exists for the voice channel, inbound callers may be prompted for verification before calls proceed. The relay server detects pending challenges and prompts callers: "Please enter your six-digit verification code using your keypad, or speak the digits now." If verification fails after 3 attempts, the call ends with "Verification failed. Goodbye."
 

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

@@ -26,35 +26,114 @@ This skill activates when the user asks to record their screen. Common phrases:
 - "finish recording"
 - "halt recording"
 
-## Classification
+**Restart recording:**
+- "restart recording"
+- "redo the recording"
+- "stop recording and start a new one"
+- "stop recording and start a new recording"
+- "stop and restart the recording"
 
-Recording prompts are classified into four intent types:
+**Pause recording:**
+- "pause recording"
+- "pause the recording"
 
-- **start_only** — Pure recording request with no additional task (e.g., "record my screen"). Handled by standalone recording route.
-- **stop_only** — Pure stop request with no additional task (e.g., "stop recording"). Handled by standalone recording route.
-- **mixed** — Recording intent embedded in a broader task (e.g., "open Safari and record my screen"). Not intercepted; routed to normal processing.
-- **none** — No recording intent detected. Normal routing.
+**Resume recording:**
+- "resume recording"
+- "unpause the recording"
+
+## Intent Classification
+
+Recording prompts are classified by `resolveRecordingIntent` into one of 11 intent kinds:
+
+### Pure commands (handled by the standalone recording route)
+
+- **`start_only`** — Pure start request with no additional task (e.g., "record my screen").
+- **`stop_only`** — Pure stop request (e.g., "stop recording").
+- **`restart_only`** — Pure restart request (e.g., "restart recording", "stop recording and start a new one").
+- **`pause_only`** — Pure pause request (e.g., "pause the recording").
+- **`resume_only`** — Pure resume request (e.g., "resume the recording").
+
+### Recording + additional task (recording action is deferred and executed alongside the task)
+
+- **`start_with_remainder`** — Start recording embedded in a broader task. The recording clause is stripped, and the remainder is processed as a separate task. Example: "open Safari and record my screen" produces remainder "open Safari".
+- **`stop_with_remainder`** — Stop recording embedded in a broader task. Example: "close the browser and stop recording" produces remainder "close the browser".
+- **`restart_with_remainder`** — Restart recording embedded in a broader task. Example: "restart recording and open Safari" produces remainder "open Safari".
+
+### Both start and stop detected
+
+- **`start_and_stop_only`** — Both start and stop patterns present with no additional task (e.g., "stop recording and record my screen").
+- **`start_and_stop_with_remainder`** — Both start and stop patterns present alongside additional task text.
+
+### No recording intent
+
+- **`none`** — No recording intent detected. Normal routing.
 
 Dynamic name prefixes (from IDENTITY.md) are stripped during classification, so "Nova, record my screen" classifies the same as "record my screen".
 
 ## Routing
 
-Recording-only requests are handled by the **standalone recording route** — they do NOT create a computer-use session.
+Recording intent resolution follows a precedence chain:
+
+### 1. `commandIntent` (structured IPC) — highest priority
+
+The macOS client can send structured intents with `domain: 'screen_recording'` and `action: 'start' | 'stop' | 'restart' | 'pause' | 'resume'`. These bypass text parsing entirely. The daemon checks for `commandIntent` before any text analysis.
+
+### 2. Deterministic text resolver (`resolveRecordingIntent`)
+
+A regex-based pipeline that classifies the user's text. The pipeline:
+1. Strips dynamic assistant names (leading vocative like "Nova, ...")
+2. Strips leading polite wrappers ("please", "can you", etc.)
+3. Applies the interrogative guard — WH-questions return `none`
+4. Checks restart compound patterns (before independent start/stop, so "stop recording and start a new one" is recognized as restart)
+5. Checks pause/resume patterns
+6. Checks start and stop patterns independently
+7. Determines if the intent is pure or has a remainder by stripping recording clauses and checking for substantive remaining content
+
+### 3. Normal processing
+
+If no recording intent is detected (kind is `none`), the message flows to the classifier and computer-use session as usual.
+
+## Interrogative Guard
+
+Questions about recording are NOT treated as commands. The resolver filters out WH-questions to prevent side effects from informational queries.
+
+**Filtered (no recording action triggered):**
+- "how do I stop recording?"
+- "what does screen recording do?"
+- "why is the recording paused?"
+- "when should I stop recording?"
+
+**Preserved as commands (recording action IS triggered):**
+- "can you stop recording?" — polite imperative
+- "could you record my screen?" — polite imperative
+- "please stop recording" — direct command with filler
+
+The guard checks for WH-question starters (how, what, why, when, where, who, which) at the beginning of the text, after stripping dynamic names and polite prefixes.
+
+## Mixed-Intent Examples
+
+When a recording intent is combined with another task, the recording clause is stripped from the text, and both parts are handled:
+
+- **"open Safari and record my screen"** — `start_with_remainder` with remainder "open Safari". Recording starts alongside the Safari task.
+- **"stop recording and start a new one and open Safari"** — `restart_with_remainder` with remainder "open Safari". Restart executes and the remainder is processed separately.
+- **"close the browser and stop recording"** — `stop_with_remainder` with remainder "close the browser". Stop executes and the remainder is processed.
 
-- When the user says "record my screen" (with no other task), the daemon intercepts this and starts a standalone recording directly.
-- When the user says "stop recording", the daemon intercepts and stops the active recording for the current conversation.
-- The recording is saved as a video file and attached to the conversation thread.
+The remainder preserves the user's original phrasing (stripping is applied to the original text, not the normalized form).
 
 ## Behavior Rules
 
 1. **Do not invoke computer use** for recording-only requests. The daemon handles these directly.
 2. **One recording at a time.** If a recording is already active, starting another returns an "already recording" message.
-3. **Conversation-scoped.** Each recording is linked to the conversation that started it. Stopping in a different thread does not affect unrelated recordings.
+3. **Conversation-linked.** Each recording is linked to the conversation that started it for attachment purposes. However, since only one recording can be active at a time, stop commands from any conversation will stop the active recording regardless of which conversation started it.
 4. **Permission required.** Screen recording requires macOS Screen Recording permission. If denied, the user sees actionable guidance to enable it in System Settings.
-5. **Mixed-intent prompts** (recording + other task) are NOT intercepted by the standalone route.
+5. **Mixed-intent prompts** (recording + other task) are NOT intercepted by the standalone route — the recording action is deferred and executed alongside the task.
+6. **Restart always reopens the source picker** and requires source reselection.
+7. **Restart cancel** (user closes the source picker) leaves state idle — no false "recording started" message.
+8. **Pause/resume toggle the recording** without stopping it. The HUD shows paused state.
 
 ## What This Skill Does NOT Do
 
 - This skill does not contain recorder logic — the `RecordingManager` and `ScreenRecorder` in the macOS app handle the actual recording.
 - This skill does not provide shell commands or scripts for recording.
 - This skill does not fall back to computer use for recording tasks.
+- This skill does not handle informational questions about recording — those flow through to normal AI response.

package/src/config/system-prompt.ts

@@ -209,6 +209,11 @@ export function buildGuardianVerificationRoutingSection(): string {
     '4. Guide the user through code entry, resend, or cancel',
     '',
     'Load with: `skill_load` using `skill: "guardian-verify-setup"`',
+    '',
+    '### Exclusivity rules',
+    '- Guardian verification intents must only be handled by `guardian-verify-setup` — load it exclusively.',
+    '- Do NOT load `phone-calls` for guardian verification intent routing. The phone-calls skill does not orchestrate verification flows.',
+    '- If the user has already explicitly specified a channel (e.g., "verify my phone for SMS", "verify my Telegram"), do not re-ask which channel unless the input is contradictory. Note: "verify my phone number" alone is ambiguous (phone numbers apply to both sms and voice) — ask which channel.',
   ].join('\n');
 }
 

package/src/config/vellum-skills/guardian-verify-setup/SKILL.md

@@ -133,3 +133,4 @@ If not yet bound, offer to resend (Step 4) or generate a new session (Step 3).
 - The resend cooldown is 15 seconds between sends, with a maximum of 5 sends per session.
 - Per-destination rate limiting allows up to 10 sends within a 1-hour rolling window.
 - Guardian verification is identity-bound: the code can only be consumed by the identity matching the destination provided at start time.
+- **Missing `secret` guardrail**: For voice and Telegram chat-ID flows, the API response MUST include a `secret` field. If `secret` is unexpectedly absent from a start or resend response that otherwise indicates success, treat this as a control-plane error. Do NOT fabricate a code or tell the user to proceed without one. Instead, tell the user something went wrong and ask them to retry the start (Step 3) or resend (Step 4).

package/src/daemon/handlers/config-channels.ts

@@ -1,22 +1,22 @@
 import * as net from 'node:net';
 
+import type { ChannelId } from '../../channels/types.js';
 import * as externalConversationStore from '../../memory/external-conversation-store.js';
 import {
   createVerificationChallenge,
+  findActiveSession,
   getGuardianBinding,
   getPendingChallenge,
   revokeBinding as revokeGuardianBinding,
   revokePendingChallenges,
-  findActiveSession,
 } from '../../runtime/channel-guardian-service.js';
 import { type ChannelReadinessService, createReadinessService } from '../../runtime/channel-readiness-service.js';
 import {
-  startOutbound,
-  resendOutbound,
   cancelOutbound,
+  resendOutbound,
+  startOutbound,
 } from '../../runtime/guardian-outbound-actions.js';
 import { normalizeAssistantId } from '../../util/platform.js';
-import type { ChannelId } from '../../channels/types.js';
 import type {
   ChannelReadinessRequest,
   GuardianVerificationRequest,
@@ -34,10 +34,10 @@ export type GuardianVerificationResult = Omit<GuardianVerificationResponse, 'typ
 // ---------------------------------------------------------------------------
 
 export {
+  DESTINATION_RATE_WINDOW_MS,
+  MAX_SENDS_PER_DESTINATION_WINDOW,
   MAX_SENDS_PER_SESSION,
   RESEND_COOLDOWN_MS,
-  MAX_SENDS_PER_DESTINATION_WINDOW,
-  DESTINATION_RATE_WINDOW_MS,
 } from '../../runtime/guardian-outbound-actions.js';
 
 // ---------------------------------------------------------------------------

package/src/daemon/handlers/index.ts

@@ -1,6 +1,6 @@
 import * as net from 'node:net';
 
-import { recordConversationSeenSignal, type Confidence, type SignalType } from '../../memory/conversation-attention-store.js';
+import { type Confidence, recordConversationSeenSignal, type SignalType } from '../../memory/conversation-attention-store.js';
 import { updateDeliveryClientOutcome } from '../../notifications/deliveries-store.js';
 import type { ClientMessage } from '../ipc-protocol.js';
 import { handleRideShotgunStart, handleRideShotgunStop } from '../ride-shotgun-handler.js';