@vellumai/assistant 0.11.2-dev.202608070534.d55eaf1 → 0.11.2-dev.202608070733.a268a16

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

@@ -40,3 +40,42 @@ export function isChannelId(value: unknown): value is ChannelId {
     (CHANNEL_IDS as readonly string[]).includes(value)
   );
 }
+
+/**
+ * The provider key holding each channel's bot credential.
+ *
+ * Two senses of "connected" share the provider registry: a provider the user
+ * authorized so the assistant can act **as them** (`slack`, `discord`,
+ * `google`), and a bot credential letting people reach the assistant **as
+ * itself**. Nothing in a provider key says which, and the naming actively
+ * misleads: `slack` and `discord` name the user integration while their bots
+ * take a `_channel` suffix, yet `telegram` *is* the bot, because Telegram has
+ * no user-identity integration.
+ *
+ * That irregularity is why this is stated rather than derived from the key,
+ * and it is stated here because this file already owns what a channel is.
+ *
+ * Deliberately only the key. What fields each credential requires is declared
+ * once already, per service, in the gateway's credential specs; restating it
+ * here would be a second copy of a different fact.
+ *
+ * Channels absent from this map reach the assistant without a bot credential
+ * of their own: `phone` through the voice provider, `vellum` and `platform`
+ * internally.
+ */
+export const CHANNEL_BOT_PROVIDER = {
+  slack: "slack_channel",
+  discord: "discord_channel",
+  telegram: "telegram",
+} as const satisfies Partial<Record<ChannelId, string>>;
+
+/**
+ * Whether a provider key names a bot the assistant is reached through, rather
+ * than a grant letting it act as the user. This is the "which sense of
+ * connected" question, for any provider key.
+ */
+export function isChannelBotProvider(providerKey: string): boolean {
+  return (Object.values(CHANNEL_BOT_PROVIDER) as readonly string[]).includes(
+    providerKey,
+  );
+}

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

@@ -40,3 +40,42 @@ export function isChannelId(value: unknown): value is ChannelId {
     (CHANNEL_IDS as readonly string[]).includes(value)
   );
 }
+
+/**
+ * The provider key holding each channel's bot credential.
+ *
+ * Two senses of "connected" share the provider registry: a provider the user
+ * authorized so the assistant can act **as them** (`slack`, `discord`,
+ * `google`), and a bot credential letting people reach the assistant **as
+ * itself**. Nothing in a provider key says which, and the naming actively
+ * misleads: `slack` and `discord` name the user integration while their bots
+ * take a `_channel` suffix, yet `telegram` *is* the bot, because Telegram has
+ * no user-identity integration.
+ *
+ * That irregularity is why this is stated rather than derived from the key,
+ * and it is stated here because this file already owns what a channel is.
+ *
+ * Deliberately only the key. What fields each credential requires is declared
+ * once already, per service, in the gateway's credential specs; restating it
+ * here would be a second copy of a different fact.
+ *
+ * Channels absent from this map reach the assistant without a bot credential
+ * of their own: `phone` through the voice provider, `vellum` and `platform`
+ * internally.
+ */
+export const CHANNEL_BOT_PROVIDER = {
+  slack: "slack_channel",
+  discord: "discord_channel",
+  telegram: "telegram",
+} as const satisfies Partial<Record<ChannelId, string>>;
+
+/**
+ * Whether a provider key names a bot the assistant is reached through, rather
+ * than a grant letting it act as the user. This is the "which sense of
+ * connected" question, for any provider key.
+ */
+export function isChannelBotProvider(providerKey: string): boolean {
+  return (Object.values(CHANNEL_BOT_PROVIDER) as readonly string[]).includes(
+    providerKey,
+  );
+}

package/node_modules/@vellumai/service-contracts/src/channels.ts

@@ -40,3 +40,42 @@ export function isChannelId(value: unknown): value is ChannelId {
     (CHANNEL_IDS as readonly string[]).includes(value)
   );
 }
+
+/**
+ * The provider key holding each channel's bot credential.
+ *
+ * Two senses of "connected" share the provider registry: a provider the user
+ * authorized so the assistant can act **as them** (`slack`, `discord`,
+ * `google`), and a bot credential letting people reach the assistant **as
+ * itself**. Nothing in a provider key says which, and the naming actively
+ * misleads: `slack` and `discord` name the user integration while their bots
+ * take a `_channel` suffix, yet `telegram` *is* the bot, because Telegram has
+ * no user-identity integration.
+ *
+ * That irregularity is why this is stated rather than derived from the key,
+ * and it is stated here because this file already owns what a channel is.
+ *
+ * Deliberately only the key. What fields each credential requires is declared
+ * once already, per service, in the gateway's credential specs; restating it
+ * here would be a second copy of a different fact.
+ *
+ * Channels absent from this map reach the assistant without a bot credential
+ * of their own: `phone` through the voice provider, `vellum` and `platform`
+ * internally.
+ */
+export const CHANNEL_BOT_PROVIDER = {
+  slack: "slack_channel",
+  discord: "discord_channel",
+  telegram: "telegram",
+} as const satisfies Partial<Record<ChannelId, string>>;
+
+/**
+ * Whether a provider key names a bot the assistant is reached through, rather
+ * than a grant letting it act as the user. This is the "which sense of
+ * connected" question, for any provider key.
+ */
+export function isChannelBotProvider(providerKey: string): boolean {
+  return (Object.values(CHANNEL_BOT_PROVIDER) as readonly string[]).includes(
+    providerKey,
+  );
+}

package/openapi.yaml

@@ -22151,6 +22151,11 @@ paths:
                             anyOf:
                               - type: string
                               - type: "null"
+                          acts_as:
+                            type: string
+                            enum:
+                              - user
+                              - assistant
                         required:
                           - provider_key
                           - display_name
@@ -22162,6 +22167,7 @@ paths:
                           - supports_managed_mode
                           - managed_service_is_paid
                           - feature_flag
+                          - acts_as
                         additionalProperties: false
                       - type: "null"
                   apps:
@@ -22679,6 +22685,11 @@ paths:
                           anyOf:
                             - type: string
                             - type: "null"
+                        acts_as:
+                          type: string
+                          enum:
+                            - user
+                            - assistant
                       required:
                         - provider_key
                         - display_name
@@ -22690,6 +22701,7 @@ paths:
                         - supports_managed_mode
                         - managed_service_is_paid
                         - feature_flag
+                        - acts_as
                       additionalProperties: false
                 required:
                   - providers

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vellumai/assistant",
-  "version": "0.11.2-dev.202608070534.d55eaf1",
+  "version": "0.11.2-dev.202608070733.a268a16",
   "license": "MIT",
   "type": "module",
   "exports": {

package/src/__tests__/manual-token-reconciliation.test.ts

@@ -139,6 +139,51 @@ describe("syncManualTokenConnection", () => {
     warnings.length = 0;
   });
 
+  // ---- Discord server bot: one required field ----
+
+  test("connects discord_channel once the bot token is stored", async () => {
+    // Seeding the provider without this reconciliation leaves it listed and
+    // permanently disconnected, which is worse than not listing it: the
+    // setup skill stores the token and nothing ever reflects that.
+    setCredentialResult("discord_channel", "bot_token", {
+      value: "bot-token-value",
+      unreachable: false,
+    });
+
+    await syncManualTokenConnection("discord_channel");
+
+    expect(createdConnections.map((c) => c.provider)).toContain(
+      "discord_channel",
+    );
+  });
+
+  test("removes the discord_channel connection when the bot token is gone", async () => {
+    seedConnection("discord_channel");
+    setCredentialResult("discord_channel", "bot_token", {
+      value: undefined,
+      unreachable: false,
+    });
+
+    await syncManualTokenConnection("discord_channel");
+
+    expect(deletedConnectionIds).toContain("conn-discord_channel");
+  });
+
+  test("leaves the discord_channel row alone when the backend is unreachable", async () => {
+    // An unreachable credential store is not evidence the token is gone, so
+    // reconciliation must not read it as a disconnection.
+    seedConnection("discord_channel");
+    setCredentialResult("discord_channel", "bot_token", {
+      value: undefined,
+      unreachable: true,
+    });
+
+    await syncManualTokenConnection("discord_channel");
+
+    expect(deletedConnectionIds).not.toContain("conn-discord_channel");
+    expect(connectionStore["discord_channel"]).toBeDefined();
+  });
+
   // ---- Slack: reachable backend, missing tokens -> removes row ----
 
   test("removes slack_channel connection when bot token is missing and backend is reachable", async () => {

package/src/__tests__/oauth-provider-serializer.test.ts

@@ -291,9 +291,26 @@ describe("serializeProviderSummary", () => {
       supports_managed_mode: true,
       managed_service_is_paid: false,
       feature_flag: null,
+      acts_as: "user",
     });
   });
 
+  test("names which sense of connected a provider represents", () => {
+    // The provider key does not say, and the naming actively misleads:
+    // `slack` is the user integration while its bot is `slack_channel`, but
+    // `telegram` is itself the bot. A caller asking "is X connected?" needs
+    // this to answer which X it found.
+    const sense = (provider: string) =>
+      serializeProviderSummary(makeRow({ provider }))!.acts_as;
+
+    expect(sense("slack")).toBe("user");
+    expect(sense("slack_channel")).toBe("assistant");
+    expect(sense("discord")).toBe("user");
+    expect(sense("discord_channel")).toBe("assistant");
+    expect(sense("telegram")).toBe("assistant");
+    expect(sense("google")).toBe("user");
+  });
+
   test("nullifies missing optional fields", () => {
     const row = makeRow({
       displayLabel: null,

package/src/__tests__/oauth-providers-routes.test.ts

@@ -178,6 +178,7 @@ describe("GET /v1/oauth/providers", () => {
       "supports_managed_mode",
       "managed_service_is_paid",
       "feature_flag",
+      "acts_as",
     ];
 
     for (const provider of providers) {

package/src/cli/commands/oauth/providers.ts

@@ -13,6 +13,8 @@ const log = getCliLogger("cli");
 
 interface SerializedProvider {
   providerKey: string;
+  /** Which sense of connected: a grant to act as the user, or a bot. */
+  actsAs?: "user" | "assistant";
   displayName?: string | null;
   description?: string | null;
   supportsManagedMode?: boolean;
@@ -301,6 +303,7 @@ export function registerProviderCommands(oauth: Command): void {
         dashboardUrl: p.dashboard_url as string | null,
         clientIdPlaceholder: p.client_id_placeholder as string | null,
         featureFlag: p.feature_flag as string | null,
+        actsAs: p.acts_as as "user" | "assistant" | undefined,
       }));
 
       if (opts.providerKey) {

package/src/oauth/byo-connection.ts

@@ -47,6 +47,11 @@ export class BYOOAuthConnection implements OAuthConnection {
       async (token) => {
         const effectiveBaseUrl = req.baseUrl ?? this.baseUrl;
         const isTelegram = this.provider === "telegram";
+        // Discord bot tokens authenticate with the `Bot ` scheme, not
+        // `Bearer`. Sending Bearer here reaches Discord as an unusable
+        // credential and comes back 401, which reads as a revoked token.
+        const authScheme =
+          this.provider === "discord_channel" ? "Bot" : "Bearer";
         const requestPath = isTelegram
           ? buildTelegramBotApiPath(req.path, token)
           : req.path;
@@ -87,7 +92,7 @@ export class BYOOAuthConnection implements OAuthConnection {
           }
         }
         if (!isTelegram) {
-          headers.set("Authorization", `Bearer ${token}`);
+          headers.set("Authorization", `${authScheme} ${token}`);
         }
 
         const resp = await fetch(fullUrl, {

package/src/oauth/credential-token-resolver.ts

@@ -19,6 +19,7 @@ import {
   getSecureKeyResultAsync,
   type SecureKeyResult,
 } from "../security/secure-keys.js";
+import { manualTokenProvider } from "./manual-token-providers.js";
 
 // ── Types ─────────────────────────────────────────────────────────────
 
@@ -44,16 +45,8 @@ export interface ConnectionAccessTokenResult {
  * rather than assuming the OAuth access-token path.
  */
 function manualTokenAccessCredentialKey(provider: string): string | null {
-  switch (provider) {
-    case "slack_channel":
-      return credentialKey("slack_channel", "bot_token");
-    case "telegram":
-      return credentialKey("telegram", "bot_token");
-    case "sanity":
-      return credentialKey("sanity", "api_token");
-    default:
-      return null;
-  }
+  const spec = manualTokenProvider(provider);
+  return spec ? credentialKey(provider, spec.accessField) : null;
 }
 
 /**

package/src/oauth/manual-token-connection.ts

@@ -12,6 +12,10 @@ import { credentialKey } from "../security/credential-key.js";
 import { getSecureKeyResultAsync } from "../security/secure-keys.js";
 import { getTelegramBotUsername } from "../telegram/bot-username.js";
 import { getLogger } from "../util/logger.js";
+import {
+  MANUAL_TOKEN_PROVIDERS,
+  manualTokenProvider,
+} from "./manual-token-providers.js";
 import {
   createConnection,
   deleteConnection,
@@ -135,69 +139,30 @@ export async function syncManualTokenConnection(
     resolvedAccountInfo,
   );
 
-  switch (provider) {
-    case "telegram": {
-      const botTokenResult = await getSecureKeyResultAsync(
-        credentialKey("telegram", "bot_token"),
-      );
-      const webhookSecretResult = await getSecureKeyResultAsync(
-        credentialKey("telegram", "webhook_secret"),
-      );
-      if (botTokenResult.unreachable || webhookSecretResult.unreachable) {
-        log.warn(
-          "Skipping telegram manual-token reconciliation — credential backend unreachable",
-        );
-        return;
-      }
-      if (botTokenResult.value && webhookSecretResult.value) {
-        await ensureManualTokenConnection(provider, accountInfoToStore);
-      } else {
-        removeManualTokenConnection(provider);
-      }
-      return;
-    }
-
-    case "slack_channel": {
-      const botTokenResult = await getSecureKeyResultAsync(
-        credentialKey("slack_channel", "bot_token"),
-      );
-      const appTokenResult = await getSecureKeyResultAsync(
-        credentialKey("slack_channel", "app_token"),
-      );
-      if (botTokenResult.unreachable || appTokenResult.unreachable) {
-        log.warn(
-          "Skipping slack_channel manual-token reconciliation — credential backend unreachable",
-        );
-        return;
-      }
-      if (botTokenResult.value && appTokenResult.value) {
-        await ensureManualTokenConnection(provider, accountInfoToStore);
-      } else {
-        removeManualTokenConnection(provider);
-      }
-      return;
-    }
+  const spec = manualTokenProvider(provider);
+  if (!spec) {
+    return;
+  }
 
-    case "sanity": {
-      const tokenResult = await getSecureKeyResultAsync(
-        credentialKey("sanity", "api_token"),
-      );
-      if (tokenResult.unreachable) {
-        log.warn(
-          "Skipping sanity manual-token reconciliation — credential backend unreachable",
-        );
-        return;
-      }
-      if (tokenResult.value) {
-        await ensureManualTokenConnection(provider, accountInfoToStore);
-      } else {
-        removeManualTokenConnection(provider);
-      }
-      return;
-    }
+  // Every field must be present and readable. An unreachable backend is not
+  // evidence a credential was removed, so the row is left as it stands rather
+  // than being read as a disconnection.
+  const results = await Promise.all(
+    spec.fields.map((field) =>
+      getSecureKeyResultAsync(credentialKey(provider, field)),
+    ),
+  );
+  if (results.some((r) => r.unreachable)) {
+    log.warn(
+      `Skipping ${provider} manual-token reconciliation: credential backend unreachable`,
+    );
+    return;
+  }
 
-    default:
-      return;
+  if (results.every((r) => r.value)) {
+    await ensureManualTokenConnection(provider, accountInfoToStore);
+  } else {
+    removeManualTokenConnection(provider);
   }
 }
 
@@ -214,7 +179,7 @@ export async function syncManualTokenConnection(
  * connection row.
  */
 export async function backfillManualTokenConnections(): Promise<void> {
-  await syncManualTokenConnection("telegram");
-  await syncManualTokenConnection("slack_channel");
-  await syncManualTokenConnection("sanity");
+  for (const provider of Object.keys(MANUAL_TOKEN_PROVIDERS)) {
+    await syncManualTokenConnection(provider);
+  }
 }

package/src/oauth/manual-token-providers.ts

@@ -0,0 +1,62 @@
+/**
+ * Providers whose credentials are pasted in rather than granted through a
+ * browser flow, and what each one stores.
+ *
+ * Two questions are answered together because they are the same fact seen from
+ * two sides, and answering them in separate tables lets them drift: which
+ * fields must be present for the provider to count as configured
+ * (reconciliation), and which single field an API request authenticates with
+ * (token resolution). Slack stores an app token and Telegram a webhook secret,
+ * and neither authenticates a request.
+ *
+ * `accessField` is named rather than taken as the first of `fields`, so
+ * reordering that list cannot silently change which secret gets sent.
+ *
+ * Channel bots are keyed off the shared channel contract, so adding a channel
+ * does not mean remembering this file exists. `sanity` is not in that contract
+ * because it is a user's own API token: manual to enter, but not a bot and not
+ * a channel.
+ *
+ * The gateway declares the same field sets for its own reading of these
+ * credentials (`gateway/src/credential-reader.ts`). One declaration serving
+ * both is worth doing and needs the specs hoisted into a shared package.
+ */
+
+import { CHANNEL_BOT_PROVIDER } from "@vellumai/service-contracts/channels";
+
+export interface ManualTokenProviderSpec {
+  /** Every field that must be present for the provider to count as connected. */
+  fields: readonly string[];
+  /** The one field an API request authenticates with. */
+  accessField: string;
+}
+
+export const MANUAL_TOKEN_PROVIDERS: Record<string, ManualTokenProviderSpec> = {
+  [CHANNEL_BOT_PROVIDER.slack]: {
+    fields: ["bot_token", "app_token"],
+    accessField: "bot_token",
+  },
+  [CHANNEL_BOT_PROVIDER.discord]: {
+    fields: ["bot_token"],
+    accessField: "bot_token",
+  },
+  [CHANNEL_BOT_PROVIDER.telegram]: {
+    fields: ["bot_token", "webhook_secret"],
+    accessField: "bot_token",
+  },
+  sanity: { fields: ["api_token"], accessField: "api_token" },
+};
+
+/**
+ * The spec for a provider, or undefined when it is not a manual-token one.
+ *
+ * Own-property lookup so an inherited key (`constructor`, `__proto__`) reads
+ * as absent rather than returning a function.
+ */
+export function manualTokenProvider(
+  provider: string,
+): ManualTokenProviderSpec | undefined {
+  return Object.prototype.hasOwnProperty.call(MANUAL_TOKEN_PROVIDERS, provider)
+    ? MANUAL_TOKEN_PROVIDERS[provider]
+    : undefined;
+}

package/src/oauth/provider-serializer.ts

@@ -18,6 +18,8 @@ import type { OAuthProviderRow } from "./oauth-store.js";
 export type SerializedProvider = ReturnType<typeof serializeProvider> &
   Record<string, unknown>;
 
+import { isChannelBotProvider } from "@vellumai/service-contracts/channels";
+
 /**
  * Lightweight summary projection of an OAuth provider, suitable for API
  * list responses where full detail is not needed. All keys are snake_case
@@ -34,6 +36,16 @@ export interface SerializedProviderSummary {
   supports_managed_mode: boolean;
   managed_service_is_paid: boolean;
   feature_flag: string | null;
+  /**
+   * Which sense of "connected" this provider represents: `assistant` for a bot
+   * credential people reach the assistant through, `user` for a grant letting
+   * it act as the person who authorized it.
+   *
+   * Derived rather than stored, because the provider key does not say: `slack`
+   * and `discord` name the user integration while their bots take a `_channel`
+   * suffix, yet `telegram` is the bot.
+   */
+  acts_as: "user" | "assistant";
 }
 
 /**
@@ -152,5 +164,6 @@ export function serializeProviderSummary(
     supports_managed_mode: !!row.managedServiceConfigKey,
     managed_service_is_paid: !!row.managedServiceIsPaid,
     feature_flag: row.featureFlag ?? null,
+    acts_as: isChannelBotProvider(row.provider) ? "assistant" : "user",
   };
 }

package/src/oauth/seed-providers.ts

@@ -454,16 +454,15 @@ export const PROVIDER_SEED_DATA: Record<
     pingUrl: "https://discord.com/api/v10/users/@me",
     baseUrl: "https://discord.com/api/v10",
     displayLabel: "Discord",
-    description: "Servers and messages",
+    // Your servers, not their contents. These scopes reach the guild list and
+    // your membership in one; reading messages is not among them. Discord
+    // documents `messages.read` as local RPC only, so requesting it would put
+    // a permission on the consent screen that grants nothing here.
+    description: "Your servers and profile",
     dashboardUrl: "https://discord.com/developers/applications",
     clientIdPlaceholder: null,
     logoUrl: "https://cdn.simpleicons.org/discord",
-    defaultScopes: [
-      "identify",
-      "guilds",
-      "guilds.members.read",
-      "messages.read",
-    ],
+    defaultScopes: ["identify", "guilds", "guilds.members.read"],
     availableScopes:
       "https://discord.com/developers/docs/topics/oauth2#shared-resources-oauth2-scopes",
     loopbackPort: 17326,
@@ -777,6 +776,35 @@ export const PROVIDER_SEED_DATA: Record<
     ],
   },
 
+  // The bot that sits in a server and talks to people there, which is a
+  // different thing from the `discord` integration above and starts at the
+  // same Discord authorize URL. Both are reasonably called "connecting
+  // Discord", so each has to be nameable on its own. The bot token is already
+  // stored under this key by `skills/discord-app-setup`; seeding the provider
+  // is what lets the product tell the two apart.
+  discord_channel: {
+    provider: "discord_channel",
+    authorizeUrl: "urn:manual-token",
+    tokenExchangeUrl: "urn:manual-token",
+    pingUrl: "https://discord.com/api/v10/users/@me",
+    baseUrl: "https://discord.com/api/v10",
+    displayLabel: "Discord Server",
+    description: "A bot in your server",
+    dashboardUrl: "https://discord.com/developers/applications",
+    clientIdPlaceholder: null,
+    requiresClientSecret: false,
+    logoUrl: "https://cdn.simpleicons.org/discord",
+    defaultScopes: [],
+    injectionTemplates: [
+      {
+        hostPattern: "discord.com",
+        injectionType: "header",
+        headerName: "Authorization",
+        valuePrefix: "Bot ",
+      },
+    ],
+  },
+
   telegram: {
     provider: "telegram",
     authorizeUrl: "urn:manual-token",

package/src/runtime/routes/oauth-providers.ts

@@ -397,6 +397,7 @@ export const oauthProviderSummarySchema = z.object({
   supports_managed_mode: z.boolean(),
   managed_service_is_paid: z.boolean(),
   feature_flag: z.string().nullable(),
+  acts_as: z.enum(["user", "assistant"]),
 });
 
 /**