@vellumai/assistant 0.11.10 → 0.11.11-staging.1

package/src/notifications/decision-engine.ts

@@ -86,6 +86,20 @@ const ASSISTANT_REPLY_CHANNELS = [
   "platform",
 ] as const satisfies readonly NotificationChannel[];
 
+/**
+ * Delivery scope for `schedule.result` signals. Wider than
+ * {@link ASSISTANT_REPLY_CHANNELS} by one channel, and the difference is the
+ * point: an unseen chat reply is already sitting in a conversation the user
+ * opened, so a push is the only thing it can add. A scheduled run's output has
+ * no such home — nobody is looking at the run's conversation — so `vellum`
+ * carries it into the notification center where it persists, and `platform`
+ * pushes it.
+ */
+const SCHEDULE_RESULT_CHANNELS = [
+  "vellum",
+  "platform",
+] as const satisfies readonly NotificationChannel[];
+
 // ── System prompt ──────────────────────────────────────────────────────
 
 function buildSystemPrompt(
@@ -224,23 +238,28 @@ function buildUserPrompt(signal: NotificationSignal): string {
 // ── Tool definition ────────────────────────────────────────────────────
 
 /**
- * Spec for the per-channel notification title. Mirrors the conversation title
- * prompt (`persistence/conversation-title-service.ts`), which gets clean
- * noun-phrase headlines out of this same model profile.
+ * Spec for the per-channel notification title. The title is the one line a
+ * reader sees in the notification bell, where a row that only reports shows
+ * nothing else, so it has to say what happened on its own rather than name a
+ * topic the body then explains. Same length discipline as the conversation
+ * title prompt (`persistence/conversation-title-service.ts`), which shares
+ * this model profile and the `normalizeTitle` clamp.
  */
 const TITLE_FIELD_DESCRIPTION = [
-  "Scannable headline naming the TOPIC of this notification, not a summary of it.",
+  "Scannable headline saying WHAT HAPPENED or WHAT IS NEEDED, so it stands on its own without the body.",
   "Rules:",
-  "- 2 to 5 words. Longer titles are unacceptable, ruthlessly compress",
+  "- 2 to 6 words. Longer titles are unacceptable, ruthlessly compress",
   "- 40 characters absolute maximum, longer titles get truncated and look broken",
-  "- A noun phrase naming the topic, never a sentence, question, or greeting (e.g. 'Platform Standup', 'Nightly Backup Failure')",
-  "- Do NOT restate, summarize, or echo the body. The title and the body must carry different information",
+  "- Lead with the outcome as a short clause: a past-tense verb for something done ('Prepared a wedding schedule', 'Nightly backup failed'), a need for something waiting on the reader ('Needs an answer on the venue')",
+  "- Sentence case, never Title Case",
+  "- Do NOT restate the body word for word. The body adds the detail the title leaves out: numbers, names, what to do next",
   "- No quotes, no markdown, no trailing punctuation",
-  "- Never describe missing or thin context. Titles like 'Notification', 'Update', 'Missing Context' are forbidden. Extract a topic from the words that ARE present",
+  "- Never describe missing or thin context. Titles like 'Notification', 'Update', 'Activity complete', 'Missing context' are forbidden. Say what was done from the words that ARE present",
   "Examples:",
-  "- Body 'Your 9am standup with the platform team starts in 5 minutes' -> 'Platform Standup', NOT 'Standup Starts In 5 Minutes'",
-  "- Body 'The nightly backup job failed on db-primary at 02:14' -> 'Nightly Backup Failure', NOT 'Nightly Backup Job Failed On db-primary'",
-  "- Body 'Alice replied about the Q3 pricing deck and wants your notes' -> 'Q3 Pricing Deck', NOT 'Alice Replied About The Pricing Deck'",
+  "- Body 'Your 9am standup with the platform team starts in 5 minutes' -> 'Platform standup in 5 minutes', NOT 'Platform Standup'",
+  "- Body 'The nightly backup job failed on db-primary at 02:14' -> 'Nightly backup failed', NOT 'Nightly Backup Failure'",
+  "- Body 'Alice replied about the Q3 pricing deck and wants your notes' -> 'Alice wants notes on the Q3 deck', NOT 'Q3 Pricing Deck'",
+  "- Body 'Recapped the 12 emails that needed a reply and deleted 6 newsletters' -> 'Recapped 12 emails, deleted 6', NOT 'Inbox Recap'",
 ].join("\n");
 
 function buildDecisionTool(availableChannels: NotificationChannel[]) {
@@ -907,6 +926,24 @@ export async function evaluateSignal(
     });
   }
 
+  // Schedule-result pass-through: the body is the run's own reply, which is
+  // the whole point of the notification — a briefing, a digest, a report. The
+  // classifier rewrites bodies into short alerts, which would throw away the
+  // content the user set the schedule up to receive. Routing has nothing to
+  // decide either: the user asked for this cadence, so it goes to the inbox
+  // and to push, and `enforceRoutingIntent` still narrows it afterwards.
+  if (signal.sourceEventName === "schedule.result" && requestedBody) {
+    return buildPassThroughDecision({
+      signal,
+      availableChannels,
+      selectedChannels: SCHEDULE_RESULT_CHANNELS.filter((ch) =>
+        availableChannels.includes(ch),
+      ),
+      body: requestedBody,
+      reasoningSummary: "schedule_result pass-through",
+    });
+  }
+
   // When no explicit preference context is provided, load the user's
   // stored notification preferences from the memory-backed store.
   // Wrapped in try/catch so a DB failure doesn't break the decision path.

package/src/notifications/events-store.ts

@@ -6,10 +6,14 @@
  * and context payload. Decision/delivery records are tracked separately.
  */
 
-import { and, desc, eq } from "drizzle-orm";
+import { and, desc, eq, gte, inArray, or } from "drizzle-orm";
 
 import { getDb } from "../persistence/db-connection.js";
-import { notificationEvents } from "../persistence/schema/index.js";
+import {
+  notificationDecisions,
+  notificationDeliveries,
+  notificationEvents,
+} from "../persistence/schema/index.js";
 import type { AttentionHints } from "./signal.js";
 
 export interface NotificationEventRow {
@@ -138,3 +142,65 @@ export function listEvents(
 
   return rows.map(rowToEvent);
 }
+
+/**
+ * True when a notification emitted against `sourceContextId` at or after
+ * `sinceMs` reached a verdict the user can be said to have received.
+ *
+ * The schedule-result producer's "did this run already speak for itself?"
+ * probe. A run's conversation id is the `sourceContextId` every notification
+ * the run emits carries — `assistant notifications send` resolves it from
+ * `__CONVERSATION_ID` — so a hit means the agent notified on its own and the
+ * fallback must stay quiet.
+ *
+ * An event row alone is not a hit. `emitNotificationSignal` persists the event
+ * first and the pipeline can still fail after that, leaving an audit row for a
+ * notification nobody received; counting it would suppress the fallback in
+ * exactly the case it exists for. A hit therefore needs one of:
+ *
+ * - a decision **not** to notify. The engine ruled on the run's own signal
+ *   (preferences, quiet hours, its own judgment), and the fallback exists to
+ *   cover runs that never asked, not to appeal verdicts the user's settings
+ *   produced; or
+ * - a delivery row that is `sent` or still `pending` — something went out, or
+ *   is about to. An event whose every delivery `failed`, or that never got a
+ *   decision row at all, does not count.
+ *
+ * The `sinceMs` bound is load-bearing rather than an optimization: a recurring
+ * schedule with `reuseConversation` runs every firing in the same conversation,
+ * so an unbounded probe would see last week's notification and silence every
+ * run after the first.
+ */
+export function hasNotifiedSourceContextSince(
+  sourceContextId: string,
+  sinceMs: number,
+): boolean {
+  const db = getDb();
+  const row = db
+    .select({ id: notificationEvents.id })
+    .from(notificationEvents)
+    .innerJoin(
+      notificationDecisions,
+      eq(notificationDecisions.notificationEventId, notificationEvents.id),
+    )
+    .leftJoin(
+      notificationDeliveries,
+      eq(
+        notificationDeliveries.notificationDecisionId,
+        notificationDecisions.id,
+      ),
+    )
+    .where(
+      and(
+        eq(notificationEvents.sourceContextId, sourceContextId),
+        gte(notificationEvents.createdAt, sinceMs),
+        or(
+          eq(notificationDecisions.shouldNotify, 0),
+          inArray(notificationDeliveries.status, ["pending", "sent"]),
+        ),
+      ),
+    )
+    .limit(1)
+    .get();
+  return row !== undefined;
+}

package/src/notifications/home-feed-side-effect.ts

@@ -194,7 +194,7 @@ export async function writeHomeFeedItemForSignal(
     timestamp: now,
     createdAt: now,
     status: "new",
-    category,
+    ...(category ? { category } : {}),
     noteworthy: deriveNoteworthy(signal),
     fromAssistant: signal.sourceChannel === "assistant_tool",
     ...(guardianProjection ? { guardianRequest: guardianProjection } : {}),
@@ -442,14 +442,26 @@ const EVENT_CATEGORY_MAP: Record<string, FeedItemCategory> = {
   "activity.complete": "background",
   "watcher.notification": "system",
   "schedule.notify": "scheduling",
+  "schedule.result": "scheduling",
   "guardian.question": "security",
   "guardian.channel_activation": "security",
   "ingress.access_request": "security",
   "telegram.webhook_health_alert": "system",
 };
 
-function deriveCategory(signal: NotificationSignal): FeedItemCategory {
-  return EVENT_CATEGORY_MAP[signal.sourceEventName] ?? "system";
+/**
+ * Map a signal's source event to a feed category, or nothing when the event
+ * has no entry. An unmapped event used to land in `system`, a bucket named
+ * for our architecture rather than the user's world, and every deliberate
+ * assistant notification (`user.send_notification`) ended up there. The
+ * category is optional on the wire, so an event without a home simply
+ * carries none: readers that filter by category skip it, and nothing has
+ * to guess.
+ */
+function deriveCategory(
+  signal: NotificationSignal,
+): FeedItemCategory | undefined {
+  return EVENT_CATEGORY_MAP[signal.sourceEventName];
 }
 
 function deriveDetailPanelKind(

package/src/notifications/schedule-result-producer.ts

@@ -0,0 +1,275 @@
+/**
+ * `schedule.result` producer: the notification a scheduled run owes the user
+ * when it produced output and never spoke up on its own.
+ *
+ * Every other conversation kind already has a producer that answers for it
+ * (see the kind switch in `assistant-reply-producer.ts`). Scheduled runs were
+ * the exception: their "producer" was the model remembering to call
+ * `assistant notifications send`, decided per run against free-form prompt
+ * text and the notifications skill's "only when something notable happened"
+ * guidance. A daily briefing could therefore run, spend money, write a reply
+ * into a conversation nobody has open, and leave no trace the user ever sees.
+ *
+ * This closes that hole from the other end. It does not re-judge whether the
+ * output was notable — that judgment is the bug. It asks two mechanical
+ * questions: did this run say anything, and has the user been told? A run that
+ * notified itself is left alone, so a well-authored schedule sees no change
+ * and no duplicate.
+ *
+ * Deliberately scoped to execute-mode schedule runs. Heartbeats, watchers, and
+ * background jobs stay strict — their firing is the assistant's idea, so
+ * silence is the correct default. A schedule's firing is the user's idea, on a
+ * cadence they chose, which is what earns its output a notification.
+ *
+ * Best-effort throughout, like every producer here: a notification failure
+ * must never turn a schedule run that succeeded into one recorded as failed.
+ */
+
+import type pino from "pino";
+
+import { isAssistantFeatureFlagEnabled } from "../config/assistant-feature-flags.js";
+import { getAttentionStateByConversationIds } from "../persistence/conversation-attention-store.js";
+import {
+  getAssistantMessageIdsInTurn,
+  getMessageById,
+  type MessageRow,
+} from "../persistence/conversation-crud.js";
+import { stringifyMessageContent } from "../persistence/message-content.js";
+import type { ContentBlock } from "../providers/types.js";
+import { emitNotificationSignal } from "./emit-signal.js";
+import { hasNotifiedSourceContextSince } from "./events-store.js";
+import {
+  sanitizeNotificationTitle,
+  stripMarkdownForPreview,
+  truncate,
+} from "./notification-utils.js";
+
+/** Kill switch for this producer, on by default. */
+const SCHEDULE_RESULT_NOTIFY_FLAG = "schedule-result-notify" as const;
+
+/**
+ * Body cap. Far above `MESSAGE_PREVIEW_MAX_LENGTH` (200) on purpose: this body
+ * is the deliverable, not a preview of one, and the home feed's detail panel
+ * renders it as markdown. A lock-screen banner truncates on its own, so the
+ * cap exists only to keep a runaway reply out of the payload.
+ */
+const MAX_RESULT_BODY_CHARS = 2000;
+
+export interface ScheduleResultNotificationParams {
+  /** `cron_jobs.id` of the schedule that fired. */
+  scheduleId: string;
+  /** The schedule's user-authored name; becomes the notification title. */
+  scheduleName: string;
+  /** Conversation the run executed in. */
+  conversationId: string;
+  /** `cron_runs.id` for this firing — scopes the dedupe key to one run. */
+  runId: string;
+  /**
+   * When the run started, in epoch ms. The lower bound on the "did this run
+   * already notify?" probe, and the reason a reused conversation's earlier
+   * runs cannot silence this one.
+   */
+  runStartedAt: number;
+  rlog: pino.Logger;
+}
+
+/**
+ * Whether a tool call in the run's turn delivered the result somewhere the
+ * user will see it, outside the notification pipeline.
+ *
+ * The schedule skill prescribes two such routes for rich content — the
+ * messaging tool for email, and the Slack Web API's `chat.postMessage` through
+ * bash — and neither writes a `notification_events` row, so the pipeline probe
+ * cannot see them. Without this check a well-authored Slack digest would post
+ * its summary and then get a second notification whose body is "Posted the
+ * digest to #general." This is a recognized-routes list, not a general "did
+ * the run do anything?" heuristic: a route that is not here gets the fallback,
+ * which is the safe failure.
+ */
+function isDirectDelivery(block: ContentBlock): boolean {
+  if (block.type !== "tool_use") {
+    return false;
+  }
+  if (block.name === "messaging_send") {
+    return true;
+  }
+  if (block.name === "bash") {
+    const command = (block.input as { command?: unknown } | undefined)?.command;
+    return typeof command === "string" && command.includes("chat.postMessage");
+  }
+  return false;
+}
+
+/**
+ * The assistant rows this run wrote, in order, ending on `latestRow`.
+ *
+ * A run is one agent turn: `getAssistantMessageIdsInTurn` walks the tool-call
+ * loop back to the user message that opened it. Rows from before the run
+ * started are dropped defensively — a reused conversation's earlier turns must
+ * never be mistaken for this one.
+ */
+function collectRunRows(
+  latestRow: MessageRow,
+  conversationId: string,
+  runStartedAt: number,
+): MessageRow[] {
+  const rows: MessageRow[] = [];
+  for (const id of getAssistantMessageIdsInTurn(latestRow.id)) {
+    const row =
+      id === latestRow.id ? latestRow : getMessageById(id, conversationId);
+    if (row && row.createdAt >= runStartedAt) {
+      rows.push(row);
+    }
+  }
+  return rows;
+}
+
+/**
+ * Whether the run left the user anything worth reading, and what.
+ *
+ * Substance is judged mechanically: markdown is flattened and whitespace
+ * collapsed, and whatever survives is the answer. A run that ended on tool
+ * calls with no closing prose flattens to nothing and stays silent — the
+ * "nothing to say" case. Anything else counts, including a briefing whose
+ * honest finding is that nothing changed; the user asked for that cadence, and
+ * "no new mail today" is a result, not noise.
+ *
+ * The returned body keeps its original markdown — only the emptiness test runs
+ * on the flattened form, because the detail panel renders the real thing.
+ */
+function resolveRunOutput(latestRow: MessageRow): string | undefined {
+  const text = stringifyMessageContent(latestRow.content);
+  const flattened = stripMarkdownForPreview(text).replace(/\s+/g, " ").trim();
+  if (!flattened) {
+    return undefined;
+  }
+  return truncate(text.trim(), MAX_RESULT_BODY_CHARS);
+}
+
+/**
+ * The run's final assistant row, or nothing if the run wrote none.
+ *
+ * `latestAssistantMessageId` is per conversation, not per run, so a reused
+ * conversation whose current run wrote no reply would otherwise hand back the
+ * previous run's — and the fallback would re-send yesterday's briefing.
+ */
+function resolveLatestRunRow(
+  conversationId: string,
+  runStartedAt: number,
+): MessageRow | undefined {
+  const attention = getAttentionStateByConversationIds([conversationId]).get(
+    conversationId,
+  );
+  const assistantMessageId = attention?.latestAssistantMessageId;
+  if (!assistantMessageId) {
+    return undefined;
+  }
+  const row = getMessageById(assistantMessageId, conversationId);
+  if (!row || row.createdAt < runStartedAt) {
+    return undefined;
+  }
+  return row;
+}
+
+/**
+ * Emit the fallback notification for a schedule run that finished without
+ * notifying. No-ops when the flag is off, when the run already notified, or
+ * when the run produced no user-facing text.
+ */
+export async function emitScheduleResultNotification(
+  params: ScheduleResultNotificationParams,
+): Promise<void> {
+  const {
+    scheduleId,
+    scheduleName,
+    conversationId,
+    runId,
+    runStartedAt,
+    rlog,
+  } = params;
+  try {
+    if (!isAssistantFeatureFlagEnabled(SCHEDULE_RESULT_NOTIFY_FLAG)) {
+      return;
+    }
+    // A bootstrap failure hands back a sentinel rather than a real id; there
+    // is no conversation to read and nothing to say about it.
+    if (!conversationId || conversationId.startsWith("bootstrap-error:")) {
+      return;
+    }
+
+    // The run spoke for itself — an explicit `assistant notifications send`,
+    // or any other signal the turn emitted against this conversation, that
+    // reached a verdict or a channel. Leaving it alone is what keeps a
+    // well-authored schedule from notifying twice.
+    if (hasNotifiedSourceContextSince(conversationId, runStartedAt)) {
+      return;
+    }
+
+    const latestRow = resolveLatestRunRow(conversationId, runStartedAt);
+    if (!latestRow) {
+      return;
+    }
+
+    // The run delivered around the pipeline — an email through the messaging
+    // tool, a Slack post through the Web API. The user has the result; a
+    // notification reading "posted it" on top would be the duplicate.
+    const runRows = collectRunRows(latestRow, conversationId, runStartedAt);
+    if (runRows.some((row) => row.content.some(isDirectDelivery))) {
+      return;
+    }
+
+    const body = resolveRunOutput(latestRow);
+    if (!body) {
+      return;
+    }
+
+    // Schedule names are user-authored and unbounded, so the title gets the
+    // same clamp as any other string headed for a lock screen.
+    const requestedTitle = sanitizeNotificationTitle(
+      scheduleName.replace(/\s+/g, " ").trim(),
+    );
+
+    await emitNotificationSignal({
+      sourceEventName: "schedule.result",
+      sourceChannel: "scheduler",
+      // The run's conversation: the deep-link target, and what tells
+      // `resolveHomeFeedMirror` this is a background conversation worth
+      // mirroring into the home feed.
+      sourceContextId: conversationId,
+      attentionHints: {
+        requiresAction: false,
+        // Medium, not low: low routes to the notification center alone and
+        // posts silently, which is the invisibility this producer exists to
+        // fix. Not high either — that force-adds an in-app banner on every
+        // client for what is a digest, not an alarm.
+        urgency: "medium",
+        // Marks the signal as background-originated, which is what earns the
+        // home-feed mirror independently of the conversation-type check.
+        isAsyncBackground: true,
+        // Nobody is watching a scheduled run's conversation; that is the
+        // premise of this whole producer.
+        visibleInSourceNow: false,
+      },
+      contextPayload: {
+        requestedTitle,
+        requestedMessage: body,
+        scheduleName,
+        scheduleId,
+      },
+      // Keyed on the run, not the schedule: the pipeline's dedupe window is a
+      // flat hour, so a schedule firing more often than hourly would have its
+      // later runs silently dropped under a schedule-scoped key.
+      dedupeKey: `schedule.result:${scheduleId}:${runId}`,
+    });
+
+    rlog.info(
+      { scheduleId, runId, conversationId },
+      "Emitted fallback notification for a schedule run that produced output without notifying",
+    );
+  } catch (err) {
+    rlog.warn(
+      { err, scheduleId, runId, conversationId },
+      "Failed to emit schedule result notification (non-fatal)",
+    );
+  }
+}

package/src/notifications/signal.ts

@@ -66,6 +66,11 @@ export const NOTIFICATION_SOURCE_EVENT_NAMES = [
     id: "schedule.notify",
     description: "Scheduled notification triggered (one-shot or recurring)",
   },
+  {
+    id: "schedule.result",
+    description:
+      "Execute-mode schedule run finished with user-facing output it did not notify about itself",
+  },
   {
     id: "schedule.definition_error",
     description: "Plugin schedule declaration failed to parse or validate",

package/src/oauth/seed-providers.ts

@@ -1286,8 +1286,9 @@ export const PROVIDER_SEED_DATA: Record<
     // Link issues OAuth clients by request rather than through a self-serve
     // dashboard, so there is no placeholder shape to suggest.
     clientIdPlaceholder: null,
-    // Simple Icons has no Link mark (`link` 404s on the CDN), so the parent
-    // Stripe mark stands in.
+    // Clients draw the bundled Link symbol; this remote fallback carries the
+    // parent Stripe mark because Simple Icons has no Link one (`link` 404s on
+    // the CDN).
     logoUrl: "https://cdn.simpleicons.org/stripe",
     defaultScopes: ["payment_methods.agentic", "userinfo:read"],
     availableScopes: [

package/src/persistence/conversation-crud.ts

@@ -2705,6 +2705,44 @@ export function selectSightFrameCaptureTimes(
   return captureTimes;
 }
 
+/**
+ * The newest camera frame in the conversation, by the `createdAt` of the row
+ * that carries it, or null when no row carries one.
+ *
+ * The one-row form of {@link selectSightFrameCaptureTimes}, for a caller that
+ * wants only the latest and runs on every voice turn: every stored frame stays
+ * a row for the life of the conversation, so the full scan grows with the
+ * call. Same narrowing and the same validation, so the two agree on what a
+ * frame is. A row carrying several frames answers with the last attached.
+ */
+export function selectNewestSightFrameCapture(
+  conversationId: string,
+): { attachmentId: string; createdAt: number } | null {
+  const db = getDb();
+  const row = db
+    .select({ metadata: messages.metadata, createdAt: messages.createdAt })
+    .from(messages)
+    .where(
+      and(
+        lineageFilter(conversationId),
+        like(messages.metadata, `%"${SIGHT_FRAME_ATTACHMENT_IDS_KEY}"%`),
+      ),
+    )
+    .orderBy(desc(messages.createdAt))
+    .limit(1)
+    .get();
+  if (!row) {
+    return null;
+  }
+  const ids = sightFrameAttachmentIdsFromMetadata(
+    parseMessageMetadata(row.metadata),
+  );
+  const attachmentId = ids.at(-1);
+  return attachmentId === undefined
+    ? null
+    : { attachmentId, createdAt: row.createdAt };
+}
+
 /**
  * Count messages in a conversation that were created strictly after the
  * `afterMessageId` reference message. If `afterMessageId` is `null` or empty,