@jskit-ai/connectors-catalog 0.1.1

package/docs/ashby.md

@@ -0,0 +1,188 @@
+# Ashby
+
+Import `ashbyProvider` from `@jskit-ai/connectors-catalog/server/ashby`.
+This adapter verifies an organization key by reading jobs, preserves explicit
+cursor/incremental sync, and supports candidate/application hiring workflows.
+
+## Provider setup
+
+1. Sign into the intended Ashby organization as an administrator. Open
+   **Admin → Integrations → API Keys → + New**. Name the key, leave the
+   optional integration partner unset unless applicable, then **Create API Key**.
+2. Enable **Jobs: Read** (`jobsRead`) for verification. Add `candidatesRead`
+   for candidate/application reads, `candidatesWrite` for edits and stage changes,
+   `interviewsRead` for plans/stages and `hiringProcessMetadataRead` for archive
+   reasons. Hover the module information icon to check its endpoint list. Leave
+   confidential jobs/private fields and other extra permissions off unless needed.
+   Choose **Save and Continue**. Copy the key before closing the wizard.
+3. Copy the issued key into the backend environment as `ASHBY_API_KEY`.
+   In Vibe64, add Ashby and enter `env:ASHBY_API_KEY` in **API key reference**.
+   Save, choose **Set credential in Env** to enter the key, then **Connect account**
+   or **Verify again**. **Check connection** reads status only. CLI uses the same
+   file and `connectApiKey`. To revoke, open the key by name and choose **Disable**;
+   disconnecting locally does not disable it. For rotation, create a replacement,
+   update Env and verify before disabling the old key.
+
+Ashby uses Basic authentication: key as username, empty password. Keys belong
+on a server. This adapter sends `Accept: application/json; version=1`.
+Missing credentials can return 401; invalid/deactivated keys and insufficient
+permissions can both return 403.
+[Authentication and permissions](https://developers.ashbyhq.com/reference/authentication),
+[Key setup and disabling](https://docs.ashbyhq.com/how-do-i-generate-an-api-key).
+
+## Configuration and library calls
+
+```json
+{
+  "schemaVersion": 1,
+  "registrations": {},
+  "integrations": {
+    "hiring": {
+      "provider": "ashby",
+      "displayName": "Hiring jobs",
+      "accountMode": "shared",
+      "scopes": [],
+      "authentication": { "method": "api-key", "secretRef": "env:ASHBY_API_KEY" }
+    }
+  }
+}
+```
+
+Use the [API-key composition pattern](../patterns/api-key-connection/PATTERN.md)
+with `providers: [ashbyProvider]`, an authenticated application policy and the
+file connection store. Portable configuration and durable runtime state remain
+text files. The key is resolved from the environment for requests.
+
+```js
+await connections.connectApiKey({ context, integrationId: "hiring" });
+const page = await connections.invoke({
+  context, integrationId: "hiring", operation: "jobs.list",
+  input: { limit: 25 }
+});
+```
+
+`jobs.list` sends `POST /job.list`; this is a read despite the HTTP method.
+The fragment accepts integer `limit` 1–100 (default 25) and optional opaque
+`cursor` and `syncToken` strings, each up to 8192 characters. Positive page sizes
+and token-length caps are local validation choices. It returns the original
+`results`, `moreDataAvailable`, `nextCursor` and `syncToken` envelope.
+Additional date/status filters and job writes are not implemented.
+[Job listing](https://developers.ashbyhq.com/reference/joblist).
+
+For a full scan, begin without a cursor or sync token. While
+`moreDataAvailable` is true, explicitly request the next page with `nextCursor`.
+Retain the final page's `syncToken` for a later incremental scan. During that
+scan, send the same starting sync token alongside subsequent cursors; replace
+the stored sync token only after the scan finishes. Ashby documents cursor
+expiry after 14 days and may report errors in an HTTP-200 response.
+[Pagination and incremental sync](https://developers.ashbyhq.com/docs/pagination-and-incremental-sync).
+
+The application owns its synchronization checkpoint, scoped to the authorized
+connection. This library does not silently reset it or traverse all pages.
+`success: false` becomes a generic provider failure without exposing provider
+error payloads. An expired cursor therefore needs explicit recovery by the
+application. The common 403 classification is permission denied; it cannot
+distinguish a deactivated key from missing permissions. Check the provider key
+and reverify after correction. Disconnect removes local state; it does not
+revoke the organization key.
+
+## Automation and application ownership
+
+An AI can write the configuration, environment reference, library wiring and
+checkpoint logic. The reviewed API documents expose inspection of an existing
+key, not a key-creation workflow. Initial organization access and key creation
+remain administrator steps; do not invent an API for those steps.
+[Current-key inspection](https://developers.ashbyhq.com/reference/apikeyinfo).
+
+Each application uses an authorized key stored in its private Env. These keys
+are not OAuth registrations and do not connect unrelated organizations.
+Customer-owned data requires that customer's authorized key. The key guide documents a per-key request limit; it does not reserve independent
+organization capacity or change licensed product access. Application owners
+must arrange the capacity needed for their usage. No callback is used, so editor VM and deployed app
+domains do not change this flow. A jobs result does not establish user login.
+
+## Focused evidence
+
+Simulated provider tests cover Basic headers, POST bodies, explicit paging,
+empty results, invalid envelopes, HTTP-200 failures, input boundaries, real
+temporary file-store restart, rotation, ownership and disconnect. Editor
+automation verifies reference-only configuration and save/reload. Live provider
+use, organization signup and sample-app generation are excluded.
+
+## Recruiter workflow operations
+
+All calls use the fixed `https://api.ashbyhq.com` origin, Basic key authentication
+and POST JSON. Lists are reads despite POST. Responses retain Ashby's `success`
+and `results` envelope; HTTP-200 `success: false` is a failure, not completion.
+
+| Operation | Endpoint | Relevant inputs |
+| --- | --- | --- |
+| `jobs.get` | `job.info` | Job `id`. |
+| `candidates.list` | `candidate.list` | `limit`, cursor, syncToken. |
+| `candidates.get` | `candidate.info` | Candidate `id`. |
+| `candidates.create` | `candidate.create` | Required `name`; optional email and phoneNumber. |
+| `candidates.update` | `candidate.update` | `candidateId` and at least one name/email/phone change; notifications default off. |
+| `applications.list` | `application.list` | Page inputs, optional `jobId` and Hired/Archived/Active/Lead status. |
+| `applications.get` | `application.info` | `applicationId`. |
+| `applications.create` | `application.create` | `candidateId`, `jobId`; optional interviewPlanId and interviewStageId. |
+| `applications.changeStage` | `application.changeStage` | `applicationId`, `interviewStageId`; archiveReasonId for an Archived stage. |
+| `interviewPlans.list` | `interviewPlan.list` | Page inputs, optional includeArchived (default false). |
+| `interviewStages.list` | `interviewStage.list` | `interviewPlanId`. |
+| `archiveReasons.list` | `archiveReason.list` | Optional includeArchived (default false). |
+
+Use the same explicit cursor/checkpoint procedure for candidate, application and
+interview-plan lists. Keep a separate checkpoint for each endpoint/filter/connection;
+finish the scan before replacing it. Stage and archive-reason lists are unpaged.
+UUID inputs come from provider records; names or display labels cannot replace IDs.
+
+1. Select an authorized job and candidate. Create a candidate only after checking
+   existing records to avoid accidental duplicates. Profile updates send only
+   provided fields. They set `sendNotifications: false` by default; enabling it
+   explicitly can notify users subscribed to that candidate.
+2. Source that candidate into the selected job with `applications.create`.
+   This is a recruiter action. A public careers form uses Ashby's separate
+   `applicationForm.submit` API and its form requirements, not this shortcut.
+3. Read the application's interview plan; list published plans/stages if needed.
+   Choose a stage from the job's actual plan, not one with a similar name in
+   another plan. The provider rejects invalid plan/stage combinations.
+4. After application authorization and confirmation, call `applications.changeStage`.
+   For an Archived stage, choose an active reason from `archiveReasons.list` and
+   send its ID. This adapter does not accept `archiveEmail` or send an archive
+   message. Read the application again to show the resulting stage/status.
+5. Persist returned IDs. If a creation/stage change times out, inspect Ashby before
+   retrying; the adapter makes one attempt and cannot prove a lost response means
+   nothing happened. HTTP-200 provider errors and 403/429 remain visible failures.
+
+```js
+const application = await connections.invoke({ context, integrationId: "hiring",
+  operation: "applications.create", input: { candidateId, jobId } });
+// After an authorized recruiter chooses a stage from this application's plan:
+await connections.invoke({ context, integrationId: "hiring",
+  operation: "applications.changeStage",
+  input: { applicationId: application.results.id, interviewStageId } });
+```
+
+The generated application owns recruiter authorization, job/candidate visibility,
+consent to changes and UI. The organization API key is not a tenant/user identity.
+The optional Node runtime works without Vibe64 using the same JSON and Env
+reference. Other frameworks can use their own HTTP client for these documented
+endpoints, preserving the same ownership and connection configuration.
+
+Sources: [candidates](https://developers.ashbyhq.com/reference/candidatelist),
+[create candidate](https://developers.ashbyhq.com/reference/candidatecreate),
+[update candidate](https://developers.ashbyhq.com/reference/candidateupdate),
+[applications](https://developers.ashbyhq.com/reference/applicationlist),
+[source candidate](https://developers.ashbyhq.com/reference/applicationcreate),
+[change stage](https://developers.ashbyhq.com/reference/applicationchangestage),
+[plans](https://developers.ashbyhq.com/reference/interviewplanlist),
+[stages](https://developers.ashbyhq.com/reference/interviewstagelist),
+[archive reasons](https://developers.ashbyhq.com/reference/archivereasonlist-1).
+
+## Limitations
+
+Editor coding-assistant attachment is deferred. For example, a generated hiring
+app can display candidates and advance a recruiter-selected application, but
+asking Vibe64's assistant to inspect your candidates does not give it access.
+The app owns its hiring screens and policies. Public careers forms, scheduling,
+offer management, file upload, messages and custom fields are not supplied here.
+Live hiring changes, real credentials and generated-app execution were not tested.

package/docs/atlassian.md

@@ -0,0 +1,224 @@
+# Atlassian assistant MCP
+
+Import `atlassianProvider` and `registerAtlassianClient` from
+`@jskit-ai/connectors-catalog/server/atlassian`. This initial fragment connects
+the assistant owner's account to Rovo MCP v2. It uses `tools.list` and explicit
+`tools.call` through the existing OAuth/file runtime and official MCP SDK.
+
+## Vibe64 setup
+
+Open **Integrations → Add Atlassian**. Choose permissions, set the owning
+application's **Suggested callback URL**, and select **Register client and connect**.
+The editor registers this project’s client and saves its ID in `integrations.json`
+and its secret/callback/recovery ID in development Env. It does not overwrite
+existing Env values. The application must implement its callback and integration
+setup command before consent can finish. If registration has an uncertain result,
+inspect provider registration and project Env before explicitly allowing a retry.
+An existing client can be entered using the manual steps below. Production Env
+is configured on Deploy; copying configuration alone does not copy secrets.
+
+## Manual setup
+
+1. Choose the assistant host and its exact callback URL. Use HTTPS in a hosted
+   environment; an operator's local CLI may use an HTTP loopback callback.
+2. Register a confidential client using the helper below or the equivalent
+   HTTP request. The reviewed metadata establishes dynamic registration; these
+   instructions do not assume a developer-console form for creating an MCP v2
+   client. A Jira REST OAuth client or an old MCP v1 client is not interchangeable.
+3. In Vibe64, open **Integrations → Add Atlassian → Credentials**. Enter the
+   returned **Client ID**. Store the returned secret and callback URL through
+   Env; enter their names as **Client secret reference** and **Callback URL
+   reference**, for example `env:ATLASSIAN_CLIENT_SECRET` and
+   `env:ATLASSIAN_CALLBACK_URL`.
+4. Open **Permissions**. Select the products needed by the assistant. Profile,
+   account, refresh, Jira read/search and Confluence read/search start selected.
+   Writes, deletes, administration and other products start unselected. Save
+   configuration. The JSON contains references, never the secret itself.
+5. The host calls `beginAuthorization` and opens its returned URL. Sign into
+   the intended Atlassian account and review the products/sites and permissions
+   presented by Atlassian. Complete consent. The exact provider consent controls
+   were not exercised in this implementation; do not substitute automated
+   consent for the account owner's decision.
+6. Handle the callback under the same authenticated assistant owner using
+   `completeAuthorization`. The runtime lists tools before saving a grant.
+   A connected status, including an empty tool list, does not establish access
+   to every product, site or write operation. Request additional permissions
+   through a new authorization attempt when the application needs them.
+
+[Atlassian OAuth configuration](https://support.atlassian.com/atlassian-ai-gateway/docs/configure-oauth-2-1/)
+describes consent, product permissions and site restrictions. Existing account
+permissions continue to control tool access. If authorization or a tool is
+blocked, have the relevant administrator review product/site access and
+callback restrictions. This fragment does not change administration policies.
+
+## Provider registration automation
+
+The public [v2 resource metadata](https://mcp.atlassian.com/.well-known/oauth-protected-resource/v2/mcp)
+identifies the resource `https://mcp.atlassian.com/v2/mcp`, its issuer and 32
+supported scopes. The [issuer metadata](https://auth.atlassian.com/.well-known/oauth-authorization-server/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3)
+advertises dynamic registration, S256 PKCE and confidential-client authentication.
+Both documents were read on 9 September 2026 without registering or signing in.
+
+An authorized setup script can perform registration:
+
+```js
+import { registerAtlassianClient } from "@jskit-ai/connectors-catalog/server/atlassian";
+
+const client = await registerAtlassianClient({
+  clientName: "My assistant",
+  callbackUrl: "https://assistant.example/connections/atlassian/callback",
+  scopes: ["read:me", "read:jira:agent-interface", "offline_access"]
+});
+// Persist client.clientSecret through the host's existing private secret owner.
+// Write client.clientId into the portable registration. Never log this result.
+```
+
+The helper validates names, callback URLs and unique supported permissions,
+uses the official SDK, and returns `clientId`, `clientSecret` and optional
+`clientSecretExpiresAt`. The caller owns authorization, secure secret storage
+and configuration persistence. Registration runs only when explicitly requested,
+never on file save, startup or every Connect action.
+
+For manual registration, use an HTTP client on your own machine:
+
+In Vibe64, expand **Set up Atlassian → OAuth client registration**. Set the
+permissions and **Suggested callback URL** first. **Copy registration endpoint**
+and **Copy registration request** supply this project's values before a Client
+ID exists. Copying sends no request. CLI users can prepare the example below
+with their own framework tools.
+
+1. Create a **POST** request to
+   `https://auth.atlassian.com/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3/dcr/register`.
+   This is the registration endpoint, not the `/v2/mcp` tool endpoint.
+2. Set `Content-Type: application/json` and select a raw JSON body. Replace
+   the example name and callback below with the owning application's name and
+   exact callback shown in Vibe64. Implement that route in the application
+   before attempting user consent.
+3. Set the space-delimited `scope` to the permissions selected in Vibe64.
+   The example below matches the screen's default profile/account, refresh,
+   Jira read/search and Confluence read/search permissions. Remove products
+   you do not need from both places.
+4. Send once. Copy the successful response's `client_id` into **Client ID**.
+   Store `client_secret` as `ATLASSIAN_CLIENT_SECRET` through the project's
+   Env editor and enter `env:ATLASSIAN_CLIENT_SECRET` in **Client secret reference**.
+   Store the exact callback as `ATLASSIAN_CALLBACK_URL` and enter
+   `env:ATLASSIAN_CALLBACK_URL` in **Callback URL reference**.
+5. An error response, missing credentials or a different returned redirect URI
+   is not a usable registration. Keep the response private; do not paste it
+   into source, chat or a shared HTTP-client collection.
+
+```json
+{
+  "client_name": "My assistant",
+  "redirect_uris": ["https://assistant.example/connections/atlassian/callback"],
+  "token_endpoint_auth_method": "client_secret_post",
+  "grant_types": ["authorization_code", "refresh_token"],
+  "response_types": ["code"],
+  "scope": "read:me read:account offline_access read:jira:agent-interface search:jira:agent-interface read:confluence:agent-interface search:confluence:agent-interface"
+}
+```
+
+The HTTP response uses `client_id` and `client_secret`; the JavaScript helper
+returns `clientId` and `clientSecret`. Node applications should reuse the helper
+and its response validation. Other frameworks use their own HTTP and private
+secret-storage tools; they do not need JSKIT installed.
+
+The helper checks that returned credentials, authentication method and the
+single redirect URI match its contract. It does not follow redirects or retry
+ambiguous failures. A timeout may leave a client registered; inspect the
+provider before creating another one. Metadata proves the advertised protocol,
+not that a live registration will be accepted for every client policy. Live
+issuance and consent remain untested.
+
+AI can prepare this JSON, call the explicit registration operation after
+operator authorization and write the resulting references. It cannot choose a
+user's product access, approve consent or establish provider quotas on its own.
+
+## Runtime and portable configuration
+
+```json
+{
+  "schemaVersion": 1,
+  "registrations": {
+    "atlassian": {
+      "source": "own",
+      "clientId": "assigned-v2-client-id",
+      "clientSecretRef": "env:ATLASSIAN_CLIENT_SECRET",
+      "callbackUrlRef": "env:ATLASSIAN_CALLBACK_URL"
+    }
+  },
+  "integrations": {
+    "work": {
+      "provider": "atlassian",
+      "accountMode": "assistant",
+      "scopes": ["read:me", "read:jira:agent-interface", "offline_access"],
+      "authentication": { "method": "oauth2", "registrationRef": "atlassian" }
+    }
+  }
+}
+```
+
+Compose the [OAuth file pattern](../patterns/oauth-connection/PATTERN.md) with
+`providers: [atlassianProvider]`. The shared
+[assistant OAuth pattern](../patterns/assistant-mcp-oauth/PATTERN.md) supplies
+AI wiring guidance. UI and CLI edit the same validated file. The host uses
+encrypted text files for pending attempts and access/refresh grants.
+
+Authorization goes to `auth.atlassian.com/authorize`; token exchange and refresh
+go to `auth.atlassian.com/oauth/token`. All three include the v2 resource
+identifier. MCP requests go only to `https://mcp.atlassian.com/v2/mcp?tools=all`.
+The query requests a flat tool catalogue, as documented in the
+[v2 migration guide](https://support.atlassian.com/atlassian-ai-gateway/docs/how-to-upgrade-from-atlassian-rovo-mcp-v1-to-atlassian-rovo-mcp-v2/).
+The resource identifier has no query. No token is sent to an arbitrary address
+supplied by a tool response or authentication challenge.
+
+`tools.list` accepts an optional cursor. `tools.call` accepts `name` and
+`arguments`. The host must authorize that exact name and argument ownership,
+including the destination site/project. Tool discovery is not approval to
+execute everything it contains. Product permissions remain enforced by
+Atlassian; returned `isError` must be handled before reporting success. The
+transport grants no sampling/elicitation capability and tries to delete its MCP
+session after work. Cancellation cannot undo an accepted tool mutation.
+Disconnect deletes the local grant; it does not revoke all provider access.
+
+## Connection ownership and callbacks
+
+This fragment is for an explicitly configured assistant host. That host owns its
+client registration, callback, private credentials and grants; it may be an
+application-owned assistant or an opt-in editor tool. Merely adding the provider
+to a project does not authorize the editor's coding assistant. It does not supply
+published app-user login. The host's callback may differ from the published app's
+domain, but it must match that host's real route and registered redirect URI.
+
+Use the owning host's actual callback as the registration helper's `callbackUrl`.
+Persist the resulting credentials in its private Env. Update the registration
+and callback Env if this route changes when moving hosts; retain the runtime's
+identity and stored grants. Separate clients do not establish separate capacity:
+[Atlassian's overview](https://support.atlassian.com/atlassian-ai-gateway/docs/get-started-with-the-atlassian-remote-mcp-server/)
+describes organization-level Rovo credit usage.
+
+This fragment does not implement native public-client authentication, app-user
+login, API tokens, REST adapters or automatic assistant attachment. V1 uses a
+different OAuth resource; existing v1 clients/grants must not be silently reused
+for v2.
+
+## Focused proof
+
+Eight simulated-provider tests exercise registration, PKCE/resource binding,
+refresh after file restart, encrypted state, owner/site isolation, changed
+consent scopes, reduced grants, empty/malformed discovery, provider failures,
+interruption and session cleanup. Editor proof checks product permission
+choices, reference validation and file reload. No live client registration,
+consent, provider tool use or generated application is included.
+
+## LIMITATIONS
+
+Vibe64's coding assistants do not yet receive these tools automatically. For
+example, connecting Jira here does not let the editor's Codex/OpenCode chat
+retrieve DOG-42. An application-owned assistant can call the runtime's tools
+with its own authorization policy; this bridge to editor chat is deferred.
+
+The runtime preserves Jira issue and Confluence page content supplied by tools,
+but the application owns how it presents, summarizes or acts on that content.
+OAuth consent and organization policies still control actual product access.
+No live registration, real Jira/Confluence access or generated-app run was tested.

package/docs/attention.md

@@ -0,0 +1,162 @@
+# Attention
+
+Import `attentionProvider` from `@jskit-ai/connectors-catalog/server/attention`.
+This adapter verifies an organization key by listing conversations, then provides
+explicit conversation, coaching and organization operations.
+
+## Manual provider setup
+
+1. Sign into [Attention](https://app.attention.tech) as an organization admin.
+   Open the profile avatar at the top left, then **Settings**.
+2. Under **Organization**, select **API Keys**. Choose **+ Create API Key**
+   and enter a descriptive name.
+3. Copy the key from **API Key Created**; it is shown only once. Put it in the
+   backend environment as `ATTENTION_API_KEY`.
+4. Add Attention in Vibe64 and enter `env:ATTENTION_API_KEY` in **API key
+   reference**. Save, choose **Set credential in Env**, save the value there, then return and
+   choose **Connect account** or **Verify again**. **Check connection** only reloads
+   status; it does not validate a newly entered key.
+5. For rotation, create a replacement, update the binding and verify before
+   deleting the old key through its **⋯ → Delete** menu.
+
+The dedicated authentication guide requires `Authorization: Bearer <key>`.
+Generated endpoint examples show a generic Authorization placeholder; this
+adapter follows the explicit authentication guide.
+[Authentication and dashboard instructions](https://docs.attention.com/api-authentication).
+
+## Portable configuration and runtime
+
+```json
+{
+  "schemaVersion": 1,
+  "registrations": {},
+  "integrations": {
+    "calls": {
+      "provider": "attention",
+      "displayName": "Sales conversations",
+      "accountMode": "shared",
+      "scopes": [],
+      "authentication": { "method": "api-key", "secretRef": "env:ATTENTION_API_KEY" }
+    }
+  }
+}
+```
+
+Compose `providers: [attentionProvider]` with the
+[API-key pattern](../patterns/api-key-connection/PATTERN.md), an application
+authorization policy and the file connection store. Configuration and runtime
+state are text files; no editor-specific service or database is required by
+the CLI application.
+
+```js
+await connections.connectApiKey({ context, integrationId: "calls" });
+const page = await connections.invoke({
+  context, integrationId: "calls", operation: "conversations.list",
+  input: { page: 1, size: 20, "filter[title]": "Review", detailedTranscript: false }
+});
+```
+
+Requests use `GET https://api.attention.tech/v2/conversations/list`, the current
+optimized listing. Pages start at 1 and the provider limits page size to 50.
+This endpoint can include empty conversations and omits some extracted CRM
+intelligence by default. Results contain `data`, with `links` and `meta` where
+available. Title filtering is a case-insensitive partial match.
+[Conversation listing](https://docs.attention.com/api-reference/conversation/list-conversations-optimized).
+
+This fragment defaults to page 1, size 20 and `detailedTranscript: false`.
+It accepts optional `filter[title]` up to 500 characters and
+`filter[hide_internal]` as a boolean. The page cap of 100000 and title bound
+are local choices. Additional list date/team filters and CRM expansion are not implemented;
+retrieve one conversation for full content. False for detailed transcripts does not mean the result
+contains no transcript content; authorize access to the conversation data.
+
+The adapter checks the collection and any available numeric page metadata,
+preserves other fields and accepts empty results. It never follows returned
+URLs with credentials. Call the named operation with the next page number
+explicitly. Keys are resolved per request, sent to the fixed HTTPS origin and
+excluded from source. Disconnect removes local state and does not revoke a
+provider key. Provider user identities do not establish an application login.
+
+## API provisioning and application ownership
+
+Attention documents `POST https://api.attention.tech/v2/api_keys` with required
+`name` and boolean `orgLevel`, authenticated by an existing credential. Its
+response includes the generated key in `value`. An authorized administrator
+can issue a key named for the application, store the response directly in its
+private Env and save only the reference in configuration.
+Initial organization access and the bootstrap credential remain prerequisites.
+[Key-creation API](https://docs.attention.com/api-reference/api-key/create-api-key).
+
+An AI can prepare that provisioning request and runtime/configuration wiring.
+The normal conversation adapter deliberately exposes no key-creation action:
+provisioning belongs to the authorized operator and must not return new secrets
+through an ordinary conversation response. This documented automation route
+has not been exercised with live credentials.
+
+Separate keys support independent revocation but do not prove independent
+organization capacity. The authentication guide directs organizations to their
+account manager for rate-limit increases. The application owner must verify
+provider capacity arrangements for its usage. Each
+customer organization supplies its own authorized key. No OAuth callback is
+used, so VM subdomains and deployed app domains do not change this flow.
+
+## Focused evidence
+
+Simulated protocol tests with real temporary JSON state cover the bearer header,
+current endpoint, title encoding, page bounds, detailed-transcript selection,
+partial metadata, empty results, failures, ownership, restart, rotation and
+disconnect. The editor check verifies reference-only saving and reload.
+Live provider requests, key provisioning and sample-app generation are excluded.
+
+## Complete app workflows
+
+The provider's [OpenAPI contract](https://docs.attention.com/api-reference/openapi.json)
+was inspected on 12 September 2026. All paths below are relative to
+`https://api.attention.tech/v2` and use the same backend-only Bearer key.
+
+| Operation | HTTP path | Input and result |
+|---|---|---|
+| conversations.get | GET /conversations/{id} | Detailed transcript defaults true; preserves participants, timing, processing status, scorecard results and intelligence. Optional `by: external_id` and metadata flags. |
+| conversations.update | PUT /conversations/{id} | Explicit title and/or labels; omitted fields remain untouched. Labels may replace existing metadata: read before replacing. |
+| conversations.archive | DELETE /conversations/{id} | Archives the selected call. |
+| conversations.import | POST /conversations/import | HTTPS mediaURL and userID; optional title, external source ID/name, timestamp and calculation/export skip flags. Returns a UUID; transcription/analysis may still be pending. |
+| snippets.create | POST /snippets | user_uuid, conversation_id, video start_time/end_time in seconds; internal and notify_views must be chosen explicitly. Returns a link; does not open/fetch it. |
+| analysis.ask | POST /ask_attention/v2 | prompt, conversations_ids and deal_id (empty string when not filtering by deal). Preserves each answer's source conversation and error; check errors before displaying success. |
+| scorecards.list / scorecards.get | GET /scorecards, /scorecards/{id} | Browse templates; preserve returned criteria and identifiers. |
+| scorecardItems.list | GET /scorecards/{id}/items | Page through scoring criteria and their provider-defined ranges. |
+| scorecards.summary | POST /scorecards/summary | Required ISO fromDateTime/toDateTime, scorecardUUID, scorecardsItemsUUIDs, teamUUIDs and userUUIDs. Empty filter arrays are passed explicitly. |
+| scorecardResults.create | POST /createScorecardResult | conversation_uuid, scorecard_uuid, summary and items (scorecard_item_uuid, description, optional integer numeric_result). Choose scores using that template's ranges. |
+| users.list / roles.list / teams.list | GET /organizations/users, /organizations/roles, /organizations/teams | Organization discovery; optional teamUUID for users. |
+| users.create | POST /organizations/users | email, first_name, last_name, roleUUID, teams with uuid/optional primary; explicit seat_type listener or recording. |
+| users.update | PATCH /organizations/users/{id} | Sparse firstName/lastName, roleUUID, seat_type, teamUUIDsToRemove and teamsToAdd. Provider creation/update field spellings differ. |
+| users.delete | DELETE /organizations/users/{id} | Permanent organization-user removal and loss of access. Empty successful response; no automatic retry. |
+| teams.create / teams.update | POST /organizations/teams, PATCH /organizations/teams/{id} | Name and optional parentTeamUUID; update sends only selected changes. |
+
+For a coaching dashboard, list calls, retrieve the chosen call with
+`conversations.get`, inspect transcriptStatus, and display the returned transcript,
+participants and existing scorecardResults. Load templates/items before submitting
+reviewer scores; fetch summaries for trends. A successful import UUID is not a
+completed recording. Poll its detail explicitly while processing is pending.
+
+The application must authorize organization management separately from viewing
+calls. Seat assignment, media import and AI analysis can consume the customer's
+provider allowance. Creating users is not an app login mechanism. No provider
+operation runs when saving configuration. Writes are never retried automatically:
+a lost response may mean the mutation succeeded. Inspect the provider before
+retrying imports, snippets, users or scorecard results.
+
+The same `integrations.json`, Env reference and API-key composition work from CLI
+without Vibe64. Other frameworks use their native HTTP/client, secret storage and
+application authorization against these endpoints; they need no Node service.
+
+## LIMITATIONS
+
+Editor coding-assistant attachment is deferred. For example, an app can display
+a sales-call transcript and save a manager's coaching score, but configuring this
+connector does not let Vibe64's Codex/OpenCode read those calls from editor chat.
+The app owns its dashboard, permissions, polling and handling of pending/error
+results. This does not supply Attention's recorder, CRM installation, webhooks,
+SCIM, scorecard-template designer or per-user OAuth. Media imports use an accessible
+HTTPS file URL; custom fetch headers and precomputed transcript imports require
+native provider wiring. Public snippet sharing is an explicit caller choice.
+No real organization, live recording, billing action or generated app was exercised.