@tangle-network/agent-integrations 0.25.7 → 0.27.0

package/dist/index-BQY5ry2s.d.ts

@@ -1,808 +0,0 @@
-/**
- * Connector primitives — the contract a concrete first-party integration
- * (Google Calendar, HubSpot, Stripe, ...) implements. Lower level than the
- * hub-side `IntegrationProvider` interface from `../index.ts`: a single
- * `IntegrationProvider` typically wraps several connectors (e.g., a
- * "first-party" provider that lists all your shipped connectors as a
- * single catalog).
- *
- * Layering:
- *
- *   IntegrationHub                                — vendor-neutral facade (../index.ts)
- *     ↓
- *   IntegrationProvider                           — one per gateway or first-party provider
- *     ↓
- *   ConnectorAdapter (this file)                  — one per integration (Google Calendar, ...)
- *     ↓
- *   upstream HTTP API                             — vendor SDK / fetch / OAuth
- *
- * Three load-bearing decisions encoded here:
- *
- * 1. Capabilities are typed (`read` vs `mutation`). Every mutation MUST
- *    declare a CAS strategy. Conflict resolution is the SDK's job, not the
- *    connector's. `validateConnectorManifest()` rejects unsafe manifests
- *    before a connector is registered.
- *
- * 2. ConsistencyModel pins what the rest of the system can assume:
- *      authoritative → the source IS the truth (Calendar, payments)
- *      cache         → we mirror with TTL and may serve stale (price list)
- *      advisory      → informational only (FAQ doc)
- *    Agent planners can (and should) refuse to promise outcomes based on
- *    `cache`/`advisory` data without a live `authoritative` confirmation.
- *
- * 3. Capabilities surface to the calling agent's tool registry by
- *    transformation, not by hand-wiring. Adding a connector automatically
- *    expands the agent's toolbelt for that specific user without touching
- *    the prompt or runner.
- */
-/** Minimal JSON-schema shape used for capability arg validation. We
- *  intentionally don't pull `@types/json-schema` — most consumers already
- *  declare parameters as `Record<string, unknown>` and the
- *  shape is whatever the LLM SDK's structured-output expects. Keep the
- *  contract loose at the boundary; tighten via runtime zod where needed. */
-type CapabilityParameterSchema = Record<string, unknown>;
-/** What the rest of the system is allowed to assume about freshness. */
-type ConsistencyModel = 'authoritative' | 'cache' | 'advisory';
-/** Capability classes. `read` is safe to retry; `mutation` must go through
- *  MutationGuard (CAS + idempotency). `subscribe` is reserved for future
- *  push-driven sources (webhook callbacks) and is not yet wired. */
-type CapabilityClass = 'read' | 'mutation' | 'subscribe';
-/** Compare-and-swap strategy a mutation uses to detect conflicts. */
-type CASStrategy = 
-/** Upstream returns an etag/sequence on read, accepts If-Match on write
- *  (Google Calendar, GitHub, GDocs revision_id). The connector returns
- *  412 / Precondition Failed on conflict; the SDK maps to ResourceContention. */
-'etag-if-match'
-/** Upstream guarantees exactly-once-per-key (Stripe, idempotent webhooks).
- *  The SDK passes the idempotency key through; no etag check. */
- | 'native-idempotency'
-/** No upstream concurrency control. Connector MUST do read-then-write
- *  and verify nothing changed in-between (best-effort). Suitable only
- *  for low-contention single-user resources; rejected for any
- *  consistencyModel='authoritative' write that may race. */
- | 'optimistic-read-verify'
-/** Source is not contended (e.g. logging, telemetry). Mutations are
- *  fire-and-forget. Marks the capability as not eligible for
- *  authoritative writes. */
- | 'none';
-interface CapabilityRead {
-    name: string;
-    class: 'read';
-    description: string;
-    /** JSON-schema for the tool args the agent passes when invoking. */
-    parameters: CapabilityParameterSchema;
-    /** Optional: declare which scopes (per the connector manifest) this
-     *  capability requires. The capability is hidden from the agent's
-     *  tool registry if the user's grant didn't include them. */
-    requiredScopes?: string[];
-}
-interface CapabilityMutation {
-    name: string;
-    class: 'mutation';
-    description: string;
-    parameters: CapabilityParameterSchema;
-    /** Mandatory: how does the connector guarantee at-most-once + conflict-detect? */
-    cas: CASStrategy;
-    /** True for capabilities that affect resources outside the calling user
-     *  (e.g. booking against a shared calendar, charging a card). The agent's
-     *  planner treats these specially: requires explicit caller confirmation
-     *  before the call. */
-    externalEffect: boolean;
-    requiredScopes?: string[];
-}
-type Capability = CapabilityRead | CapabilityMutation;
-/** OAuth2 scope catalog the user has granted us, plus arbitrary metadata
- *  the connector pinned at connect-time (calendar id, sheet id, webhook
- *  url, …). `metadata` MUST NOT contain secrets — those go in the
- *  encrypted credentials envelope. */
-interface DataSourceMetadata {
-    scopes: string[];
-    [key: string]: unknown;
-}
-/** A connected, authenticated, ready-to-call data source for a project.
- *  Persistence shape mirrors the product's connection/source row but normalized — the
- *  encrypted credentials envelope is decrypted at hand-out time and held
- *  in memory only for the duration of the call. */
-interface ResolvedDataSource {
-    id: string;
-    projectId: string;
-    publishedAgentId: string | null;
-    kind: string;
-    label: string;
-    consistencyModel: ConsistencyModel;
-    scopes: string[];
-    metadata: Record<string, unknown>;
-    /** Unwrapped credentials handed to the connector at call-time. Never
-     *  persisted in this shape; never logged. */
-    credentials: ConnectorCredentials;
-    status: 'active' | 'revoked' | 'error';
-}
-/** Discriminated union of credential shapes. Connectors that need new
- *  shapes extend this union — `kind` is sealed via the tagged pattern so
- *  TypeScript catches an exhaustiveness gap at compile time. */
-type ConnectorCredentials = {
-    kind: 'oauth2';
-    accessToken: string;
-    refreshToken?: string;
-    expiresAt?: number;
-} | {
-    kind: 'api-key';
-    apiKey: string;
-} | {
-    kind: 'custom';
-    values: Record<string, unknown>;
-} | {
-    kind: 'hmac';
-    secret: string;
-} | {
-    kind: 'none';
-};
-/** Result of a read capability invocation. */
-interface CapabilityReadResult {
-    /** Free-form payload — the connector's data shape. The agent receives
-     *  this as the tool result; planners consume it via JSON-shape contract
-     *  declared in the capability's `parameters` (output schema). */
-    data: unknown;
-    /** Optional etag/sequence the caller can reuse for a subsequent CAS
-     *  mutation. */
-    etag?: string;
-    /** When this read happened (UTC ms since epoch). */
-    fetchedAt: number;
-}
-/** Result of a mutation capability invocation. Either committed (with the
- *  resulting etag/sequence so the caller can chain mutations), or
- *  contended (the upstream rejected with a state mismatch — the agent
- *  should re-read and retry, or surface alternatives to the caller). */
-type CapabilityMutationResult = {
-    status: 'committed';
-    data: unknown;
-    etagAfter?: string;
-    committedAt: number;
-    /** True iff this commit was returned from the idempotency store
-     *  rather than executed against upstream. The caller can use this
-     *  to suppress confirmation messages on retry. */
-    idempotentReplay: boolean;
-} | {
-    status: 'conflict';
-    /** Best-effort alternative options the upstream surfaced (e.g.,
-     *  next-available calendar slots after a booking conflict). */
-    alternatives: unknown[];
-    /** The current authoritative state, if the connector could re-read
-     *  cheaply. */
-    currentState?: unknown;
-    message: string;
-} | {
-    status: 'rate-limited';
-    /** Wall-clock ms the caller should wait before retrying. The SDK
-     *  computes this from the bucket's refill schedule so the agent
-     *  doesn't have to guess. */
-    retryAfterMs: number;
-    message: string;
-};
-/** Inputs the SDK passes into the connector's executeRead / executeMutation. */
-interface ConnectorInvocation {
-    source: ResolvedDataSource;
-    capabilityName: string;
-    args: Record<string, unknown>;
-    /** Idempotency key the caller (or the SDK's defaulting policy) supplied.
-     *  Always present at the connector boundary — the SDK manufactures one
-     *  if the agent didn't pass one. */
-    idempotencyKey: string;
-    /** Optional caller-supplied etag the connector should send as If-Match. */
-    expectedEtag?: string;
-    /** Product/session id (if any) for forensic logging. */
-    callSessionId?: string;
-}
-/** A single inbound event extracted from a push payload. The webhook
- *  receiver persists one `InboundEvent` row per entry the connector returns. */
-interface InboundEvent {
-    eventType: string;
-    providerEventId?: string;
-    payload: Record<string, unknown>;
-}
-/** Adapter response from an inbound-webhook dispatch. The receiver persists
- *  every `events[]` entry, then either honors the connector's `response`
- *  override (Slack `url_verification` echo, provider-specific 2xx body) or
- *  defaults to `{status: 200, body: {received: true, count: events.length}}`. */
-interface EventHandlerResult {
-    events: InboundEvent[];
-    /** Optional: how to respond to the provider. Stripe wants 200 within
-     *  30s; Slack wants the challenge param echoed. */
-    response?: {
-        status: number;
-        body: unknown;
-        headers?: Record<string, string>;
-    };
-}
-/**
- * Connector adapter — one per integration kind. Stateless. The SDK holds
- * the persistence + crypto + mutation-guard concerns; the adapter only
- * knows how to talk to its upstream.
- */
-interface ConnectorAdapter {
-    /** Manifest entry the registry uses to render UI + validate args. */
-    manifest: ConnectorManifest;
-    /** Read invocation. Required when manifest.capabilities contains reads.
-     *  Should return whatever shape the capability declared
-     *  in its parameters output schema. */
-    executeRead?(inv: ConnectorInvocation): Promise<CapabilityReadResult>;
-    /** Mutation invocation. Required when manifest.capabilities contains mutations.
-     *  Throws ResourceContention on a CAS miss; throws
-     *  any other Error for upstream failures. The MutationGuard wraps this
-     *  with idempotency-key short-circuit + audit logging — adapters do
-     *  NOT manage their own dedup. */
-    executeMutation?(inv: ConnectorInvocation): Promise<CapabilityMutationResult>;
-    /** Inbound webhook signature verifier. Called BEFORE handleInboundEvent.
-     *  MUST use constant-time comparison (`crypto.timingSafeEqual`) for any
-     *  HMAC check. The receiver returns 401 on `valid=false` without invoking
-     *  handleInboundEvent. Optional: connectors that don't accept push events
-     *  omit this method and the receiver returns 405 for the kind. */
-    verifySignature?(input: {
-        rawBody: string;
-        headers: Record<string, string | string[] | undefined>;
-        source: ResolvedDataSource;
-    }): {
-        valid: boolean;
-        reason?: string;
-    };
-    /** Inbound webhook dispatch. Called AFTER verifySignature passes. The
-     *  adapter parses the provider payload and emits zero-or-more
-     *  `InboundEvent` rows; the receiver persists them as one row each (modulo
-     *  the (dataSourceId, providerEventId) dedup unique). The optional
-     *  `response` overrides the receiver's default 200 (Slack `url_verification`
-     *  needs to echo the challenge in the body to pass Slack's app-config check). */
-    handleInboundEvent?(input: {
-        source: ResolvedDataSource;
-        rawBody: string;
-        headers: Record<string, string | string[] | undefined>;
-    }): Promise<EventHandlerResult>;
-    /** OAuth callback handler — exchanges the auth code for tokens, returns
-     *  the credentials envelope + scopes + metadata. Only present for
-     *  oauth2-style adapters. */
-    exchangeOAuth?(input: {
-        code: string;
-        state: string;
-        codeVerifier: string;
-        redirectUri: string;
-    }): Promise<{
-        credentials: ConnectorCredentials;
-        scopes: string[];
-        metadata: Record<string, unknown>;
-    }>;
-    /** Refresh access token. Only required for oauth2 adapters with
-     *  short-lived access tokens. */
-    refreshToken?(input: ConnectorCredentials): Promise<ConnectorCredentials>;
-    /** Health check — invoked when the user clicks "Test connection" in the
-     *  UI. Should perform the cheapest possible read that proves the grant
-     *  is still valid. Returns `{ok: false, reason}` rather than throwing
-     *  for the common case (token expired, scope missing). */
-    test(source: ResolvedDataSource): Promise<{
-        ok: true;
-    } | {
-        ok: false;
-        reason: string;
-    }>;
-}
-/** Static manifest a connector module exports. Drives the UI catalog,
- *  scope display, capability discovery for the agent's tool registry. */
-interface ConnectorManifest {
-    /** Stable kind id used as the foreign key in DataSource.kind. */
-    kind: string;
-    /** Human label shown in the UI catalog. */
-    displayName: string;
-    /** One-paragraph description shown next to the connect button. */
-    description: string;
-    /** Auth shape this connector requires. */
-    auth: AuthSpec;
-    /** Capability catalog — the agent's tool registry derives ToolDefinition
-     *  entries from this list at request time. */
-    capabilities: Capability[];
-    /** ConsistencyModel default for this kind — overridable per DataSource
-     *  if a particular instance is special (e.g., a user marks a sheet as
-     *  `cache` because they refresh it nightly). */
-    defaultConsistencyModel: ConsistencyModel;
-    /** Connector category for UI grouping. */
-    category: 'calendar' | 'spreadsheet' | 'crm' | 'doc' | 'webhook' | 'storage' | 'comms' | 'commerce' | 'other';
-    /** Optional icon URL or named icon. */
-    icon?: string;
-    /** Optional per-kind rate-limit budget. The SDK enforces it inside
-     *  `executeGuardedMutation` and the read path of `/invoke`. Omit to
-     *  leave the connector unrestricted. */
-    rateLimit?: RateLimitSpec;
-}
-/** Token-bucket budget the SDK enforces against the connector's upstream.
- *  We meter on OUR side rather than letting the upstream reject so a
- *  chatty agent can't burn quota that's shared across customers (almost
- *  every OAuth client is). */
-interface RateLimitSpec {
-    /** Max requests per window. */
-    requests: number;
-    /** Window in ms. */
-    windowMs: number;
-    /** Whether to apply across all DataSources sharing the same OAuth
-     *  client (true; default), or per-DataSource (false). The former
-     *  matches how upstreams meter (per-app), so almost always pick true. */
-    scope?: 'oauth-client' | 'data-source';
-}
-type AuthSpec = {
-    kind: 'oauth2';
-    /** Authorization endpoint URL. */
-    authorizationUrl: string;
-    /** Token endpoint URL. */
-    tokenUrl: string;
-    /** Scopes requested in the authorization grant. The user UI shows
-     *  these so the customer knows what's being shared. */
-    scopes: string[];
-    /** Whether the connector supports incremental authorization (Google
-     *  does; many don't). */
-    incremental?: boolean;
-    /** Env-var name holding the OAuth client_id. */
-    clientIdEnv: string;
-    /** Env-var name holding the OAuth client_secret. */
-    clientSecretEnv: string;
-    /** Optional extra params attached to the authorization URL (e.g.,
-     *  Google's `access_type=offline&prompt=consent` to obtain refresh
-     *  tokens). */
-    extraAuthParams?: Record<string, string>;
-} | {
-    kind: 'api-key';
-    /** UI hint shown when collecting the key. */
-    hint: string;
-} | {
-    kind: 'hmac';
-} | {
-    kind: 'none';
-};
-/** Thrown by `executeMutation` when upstream rejects on CAS — caught and
- *  rewrapped by MutationGuard. */
-declare class ResourceContention extends Error {
-    readonly alternatives: unknown[];
-    readonly currentState?: unknown | undefined;
-    readonly name = "ResourceContention";
-    constructor(message: string, alternatives?: unknown[], currentState?: unknown | undefined);
-}
-/** Thrown when the connector finds the user's grant has been revoked or
- *  the access token is no longer valid AND refresh failed. Surfaces to
- *  the UI as "Reconnect required". */
-declare class CredentialsExpired extends Error {
-    readonly dataSourceId: string;
-    readonly name = "CredentialsExpired";
-    constructor(message: string, dataSourceId: string);
-}
-interface ConnectorManifestValidationIssue {
-    path: string;
-    message: string;
-}
-interface ConnectorManifestValidationResult {
-    ok: boolean;
-    issues: ConnectorManifestValidationIssue[];
-}
-/** Validate the static connector manifest before a provider registers it.
- *  This catches the expensive mistakes early: duplicate capability names,
- *  mutation capabilities without CAS, authoritative fire-and-forget writes,
- *  and invalid rate-limit specs. */
-declare function validateConnectorManifest(manifest: ConnectorManifest): ConnectorManifestValidationResult;
-declare function assertValidConnectorManifest(manifest: ConnectorManifest): void;
-
-/**
- * Google Calendar connector — CAS reference implementation.
- *
- * Scopes: `https://www.googleapis.com/auth/calendar` covers list/insert/
- * patch on the user's calendars. We could split read/write but for v1 the
- * single scope keeps the consent screen simple; an operator who wants
- * read-only-Calendar can pick a different `kind` later (`google-calendar-readonly`).
- *
- * The two capabilities the agent actually needs:
- *
- *   list_availability(calendarId, timeMin, timeMax)
- *     → {busy: [{start, end}], events: [{id, etag, start, end, summary}]}
- *     Read; no CAS. Cheap (events.list).
- *
- *   book_slot(calendarId, start, end, summary, attendees?)
- *     → {eventId, etag}
- *     Mutation. CAS by Calendar's own conflict-detection: we re-list
- *     events for the requested window inside the same call, and if any
- *     OVERLAP exists we return `conflict` with the next-3 free slots
- *     mined from the user's freebusy, instead of inserting.
- *
- * Why pre-flight read-then-insert rather than relying on If-Match:
- * `events.insert` doesn't take If-Match (you can't precondition an
- * insert against a non-existent resource). Calendar's own
- * `freebusy.query` is the canonical conflict signal. The whole flow is:
- *
- *   1. freebusy.query for [start, end] on this calendarId
- *   2. if busy → emit ResourceContention with next-3 free slots
- *      (computed by walking forward in 30-min steps until 3 free
- *      windows of (end-start) duration found)
- *   3. else events.insert with idempotency-key as `requestId` (a Calendar
- *      API feature that gives us per-key dedup at upstream)
- *
- * Step 3's `requestId` parameter means a retry of the same idempotency
- * key on the same calendar will return the original event rather than
- * creating a duplicate, which composes correctly with our MutationGuard's
- * idempotency record (which short-circuits before ever hitting upstream
- * on the second call). Defense-in-depth.
- */
-
-/** OAuth client config the factory closes over. Caller resolves these
- *  at construction time (env, DB, secret manager — package doesn't care). */
-interface GoogleCalendarOptions {
-    clientId: string;
-    clientSecret: string;
-}
-declare function googleCalendar(opts: GoogleCalendarOptions): ConnectorAdapter;
-
-/**
- * Google Sheets connector — live KB source + writable rows.
- *
- * The flagship for the "agent reads from a live spreadsheet" UX. The
- * customer points the connection at a Sheet (spreadsheetId + sheetName +
- * headerRow). We expose:
- *
- *   list_rows(filter?, limit?)
- *     → {rows: [{...header→cell}], nextCursor?}
- *     Cheap; just spreadsheets.values.get with the configured range.
- *
- *   query_rows(predicate)
- *     → same shape as list_rows but with a structured filter (k=v pairs
- *     ANDed together). Simple and explainable; no SQL.
- *
- *   update_row(rowKey, patch)
- *     → {row: {...header→cell}, updatedRange}
- *     Mutation. CAS via Sheets' spreadsheets.values.update + a
- *     pre-flight read of the row's revisionId-equivalent hash. Sheets
- *     doesn't expose a per-row etag, so we synthesize one — see
- *     `rowFingerprint`. If the fingerprint doesn't match what the agent
- *     last read, we surface ResourceContention with the current row in
- *     `currentState`.
- *
- * KB binding: when a Sheet is `consistencyModel: 'cache'` (the default
- * for spreadsheets — they're slow-moving), the system also indexes the
- * rows as KB chunks. The KB build pipeline calls `list_rows` and emits
- * one markdown page per row; on a connector-level "refresh" event the
- * agent's KB rebuilds.
- */
-
-/** OAuth client config the factory closes over. Caller resolves these
- *  at construction time (env, DB, secret manager — package doesn't care). */
-interface GoogleSheetsOptions {
-    clientId: string;
-    clientSecret: string;
-}
-declare function googleSheets(opts: GoogleSheetsOptions): ConnectorAdapter;
-
-/**
- * Microsoft Graph Calendar connector — the Outlook half of the
- * voice-agent's "book me a slot" surface.
- *
- * Mirrors the Google Calendar pattern almost line-for-line, with two
- * upstream-specific quirks worth calling out:
- *
- *   1. Graph exposes `@odata.etag` on every event resource AND honors
- *      `If-Match` on `events.patch` / `events.delete`. So unlike Calendar
- *      (insert can't be preconditioned against a non-existent resource),
- *      we DO get real etag CAS for updates after the booking. We still
- *      use the freebusy pre-flight for the create path, because the
- *      "two callers grab the same slot" race happens before any event
- *      exists.
- *
- *   2. `getSchedule` is the Graph equivalent of `freeBusy.query`. Same
- *      shape: send `[start, end]` plus the calendar's email/UPN, get
- *      back a `scheduleItems` list of busy windows.
- *
- * Why the same flow ports cleanly: the conflict mode is identical
- * ("did someone else grab this slot between read and write?"). The
- * mechanism — pre-flight read + idempotent insert — composes regardless
- * of whether upstream gives us a request-id dedup feature. Graph does
- * not have a `requestId` analogue on `events.create`, so we rely
- * exclusively on MutationGuard's idempotency-key short-circuit ABOVE
- * the connector. That layer prevents duplicate inserts on retry.
- */
-
-/** OAuth client config the factory closes over. Caller resolves these
- *  at construction time (env, DB, secret manager — package doesn't care). */
-interface MicrosoftCalendarOptions {
-    clientId: string;
-    clientSecret: string;
-}
-declare function microsoftCalendar(opts: MicrosoftCalendarOptions): ConnectorAdapter;
-
-/**
- * HubSpot CRM connector — three load-bearing capabilities, picked to
- * cover the voice-agent's CRM hot path without trying to swallow all of
- * HubSpot's surface in v1.
- *
- *   find_contact(email)
- *     → {contact: {id, properties}} | {found: false}
- *     POST /crm/v3/objects/contacts/search with an email-equality filter.
- *     Cheap, idempotent, no CAS needed (read).
- *
- *   upsert_contact(email, properties)
- *     → {contactId, created}
- *     Mutation. CAS strategy = native-idempotency, BUT: HubSpot's
- *     `idempotencyKey` query param is ONLY available on the v3 *batch*
- *     endpoints (`/crm/v3/objects/contacts/batch/upsert`). The
- *     single-record endpoints don't honor it. We use the batch endpoint
- *     with a single-element array to get native idempotency on retry.
- *
- *   create_note(contactId, body)
- *     → {noteId}
- *     Mutation that logs a note engagement on a contact and associates
- *     it. Notes are append-only — there's no conflict to detect — so we
- *     use native-idempotency via the same batch trick on
- *     `/crm/v3/objects/notes/batch/create`.
- *
- * Why three and not thirty: the agent's leverage on HubSpot is
- * "remember who I just spoke to". `find_contact` lets the agent address
- * a returning caller by name; `upsert_contact` captures a new one
- * without duplicates; `create_note` writes the call's outcome as a CRM
- * activity. Anything beyond these (deals, tickets, lists) lives in
- * Tier-2 specific kinds — keeping the manifest tight keeps the agent's
- * tool registry comprehensible.
- */
-
-/** OAuth client config the factory closes over. Caller resolves these
- *  at construction time (env, DB, secret manager — package doesn't care). */
-interface HubSpotOptions {
-    clientId: string;
-    clientSecret: string;
-}
-declare function hubspot(opts: HubSpotOptions): ConnectorAdapter;
-
-/**
- * Slack connector — bot-token OAuth, three messaging-oriented capabilities.
- *
- *   post_message(channel, text|blocks)  → mutation; cas: 'none'
- *   lookup_user(email)                  → read
- *   list_channels(types?, limit?)       → read
- *
- * Why `cas: 'none'` is acceptable here (and only here in this batch):
- * Slack messages are advisory — we set
- * `defaultConsistencyModel: 'advisory'`. The registry validator allows
- * `cas: 'none'` only on non-authoritative connectors precisely so that
- * append-only messaging surfaces don't have to invent fake CAS theatre.
- * The agent's planner already treats `advisory` data as informational
- * and does not promise outcomes based on its post results without
- * a separate authoritative confirm. MutationGuard's idempotency-key
- * dedup remains in force above the connector — a retry of the same
- * post_message call will short-circuit before reaching Slack.
- *
- * Auth: standard OAuth2. Slack's `/oauth.v2.access` returns a bot
- * `access_token` (`xoxb-…`) but does NOT return a refresh_token unless
- * the app has rotated tokens enabled. Bot tokens are long-lived by
- * default; we surface refreshToken handling but treat its absence as
- * normal rather than an error.
- */
-
-/** OAuth client config the factory closes over. Caller resolves these
- *  at construction time (env, DB, secret manager — package doesn't care). */
-interface SlackOptions {
-    clientId: string;
-    clientSecret: string;
-}
-declare function slack(opts: SlackOptions): ConnectorAdapter;
-
-/**
- * Notion database connector — query + page-level CRUD against a single
- * connected database.
- *
- *   query_database(filter?, pageSize?)  → read
- *   create_page(properties)             → mutation; cas: 'native-idempotency'
- *   update_page(pageId, properties)     → mutation; cas: 'etag-if-match'
- *
- * CAS quirks worth flagging:
- *
- *   1. Notion added support for the `Idempotency-Key` HTTP header on
- *      mutating requests. We forward our SDK's idempotency key on
- *      create_page, which gives at-most-once semantics under the same
- *      key for ~24h. MutationGuard's record short-circuits above us;
- *      Notion's dedup is the second line of defense.
- *
- *   2. Notion does NOT expose a per-page etag the way Graph does. The
- *      canonical drift signal is `last_edited_time` (RFC3339). Our
- *      `update_page` capability accepts an `expectedLastEditedTime` arg;
- *      if supplied, we GET the page first and compare. Mismatch →
- *      ResourceContention with the current page state. Conflict-free
- *      callers can omit the field (last-write-wins, the Notion default).
- *
- * Auth: standard OAuth2. Notion's token endpoint follows RFC 6749 with
- * one twist — the workspace_id and bot_id come back in the response and
- * we stash them in `metadata` so the agent can address resources by
- * workspace where useful.
- */
-
-/** OAuth client config the factory closes over. Caller resolves these
- *  at construction time (env, DB, secret manager — package doesn't care). */
-interface NotionDatabaseOptions {
-    clientId: string;
-    clientSecret: string;
-}
-declare function notionDatabase(opts: NotionDatabaseOptions): ConnectorAdapter;
-
-type RestCredentialPlacement = {
-    kind: 'bearer';
-} | {
-    kind: 'header';
-    header: string;
-    prefix?: string;
-} | {
-    kind: 'query';
-    parameter: string;
-};
-interface RestConnectorSpec {
-    kind: string;
-    displayName: string;
-    description: string;
-    auth: ConnectorAdapter['manifest']['auth'];
-    category: ConnectorAdapter['manifest']['category'];
-    defaultConsistencyModel: ConnectorAdapter['manifest']['defaultConsistencyModel'];
-    baseUrl: string | {
-        metadataKey: string;
-        fallback?: string;
-    };
-    credentialPlacement?: RestCredentialPlacement;
-    defaultHeaders?: Record<string, string>;
-    capabilities: RestOperationSpec[];
-    test?: RestRequestSpec;
-}
-interface RestOperationSpec {
-    name: string;
-    class: 'read' | 'mutation';
-    description: string;
-    parameters: Record<string, unknown>;
-    requiredScopes?: string[];
-    request: RestRequestSpec;
-    cas?: 'etag-if-match' | 'native-idempotency' | 'optimistic-read-verify' | 'none';
-    externalEffect?: boolean;
-}
-interface RestRequestSpec {
-    method: 'GET' | 'POST' | 'PUT' | 'PATCH' | 'DELETE';
-    path: string;
-    query?: Record<string, string | number | boolean | undefined>;
-    headers?: Record<string, string>;
-    body?: 'args' | string | Record<string, unknown>;
-}
-declare function declarativeRestConnector(spec: RestConnectorSpec): ConnectorAdapter;
-
-/**
- * Twilio SMS connector — outbound texts + recent-message lookup. The
- * agent's "send the caller a confirmation link" surface.
- *
- * Auth: HTTP Basic (Account SID + Auth Token). Twilio's API key auth
- * also supports SID/Secret pairs; we accept either by treating the
- * stored apiKey envelope as `accountSid:authToken` (or
- * `accountSid:keySid:secret`) — the connector parses it at call time.
- *
- *   send_sms(to, body)
- *     Mutation. CAS = native-idempotency. Twilio added the
- *     `Idempotency-Key` HTTP header to POST /Messages in 2024 — same
- *     key + same args within 24h returns the original Message resource
- *     instead of sending a second SMS. MutationGuard's record short-
- *     circuits before us; Twilio's own dedup is defense-in-depth.
- *
- *   lookup_number(phoneNumber)
- *     Read. Hits /v1/PhoneNumbers/{e164} on Lookup API. Confirms the
- *     number is real, returns carrier info if the caller has Lookup
- *     enabled on their account.
- *
- *   find_recent_messages(toOrFrom?, limit?)
- *     Read. Returns the most recent Messages on the account, optionally
- *     filtered by To/From. Useful for "did the confirmation actually
- *     send?" introspection inside an agent run.
- */
-
-declare const twilioSmsConnector: ConnectorAdapter;
-
-/**
- * Stripe pack connector — single connector kind packing 3 capabilities,
- * validating the "connector pack" concept (one auth handshake, multiple
- * related capabilities) without exploding the registry into
- * `stripe-customers`, `stripe-checkout`, `stripe-invoices` triplets.
- *
- *   find_customer(email)               → read; CAS n/a
- *   create_invoice(customerId, items)  → mutation; cas: 'native-idempotency'
- *   create_checkout_session(...)       → mutation; cas: 'native-idempotency'
- *
- * Auth: API key (Stripe restricted key). Operator pastes the key into
- * the Connections UI. We never see their account password / OAuth flow;
- * Stripe restricted keys are the customer's responsibility (they pick
- * which permissions the key carries). The kind exposes a webhook URL
- * post-connect for the operator to paste into the Stripe dashboard —
- * we'll wire the receiver to P-3's inbound webhook surface in a later
- * commit. That URL is returned in `metadata.webhookUrl` so the UI can
- * render it.
- *
- * Why this is the textbook example of `cas: 'native-idempotency'`:
- * Stripe's `Idempotency-Key` HTTP header is THE reference implementation
- * of native idempotency. Same key + same args within 24h returns the
- * stored response (Stripe's words, not ours). Same key + different args
- * → 400 with `idempotency_error`. We forward the SDK's idempotency key
- * directly. MutationGuard short-circuits before us on retry; Stripe's
- * own dedup is the second line of defense.
- */
-
-declare const stripePackConnector: ConnectorAdapter;
-
-/**
- * Universal webhook connector — the long-tail escape hatch.
- *
- * The user declares a target URL + a JSON-schema for the request body
- * the agent should send, plus an optional shared secret. We sign every
- * outbound POST with HMAC-SHA256 over `timestamp.body` and forward the
- * agent's idempotency key as a header. The receiving system enforces
- * its own idempotency.
- *
- * One adapter, two capabilities. Both arity-1 — `body` is whatever JSON
- * the agent's planner constructs from the operator-defined schema (which
- * lives in DataSource.metadata.requestSchema). The agent's planner reads
- * that schema at request time and constructs valid args.
- *
- * Why one connector covers 50 systems badly and 1 system well: the agent
- * gets a generic "send_event" tool that doesn't *know* what the upstream
- * does with the payload. That's fine for fire-and-forget event posting
- * (Zapier-style); it's wrong for booking against a calendar where you
- * need conflict-resolution. So webhook's `post_event` capability is
- * marked `cas: 'native-idempotency'` (we forward the key — the receiver
- * MUST honor it) and `defaultConsistencyModel: 'advisory'`. Anyone
- * needing real CAS uses a kind-specific connector (Calendar, Sheets, ...).
- */
-
-declare const webhookConnector: ConnectorAdapter;
-
-/**
- * Stripe inbound-webhook receiver — push-only side of a Stripe connector.
- *
- * The full Stripe connector (charges/customers/invoices read+mutation) is
- * tracked in INTEGRATIONS.md as separate `stripe-customers` / `stripe-invoices`
- * rows. This adapter only ships the inbound surface today: receive a push,
- * verify the signature, persist one `InboundEvent` per Stripe event so the
- * agent's runtime can react (e.g. payment_failed → outbound dunning call).
- *
- * This connector is for the connected account owner: they paste their
- * `whsec_*` and the consuming product listens on a per-data-source URL such
- * as /api/webhooks/inbound/stripe/:dataSourceId.
- *
- * Signature scheme: Stripe's `t=<unix>,v1=<hmac>` header. HMAC is
- * sha256(`${t}.${rawBody}`) keyed by the customer's webhook secret. We use
- * `timingSafeEqual` to defeat timing oracles and bound timestamp skew at
- * 5 minutes (Stripe's recommendation) to thwart replay against captured
- * signatures.
- */
-
-declare const stripeWebhookReceiverConnector: ConnectorAdapter;
-
-/**
- * Slack Events API inbound receiver.
- *
- * Slack sends two distinct request shapes to the same webhook URL:
- *
- *   1. `url_verification` — a one-off handshake during app-config. The body
- *      contains a `challenge` string we MUST echo back as the response body
- *      (Slack's app-config UI fails the URL otherwise). No InboundEvent is
- *      persisted for this — it's an infrastructure ping, not a user event.
- *
- *   2. `event_callback` — every actual workspace event (message posted,
- *      reaction added, channel created, …). We persist one InboundEvent
- *      keyed by `event_id` so a Slack retry (Slack retries 3 times on any
- *      non-2xx) is deduped at the unique constraint, not after we've
- *      double-processed.
- *
- * Signature scheme: `v0=<hmac(sha256, "v0:<timestamp>:<rawBody>")>` keyed by
- * the app's signing secret. Header `X-Slack-Request-Timestamp` carries the
- * timestamp; we reject anything older than 5 minutes (Slack's recommendation)
- * to bound replay risk.
- */
-
-declare const slackEventsConnector: ConnectorAdapter;
-
-declare const githubConnector: ConnectorAdapter;
-
-declare const gitlabConnector: ConnectorAdapter;
-
-declare const airtableConnector: ConnectorAdapter;
-
-declare const asanaConnector: ConnectorAdapter;
-
-declare const salesforceConnector: ConnectorAdapter;
-
-export { type AuthSpec as A, githubConnector as B, type ConnectorAdapter as C, type DataSourceMetadata as D, type EventHandlerResult as E, gitlabConnector as F, type GoogleCalendarOptions as G, type HubSpotOptions as H, type InboundEvent as I, googleCalendar as J, googleSheets as K, hubspot as L, type MicrosoftCalendarOptions as M, type NotionDatabaseOptions as N, microsoftCalendar as O, notionDatabase as P, salesforceConnector as Q, type ResolvedDataSource as R, type SlackOptions as S, slack as T, slackEventsConnector as U, stripePackConnector as V, stripeWebhookReceiverConnector as W, twilioSmsConnector as X, validateConnectorManifest as Y, webhookConnector as Z, type ConnectorCredentials as a, type CASStrategy as b, type Capability as c, type CapabilityClass as d, type CapabilityMutation as e, type CapabilityMutationResult as f, type CapabilityParameterSchema as g, type CapabilityRead as h, type CapabilityReadResult as i, type ConnectorInvocation as j, type ConnectorManifest as k, type ConnectorManifestValidationIssue as l, type ConnectorManifestValidationResult as m, type ConsistencyModel as n, CredentialsExpired as o, type GoogleSheetsOptions as p, type RateLimitSpec as q, ResourceContention as r, type RestConnectorSpec as s, type RestCredentialPlacement as t, type RestOperationSpec as u, type RestRequestSpec as v, airtableConnector as w, asanaConnector as x, assertValidConnectorManifest as y, declarativeRestConnector as z };