@vellumai/vellum-gateway 0.11.8 → 0.11.9-staging.2

package/AGENTS.md

@@ -83,8 +83,10 @@ Gateway inbound events use a channel-discriminated union model (`GatewayInboundE
 
 - **`conversationExternalId`**: Delivery/conversation address (e.g., Telegram chat ID, phone number). Used for conversation binding and message routing. **Not** used for trust classification.
 - **`actorExternalId`**: Sender identity (e.g., Telegram user ID, WhatsApp phone number). Used for trust classification, guardian binding, and ACL enforcement. **Required** for all public channel ingress.
+- **`externalMessageId`**: Dedup identity. It must name one OCCURRENCE of an event, not one kind of event: two distinct acts by the same actor differ here, and the same act delivered twice repeats here. Both halves are load-bearing, because the gateway claims a delivery on `(sourceChannel, externalChatId, externalMessageId)` (`db/inbound-dedup-store.ts`) and the daemon records the permanent event row on the same triple. Prefer the provider's own per-event id (Telegram `update_id`, Slack `event_id`, a Discord snowflake, an email `Message-ID`). Where a provider names only the thing acted on and not the act, as both reaction families do, addressing fields alone (room, target message, actor, verb) repeat byte for byte on the second occurrence and silently dedup it away, so the normalizer must carry a per-event component of its own.
 - **"conversation"** is canonical vocabulary for delivery addresses. "thread" is reserved for provider-specific fields (Slack `thread_ts`, email thread IDs).
 - **"actor"** is canonical vocabulary for sender identity.
+- **`source.actorUnattributed`**: set when the platform names no person for an event. `actorExternalId` then carries the channel's synthetic system id (`discord-system`, `slack-system`) and is not an identity claim: the gateway seeds no contact from it, and the runtime's ACL neither resolves a member nor denies, applying the event only to a row the daemon already holds for that chat. Only event kinds that cannot start a turn may carry it; today that is the delete family (Discord names no author; Slack names the author, never the deleter, and the author may be the assistant itself). The `no_one` kill switch still applies, since it keys on the policy alone.
 
 Trust/guardian decisions must be keyed on `actorExternalId` only — never fall back to `conversationExternalId` for actor identity.
 

package/node_modules/@vellumai/ces-client/node_modules/@vellumai/service-contracts/package.json

@@ -22,7 +22,10 @@
     "./redacted-credential": "./src/redacted-credential.ts",
     "./secret-detection": "./src/secret-detection.ts",
     "./stripe-currency": "./src/stripe-currency.ts",
-    "./error": "./src/error.ts"
+    "./error": "./src/error.ts",
+    "./reactions": "./src/reactions.ts",
+    "./guardian-requests": "./src/guardian-requests.ts",
+    "./platform-credential": "./src/platform-credential.ts"
   },
   "scripts": {
     "typecheck": "bunx tsc --noEmit",

package/node_modules/@vellumai/ces-client/node_modules/@vellumai/service-contracts/src/guardian-requests.ts

@@ -0,0 +1,18 @@
+/**
+ * Canonical vocabulary for a guardian request's lifecycle status, shared by
+ * the gateway that owns the request rows, the daemon that decides and
+ * projects them, and the web that renders the projection.
+ */
+import { z } from "zod";
+
+export const GUARDIAN_REQUEST_STATUS_VALUES = [
+  "pending",
+  "approved",
+  "denied",
+  "expired",
+  "cancelled",
+] as const;
+export const GuardianRequestStatusSchema = z.enum(
+  GUARDIAN_REQUEST_STATUS_VALUES,
+);
+export type GuardianRequestStatus = z.infer<typeof GuardianRequestStatusSchema>;

package/node_modules/@vellumai/ces-client/node_modules/@vellumai/service-contracts/src/index.ts

@@ -28,6 +28,7 @@ export * from "./rpc.js";
 export * from "./trust-rules.js";
 export * from "./ingress.js";
 export * from "./no-response.js";
+export * from "./platform-credential.js";
 export * from "./remote-web-pairing.js";
 export * from "./twilio-ingress.js";
 export * from "./url-normalization.js";

package/node_modules/@vellumai/ces-client/node_modules/@vellumai/service-contracts/src/platform-credential.ts

@@ -0,0 +1,41 @@
+/**
+ * Wire contract for asking an assistant whether its stored platform-managed
+ * credential still authenticates.
+ *
+ * The daemon route is the authoritative serving side:
+ *   - `POST /v1/platform/verify-credential`
+ *       (`assistant/src/runtime/routes/platform-routes.ts`)
+ *
+ * The daemon's platform client produces the verdict, the route reports it,
+ * and the `vellum` CLI reads it before deciding whether a stored key can be
+ * re-injected (`cli/src/lib/assistant-api-key-resolution.ts`), so all three
+ * share one definition and cannot silently drift. The web app reads the same
+ * shape through its generated daemon client.
+ */
+import { z } from "zod";
+
+/**
+ * What the platform said about the stored credential, right now.
+ *
+ *   - `valid`: the platform accepted it.
+ *   - `rejected`: the platform refused it (unauthorized or forbidden); the
+ *     credential needs replacing.
+ *   - `unknown`: the check itself could not run (no credential stored, the
+ *     platform unreachable, a server error). Not evidence either way.
+ */
+export const PlatformCredentialVerificationStatusSchema = z.enum([
+  "valid",
+  "rejected",
+  "unknown",
+]);
+export type PlatformCredentialVerificationStatus = z.infer<
+  typeof PlatformCredentialVerificationStatusSchema
+>;
+
+/** `POST /v1/platform/verify-credential` response body. */
+export const PlatformVerifyCredentialResponseSchema = z.object({
+  status: PlatformCredentialVerificationStatusSchema,
+});
+export type PlatformVerifyCredentialResponse = z.infer<
+  typeof PlatformVerifyCredentialResponseSchema
+>;

package/node_modules/@vellumai/ces-client/node_modules/@vellumai/service-contracts/src/reactions.ts

@@ -0,0 +1,60 @@
+/**
+ * Canonical vocabulary for a reaction's emoji, shared by every service that
+ * handles one: the gateway that normalizes it, the daemon that stores and
+ * projects it, and the web that renders it.
+ *
+ * The kind is said by the channel rather than inferred from how the emoji
+ * is spelled. Modelled on Zulip's `reaction_type`, the one surveyed system
+ * that separates the namespace from the name.
+ *
+ * `shortcode` is a name in a channel's own namespace whose kind the channel
+ * does not disclose: Slack sends `+1` for the standard emoji and `blob_wave`
+ * for a workspace upload with nothing to tell them apart, and only the
+ * workspace token can resolve the second. It is a distinct kind from
+ * `unicode`, not a stand-in for an unknown one.
+ */
+import { z } from "zod";
+
+export const REACTION_EMOJI_KINDS = ["unicode", "shortcode", "custom"] as const;
+export type ReactionEmojiKind = (typeof REACTION_EMOJI_KINDS)[number];
+
+/**
+ * The typed emoji fields every schema that carries a reaction spreads in,
+ * so the wire contract, the stored envelopes, and the response projection
+ * describe one shape. Optional throughout: a persisted row or a replayed
+ * payload may carry only the spelling.
+ */
+export const ReactionEmojiFieldsSchema = z.object({
+  /** Which namespace the emoji was drawn from. */
+  emojiKind: z.enum(REACTION_EMOJI_KINDS).optional(),
+  /**
+   * The emoji's name in that namespace: the character itself for `unicode`,
+   * the bare name for `shortcode` and `custom`. Never a mention form.
+   */
+  emojiName: z.string().optional(),
+  /** The channel's id for a `custom` emoji, absent for every other kind. */
+  emojiId: z.string().optional(),
+  /** Whether a `custom` emoji animates. Absent for every other kind. */
+  emojiAnimated: z.boolean().optional(),
+});
+export type ReactionEmojiFields = z.infer<typeof ReactionEmojiFieldsSchema>;
+
+/**
+ * The typed emoji fields a source actually carries, with undefined ones
+ * omitted: an absent key and a present-but-undefined one serialize alike, but the
+ * stored envelope and the response should carry only what was declared. Every writer of a reaction shape (the wire
+ * payload, both stored envelopes, the response projection) copies the
+ * fields through this rather than restating the four-way pick.
+ */
+export function pickReactionEmojiFields(
+  source: ReactionEmojiFields,
+): ReactionEmojiFields {
+  return {
+    ...(source.emojiKind !== undefined ? { emojiKind: source.emojiKind } : {}),
+    ...(source.emojiName !== undefined ? { emojiName: source.emojiName } : {}),
+    ...(source.emojiId !== undefined ? { emojiId: source.emojiId } : {}),
+    ...(source.emojiAnimated !== undefined
+      ? { emojiAnimated: source.emojiAnimated }
+      : {}),
+  };
+}

package/node_modules/@vellumai/gateway-client/node_modules/@vellumai/service-contracts/package.json

@@ -22,7 +22,10 @@
     "./redacted-credential": "./src/redacted-credential.ts",
     "./secret-detection": "./src/secret-detection.ts",
     "./stripe-currency": "./src/stripe-currency.ts",
-    "./error": "./src/error.ts"
+    "./error": "./src/error.ts",
+    "./reactions": "./src/reactions.ts",
+    "./guardian-requests": "./src/guardian-requests.ts",
+    "./platform-credential": "./src/platform-credential.ts"
   },
   "scripts": {
     "typecheck": "bunx tsc --noEmit",

package/node_modules/@vellumai/gateway-client/node_modules/@vellumai/service-contracts/src/guardian-requests.ts

@@ -0,0 +1,18 @@
+/**
+ * Canonical vocabulary for a guardian request's lifecycle status, shared by
+ * the gateway that owns the request rows, the daemon that decides and
+ * projects them, and the web that renders the projection.
+ */
+import { z } from "zod";
+
+export const GUARDIAN_REQUEST_STATUS_VALUES = [
+  "pending",
+  "approved",
+  "denied",
+  "expired",
+  "cancelled",
+] as const;
+export const GuardianRequestStatusSchema = z.enum(
+  GUARDIAN_REQUEST_STATUS_VALUES,
+);
+export type GuardianRequestStatus = z.infer<typeof GuardianRequestStatusSchema>;

package/node_modules/@vellumai/gateway-client/node_modules/@vellumai/service-contracts/src/index.ts

@@ -28,6 +28,7 @@ export * from "./rpc.js";
 export * from "./trust-rules.js";
 export * from "./ingress.js";
 export * from "./no-response.js";
+export * from "./platform-credential.js";
 export * from "./remote-web-pairing.js";
 export * from "./twilio-ingress.js";
 export * from "./url-normalization.js";

package/node_modules/@vellumai/gateway-client/node_modules/@vellumai/service-contracts/src/platform-credential.ts

@@ -0,0 +1,41 @@
+/**
+ * Wire contract for asking an assistant whether its stored platform-managed
+ * credential still authenticates.
+ *
+ * The daemon route is the authoritative serving side:
+ *   - `POST /v1/platform/verify-credential`
+ *       (`assistant/src/runtime/routes/platform-routes.ts`)
+ *
+ * The daemon's platform client produces the verdict, the route reports it,
+ * and the `vellum` CLI reads it before deciding whether a stored key can be
+ * re-injected (`cli/src/lib/assistant-api-key-resolution.ts`), so all three
+ * share one definition and cannot silently drift. The web app reads the same
+ * shape through its generated daemon client.
+ */
+import { z } from "zod";
+
+/**
+ * What the platform said about the stored credential, right now.
+ *
+ *   - `valid`: the platform accepted it.
+ *   - `rejected`: the platform refused it (unauthorized or forbidden); the
+ *     credential needs replacing.
+ *   - `unknown`: the check itself could not run (no credential stored, the
+ *     platform unreachable, a server error). Not evidence either way.
+ */
+export const PlatformCredentialVerificationStatusSchema = z.enum([
+  "valid",
+  "rejected",
+  "unknown",
+]);
+export type PlatformCredentialVerificationStatus = z.infer<
+  typeof PlatformCredentialVerificationStatusSchema
+>;
+
+/** `POST /v1/platform/verify-credential` response body. */
+export const PlatformVerifyCredentialResponseSchema = z.object({
+  status: PlatformCredentialVerificationStatusSchema,
+});
+export type PlatformVerifyCredentialResponse = z.infer<
+  typeof PlatformVerifyCredentialResponseSchema
+>;

package/node_modules/@vellumai/gateway-client/node_modules/@vellumai/service-contracts/src/reactions.ts

@@ -0,0 +1,60 @@
+/**
+ * Canonical vocabulary for a reaction's emoji, shared by every service that
+ * handles one: the gateway that normalizes it, the daemon that stores and
+ * projects it, and the web that renders it.
+ *
+ * The kind is said by the channel rather than inferred from how the emoji
+ * is spelled. Modelled on Zulip's `reaction_type`, the one surveyed system
+ * that separates the namespace from the name.
+ *
+ * `shortcode` is a name in a channel's own namespace whose kind the channel
+ * does not disclose: Slack sends `+1` for the standard emoji and `blob_wave`
+ * for a workspace upload with nothing to tell them apart, and only the
+ * workspace token can resolve the second. It is a distinct kind from
+ * `unicode`, not a stand-in for an unknown one.
+ */
+import { z } from "zod";
+
+export const REACTION_EMOJI_KINDS = ["unicode", "shortcode", "custom"] as const;
+export type ReactionEmojiKind = (typeof REACTION_EMOJI_KINDS)[number];
+
+/**
+ * The typed emoji fields every schema that carries a reaction spreads in,
+ * so the wire contract, the stored envelopes, and the response projection
+ * describe one shape. Optional throughout: a persisted row or a replayed
+ * payload may carry only the spelling.
+ */
+export const ReactionEmojiFieldsSchema = z.object({
+  /** Which namespace the emoji was drawn from. */
+  emojiKind: z.enum(REACTION_EMOJI_KINDS).optional(),
+  /**
+   * The emoji's name in that namespace: the character itself for `unicode`,
+   * the bare name for `shortcode` and `custom`. Never a mention form.
+   */
+  emojiName: z.string().optional(),
+  /** The channel's id for a `custom` emoji, absent for every other kind. */
+  emojiId: z.string().optional(),
+  /** Whether a `custom` emoji animates. Absent for every other kind. */
+  emojiAnimated: z.boolean().optional(),
+});
+export type ReactionEmojiFields = z.infer<typeof ReactionEmojiFieldsSchema>;
+
+/**
+ * The typed emoji fields a source actually carries, with undefined ones
+ * omitted: an absent key and a present-but-undefined one serialize alike, but the
+ * stored envelope and the response should carry only what was declared. Every writer of a reaction shape (the wire
+ * payload, both stored envelopes, the response projection) copies the
+ * fields through this rather than restating the four-way pick.
+ */
+export function pickReactionEmojiFields(
+  source: ReactionEmojiFields,
+): ReactionEmojiFields {
+  return {
+    ...(source.emojiKind !== undefined ? { emojiKind: source.emojiKind } : {}),
+    ...(source.emojiName !== undefined ? { emojiName: source.emojiName } : {}),
+    ...(source.emojiId !== undefined ? { emojiId: source.emojiId } : {}),
+    ...(source.emojiAnimated !== undefined
+      ? { emojiAnimated: source.emojiAnimated }
+      : {}),
+  };
+}

package/node_modules/@vellumai/gateway-client/src/__tests__/guardian-request-contract.test.ts

@@ -16,7 +16,6 @@ import {
   ExpireGuardianRequestIpcParamsSchema,
   ExpireInteractionBoundIpcResponseSchema,
   GetGuardianRequestByCallSessionIpcParamsSchema,
-  GetGuardianRequestByDestinationMessageIpcParamsSchema,
   GetGuardianRequestByPendingQuestionIpcParamsSchema,
   GUARDIAN_REQUESTS_IPC_METHODS,
   GuardianRequestAclOutcomeSchema,
@@ -482,23 +481,6 @@ describe("delivery + destination IPC schemas", () => {
     );
   });
 
-  test("get_by_destination_message requires all three keys", () => {
-    const params = {
-      channel: "telegram",
-      chatId: "tg-chat-guardian",
-      messageId: "msg-42",
-    };
-    expect(
-      GetGuardianRequestByDestinationMessageIpcParamsSchema.parse(params),
-    ).toEqual(params);
-    expect(() =>
-      GetGuardianRequestByDestinationMessageIpcParamsSchema.parse({
-        channel: "telegram",
-        chatId: "tg-chat-guardian",
-      }),
-    ).toThrow();
-  });
-
   test("list_pending_by_destination accepts either addressing form", () => {
     const byConversation = { conversationId: "conv-1", channel: "telegram" };
     expect(

package/node_modules/@vellumai/gateway-client/src/__tests__/inbound-event-kind.test.ts

@@ -11,6 +11,7 @@ import {
   resolveInboundEventKind,
   resolveInboundReactionPayload,
 } from "../inbound-event-kind.js";
+import { RuntimeInboundPayloadSchema } from "../inbound-contract.js";
 
 describe("resolveInboundEventKind", () => {
   test("a stamped kind wins over every legacy field", () => {
@@ -83,14 +84,58 @@ describe("inboundEventRefersToAnotherMessage", () => {
 });
 
 describe("resolveInboundReactionPayload", () => {
-  test("a structured payload wins outright", () => {
+  test("a structured payload wins outright, typed fields included", () => {
     expect(
       resolveInboundReactionPayload({
         eventKind: "reaction",
-        reaction: { op: "removed", emoji: "+1", targetMessageId: "11.22" },
+        reaction: {
+          op: "removed",
+          emoji: "+1",
+          emojiKind: "shortcode",
+          emojiName: "+1",
+          targetMessageId: "11.22",
+        },
         callbackData: "reaction:eyes",
       }),
-    ).toEqual({ op: "removed", emoji: "+1", targetMessageId: "11.22" });
+    ).toEqual({
+      op: "removed",
+      emoji: "+1",
+      emojiKind: "shortcode",
+      emojiName: "+1",
+      targetMessageId: "11.22",
+    });
+  });
+
+  test("a stored payload without typed fields recovers its kind", () => {
+    // Rows predating the typed fields carry the spelling only. This is the
+    // one place the kind is inferred, and each spelling has one answer.
+    const at = (emoji: string) =>
+      resolveInboundReactionPayload({
+        eventKind: "reaction",
+        reaction: { op: "added", emoji, targetMessageId: "11.22" },
+      });
+    expect(at("<:blob_wave:987>")).toMatchObject({
+      emojiKind: "custom",
+      emojiName: "blob_wave",
+      emojiId: "987",
+    });
+    // The plain form records nothing about animation, so the field is
+    // absent rather than a fabricated false; a resolver must not read
+    // "not animated" off a row that never knew.
+    expect(at("<:blob_wave:987>")).not.toHaveProperty("emojiAnimated");
+    expect(at("<a:party:5>")).toMatchObject({
+      emojiKind: "custom",
+      emojiName: "party",
+      emojiId: "5",
+      emojiAnimated: true,
+    });
+    expect(at("thumbsup")).toMatchObject({
+      emojiKind: "shortcode",
+      emojiName: "thumbsup",
+    });
+    expect(at("🎉")).toMatchObject({ emojiKind: "unicode", emojiName: "🎉" });
+    // The spelling itself is never rewritten: the write path parses it back.
+    expect(at("<:blob_wave:987>")?.emoji).toBe("<:blob_wave:987>");
   });
 
   test("a replayed payload parses its sentinel and wire target", () => {
@@ -99,13 +144,25 @@ describe("resolveInboundReactionPayload", () => {
         callbackData: "reaction:thumbsup",
         sourceMetadata: { messageId: "33.44" },
       }),
-    ).toEqual({ op: "added", emoji: "thumbsup", targetMessageId: "33.44" });
+    ).toEqual({
+      op: "added",
+      emoji: "thumbsup",
+      emojiKind: "shortcode",
+      emojiName: "thumbsup",
+      targetMessageId: "33.44",
+    });
     expect(
       resolveInboundReactionPayload({
         callbackData: "reaction_removed:thumbsup",
         sourceMetadata: { messageId: "33.44" },
       }),
-    ).toEqual({ op: "removed", emoji: "thumbsup", targetMessageId: "33.44" });
+    ).toEqual({
+      op: "removed",
+      emoji: "thumbsup",
+      emojiKind: "shortcode",
+      emojiName: "thumbsup",
+      targetMessageId: "33.44",
+    });
   });
 
   test("no emoji or no target is not a reaction payload", () => {
@@ -126,3 +183,51 @@ describe("resolveInboundReactionPayload", () => {
     ).toBeNull();
   });
 });
+
+describe("RuntimeInboundPayloadSchema carries a reaction's typed emoji", () => {
+  const base = {
+    sourceChannel: "discord",
+    interface: "discord",
+    conversationExternalId: "chan-1",
+    externalMessageId: "msg-1:reaction:<:party_blob:111>:user-1:ingest-1",
+    content: "",
+    eventKind: "reaction",
+    actorExternalId: "user-1",
+  };
+
+  test("a custom emoji keeps all four typed fields through the wire schema", () => {
+    const parsed = RuntimeInboundPayloadSchema.parse({
+      ...base,
+      reaction: {
+        op: "added",
+        emoji: "<:party_blob:111>",
+        emojiKind: "custom",
+        emojiName: "party_blob",
+        emojiId: "111",
+        emojiAnimated: true,
+        targetMessageId: "msg-1",
+      },
+    });
+    expect(parsed.reaction).toEqual({
+      op: "added",
+      emoji: "<:party_blob:111>",
+      emojiKind: "custom",
+      emojiName: "party_blob",
+      emojiId: "111",
+      emojiAnimated: true,
+      targetMessageId: "msg-1",
+    });
+  });
+
+  test("a reaction carrying only the spelling still parses", () => {
+    const parsed = RuntimeInboundPayloadSchema.parse({
+      ...base,
+      reaction: { op: "removed", emoji: "+1", targetMessageId: "msg-1" },
+    });
+    expect(parsed.reaction).toEqual({
+      op: "removed",
+      emoji: "+1",
+      targetMessageId: "msg-1",
+    });
+  });
+});

package/node_modules/@vellumai/gateway-client/src/guardian-request-contract.ts

@@ -15,13 +15,9 @@
  * daemon's client-facing HTTP surface owns the distinct `guardian_actions_*`
  * operationIds (`guardian_actions_pending` / `guardian_actions_decision`),
  * which do not change.
- *
- * Destination lookups are deliberately split into a single-message lookup
- * (`get_by_destination_message`) and a pending-list read
- * (`list_pending_by_destination`) so each response schema has exactly one
- * shape instead of a params-dependent polymorphic result.
  */
 
+import { GuardianRequestStatusSchema } from "@vellumai/service-contracts/guardian-requests";
 import { z } from "zod";
 
 import {
@@ -33,19 +29,11 @@ import {
 // Enums
 // ---------------------------------------------------------------------------
 
-const GUARDIAN_REQUEST_STATUS_VALUES = [
-  "pending",
-  "approved",
-  "denied",
-  "expired",
-  "cancelled",
-] as const;
-
-export const GuardianRequestStatusSchema = z.enum(
+export {
   GUARDIAN_REQUEST_STATUS_VALUES,
-);
-
-export type GuardianRequestStatus = z.infer<typeof GuardianRequestStatusSchema>;
+  type GuardianRequestStatus,
+  GuardianRequestStatusSchema,
+} from "@vellumai/service-contracts/guardian-requests";
 
 const GUARDIAN_REQUEST_KIND_VALUES = [
   "access_request",
@@ -194,7 +182,6 @@ export const GUARDIAN_REQUESTS_IPC_METHODS = {
   updateDelivery: "guardian_requests_update_delivery",
   listDeliveries: "guardian_requests_list_deliveries",
   listDeliveriesByChat: "guardian_requests_list_deliveries_by_chat",
-  getByDestinationMessage: "guardian_requests_get_by_destination_message",
   listPendingByDestination: "guardian_requests_list_pending_by_destination",
   listPendingByScope: "guardian_requests_list_pending_by_scope",
   inScope: "guardian_requests_in_scope",
@@ -627,21 +614,6 @@ export type GuardianRequestDeliveryListIpcResponse = z.infer<
 // Destination + scope lookups
 // ---------------------------------------------------------------------------
 
-/**
- * Request for `guardian_requests_get_by_destination_message` — reaction
- * routing: recover the pending request whose delivered card is the reacted-to
- * message.
- */
-export const GetGuardianRequestByDestinationMessageIpcParamsSchema = z.object({
-  channel: z.string().min(1),
-  chatId: z.string().min(1),
-  messageId: z.string().min(1),
-});
-
-export type GetGuardianRequestByDestinationMessageIpcParams = z.infer<
-  typeof GetGuardianRequestByDestinationMessageIpcParamsSchema
->;
-
 /**
  * Request for `guardian_requests_list_pending_by_destination`. Two forms:
  * by destination conversation (`conversationId`, optionally narrowed by

package/node_modules/@vellumai/gateway-client/src/inbound-contract.ts

@@ -13,6 +13,8 @@
 import { INBOUND_EVENT_KINDS } from "./inbound-event-kind.js";
 import { z } from "zod";
 
+import { ReactionEmojiFieldsSchema } from "@vellumai/service-contracts/reactions";
+
 import { ChannelConversationTypeSchema } from "./channel-permission-contract.js";
 
 import { AdmissionPolicySchema } from "./admission-policy-contract.js";
@@ -183,6 +185,7 @@ export const RuntimeInboundPayloadSchema = z.object({
     .object({
       op: z.enum(["added", "removed"]),
       emoji: z.string(),
+      ...ReactionEmojiFieldsSchema.shape,
       targetMessageId: z.string(),
     })
     .optional(),