@vellumai/assistant 0.10.4-dev.202607021247.94bb87f → 0.10.4-dev.202607021328.aaa3f0c

package/ARCHITECTURE.md

@@ -429,9 +429,8 @@ External users who are not the guardian can gain access to the assistant through
 | `src/runtime/routes/access-request-decision.ts`        | Guardian decision → verification session creation                             |
 | `src/runtime/routes/guardian-approval-interception.ts` | Routes guardian decisions (button + conversational) to access request handler |
 | `src/runtime/channel-verification-service.ts`          | Verification session lifecycle, identity binding, rate limiting               |
-| `src/runtime/routes/contact-routes.ts`                 | HTTP API handlers for contact and channel management                          |
-| `src/runtime/routes/invite-routes.ts`                  | HTTP API handlers for invite management                                       |
-| `src/runtime/invite-service.ts`                        | Business logic for invite operations                                          |
+| `src/runtime/routes/contact-routes.ts`                 | HTTP/IPC handlers for contacts, channels, and invites (invite ops relay to gateway IPC) |
+| `src/runtime/invite-service.ts`                        | Daemon-owned invite presentation (share link, guardian instruction) over gateway-minted invites |
 | `src/contacts/contact-store.ts`                        | Contact read queries — lookup, search, list, and channel operations           |
 | `src/memory/guardian-approvals.ts`                     | Approval request persistence                                                  |
 | `src/channels/channel-verification-sessions.ts`        | Verification challenge persistence                                            |
@@ -455,11 +454,12 @@ A complementary access-granting flow where the guardian proactively creates a sh
 │    • extractInboundToken(payload) → token | undefined        │
 │  Registered: Telegram  │  Deferred: Slack, Voice             │
 ├─────────────────────────────────────────────────────────────┤
-│  Core Redemption Engine (invite-redemption-service.ts)       │
-│  Channel-agnostic token validation, expiry, use-count,       │
-│  channel-match enforcement, contact activation/reactivation  │
+│  Core Redemption Engine (gateway-native)                     │
+│  gateway/src/verification/invite-redemption.ts               │
+│  Token/code validation, expiry, use-count, channel-match     │
+│  enforcement, atomic claim, gateway ACL activation           │
 │  Returns: InviteRedemptionOutcome (discriminated union)      │
-│  Reply templates: invite-redemption-templates.ts             │
+│  Daemon mirrors contact info via the invite_redeemed event   │
 └─────────────────────────────────────────────────────────────┘
 ```
 
@@ -467,16 +467,16 @@ A complementary access-granting flow where the guardian proactively creates a sh
 
 1. Guardian asks the assistant to create an invite via desktop chat.
 2. `guardian-invite-intent.ts` detects the intent and rewrites the message to force-load the `contacts` skill.
-3. The skill calls the ingress HTTP API to create an invite token, then calls the Telegram transport adapter to build a deep link: `https://t.me/<bot>?start=iv_<token>`.
+3. The skill calls the invites HTTP API; the daemon relays the mint to the gateway (`invites_create` IPC), which writes the canonical `ingress_invites` row, then the daemon's Telegram transport adapter builds a deep link: `https://t.me/<bot>?start=iv_<token>`.
 4. Guardian shares the link with the invitee out-of-band.
 5. Invitee clicks the link, opening Telegram which sends `/start iv_<token>` to the bot.
-6. The gateway forwards the message to `/channels/inbound`. The inbound handler calls `getInviteAdapterRegistry().get('telegram').extractInboundToken()` to parse the `iv_` token.
-7. The token is redeemed via `invite-redemption-service.ts`, which validates, activates the contact, and returns a `redeemed` outcome.
+6. The gateway intercepts the `/start iv_<token>` message at ingress (before any daemon forwarding) and redeems the token against its canonical `ingress_invites` row.
+7. The gateway's redemption engine validates, activates the channel in the gateway ACL, and notifies the daemon (`invite_redeemed`) to mirror the contact info locally.
 8. A deterministic welcome message is delivered to the invitee (bypasses the LLM pipeline).
 
 **Token prefix convention:** The `iv_` prefix distinguishes invite tokens from `gv_` (guardian verification) tokens. Both use the same Telegram `/start` deep-link mechanism but are routed to different handlers.
 
-**Inbound intercept points:** Invite token extraction runs early in the inbound handler, before ACL denial, so valid invites short-circuit the contact check. Two intercept branches handle: (a) unknown contacts — the invite creates their first contact record; (b) inactive contacts (revoked/pending) — the invite reactivates them.
+**Inbound intercept points:** Invite token/code extraction runs at gateway ingress for non-member senders, before ACL denial, so valid invites short-circuit the contact check. The engine handles: (a) unknown contacts — the invite creates their first channel record; (b) inactive contacts (revoked) — the invite reactivates them; blocked channels are never reactivated.
 
 **Channel adapter status:**
 
@@ -488,21 +488,21 @@ A complementary access-granting flow where the guardian proactively creates a sh
 
 ### Voice Invite Flow (invite_redemption_pending)
 
-Voice invites use a short numeric code (4-10 digits, default 6) instead of a URL token. The guardian creates an invite bound to the invitee's E.164 phone number; the invitee redeems it by entering the code during an inbound voice call.
+Voice invites use a short numeric code (6 digits) instead of a URL token. The guardian creates an invite bound to the invitee's E.164 phone number; the invitee redeems it by entering the code during an inbound voice call.
 
 **Creation flow:**
 
 1. Guardian creates a voice invite via `POST /v1/contacts/invites` with `sourceChannel: "phone"` and `expectedExternalUserId` (E.164 phone).
-2. `invite-service.ts` generates a cryptographically random numeric code (`generateVoiceCode`), hashes it with SHA-256 (`hashVoiceCode`), and stores only the hash.
+2. The daemon relays the mint to the gateway (`invites_create` IPC), which generates a cryptographically random numeric code and stores only its SHA-256 hash on the canonical `ingress_invites` row.
 3. The one-time plaintext `voiceCode` is returned in the creation response. The raw token is NOT returned for voice invites — redemption uses the identity-bound code flow exclusively.
 4. Guardian communicates the code to the invitee out-of-band.
 
 **Call-time redemption subflow (`invite_redemption_pending`):**
 
 1. Unknown caller dials in. `relay-server.ts` resolves trust via `resolveActorTrust`. Caller is `unknown`, no pending guardian challenge.
-2. The relay checks `findActiveVoiceInvites` for invites bound to the caller's phone number.
-3. If active, non-expired invites exist, the relay enters the `invite_redemption_pending` state (reuses the `verification_pending` connection state) and prompts the caller with personalized copy: `Welcome <friend-name>. Please enter the 6-digit code that <guardian-name> provided you to verify your identity.`
-4. `redeemVoiceInviteCode` validates: identity match, code hash match, expiry, use count. On success, the contact is activated and the call transitions to the normal call flow.
+2. The relay asks the gateway for the active voice invite bound to the caller's phone number (`get_active_voice_invite` IPC via `calls/gateway-invite-reader.ts`; fail-soft — any gateway failure falls through to the unverified path).
+3. If an active, non-expired invite exists, the relay enters the `invite_redemption_pending` state (reuses the `verification_pending` connection state) and prompts the caller with personalized copy: `Welcome <friend-name>. Please enter the 6-digit code that <guardian-name> provided you to verify your identity.`
+4. The gateway's `redeem_voice_invite` engine validates: identity match, code hash match, expiry, use count. On success, the phone channel is activated in the gateway ACL and the call transitions to the normal call flow.
 5. On invalid/expired code, the caller hears deterministic failure copy: `Sorry, the code you provided is incorrect or has since expired. Please ask <guardian-name> for a new code. Goodbye.` and the call ends immediately.
 
 **Security invariants:**
@@ -516,18 +516,15 @@ Voice invites use a short numeric code (4-10 digits, default 6) instead of a URL
 
 | File                                                | Purpose                                                                                                            |
 | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
-| `src/runtime/invite-redemption-service.ts`          | Core redemption engine — token validation, voice code redemption, contact activation, discriminated-union outcomes |
-| `src/runtime/invite-redemption-templates.ts`        | Deterministic reply templates for each redemption outcome                                                          |
+| `gateway/src/verification/invite-redemption.ts` (gateway) | Core redemption engine + gateway-ingress token/code intercept — validation, atomic claim, ACL activation, discriminated-union outcomes  |
 | `src/runtime/channel-invite-transport.ts`           | Transport adapter registry with `buildShareableInvite` / `extractInboundToken` interface                           |
 | `src/runtime/channel-invite-transports/telegram.ts` | Telegram adapter — `t.me/<bot>?start=iv_<token>` deep links, `/start iv_<token>` extraction                        |
 | `src/runtime/channel-invite-transports/voice.ts`    | Voice transport adapter — code-based redemption metadata                                                           |
 | `src/daemon/guardian-invite-intent.ts`              | Intent detection — routes create/list/revoke requests into the contacts skill                                      |
-| `src/runtime/invite-service.ts`                     | Shared business logic for invite operations (used by HTTP routes)                                                  |
-| `src/runtime/routes/invite-routes.ts`               | HTTP API handlers for invite management including voice invite creation and redemption                             |
-| `src/runtime/routes/inbound-message-handler.ts`     | Invite token intercept in the inbound flow (unknown-contact and inactive-contact branches)                         |
+| `src/runtime/invite-service.ts`                     | Daemon-owned invite presentation (share link, guardian instruction, channel handle) over gateway-minted invites    |
+| `src/runtime/routes/contact-routes.ts`              | HTTP/IPC invite handlers — relay mint/list/revoke/redeem to the gateway's invite IPC routes                        |
 | `src/calls/relay-server.ts`                         | Voice relay state machine — `invite_redemption_pending` subflow (always-on canonical behavior)                     |
-| `src/util/voice-code.ts`                            | Cryptographic voice code generation and SHA-256 hashing                                                            |
-| `src/persistence/invite-store.ts`                   | Invite persistence including `findActiveVoiceInvites` for identity-bound lookup                                    |
+| `src/calls/gateway-invite-reader.ts`                | Gateway IPC read of the active voice invite for a caller identity                                                  |
 
 ### Voice Inbound Security Model (Canonical)
 
@@ -550,7 +547,7 @@ resolveActorTrust() → trustClass
                                    |
               ┌────────────────────┼──────────────────────┐
               |                    |                       |
-    pendingChallenge?     activeVoiceInvites?      no invite, no challenge
+    pendingChallenge?     activeVoiceInvite?       no invite, no challenge
               |                    |                       |
               v                    v                       v
     Guardian verification   Invite redemption     Name capture +

package/README.md

@@ -309,7 +309,6 @@ Guardian verification and ingress contact management are complementary but indep
 | `src/runtime/trust-context-resolver.ts`             | Actor role classification: guardian / non-guardian / unverified_channel                                                          |
 | `src/runtime/routes/inbound-message-handler.ts`     | Ingress ACL enforcement, verification-code intercept, escalation creation                                                        |
 | `src/contacts/contact-store.ts`                     | Contact + channel CRUD: `findContactChannel`, `upsertContact`, `updateChannelStatus`, `searchContacts`                           |
-| `src/memory/invite-store.ts`                        | Invite lifecycle: `createInvite`, `redeemInvite` (atomically creates member record)                                              |
 | `src/memory/channel-verification-sessions.ts`       | Guardian binding types and verification challenge persistence                                                                    |
 | `src/memory/guardian-approvals.ts`                  | Approval request persistence                                                                                                     |
 | `src/runtime/verification-outbound-actions.ts`      | Shared business logic for outbound verification (start/resend/cancel)                                                            |
@@ -383,7 +382,7 @@ External users join through **invite tokens**. There are two invite flows:
 1. **Guardian requests invite** — The guardian asks the assistant (via desktop chat) to create a Telegram invite link. The `guardian-invite-intent.ts` module detects the intent and routes the request into the `contacts` skill.
 2. **Invite creation** — The skill creates an invite token via the ingress HTTP API, looks up the Telegram bot username from the integration config endpoint, and constructs a shareable deep link: `https://t.me/<bot>?start=iv_<token>`.
 3. **Guardian shares link** — The guardian copies the deep link and shares it with the invitee through any messaging channel.
-4. **Invitee redeems** — The invitee clicks the link, which opens Telegram and sends `/start iv_<token>` to the bot. The inbound message handler extracts the token via the transport adapter, redeems it through the invite redemption service, and auto-creates an active member record.
+4. **Invitee redeems** — The invitee clicks the link, which opens Telegram and sends `/start iv_<token>` to the bot. The gateway intercepts the token at ingress, redeems it against its canonical invite row, activates the member channel in the gateway ACL, and notifies the daemon to mirror the contact info.
 5. **Access granted** — The invitee receives a welcome message and all subsequent messages pass the ingress ACL.
 
 The `iv_` prefix distinguishes invite tokens from `gv_` (guardian verification) tokens, which use the same Telegram `/start` deep-link mechanism.
@@ -392,7 +391,7 @@ The `iv_` prefix distinguishes invite tokens from `gv_` (guardian verification)
 
 The invite redemption system uses a three-layer architecture:
 
-- **Core redemption engine** (`invite-redemption-service.ts`) — Channel-agnostic business logic that validates tokens, enforces expiry/use-count/channel-match constraints, handles member reactivation, and returns a discriminated-union `InviteRedemptionOutcome`. Deterministic reply templates (`invite-redemption-templates.ts`) map each outcome to a user-facing message without passing through the LLM.
+- **Core redemption engine** (gateway-native, `gateway/src/verification/invite-redemption.ts`) — Channel-agnostic business logic that validates tokens and codes, enforces expiry/use-count/channel-match constraints, handles member reactivation, and returns a discriminated-union `InviteRedemptionOutcome`. Deterministic reply templates map each outcome to a user-facing message without passing through the LLM.
 - **Channel transport adapters** (`channel-invite-transport.ts` + `channel-invite-transports/`) — A registry of per-channel adapters that know how to build shareable links (`buildShareLink`) and extract inbound tokens (`extractInboundToken`). Adapters are implemented for Telegram, Voice, Email, WhatsApp, and Slack.
 - **Conversational orchestration** (`guardian-invite-intent.ts`) — Pattern-based intent detection that intercepts guardian invite management requests (create, list, revoke) in the session pipeline and forces immediate entry into the `contacts` skill, bypassing the normal agent loop.
 
@@ -422,16 +421,14 @@ If no guardian binding exists, escalation fails closed — the message is denied
 
 | File                                                | Purpose                                                                                                          |
 | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
-| `src/memory/invite-store.ts`                        | CRUD for invite tokens with SHA-256 hashing and expiry                                                           |
 | `src/contacts/contact-store.ts`                     | Contact + channel CRUD with policy enforcement                                                                   |
-| `src/daemon/handlers/config-inbox.ts`               | HTTP handlers for invite operations                                                                              |
-| `src/runtime/routes/channel-routes.ts`              | ACL enforcement point — member lookup, policy check, escalation creation                                         |
-| `src/runtime/invite-redemption-service.ts`          | Core redemption engine — token validation, member creation, discriminated-union outcomes                         |
-| `src/runtime/invite-redemption-templates.ts`        | Deterministic reply templates for each redemption outcome                                                        |
+| `src/runtime/routes/contact-routes.ts`              | HTTP/IPC invite handlers — relay mint/list/revoke/redeem to the gateway's invite IPC routes                      |
+| `src/runtime/routes/inbound-message-handler.ts`     | ACL enforcement point — member lookup, policy check, escalation creation                                         |
+| `gateway/src/verification/invite-redemption.ts` (gateway) | Core redemption engine — token/code validation, atomic claim, ACL activation, discriminated-union outcomes |
 | `src/runtime/channel-invite-transport.ts`           | Transport adapter registry — `buildShareableInvite` / `extractInboundToken` per channel                          |
 | `src/runtime/channel-invite-transports/telegram.ts` | Telegram adapter — builds `t.me/<bot>?start=iv_<token>` deep links, extracts `iv_` tokens from `/start` commands |
 | `src/daemon/guardian-invite-intent.ts`              | Intent detection — routes guardian invite management requests into the `contacts` skill                          |
-| `src/runtime/invite-service.ts`                     | Shared business logic for invite and contact operations                                                          |
+| `src/runtime/invite-service.ts`                     | Daemon-owned invite presentation (share link, guardian instruction) over gateway-minted invites                  |
 
 ## Database
 

package/docs/trusted-contact-access.md

@@ -114,11 +114,11 @@ No member record is created. No verification session is created.
 
 ### Invites (alternative path)
 
-The `assistant_ingress_invites` table supports a parallel invite-based onboarding path. An invite carries a SHA-256 hashed token and can be redeemed via `redeemInvite()`, which atomically creates an active contact channel record. This path is distinct from the trusted contact flow but serves the same end state: an active `contact_channels` entry with `status: 'active'` and `policy: 'allow'`.
+Invites are gateway-native: the gateway's `ingress_invites` table is the sole invite store, and its redemption engine (`gateway/src/verification/invite-redemption.ts`) validates the SHA-256 hashed token, atomically claims the row, and activates the channel in the gateway ACL. The daemon only mirrors the contact/channel identity locally via the `invite_redeemed` event. This path is distinct from the trusted contact flow but serves the same end state: an active member channel.
 
-| Table                       | Purpose in trusted contact flow                                                                                                                                                      |
-| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `assistant_ingress_invites` | Not used in the guardian-mediated flow. Available as an alternative for direct invite links (e.g., guardian shares a URL instead of going through the approval + verification flow). |
+| Table                                 | Purpose in trusted contact flow                                                                                                                                                      |
+| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `ingress_invites` (gateway DB)        | Not used in the guardian-mediated flow. Available as an alternative for direct invite links (e.g., guardian shares a URL instead of going through the approval + verification flow). |
 
 ### Voice In-Call Guardian Approval (friend-initiated)
 

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

@@ -0,0 +1,233 @@
+/**
+ * Tests for the shared invite contract.
+ *
+ * The pinned hash vectors below define the hash compatibility contract:
+ * `hashInviteToken` and `hashInviteCode` must produce exactly these outputs
+ * because invite hashes already stored in the assistant and gateway DBs were
+ * produced with them. Do not update the vectors to "fix" a failure — a
+ * mismatch means the hash scheme broke.
+ */
+
+import { describe, expect, test } from "bun:test";
+
+import {
+  ActiveVoiceInviteSchema,
+  generateInviteCode,
+  generateInviteToken,
+  GetActiveVoiceInviteRequestSchema,
+  hashInviteCode,
+  hashInviteToken,
+  INVITE_CODE_REDEMPTION_CHANNELS,
+  InviteRedemptionOutcomeSchema,
+  isInviteCodeRedemptionEnabled,
+  isValidE164,
+  RedeemInviteByCodeRequestSchema,
+  RedeemInviteByTokenRequestSchema,
+  RedeemVoiceInviteRequestSchema,
+  type InviteRedemptionOutcome,
+} from "../invite-contract.js";
+
+describe("hash helpers — pinned compatibility vectors", () => {
+  test("hashInviteToken matches invite-store.ts hashToken output", () => {
+    expect(hashInviteToken("test-raw-token")).toBe(
+      "7ef58e99b3406554f5ce0c0055b8ed3ea4db2c8a36613092d644c57c6a033330",
+    );
+    expect(hashInviteToken("AbC123_-xyz")).toBe(
+      "860c47c13bb8d13decd6815b20be7de8cf11597e4b704af58b00048e90a5a337",
+    );
+  });
+
+  test("hashInviteCode matches voice-code.ts hashVoiceCode output", () => {
+    expect(hashInviteCode("123456")).toBe(
+      "8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92",
+    );
+    expect(hashInviteCode("0000")).toBe(
+      "9af15b336e6a9619928537df30b2e6a2376569fcf9d7e773eccede65606529a0",
+    );
+    expect(hashInviteCode("987654321")).toBe(
+      "8a9bcf1e51e812d0af8465a8dbcc9f741064bf0af3b3d08e6b0246437c19f7fb",
+    );
+  });
+});
+
+describe("generateInviteToken", () => {
+  test("produces a 43-character base64url token", () => {
+    const token = generateInviteToken();
+    expect(token).toMatch(/^[A-Za-z0-9_-]{43}$/);
+  });
+
+  test("produces unique tokens", () => {
+    expect(generateInviteToken()).not.toBe(generateInviteToken());
+  });
+});
+
+describe("generateInviteCode", () => {
+  test("defaults to 6 digits with no leading zero", () => {
+    const code = generateInviteCode();
+    expect(code).toMatch(/^[1-9]\d{5}$/);
+  });
+
+  test("honors the digit count at both bounds", () => {
+    expect(generateInviteCode(4)).toMatch(/^[1-9]\d{3}$/);
+    expect(generateInviteCode(10)).toMatch(/^[1-9]\d{9}$/);
+  });
+
+  test("rejects out-of-range digit counts", () => {
+    expect(() => generateInviteCode(3)).toThrow();
+    expect(() => generateInviteCode(11)).toThrow();
+  });
+});
+
+describe("isValidE164", () => {
+  test("valid E.164 number", () => {
+    expect(isValidE164("+15551234567")).toBe(true);
+  });
+
+  test("missing + prefix", () => {
+    expect(isValidE164("5551234567")).toBe(false);
+  });
+
+  test("too short", () => {
+    expect(isValidE164("+123")).toBe(false);
+  });
+});
+
+describe("invite-code channel gating", () => {
+  test("allows exactly the redemption-enabled channels", () => {
+    expect([...INVITE_CODE_REDEMPTION_CHANNELS].sort()).toEqual([
+      "email",
+      "slack",
+      "telegram",
+      "whatsapp",
+    ]);
+  });
+
+  test("isInviteCodeRedemptionEnabled matches the allowlist", () => {
+    for (const channel of ["telegram", "whatsapp", "slack", "email"]) {
+      expect(isInviteCodeRedemptionEnabled(channel)).toBe(true);
+    }
+    for (const channel of ["vellum", "platform", "phone", "a2a", "nope"]) {
+      expect(isInviteCodeRedemptionEnabled(channel)).toBe(false);
+    }
+  });
+});
+
+const fullOutcome: InviteRedemptionOutcome = {
+  inviteId: "inv-1",
+  contactId: "c-1",
+  sourceChannel: "telegram",
+  memberExternalUserId: "tg-user-1",
+  memberExternalChatId: "tg-chat-1",
+  displayName: "Member Name",
+  username: "member",
+  sourceConversationId: "conv-1",
+  result: "redeemed",
+};
+
+describe("InviteRedemptionOutcomeSchema", () => {
+  test("round-trips a fully-populated outcome", () => {
+    expect(InviteRedemptionOutcomeSchema.parse(fullOutcome)).toEqual(
+      fullOutcome,
+    );
+  });
+
+  test("parses a minimal outcome", () => {
+    const minimal = {
+      inviteId: "inv-1",
+      contactId: "c-1",
+      sourceChannel: "slack",
+      memberExternalUserId: "U123",
+      result: "already_member",
+    } satisfies InviteRedemptionOutcome;
+    expect(InviteRedemptionOutcomeSchema.parse(minimal)).toEqual(minimal);
+  });
+
+  test("rejects an invalid result", () => {
+    expect(() =>
+      InviteRedemptionOutcomeSchema.parse({
+        ...fullOutcome,
+        result: "definitely_not_a_result",
+      }),
+    ).toThrow();
+  });
+});
+
+describe("invite IPC request schemas", () => {
+  test("RedeemInviteByCodeRequestSchema round-trips full and minimal requests", () => {
+    const full = {
+      code: "123456",
+      sourceChannel: "telegram",
+      externalUserId: "tg-user-1",
+      externalChatId: "tg-chat-1",
+      displayName: "Member Name",
+      username: "member",
+    };
+    expect(RedeemInviteByCodeRequestSchema.parse(full)).toEqual(full);
+    const minimal = { code: "123456", sourceChannel: "email" };
+    expect(RedeemInviteByCodeRequestSchema.parse(minimal)).toEqual(minimal);
+    expect(() =>
+      RedeemInviteByCodeRequestSchema.parse({ code: "", sourceChannel: "" }),
+    ).toThrow();
+  });
+
+  test("RedeemInviteByTokenRequestSchema round-trips full and minimal requests", () => {
+    const full = {
+      token: "raw-token",
+      sourceChannel: "slack",
+      externalUserId: "U123",
+      externalChatId: "D456",
+      displayName: "Member Name",
+      username: "member",
+    };
+    expect(RedeemInviteByTokenRequestSchema.parse(full)).toEqual(full);
+    const minimal = { token: "raw-token", sourceChannel: "slack" };
+    expect(RedeemInviteByTokenRequestSchema.parse(minimal)).toEqual(minimal);
+    expect(() =>
+      RedeemInviteByTokenRequestSchema.parse({ sourceChannel: "slack" }),
+    ).toThrow();
+  });
+
+  test("RedeemVoiceInviteRequestSchema requires caller and code", () => {
+    const request = { callerExternalUserId: "+15555550100", code: "123456" };
+    expect(RedeemVoiceInviteRequestSchema.parse(request)).toEqual(request);
+    expect(() =>
+      RedeemVoiceInviteRequestSchema.parse({ callerExternalUserId: "+1555" }),
+    ).toThrow();
+  });
+
+  test("GetActiveVoiceInviteRequestSchema requires the caller", () => {
+    const request = { callerExternalUserId: "+15555550100" };
+    expect(GetActiveVoiceInviteRequestSchema.parse(request)).toEqual(request);
+    expect(() => GetActiveVoiceInviteRequestSchema.parse({})).toThrow();
+  });
+});
+
+describe("ActiveVoiceInviteSchema", () => {
+  test("round-trips populated and null display fields", () => {
+    const populated = {
+      inviteId: "inv-1",
+      inviteeName: "Friend",
+      guardianName: "Guardian",
+      codeDigits: 6,
+    };
+    expect(ActiveVoiceInviteSchema.parse(populated)).toEqual(populated);
+    const anonymous = {
+      inviteId: "inv-2",
+      inviteeName: null,
+      guardianName: null,
+      codeDigits: 6,
+    };
+    expect(ActiveVoiceInviteSchema.parse(anonymous)).toEqual(anonymous);
+  });
+
+  test("rejects a non-integer codeDigits", () => {
+    expect(() =>
+      ActiveVoiceInviteSchema.parse({
+        inviteId: "inv-1",
+        inviteeName: null,
+        guardianName: null,
+        codeDigits: 6.5,
+      }),
+    ).toThrow();
+  });
+});

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

@@ -92,6 +92,33 @@ export type {
   TrustVerdict,
 } from "./trust-verdict-contract.js";
 
+// Invite contract (shared gateway ↔ daemon) — hash/generate helpers,
+// channel gating, redemption outcome + invite IPC schemas
+export {
+  ActiveVoiceInviteSchema,
+  generateInviteCode,
+  generateInviteToken,
+  GetActiveVoiceInviteRequestSchema,
+  hashInviteCode,
+  hashInviteToken,
+  InviteRedemptionOutcomeSchema,
+  isInviteCodeRedemptionEnabled,
+  isValidE164,
+  RedeemInviteByCodeRequestSchema,
+  RedeemInviteByTokenRequestSchema,
+  RedeemVoiceInviteRequestSchema,
+} from "./invite-contract.js";
+
+export type {
+  ActiveVoiceInvite,
+  GetActiveVoiceInviteRequest,
+  InviteRedemptionOutcome,
+  InviteRedemptionResult,
+  RedeemInviteByCodeRequest,
+  RedeemInviteByTokenRequest,
+  RedeemVoiceInviteRequest,
+} from "./invite-contract.js";
+
 // Guardian delivery contract (daemon → gateway pull) — Zod schemas + derived types
 export {
   GuardianDeliverySchema,