@vellumai/assistant 0.11.7 → 0.11.8-staging.1

package/src/messaging/providers/slack/send.ts

@@ -9,6 +9,7 @@
 import type { Button, KnownBlock } from "@slack/types";
 import type {
   ApprovalUIMetadata,
+  ChannelDeliveryResult,
   MessageAudience,
   StreamOp,
 } from "@vellumai/gateway-client";
@@ -382,30 +383,42 @@ function imageBlocksFor(text: string): KnownBlock[] | undefined {
 
 /**
  * Add or remove an emoji reaction on a Slack message.
- * Non-throwing: logs errors but returns silently.
+ *
+ * Non-throwing: failures are logged and reported through the result so a
+ * tool-driven react can tell the model the truth, while the activity
+ * fallback is free to ignore it. Colons are stripped from the name because
+ * `reactions.add` takes the bare emoji name, and `already_reacted` /
+ * `no_reaction` count as success: the requested end state already holds.
  */
 export async function sendSlackReaction(
   channel: string,
   name: string,
   messageTs: string,
   action: "add" | "remove",
-): Promise<void> {
+): Promise<ChannelDeliveryResult> {
   const method = action === "add" ? "reactions.add" : "reactions.remove";
+  const bareName = name.replace(/^:+|:+$/g, "");
   try {
-    await callSlackApi(method, { channel, name, timestamp: messageTs });
+    await callSlackApi(method, {
+      channel,
+      name: bareName,
+      timestamp: messageTs,
+    });
+    return { ok: true };
   } catch (err) {
     if (err instanceof SlackApiError) {
       if (
         err.slackError === "already_reacted" ||
         err.slackError === "no_reaction"
       ) {
-        return;
+        return { ok: true };
       }
     }
     log.warn(
-      { err, channel, method, name },
+      { err, channel, method, name: bareName },
       "Failed to deliver Slack reaction",
     );
+    return { ok: false };
   }
 }
 

package/src/messaging/providers/slack/transport.ts

@@ -6,6 +6,7 @@ import type { ChannelTransport } from "../channel-transport.js";
 import {
   sendSlackAgentSessionStatus,
   sendSlackAttachments,
+  sendSlackReaction,
   sendSlackReply,
   sendSlackStreamOp,
   updateSlackMessage,
@@ -21,6 +22,15 @@ function mutedBlocks(text: string): KnownBlock[] {
 export const slackTransport: ChannelTransport = {
   channel: "slack",
 
+  async react(target) {
+    return sendSlackReaction(
+      target.chatId,
+      target.emoji,
+      target.messageId,
+      target.action,
+    );
+  },
+
   async deliver(ctx, payload) {
     const { chatId, text, attachments } = payload;
     const threadTs = ctx.params.threadTs;

package/src/messaging/providers/slack/types.ts

@@ -1,5 +1,11 @@
 /** Slack Web API response types. */
 
+import type {
+  AnyBlock,
+  GenericMessageEvent,
+  MessageAttachment,
+} from "@slack/types";
+
 export interface SlackApiResponse {
   ok: boolean;
   error?: string;
@@ -61,7 +67,22 @@ export interface SlackMessage {
   ts: string;
   user?: string;
   bot_id?: string;
+  /**
+   * Display name for `bot_message`-subtype rows (incoming webhooks and
+   * legacy bot posts, which carry no `user` to resolve a name from).
+   */
+  username?: string;
+  /** Profile of the posting app, attached to bot-authored rows. The type is
+   *  indexed off the official message event because `@slack/types` does not
+   *  export `BotProfile` from its root. */
+  bot_profile?: GenericMessageEvent["bot_profile"];
   text: string;
+  /**
+   * Bot/webhook posts routinely leave `text` empty and put the visible
+   * content here or in `blocks`; see `slackMessageRawText`.
+   */
+  attachments?: MessageAttachment[];
+  blocks?: AnyBlock[];
   thread_ts?: string;
   reply_count?: number;
   reactions?: Array<{ name: string; count: number; users: string[] }>;
@@ -144,8 +165,6 @@ export interface SlackConversationsOpenResponse extends SlackApiResponse {
 
 export type SlackConversationMarkResponse = SlackApiResponse;
 
-export type SlackReactionsAddResponse = SlackApiResponse;
-
 export interface SlackUsersListResponse extends SlackApiResponse {
   members: SlackUser[];
   response_metadata?: { next_cursor?: string };

package/src/messaging/providers/telegram-bot/adapter.ts

@@ -7,6 +7,7 @@
 import type { OAuthConnection } from "../../../oauth/connection.js";
 import { getConnectionByProvider } from "../../../oauth/oauth-store.js";
 import { getOrCreateConversation } from "../../../persistence/conversation-key-store.js";
+import { buildScopedConversationKey } from "../../../persistence/delivery-crud.js";
 import { upsertOutboundBinding } from "../../../persistence/external-conversation-store.js";
 import { credentialKey } from "../../../security/credential-key.js";
 import { getSecureKeyAsync } from "../../../security/secure-keys.js";
@@ -107,7 +108,10 @@ export const telegramBotMessagingProvider: MessagingProvider = {
     // conversation key mapping and binding exist for the next inbound.
     try {
       const sourceChannel = "telegram";
-      const conversationKey = `asst:self:${sourceChannel}:${conversationId}`;
+      const conversationKey = buildScopedConversationKey(
+        sourceChannel,
+        conversationId,
+      );
       const { conversationId: internalId } =
         getOrCreateConversation(conversationKey);
       upsertOutboundBinding({

package/src/messaging/providers/telegram-bot/send.test.ts

@@ -30,8 +30,12 @@ mock.module("./api.js", () => ({
 }));
 
 const { TelegramNonRetryableError } = await import("./api.js");
-const { editTelegramMessage, sendTelegramReply, sendTelegramRichReply } =
-  await import("./send.js");
+const {
+  editTelegramMessage,
+  sendTelegramReaction,
+  sendTelegramReply,
+  sendTelegramRichReply,
+} = await import("./send.js");
 const { telegramTransport } = await import("./transport.js");
 
 const approval: ApprovalUIMetadata = {
@@ -323,6 +327,49 @@ describe("telegramTransport topic targeting", () => {
   });
 });
 
+describe("sendTelegramReaction", () => {
+  test("add sends setMessageReaction with a single emoji entry", async () => {
+    const result = await sendTelegramReaction("12345", "👍", "678", "add");
+    expect(result).toEqual({ ok: true });
+    const calls = callsTo("setMessageReaction");
+    expect(calls).toHaveLength(1);
+    expect(calls[0][1]).toEqual({
+      chat_id: "12345",
+      message_id: 678,
+      reaction: [{ type: "emoji", emoji: "👍" }],
+    });
+  });
+
+  test("remove clears the bot's reaction with the empty list", async () => {
+    await sendTelegramReaction("12345", "👍", "678", "remove");
+    const calls = callsTo("setMessageReaction");
+    expect(calls[0][1]).toEqual({
+      chat_id: "12345",
+      message_id: 678,
+      reaction: [],
+    });
+  });
+
+  test("a non-numeric message id reports ok false without calling the API", async () => {
+    const result = await sendTelegramReaction(
+      "12345",
+      "👍",
+      "not-an-id",
+      "add",
+    );
+    expect(result).toEqual({ ok: false });
+    expect(callsTo("setMessageReaction")).toHaveLength(0);
+  });
+
+  test("an API rejection reports ok false without throwing", async () => {
+    callTelegramBotApiMock.mockImplementationOnce(async () => {
+      throw new TelegramNonRetryableError("400", "REACTION_INVALID");
+    });
+    const result = await sendTelegramReaction("12345", "👍", "678", "add");
+    expect(result).toEqual({ ok: false });
+  });
+});
+
 describe("editTelegramMessage", () => {
   const ctx = { callbackUrl: "http://gw/deliver/telegram", params: {} };
 

package/src/messaging/providers/telegram-bot/send.ts

@@ -5,7 +5,10 @@
  * and typing indicators by calling the Telegram Bot API directly via ./api.ts.
  */
 
-import type { ApprovalUIMetadata } from "@vellumai/gateway-client";
+import type {
+  ApprovalUIMetadata,
+  ChannelDeliveryResult,
+} from "@vellumai/gateway-client";
 
 import { getAttachmentContent } from "../../../persistence/attachments-store.js";
 import type { RuntimeAttachmentMetadata } from "../../../runtime/http-types.js";
@@ -388,6 +391,43 @@ export async function sendTelegramAttachments(
  * Send a typing indicator ("chat action") to a Telegram chat.
  * Returns true on success, false on failure (non-throwing).
  */
+/**
+ * Set or clear the bot's emoji reaction on a message.
+ *
+ * `setMessageReaction` semantics (Bot API): a bot holds at most one
+ * reaction per message, so `add` replaces any prior one and `remove`
+ * clears it by sending the empty reaction list. `emoji` is the unicode
+ * emoji itself, and Telegram accepts only its allowed set (the standard
+ * reaction emoji, narrowed further by a chat's allowed-reactions
+ * setting); a rejected emoji reports `ok: false` rather than throwing.
+ */
+export async function sendTelegramReaction(
+  chatId: string,
+  emoji: string,
+  messageId: string,
+  action: "add" | "remove",
+): Promise<ChannelDeliveryResult> {
+  const messageIdNum = Number.parseInt(messageId, 10);
+  if (!Number.isFinite(messageIdNum)) {
+    log.warn({ chatId, messageId }, "Non-numeric Telegram reaction target");
+    return { ok: false };
+  }
+  try {
+    await callTelegramBotApi("setMessageReaction", {
+      chat_id: chatId,
+      message_id: messageIdNum,
+      reaction: action === "add" ? [{ type: "emoji", emoji }] : [],
+    });
+    return { ok: true };
+  } catch (err) {
+    log.warn(
+      { err, chatId, messageId, action },
+      "Failed to deliver Telegram reaction",
+    );
+    return { ok: false };
+  }
+}
+
 export async function sendTelegramTypingIndicator(
   chatId: string,
   opts?: TelegramSendOptions,

package/src/messaging/providers/telegram-bot/transport.ts

@@ -10,6 +10,7 @@ import type { TelegramSendOptions } from "./send.js";
 import {
   editTelegramMessage,
   sendTelegramAttachments,
+  sendTelegramReaction,
   sendTelegramReply,
   sendTelegramRichReply,
   sendTelegramTypingIndicator,
@@ -32,6 +33,15 @@ export const telegramTransport: ChannelTransport = {
   // Telegram clears a chat action after about five seconds.
   activityRefreshMs: 4_000,
 
+  async react(target) {
+    return sendTelegramReaction(
+      target.chatId,
+      target.emoji,
+      target.messageId,
+      target.action,
+    );
+  },
+
   async deliver(ctx, payload) {
     const { chatId, text, attachments, approval } = payload;
     const opts = threadOptions(ctx);

package/src/messaging/providers/telegram-bot/withdraw.ts

@@ -132,24 +132,31 @@ async function clearInlineKeyboard(
  *
  * Both steps are attempted independently, so a failed keyboard edit does not
  * lose the durable outcome notice. Throws only if the status reply send
- * fails, which the caller treats as non-fatal.
+ * fails, which decision-path callers treat as non-fatal. `complete` reports
+ * whether the keyboard is durably gone: false keeps the expiry sweep's
+ * receipt held back so the still-actionable card is retried. An invalid
+ * recorded message id reports complete, because no retry can ever address
+ * it; a tap on its leftover buttons gets the stale-request handling.
  */
 export async function withdrawTelegramApprovalCard(
   params: WithdrawTelegramApprovalCardParams,
-): Promise<void> {
+): Promise<{ complete: boolean }> {
   const parsedMessageId = Number(params.messageId);
   if (!Number.isFinite(parsedMessageId)) {
     log.warn(
       { chatId: params.chatId, messageId: params.messageId },
       "Skipping Telegram card withdrawal due to invalid message id",
     );
-    return;
+    return { complete: true };
   }
 
-  await clearInlineKeyboard(params.chatId, parsedMessageId);
+  const keyboardCleared = await clearInlineKeyboard(
+    params.chatId,
+    parsedMessageId,
+  );
 
   if (!params.postStatusReply) {
-    return;
+    return { complete: keyboardCleared };
   }
 
   // Silent (no push) reply quoting the card. `allow_sending_without_reply`
@@ -163,4 +170,5 @@ export async function withdrawTelegramApprovalCard(
     },
     disable_notification: true,
   });
+  return { complete: keyboardCleared };
 }

package/src/messaging/reaction-envelopes.ts

@@ -0,0 +1,79 @@
+/**
+ * The two persisted envelope shapes of a reaction row, built from one set of
+ * facts so the inbound intercept and the assistant's own reaction records
+ * cannot drift apart.
+ *
+ * Slack keeps its own envelope because its transcript context builds
+ * provider history from rows and reads only `slackMeta`; every other channel
+ * writes the neutral shape `readProviderMetadata` serves to channel-agnostic
+ * readers.
+ */
+import type { ChannelId } from "../channels/types.js";
+import type { ProviderMessageMetadata } from "./provider-message-metadata.js";
+import type { SlackMessageMetadata } from "./providers/slack/message-metadata.js";
+
+export interface ReactionEnvelopeFacts {
+  channel: ChannelId;
+  /** Provider id of the chat the reaction belongs to. */
+  chatId: string;
+  /** Target message id, in the channel's own id space. */
+  targetMessageId: string;
+  emoji: string;
+  op: "added" | "removed";
+  /** Absent on the assistant's own reactions. */
+  actorExternalId?: string;
+  /** Absent on the assistant's own reactions. */
+  actorDisplayName?: string;
+}
+
+export function buildNeutralReactionMeta(
+  facts: ReactionEnvelopeFacts,
+): ProviderMessageMetadata {
+  return {
+    source: facts.channel,
+    conversationExternalId: facts.chatId,
+    eventKind: "reaction",
+    ...(facts.actorExternalId
+      ? { actorExternalId: facts.actorExternalId }
+      : {}),
+    ...(facts.actorDisplayName ? { displayName: facts.actorDisplayName } : {}),
+    reaction: {
+      targetMessageId: facts.targetMessageId,
+      emoji: facts.emoji,
+      op: facts.op,
+      ...(facts.actorDisplayName
+        ? { actorDisplayName: facts.actorDisplayName }
+        : {}),
+    },
+  };
+}
+
+export function buildSlackReactionMeta(
+  facts: ReactionEnvelopeFacts,
+): SlackMessageMetadata {
+  return {
+    source: "slack",
+    channelId: facts.chatId,
+    // A reaction row stores the reacted message's ts in `channelTs`, which
+    // is its target rather than an id of its own.
+    channelTs: facts.targetMessageId,
+    eventKind: "reaction",
+    // No `threadTs`: Slack sends none on a reaction, so any thread id in
+    // scope is the reacted message's own ts. It equals `channelTs`, which
+    // every reader treats as "not in a thread" anyway, and storing it makes
+    // the row false evidence that a thread belongs to this conversation
+    // (`legacySlackConversationHasThreadEvidence`).
+    ...(facts.actorExternalId
+      ? { actorExternalUserId: facts.actorExternalId }
+      : {}),
+    ...(facts.actorDisplayName ? { displayName: facts.actorDisplayName } : {}),
+    reaction: {
+      emoji: facts.emoji,
+      targetChannelTs: facts.targetMessageId,
+      op: facts.op,
+      ...(facts.actorDisplayName
+        ? { actorDisplayName: facts.actorDisplayName }
+        : {}),
+    },
+  };
+}

package/src/monitoring/control.ts

@@ -68,13 +68,13 @@ export function stopMonitoringWorkerProcess(): WorkerProcessStatus {
 
 /**
  * Daemon-lifecycle entry point: spawn the monitor as a child of the daemon
- * (`detached: false`, so it appears in `assistant ps` and is torn down on
+ * (so it appears in the daemon's process tree and is torn down on
  * shutdown). Runs on every boot — the monitor is platform infrastructure,
  * not an opt-in feature. Fire-and-forget — a monitor failure must never
  * block boot.
  */
 export function startMonitoring(): void {
-  void spawnMonitoringWorkerProcess({ detached: false })
+  void spawnMonitoringWorkerProcess()
     .then((r) =>
       log.info(
         { pid: r.pid, alreadyRunning: r.alreadyRunning },

package/src/monitoring/page-cache.ts

@@ -143,7 +143,11 @@ export async function readFileResidency(
     const { stdout } = await execFileAsync(
       "fincore",
       ["--bytes", "--json", ...paths],
-      { timeout: 10_000, maxBuffer: 4 * 1024 * 1024 },
+      {
+        timeout: 10_000,
+        maxBuffer: 4 * 1024 * 1024,
+        windowsHide: true,
+      },
     );
     return parseFincoreJson(stdout);
   } catch {

package/src/notifications/AGENTS.md

@@ -10,4 +10,4 @@ Guardian-request producers (access requests, tool approvals, tool-grant escalati
 
 Approval-card **source references** (the link back to the channel message that triggered a request) resolve only through `resolveApprovalSourceReference()` in `runtime/approval-source-link.ts` -- producers spread the result into the `guardian.question` context payload and never hand-build links. Channel-format knowledge (id shapes, permalinks, mrkdwn) lives only in `messaging/providers/<channel>/` and `notifications/adapters/<channel>`; the four-layer ownership map is documented at the top of `approval-source-link.ts`. Exception: access-request cards predate the registry and still derive their Slack permalink from payload `messageTs` in `access-request-copy.ts` -- converge them onto the registry rather than adding a third resolution path.
 
-Guardian-request card rows are **not conversation history**. `pairDeliveryWithConversation` persists a message row per delivery, and for a guardian card that row is addressed to a conversation the request is _about_ (the vellum card is pinned to the originating conversation; a channel card lands in whatever conversation the guardian's chat binds to). `isGuardianCardRow` in `approval-card-data.ts` is the single definition of which rows those are, derived from the card's own `ui_surface` id rather than a stored marker so old rows need no backfill. **Both** history assemblers must consult it -- `Conversation.loadFromDb` and `loadSlackChronologicalContext`, which re-reads rows rather than using `this.messages` -- or the unfiltered one replays the card between a parked turn's `tool_use` and its `tool_result` and history repair destroys the real result. Surface state is exempt on purpose: the card's buttons must still route after a restart. Full rationale in [docs/guardian-request-flow.md](../../docs/guardian-request-flow.md).
+Guardian-request card rows are **not conversation history**. Only the vellum delivery persists a message row (`pairDeliveryWithConversation` pins it to the conversation the request is _about_, via `buildVellumCardAffinity`); channel guardian cards are delivery projections and pair no conversation at all, with the gateway delivery row (chat id + channel-native message id) as their only persisted envelope. `isGuardianCardRow` in `approval-card-data.ts` is the single definition of which rows are guardian cards (including rows channel deliveries paired before the projection-only policy), derived from the card's own `ui_surface` id rather than a stored marker so old rows need no backfill. **Both** history assemblers must consult it -- `Conversation.loadFromDb` and `loadSlackChronologicalContext`, which re-reads rows rather than using `this.messages` -- or the unfiltered one replays the card between a parked turn's `tool_use` and its `tool_result` and history repair destroys the real result. Surface state is exempt on purpose: the card's buttons must still route after a restart. Full rationale in [docs/guardian-request-flow.md](../../docs/guardian-request-flow.md).