@jskit-ai/connectors-catalog 0.1.1

package/docs/confidence-exp.md

@@ -0,0 +1,74 @@
+# Confidence Exp
+
+Use `confidenceExpProvider` and `registerConfidenceClient` from
+`@jskit-ai/connectors-catalog/server/confidence-exp`.
+Read the [shared setup guide](confidence-oauth.md) for exact setup steps,
+registration automation, ownership, quotas, callbacks and verification limits.
+
+```json
+{
+  "schemaVersion": 1,
+  "registrations": {
+    "confidence-exp": {
+      "source": "own",
+      "clientId": "assigned-client-id",
+      "clientSecretRef": "env:CONFIDENCE_EXP_CLIENT_SECRET",
+      "callbackUrlRef": "env:CONFIDENCE_EXP_CALLBACK_URL"
+    }
+  },
+  "integrations": {
+    "experiments": {
+      "provider": "confidence-exp",
+      "accountMode": "assistant",
+      "scopes": ["openid", "profile", "email", "offline_access"],
+      "authentication": { "method": "oauth2", "registrationRef": "confidence-exp" }
+    }
+  }
+}
+```
+
+The MCP destination is `https://mcp.confidence.dev/mcp/experiments`. Verification
+uses `tools.list`. The provider describes `list_experiments`, `get_experiment`,
+`get_results` and `get_resource`. Discover current schemas before invoking
+`tools.call`; resource names must belong to the authorized request. Search and
+list filters are different modes, and summary versus full detail changes the
+returned information. See the
+[MCP guide](https://confidence.spotify.com/docs/sdks/mcp-servers).
+
+This initial adapter does not launch experiments, implement a statistics engine,
+configure a warehouse or ingest events. Tool results are retained with their
+error status; the application owns presentation and interpretation.
+The application owns and registers its callback route, using its assigned public
+URL as the initial origin. Keep that exact callback in application Env and update
+the provider registration when it changes. Its grant stays separate from a
+Confidence Flags integration.
+
+
+## Read and interpret results
+
+Call `tools.list` first and use each returned tool's current input schema. An
+explicitly wired host can call `get_experiment` for an approved instance name,
+then `get_results` for that same name (or a returned analysis name); Confidence
+resolves the primary analysis when an instance is supplied. Request `summary:
+false` only when full detail is needed. `get_resource` resolves referenced metric,
+entity, surface, segment and fact-table definitions; authorize those IDs too.
+`list_experiments` search mode ignores filter/orderBy, so do not assume it has
+applied an access filter. Apply the host's resource authorization independently.
+
+Use `connections.invoke({ context, integrationId: "experiments", operation:
+"tools.call", input: { name: "get_results", arguments: { name:
+approvedInstanceName, summary: false } } })` after connection. Preserve the MCP
+result/error status and the provider's confidence intervals, significance,
+sample sizes and status messages. A positive effect estimate is not automatically
+a winning experiment. Do not fabricate a shipping recommendation or recalculate
+provider statistics from a summary. Other frameworks can connect their native
+MCP clients to the same endpoint with their own OAuth/grant storage.
+
+**LIMITATIONS:** Vibe64 coding-assistant attachment is deferred. For example,
+saving this connection does not make Vibe64 chat explain an A/B result; an
+explicitly wired assistant host can retrieve it. Confidence owns statistical
+analysis, metric/event ingestion and experiment execution. This adapter transports
+its tools and results, not a new experimentation engine. Controlled fixtures
+prove analysis content is preserved and other experiment IDs are denied; tool
+schemas and actual statistical outputs remain provider-owned and were not
+validated against a live account.

package/docs/confidence-flags.md

@@ -0,0 +1,75 @@
+# Confidence Flags
+
+Use `confidenceFlagsProvider` and `registerConfidenceClient` from
+`@jskit-ai/connectors-catalog/server/confidence-flags`.
+Read the [shared setup guide](confidence-oauth.md) for exact setup steps,
+registration automation, ownership, quotas, callbacks and verification limits.
+
+```json
+{
+  "schemaVersion": 1,
+  "registrations": {
+    "confidence-flags": {
+      "source": "own",
+      "clientId": "assigned-client-id",
+      "clientSecretRef": "env:CONFIDENCE_FLAGS_CLIENT_SECRET",
+      "callbackUrlRef": "env:CONFIDENCE_FLAGS_CALLBACK_URL"
+    }
+  },
+  "integrations": {
+    "flags": {
+      "provider": "confidence-flags",
+      "accountMode": "assistant",
+      "scopes": ["openid", "profile", "email", "offline_access"],
+      "authentication": { "method": "oauth2", "registrationRef": "confidence-flags" }
+    }
+  }
+}
+```
+
+The MCP destination is `https://mcp.confidence.dev/mcp/flags`. Verification uses
+`tools.list`, without calling a flag tool. Discover schemas before invoking
+`tools.call`; the host can allow listing/reading while separately approving
+creation or targeting changes. Account identity scopes do not enforce that
+distinction. The provider describes tools including `listFlags`, `getFlag`,
+`createFlag` and `testResolveFlag` in its
+[MCP guide](https://confidence.spotify.com/docs/sdks/mcp-servers).
+
+This initial adapter does not implement an OpenFeature evaluation provider,
+production resolve/apply calls, event collection or a management API client.
+The application owns and registers its callback route, using its assigned public
+URL as the initial origin. Keep that exact callback in application Env and update
+the provider registration when it changes. The builder's assistant grant must
+not become a shared app-user grant.
+
+
+## Managing flags with deliberate approval
+
+Discover current schemas using `tools.list`; do not hardcode argument names from
+examples. The documented tools cover `listClients`, `listFlags`, `getFlag`,
+`createFlag`, `addFlagVariant`, `updateFlagSchema`, `createOverrideRule`,
+`testResolveFlag` and `analyzeFlagUsage`. Use `tools.call` with the discovered
+name/schema and an authenticated host policy that approves the exact operation,
+flag, variant, targeting rule and context. An identity OAuth scope is not write
+approval. Review the proposed change before executing it, then read/test the
+result. A test-user override is not a rollout to all users.
+
+For example, an explicitly wired assistant can create a boolean checkout flag,
+add an enabled variant, target only a test account, and call `testResolveFlag` to
+inspect the selected variant and explanation. Preserve tool `isError` even on
+HTTP success. If a write times out, inspect the flag/rules before retrying; neither
+local cancellation nor disconnect undoes a remotely applied change.
+
+The host owns its OAuth registration, callback and private Env references. A CLI
+can use the same JSKIT methods without Vibe64, or another framework's native MCP
+client with the same endpoint and its own OAuth storage. Production flag evaluation
+belongs to that framework's Confidence/OpenFeature integration; never place this
+management grant in a browser or treat it as the application's client secret.
+
+**LIMITATIONS:** Automatic Vibe64 coding-assistant attachment is deferred. Saving
+this connection does not let Vibe64 chat switch a feature on; an explicitly wired
+host can approve and call these management tools. This is not a feature-flag
+execution engine, event pipeline or visual rollout dashboard. The generated app
+must separately implement runtime evaluation if it wants to hide/show features.
+Controlled fixtures prove transport, exact write approval, tool-error retention
+and no replay; their example argument shapes are not live schema verification.

package/docs/confidence-oauth.md

@@ -0,0 +1,137 @@
+# Confidence MCP setup and ownership
+
+The Flags and Experiments adapters use separate integration IDs and MCP paths.
+They share an OAuth issuer and `registerConfidenceClient`, exported through
+either provider entry point. Both support assistant ownership only.
+
+## Account and manual setup
+
+1. Sign into the intended Confidence account and confirm access to the target
+   organisation. The provider's account policy remains authoritative.
+2. Add **Confidence Flags** or **Confidence Exp** in Vibe64. These configure an explicitly wired assistant host; automatic Vibe64 chat
+   attachment is deferred. They do not configure production flag evaluation.
+3. Confirm the suggested callback is the exact route served by that host and
+   choose identity/profile/email/refresh permissions. In development, the owner
+   can choose **Register client and connect**: the existing project registration action
+   saves the client ID to configuration and secret/callback/recovery ID to Env.
+   Existing Env values are preserved. Investigate any uncertain failure before
+   repeating it. The application must still implement its callback/setup command.
+4. For manual or standalone CLI setup, send the displayed registration JSON to
+   the fixed endpoint using POST and Content-Type application/json, or call
+   `registerConfidenceClient` below. Copy `client_id` to configuration and store
+   `client_secret` and the exact callback in private Env. No manual OAuth
+   client-creation console is established by the reviewed docs. Changing scopes
+   in a saved file does not update a previously registered client.
+5. The host calls `beginAuthorization` and opens its URL. Sign in at the
+   provider prompt and allow the connection. Complete the callback under the
+   same authenticated assistant owner. Verification lists tools only.
+6. Discover tool schemas and configure host policy for their names, arguments,
+   target resources and effects. Do this before exposing calls to an AI.
+
+The provider documents Streamable HTTP MCP at `/mcp/flags` and
+`/mcp/experiments`, with browser authentication. Flags include management tools;
+experiments include analysis and result retrieval. Its separate documentation
+MCP is unauthenticated and not part of either adapter.
+[Confidence MCP guide](https://confidence.spotify.com/docs/sdks/mcp-servers).
+
+## Automation and provider registration
+
+On 9 September 2026, public
+[OAuth metadata](https://mcp.confidence.dev/.well-known/oauth-authorization-server)
+advertised issuer `https://mcp.confidence.dev`, `/authorize`, `/token`, `/register`,
+S256, code/refresh grants and `none`/`client_secret_post`. The
+[resource metadata](https://mcp.confidence.dev/.well-known/oauth-protected-resource/mcp)
+declared resource `https://mcp.confidence.dev/mcp` for both paths.
+
+The documents differ on permissions: authorization metadata lists `openid`,
+`profile`, `email`, `offline_access`; resource metadata instead lists `flags:read`
+alongside the three identity scopes. This fragment exposes the authorization
+server's four scopes. It does not claim a verified `flags:read` grant or infer
+that any identity scope restricts tool calls to reads. Live consent acceptance
+remains untested.
+
+Unauthenticated MCP challenges advertised HTTP discovery addresses. This
+implementation pins the independently verified HTTPS issuer/resource and never
+follows those HTTP addresses or a replacement authentication URL from an error.
+
+An authorized operator or AI setup process can call:
+
+```js
+const client = await registerConfidenceClient({
+  clientName: "My assistant",
+  callbackUrl: "https://assistant.example/connections/confidence/callback",
+  scopes: ["openid", "profile", "email", "offline_access"]
+});
+```
+
+The helper uses the MCP SDK to POST one exact callback, code/refresh grants,
+`client_secret_post` and the chosen scopes to `/register`. It validates returned
+client/redirect metadata and returns `clientId`, `clientSecret` and any
+`clientSecretExpiresAt`. Store that result through existing privileged owners;
+never log or return the secret through ordinary UI status.
+
+For manual HTTP setup, send JSON to `https://mcp.confidence.dev/register` with
+`client_name`, `redirect_uris: [callback]`,
+`token_endpoint_auth_method: "client_secret_post"`,
+`grant_types: ["authorization_code", "refresh_token"]`,
+`response_types: ["code"]` and space-delimited `scope`. HTTPS and HTTP loopback
+callbacks are accepted by the helper; credentials, query and fragments are
+rejected. It neither follows redirects nor retries registration. An interrupted
+request may already have created a client; inspect before retrying.
+
+This is different from **Admin → API Clients**, which creates management API
+credentials, and from flag client secrets used by evaluation SDKs. Those are not
+MCP browser consent credentials.
+[Management API quickstart](https://confidence.spotify.com/docs/api/quickstart),
+[flag client credentials](https://confidence.spotify.com/docs/api/how-to-guides/flags/setup-flag-clients).
+An AI can prepare this setup and perform explicitly authorized API requests.
+It cannot complete human consent or remove provider account requirements.
+
+## Runtime and CLI contract
+
+Compose the existing `oauth-connection` and `assistant-mcp-oauth` patterns with
+the selected provider and the provider guide's `integrations.json`. CLI and UI
+use the same parser. All four scopes are initially selected; `openid` is needed
+by both initial operations. The host resolves secret references and chooses
+encrypted file storage. No database is required.
+
+`tools.list` accepts a cursor and returns one page. `tools.call` accepts `name`
+and `arguments`; discover their current schema rather than inventing fields.
+The host's `authorize` callback must validate resource ownership and approve
+each operation. Handle `isError` as a tool failure. Tool output, descriptions and
+linked documents do not grant further authority. No automatic paging, retries,
+polling, tool attachment or flag changes occur.
+
+Each configured integration keeps a distinct grant even when both use one
+registration. Changing a provider ID cannot reuse another integration's grant.
+The provider's common OAuth resource is not an application-side permission
+boundary. Disconnect removes the local grant and does not undo completed work.
+This library does not use these identity scopes to implement application login.
+
+## 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.
+
+Flags and Experiments each register the host's real callback with the appropriate
+provider endpoint. Keep their registrations, Env references and grants distinct.
+On a host/domain change, update registration and callback Env when the callback
+changes, while retaining the owning runtime identity and persistent grants.
+Separate client IDs do not establish separate provider quotas or organisation
+entitlements. Registration acceptance and commercial use need provider proof.
+The editor exposes explicit automatic or manual client registration and the
+application-owned connection lifecycle. Live provider registration and consent remain unverified.
+
+## Evidence
+
+Controlled tests exercise both MCP paths, common resource binding, confidential
+registration, file ownership and restart, refresh, exact tool policy, malformed
+responses, permission errors, cancellation and no request replay. Provider guide
+JSON and responsive editor persistence are checked separately. No live provider
+account, registration, consent, flag mutation, experiment run, database or
+generated application is used. Metadata discovery alone does not prove live
+registration or token acceptance.

package/docs/contentful.md

@@ -0,0 +1,123 @@
+# Contentful
+
+Import `contentfulProvider` from `@jskit-ai/connectors-catalog/server/contentful`.
+This connector reads published entries using a Content Delivery API key.
+
+## Configure access
+
+1. Sign into Contentful and select the space for this application.
+2. Open **Settings → API keys**. Add or select a Content delivery / preview key.
+3. Copy **Space ID** into the integration form. Copy **Content Delivery API
+   access token** into private Env as `CONTENTFUL_ACCESS_TOKEN`.
+4. Select an environment authorized for the key (`master` by default) and the
+   space's region. Enter `env:CONTENTFUL_ACCESS_TOKEN` as the token reference.
+5. Save, then explicitly connect. Verification reads one published entry at
+   most. An empty published space is a valid successful result.
+6. Rotate by updating the Env binding and verifying the replacement before
+   retiring the old key in Contentful. Disconnect deletes local state only.
+
+Content Management personal tokens and Preview tokens are different credentials.
+See [Contentful authentication](https://www.contentful.com/developers/docs/references/authentication/).
+
+## Portable configuration and CLI
+
+```json
+{
+  "schemaVersion": 1,
+  "registrations": {},
+  "integrations": {
+    "content": {
+      "provider": "contentful",
+      "accountMode": "shared",
+      "scopes": [],
+      "settings": { "spaceId": "your-space-id", "environmentId": "master", "region": "us" },
+      "authentication": { "method": "api-key", "secretRef": "env:CONTENTFUL_ACCESS_TOKEN" }
+    }
+  }
+}
+```
+
+Replace the example Space ID with the actual value. Compose the
+[API-key pattern](../patterns/api-key-connection/PATTERN.md) with this provider,
+application authorization and private file state. CLI and UI use the same file.
+The application owns its connection and controls who may read its content.
+
+`entries.list` reads `/spaces/{spaceId}/environments/{environmentId}/entries`
+on `cdn.contentful.com` or `cdn.eu.contentful.com`, using a Bearer header.
+Inputs are `limit` (1–1000, default 1), `skip` (nonnegative, default 0), optional
+`content_type`, `locale`, `include` (0–10), `order`, full-text `query` and `sys.id`.
+The original JSON envelope is preserved, including unresolved-link errors and
+`includes.Entry`/`includes.Asset`. Advance `skip` explicitly using `total`, `skip`
+and `limit`, with an appropriate stable `order`; no automatic paging occurs.
+Concurrent publication can still change offset results. Cursor/Sync APIs remain
+native work. [Delivery API](https://www.contentful.com/developers/docs/references/content-delivery-api/overview/).
+
+| Operation | Inputs | Purpose |
+|---|---|---|
+| `entries.list` | Pagination and fields above | Published entries, with optional linked content |
+| `entries.get` | `id`, optional `locale` | One published entry |
+| `assets.list` | `limit`, `skip`, optional `locale`, `order`, `query` | Published asset metadata |
+| `assets.get` | `id`, optional `locale` | One asset's fields and file URL |
+| `contentTypes.list` / `contentTypes.get` | Pagination / `id` | Content model fields |
+| `locales.list` | Pagination | Locale codes, default/fallback information |
+
+For a single article **with links**, use `entries.list` with `sys.id` and
+`include`; the individual-entry endpoint does not expand links. Contentful's
+include default is 1, maximum 10. Match linked IDs/types against `items` and
+`includes`; unpublished/missing links can remain unresolved. Do not assume a
+missing link means the entire request failed, or that every returned reference
+has a corresponding asset. Preserve provider errors and handle absent content.
+[Link resolution](https://www.contentful.com/developers/docs/references/content-delivery-api/links/).
+
+```js
+const page = await connections.invoke({ context, integrationId: "content",
+  operation: "entries.list", input: { "sys.id": approvedArticleId, include: 2, locale: "en-US" } });
+const image = await connections.invoke({ context, integrationId: "content",
+  operation: "assets.get", input: { id: approvedAssetId, locale: "en-US" } });
+```
+
+`locale: "*"` returns locale-keyed field values; do not treat them as the same
+shape as single-locale strings. Locales and fallback rules belong to the content
+model. Asset results are metadata/file URLs, not downloaded bytes. Convert
+protocol-relative file URLs to HTTPS when rendering and validate the destination
+in your application's media policy; the adapter never forwards its token to an
+asset URL. Rich-text rendering/sanitization and caching belong to the framework.
+
+All operations are read-only Delivery calls. Preview drafts, publication, edits
+and management credentials are intentionally excluded.
+
+## Provisioning and ownership
+
+The application owner supplies the space and key. No OAuth callback or Vibe64
+registration is needed; custom application domains do not change this flow.
+An AI can prepare the configuration and framework wiring. Contentful documents
+Delivery key creation through its Content Management API after authorized
+bootstrap access, as well as the console flow above. That management credential
+is separate from the delivery key stored for runtime use. Account signup,
+space access and authorizing bootstrap management access remain owner tasks.
+Different key names do not establish independent quota allocations.
+
+For Laravel, use native HTTP/configuration tools and the public application
+setup command contract; this package provides JavaScript code only.
+
+## Version-zero change and evidence
+
+The initial unpublished CMA `spaces.list` fragment has been replaced. Existing
+experimental configurations must supply `settings.spaceId`, a Delivery token,
+and use `entries.list`. There is no compatibility alias or automatic token
+conversion. Environment and region default to `master` and `us` respectively.
+
+Focused controlled tests cover delivery headers and paths, EU/environment
+selection, invalid settings before transport, published-entry validation,
+page limits, private file-store restart, token rotation, isolation, disconnect
+and provider failures. No live Contentful account or generated app was used.
+
+
+**LIMITATIONS:** Vibe64 chat attachment is deferred: the app can display published
+articles and images, but saving this connection does not let the coding assistant
+browse the space. This connector does not author/publish content or render a CMS
+interface. For example, publish the article and hero asset in Contentful first;
+the app then resolves their IDs and renders them with its native components.
+Cross-space authenticated links, Sync/cursor feeds and asset transformation are
+native extensions, not silently fetched. Controlled tests cover links, locale
+shapes, pagination, resource reads and errors; no live content was accessed.

package/docs/databricks.md

@@ -0,0 +1,180 @@
+# Databricks
+
+The initial fragment reads a workspace's Jobs API through a custom OAuth
+application or a service principal. Both use `databricksProvider` from
+`@jskit-ai/connectors-catalog/server/databricks` and the ordinary connections
+service. Configuration and encrypted runtime state can both use files.
+
+## Choose the owner and credentials
+
+| Use | Registration | Connection method | Callback |
+|---|---|---|---|
+| Each user's Databricks access | Custom confidential OAuth application | `beginAuthorization`, then `completeAuthorization` | Exact backend callback |
+| Shared service principal | Service principal client ID and Databricks OAuth secret | `connectClientCredentials` | None |
+
+The service principal has its own identity. It cannot stand in for a different
+Databricks account belonging to each app user. The application policy may let
+authorized members use a shared connection or delegate access to an assistant.
+It must derive the storage owner from trusted application identity.
+
+## Create a service principal connection
+
+1. Open the intended Databricks workspace. Open the user menu, **Settings**,
+   **Identity and access**, then **Service principals → Manage**.
+2. Select an existing principal or arrange for the admin to create and assign
+   one. Grant workspace access and visibility of the jobs the application needs.
+3. Open the principal's **Secrets** tab and select **Generate secret**. Set a
+   suitable lifetime and scopes, then generate it. Copy its client ID and the
+   one-time secret into your private configuration environment.
+4. For this fragment, a secret allowing `jobs` can be narrower than `all-apis`.
+   A legacy unrestricted secret can request `all-apis`. Avoid granting token
+   administration just to read jobs.
+5. Configure **Service account** in the editor, enter the principal's client ID
+   and save configuration. Choose **Set credential in Env**, paste the OAuth
+   secret under the displayed client-secret reference, and save it there. Select
+   `jobs` without `all-apis` when the secret is jobs-scoped. Return and verify the
+   first jobs page; this mode needs no callback or browser consent.
+
+This is Databricks OAuth, including on Azure; a Microsoft Entra secret, personal
+access token or login password is not interchangeable. The provider describes
+secret management and workspace assignment in its [service principal guide](https://docs.databricks.com/aws/en/dev-tools/auth/oauth-m2m).
+
+```json
+{
+  "schemaVersion": 1,
+  "integrations": {
+    "warehouse": {
+      "provider": "databricks",
+      "displayName": "Operations jobs",
+      "accountMode": "shared",
+      "settings": { "workspaceUrl": "https://dbc-abc123.cloud.databricks.com" },
+      "scopes": ["jobs"],
+      "authentication": { "method": "oauth2", "registrationRef": "databricks-service" }
+    }
+  },
+  "registrations": {
+    "databricks-service": {
+      "source": "own",
+      "grantType": "client_credentials",
+      "clientId": "11111111-1111-1111-1111-111111111111",
+      "clientSecretRef": "env:DATABRICKS_CLIENT_SECRET",
+      "tokenEndpointAuthMethod": "client_secret_basic"
+    }
+  }
+}
+```
+
+## Create a user consent connection
+
+An account admin opens the **account console → Settings → App connections →
+Add connection**. Enter the application's name and the exact redirect URL.
+Choose **All APIs** for the Jobs fragment and generate a client secret for a
+confidential application. Set access/refresh lifetimes, add the connection and
+save the client ID and one-time secret. Activation can take 30 minutes.
+See [custom application setup](https://docs.databricks.com/aws/en/integrations/enable-disable-oauth).
+
+In the JSON above, set `accountMode` to `per-user`, select `all-apis` and
+`offline_access`, and use a registration containing:
+
+```json
+{
+  "source": "own",
+  "grantType": "authorization_code",
+  "clientId": "22222222-2222-2222-2222-222222222222",
+  "clientSecretRef": "env:DATABRICKS_OAUTH_CLIENT_SECRET",
+  "tokenEndpointAuthMethod": "client_secret_post",
+  "callbackUrlRef": "env:DATABRICKS_CALLBACK_URL"
+}
+```
+
+Set that callback binding to your own active HTTPS route, or an explicitly
+registered loopback callback for a CLI. Start consent, open the returned URL,
+then pass the returned callback to `completeAuthorization` under the same
+authenticated app owner. PKCE/state and one-time completion are library-owned.
+Do not borrow `databricks-cli` as a third-party client ID. Databricks documents
+the [user authorization flow](https://docs.databricks.com/aws/en/dev-tools/auth/oauth-u2m).
+
+The service uses form-body client authentication for user authorization and
+refresh, matching the official SDK; service credentials use HTTP Basic. It
+renews tokens 40 seconds early because Azure can reject tokens with 30 seconds
+remaining. See the [Databricks OAuth implementation](https://github.com/databricks/databricks-sdk-py/blob/main/databricks/sdk/oauth.py).
+
+## Workspace addresses
+
+Use the exact workspace origin, without an application path, query or hash.
+This initial validator accepts `dbc-….cloud.databricks.com` on AWS,
+`adb-<digits>.<digits>.azuredatabricks.net` on Azure and
+`<digits>.<digits>.gcp.databricks.com` on Google Cloud. A final slash is allowed.
+Regional/account console URLs, private proxy aliases and newer unified domain
+forms require a separate adapter extension. See the [Azure per-workspace URL](https://learn.microsoft.com/en-us/azure/databricks/workspace/per-workspace-urls)
+and [Google Cloud workspace identifiers](https://docs.databricks.com/gcp/en/workspace/workspace-details).
+
+The configured workspace selects both `/oidc/v1/authorize` and `/oidc/v1/token`
+as well as the API origin. Neither callback parameters nor operation input can
+change that destination.
+
+## Runtime and AI composition
+
+Parse the same JSON with `parseIntegrationConfiguration(text, { providers:
+[databricksProvider] })`. Supply the ordinary `authorize`, reference resolver
+and private file store to `createConnectionService`. Compose the Feature when
+using JSKIT actions; `connectors.verifyClientCredentials` exposes service
+verification through the existing action runtime.
+
+```js
+await connections.connectClientCredentials({ context, integrationId: "warehouse" });
+const jobs = await connections.invoke({
+  context, integrationId: "warehouse", operation: "jobs.list",
+  input: { limit: 20, expand_tasks: false }
+});
+```
+
+`jobs.list` accepts `limit` (1–100), `expand_tasks`, exact `name` filtering and an
+opaque `page_token`. Empty results may omit `jobs`. `jobs.get` requires numeric
+`job_id`, accepts `include_trigger_state` and a continuation token, and returns
+one page of job details. Nested task arrays can be paginated. The caller must
+decide whether to follow tokens; the library makes one read per invocation.
+See the [Jobs API](https://docs.databricks.com/api/jobs/v2/list-jobs).
+
+The fragment bounds tokens to 8192 characters and job IDs to JavaScript's safe
+integer range. It rejects writes, SQL, arbitrary URLs, malformed job IDs and
+responses identifying a different requested job. An OAuth grant can allow
+more than these two operations; neither `jobs` nor `all-apis` is a read-only
+provider permission. Configure resource permissions accordingly.
+
+Service credentials renew with their secret rather than a refresh token.
+Renewal is serialized per connection and cannot expand the stored grant.
+Changing a service connection's scopes or grant type requires reconnecting.
+Tokens remain encrypted; source contains references. Disconnect removes the
+local connection and attempts without deleting the principal or revoking the
+provider application globally.
+
+## Public, Online and automation
+
+Register the real callback implemented by the runtime that owns this connection.
+For an application integration, use the application's assigned hosting URL as
+the initial origin and its implemented callback path. Store the exact callback
+in its Env reference and provider registration. A domain change requires updating
+both values if the callback URL changes; retain the application identity and its
+persistent grants when moving hosts. Public Vibe64, Online and CLI users supply
+their own registrations through this same contract.
+See the [callback guide](../../connectors-core/docs/oauth-callbacks.md).
+
+Service principals have no callback. Databricks custom applications are created
+within a customer account; creating one does not establish a universal third-party
+registration across every customer account. The application owner supplies its
+account's registration. Separate registrations do not reserve workspace compute
+or guarantee separate provider quotas.
+
+An AI can prepare the portable file and registration request, and an authorized
+operator can provision custom apps using the account API or
+`databricks account custom-app-integration create --confidential --json …`.
+The API accepts name, redirect URLs, scopes and token policy and returns client
+credentials. Admin authorization and storage of the returned secret remain
+operator responsibilities. See [OAuth app integration APIs](https://docs.databricks.com/api/o-auth/v1/get-custom-o-auth-app-integration).
+Service principal provisioning and secret generation similarly need account
+privileges; this fragment does not implement provisioning endpoints.
+
+Live accounts, consent, private networking, account-level operations, SQL/data
+queries, jobs execution and app login are unverified or
+unfinished. Local proof uses controlled HTTP responses and encrypted files.