@jskit-ai/connectors-catalog 0.1.1

package/docs/stripe.md

@@ -0,0 +1,77 @@
+# Stripe
+
+Import `stripeProvider` from `@jskit-ai/connectors-catalog/server/stripe`.
+The initial fragment reads a merchant account's balance. It does not implement
+checkout, subscriptions, refunds, webhooks or Stripe Connect onboarding.
+
+## Configure access
+
+Before creating a key, [create or sign into your own Stripe account](https://dashboard.stripe.com/register).
+Select the business that will receive this application's payments. Complete
+Stripe's requested activation information in its Dashboard before accepting live
+payments. Saving a key does not create, activate or approve a merchant account.
+Keep sandbox and live credentials separate.
+
+1. Select the intended Stripe account and sandbox/live mode in the Dashboard.
+   Open **API keys**, then **Create restricted key**.
+2. Start with zero permissions, give the key an application-specific name and
+   grant **Balance** read access. Leave unrelated resources disabled.
+3. Choose **Create key**, complete the verification prompt and copy the value
+   while visible. Finish the note/save dialog. These controls and the option
+   to duplicate a key are described in the
+   [restricted-key guide](https://docs.stripe.com/keys/restricted-api-keys).
+4. Put the value in backend Env as `STRIPE_API_KEY`. Save provider `stripe`,
+   mode `shared` or `assistant`, `scopes: []`, and authentication
+   `{ "method": "api-key", "secretRef": "env:STRIPE_API_KEY" }`.
+5. Run `connectApiKey` to verify balance access. Publishable keys are unsuitable;
+   restricted and secret keys authenticate backend requests. Bearer auth is
+   supported alongside Basic auth.
+   [Authentication](https://docs.stripe.com/api/authentication).
+
+## Runtime and AI composition
+
+`balance.read` performs `GET https://api.stripe.com/v1/balance` with no input.
+The returned object retains `available`, `pending`, currency amounts and
+`livemode`. It uses the account's configured Stripe API version; no version
+override or connected-account header is supplied by this fragment.
+[Balance endpoint](https://docs.stripe.com/api/balance/balance_retrieve).
+
+Use the [API-key pattern](../patterns/api-key-connection/PATTERN.md) with this
+provider. The CLI and editor use identical JSON and file-store library wiring.
+Applications must authorize who can see the shared merchant account's balance.
+
+## Automation and application ownership
+
+An AI can author the configuration and balance call after the owner supplies a
+key. This pass establishes Dashboard key creation, not an API for bootstrapping
+the merchant account or issuing its initial restricted key. Account activation
+and any requested business verification remain owner tasks.
+
+The application owner supplies a key for its merchant account through private
+Env. Separate keys do not create separate merchants or prove separate capacity.
+An application serving multiple merchants needs explicit merchant ownership and
+its own Stripe Connect design; it cannot silently collect each merchant's revenue
+into one unrelated account. That design is outside this balance fragment.
+
+Automatic merchant onboarding uses Stripe Connect, a separate platform
+integration with explicit account responsibilities and Dashboard access. It is
+not provided by entering this project's API key. See Stripe's current
+[connected-account configuration](https://docs.stripe.com/connect/accounts-v2/connected-account-configuration).
+This connector does not create connected accounts or depend on a platform's
+Connect credentials. Exported applications continue using their own merchant
+credentials and application database.
+
+Automated tests cover balance shape, headers, file-store restart, credential
+replacement, isolation, disconnect and errors. They make no live Stripe calls.
+
+## Full application payments
+
+This connector's operations are only part of a billing implementation. For
+checkout, subscriptions, feature access, renewal credits and durable catalogue
+mappings, read [payments-core](../../payments-core/README.md) and its
+[standalone composition guide](../../payments-core/docs/standalone.md). These
+JavaScript libraries work from ordinary app code or a CLI without Vibe64 or
+Genesis. Other frameworks consume the [portable contract](../../payments-core/docs/contract.md)
+and its static examples using their own runtime libraries. Keep provider setup
+from this guide; do not substitute a successful connection check for working
+checkout, verified webhooks or merchant approval.

package/docs/supabase.md

@@ -0,0 +1,51 @@
+# Supabase
+
+Import `supabaseProvider` from `@jskit-ai/connectors-catalog/server/supabase`.
+This fragment lists project metadata through the Management API. It does not
+install storage, connect to Postgres, configure login or execute SQL.
+
+## Configure access
+
+1. Open Supabase's [account token settings](https://supabase.com/dashboard/account/tokens)
+   and generate a personal access token for this application.
+2. Where available, choose a scoped token with the intended resources and
+   project-read permission. Scoped tokens are in a gradual alpha rollout;
+   classic tokens instead inherit the account's full access. Review that choice
+   before supplying a token. [Token guide](https://supabase.com/docs/guides/platform/personal-access-tokens).
+3. Put the token into backend Env as `SUPABASE_ACCESS_TOKEN`. Project anon,
+   publishable, secret and service-role keys are different from Management API
+   credentials. [API authentication](https://supabase.com/docs/reference/api/introduction).
+4. Save provider `supabase`, mode `shared` or `assistant`, `scopes: []`, and
+   authentication
+   `{ "method": "api-key", "secretRef": "env:SUPABASE_ACCESS_TOKEN" }`.
+5. Run `connectApiKey`. The project-list endpoint requires `projects_read` for
+   a fine-grained token; its corresponding OAuth scope is `projects:read`.
+   Empty accessible-project lists are valid.
+   [Project endpoint](https://supabase.com/docs/reference/api/v1-list-all-projects).
+
+## Runtime and AI composition
+
+`projects.list` performs `GET https://api.supabase.com/v1/projects` with
+Bearer authorization and no inputs. It returns the array of project metadata.
+The fragment contains no project-creation or database-mutation operation.
+
+Use the [API-key pattern](../patterns/api-key-connection/PATTERN.md), supplying
+this provider and the JSON file store. Configuration and runtime state remain
+files for the editor. A separate application may explicitly install a database
+for its own purpose; this integration does not make that decision.
+
+## Automation and application ownership
+
+The Management API offers further provisioning endpoints after authentication,
+so an AI can prepare API requests and application wiring with suitable owner
+authority. This pass verifies token bootstrap through account settings, not an
+API for creating the first personal token. OAuth registration for other users
+is a distinct flow.
+
+Personal tokens act for their owner and allowed resources. Each application
+owner supplies its authorized token through private Env. Separate token names
+are not sufficient evidence of independent organization limits or billing.
+
+Fixtures cover project records, empty results, invalid payloads, credential
+replacement, file-store restart, isolation and provider errors. No Supabase
+project or database is created or accessed during these tests.

package/docs/tally.md

@@ -0,0 +1,105 @@
+# Tally
+
+Import `tallyProvider` from `@jskit-ai/connectors-catalog/server/tally`.
+The adapter lists account forms and reads their submissions with an API key.
+
+## Configure access
+
+1. Sign into the intended Tally user account. Keys inherit that user's resource
+   access, including access changes made later.
+2. Open **Settings → API keys → Create API key**.
+3. Create and copy the key while it is displayed. This flow does not provide
+   per-form permission selection; do not invent scope checkboxes in application
+   setup that imply the provider enforces them.
+4. Store the key in backend Env as `TALLY_API_KEY`.
+5. Save provider `tally`, mode `shared` or `assistant`, `scopes: []`, and
+   authentication `{ "method": "api-key", "secretRef": "env:TALLY_API_KEY" }`.
+6. Verify through `connectApiKey`. Manage keys in Settings; removing the owner
+   from an organization also affects their keys' access.
+   [Key ownership and setup](https://developers.tally.so/api-reference/api-keys).
+
+## Runtime and AI composition
+
+`forms.list` sends `GET https://api.tally.so/forms` with Bearer authorization
+and `tally-version: 2025-02-01`. Inputs are `page` (starting at 1) and `limit`
+(1–500, default 50). The response retains `items`, `page`, `limit`, `total`
+and `hasMore`. Increment the page while `hasMore` is true. The connection check
+uses the same operation; it does not create forms or fetch submission content during verification.
+[Forms API](https://developers.tally.so/api-reference/endpoint/forms/list),
+[version header](https://tally.so/help/api).
+
+Use the [API-key pattern](../patterns/api-key-connection/PATTERN.md) from CLI
+code or an application service. The application owns which form metadata each
+of its users may see; a shared provider key is not end-user authentication.
+
+## Automation and application registrations
+
+After interactive key setup, an AI can wire calls and prepare forms or webhooks
+using documented provider APIs. The adapter exposes listing, draft creation, reading/updating forms and submission retrieval. No ordinary
+API for creating the initial API key was verified; it remains an operator step.
+
+This mode has no provider app/client ID. The application owner supplies its
+user's authorized key through private Env. Distinct configuration names cannot
+create independent capacity from one user's keys. Tests simulate pagination,
+header versioning, bad keys, rate limits, malformed results, file-store restart,
+rotation and cross-application isolation. No live forms were created or accessed.
+
+## Submission retrieval
+
+Invoke `submissions.list` with `formId`, optional `page` (default 1), `limit`
+(1–500, default 50), `filter` (`completed` by default, or `all`/`partial`) and
+`afterId` from an earlier submission. GET `/forms/{formId}/submissions` retains
+questions, answers, provider totals and `hasMore`. Advance pages explicitly;
+keep the form/filter with pagination state and deduplicate imported submissions
+by ID. An empty page is valid. False, zero and structured answers are preserved.
+
+The application owns who can read these responses and how they are retained.
+A shared key does not grant every app user access to every form. Do not fetch
+returned PDF/preview/file URLs automatically or render answers as trusted HTML.
+Other frameworks can use their native server HTTP client with the same Env
+Bearer token and version header; no JSKIT or Vibe64 process is required.
+[Submission API](https://developers.tally.so/api-reference/endpoint/forms/submissions/list).
+
+No live submission was read.
+
+
+## Create, review and publish
+
+```js
+const draft = await connections.invoke({
+  context: authenticatedOwner, integrationId: "forms", operation: "forms.create",
+  input: { blocks: [
+    { uuid: crypto.randomUUID(), type: "FORM_TITLE", groupUuid: crypto.randomUUID(),
+      groupType: "FORM_TITLE", payload: { title: "Booking request" } },
+    { uuid: crypto.randomUUID(), type: "INPUT_TEXT", groupUuid: crypto.randomUUID(),
+      groupType: "INPUT_TEXT", payload: { isRequired: true, placeholder: "Your name" } }
+  ] }
+});
+// After the application's explicit review/approval:
+await connections.invoke({ context: authenticatedOwner, integrationId: "forms",
+  operation: "forms.update", input: { formId: draft.id, status: "PUBLISHED" } });
+```
+
+`forms.create` accepts native `blocks` (up to 500), optional workspace/template/
+folder IDs and status (default `DRAFT`). The provider uses the account's default
+workspace when no workspace ID is supplied. Native block schema and account
+access remain Tally's authority; local validation checks the outer block shape,
+not every block-specific payload. Construct fresh UUIDs for new blocks and retain
+existing identifiers when editing. Never blindly replay an uncertain creation:
+list forms and reconcile the result before deliberately retrying.
+
+`forms.get` returns blocks and metadata. `forms.update` accepts a name, status
+(`BLANK`, `DRAFT`, `PUBLISHED`) or replacement blocks; omitted fields are not sent.
+Fetch and review before replacing blocks, since existing submissions may refer
+to old questions. No automatic publication, polling loop or form designer is
+created by configuring the connector.
+[Create](https://developers.tally.so/api-reference/endpoint/forms/post),
+[read](https://developers.tally.so/api-reference/endpoint/forms/get),
+[update](https://developers.tally.so/api-reference/endpoint/forms/patch).
+
+Other frameworks send the same JSON via their own server HTTP client and Env
+binding. The application owns review screens, publication decisions, ingestion
+and retention. A native Tally embed or hosted form can collect answers without
+exposing this administrative API key to the browser. Settings, webhooks, form
+trash and response deletion are not implemented by this adapter; account-level
+setup and advanced form editing remain available in Tally.

package/docs/telegram.md

@@ -0,0 +1,165 @@
+# Telegram
+
+Import `telegramProvider` from `@jskit-ai/connectors-catalog/server/telegram`.
+The adapter reads bot identity/webhook status, sends plain text and chat actions,
+and receives message updates through explicit polling. It does not change
+webhooks or authenticate application users.
+
+## Manual provider setup
+
+1. Open Telegram and find the verified [BotFather](https://t.me/BotFather).
+2. Send `/newbot`, supply a display name, then choose an available username
+   ending in `bot`. Keep the returned token private.
+3. Store the token in your backend environment as `TELEGRAM_BOT_TOKEN`.
+4. Add Telegram in Vibe64. Enter `env:TELEGRAM_BOT_TOKEN` in **Bot token
+   reference** and save. The CLI uses exactly the same JSON below.
+5. Run the application's connection verification. Saving an editor form alone
+   does not contact Telegram or prove that the token works.
+
+BotFather manages bot creation and tokens; the token belongs to a bot rather
+than its owner's personal Telegram mailbox.
+[Telegram bot tutorial](https://core.telegram.org/bots/tutorial).
+
+## Portable configuration and runtime
+
+```json
+{
+  "schemaVersion": 1,
+  "registrations": {},
+  "integrations": {
+    "bot": {
+      "provider": "telegram",
+      "displayName": "Service bot",
+      "accountMode": "shared",
+      "scopes": [],
+      "authentication": { "method": "api-key", "secretRef": "env:TELEGRAM_BOT_TOKEN" }
+    }
+  }
+}
+```
+
+Compose the [API-key pattern](../patterns/api-key-connection/PATTERN.md) with
+`providers: [telegramProvider]`, application authorization and a file connection
+store. Runtime state is private text files outside the source tree; no editor
+database or generated project is required to use the library from a CLI.
+
+```js
+await connections.connectApiKey({ context, integrationId: "bot" });
+const status = await connections.invoke({
+  context, integrationId: "bot", operation: "webhook.read"
+});
+console.log(status.result.pending_update_count);
+```
+
+| Operation | Telegram method | Input | Result |
+|---|---|---|---|
+| `profile.read` (verification) | `getMe` | `{}` | `{ ok: true, result: bot }` |
+| `webhook.read` | `getWebhookInfo` | `{}` | `{ ok: true, result: webhook }` |
+
+Bot API requests use `https://api.telegram.org/bot<TOKEN>/<METHOD>`.
+`getMe` identifies the bot. `getWebhookInfo` reports delivery configuration and
+pending updates; its URL is empty when no outgoing webhook is configured.
+`getUpdates` and webhooks are alternative delivery mechanisms, so verification
+must not start polling or acknowledge updates. Telegram error envelopes contain
+`ok: false`, a description and an error code.
+[Bot API methods and envelopes](https://core.telegram.org/bots/api).
+
+The adapter checks the token's numeric-ID/colon/token shape before transport,
+validates successful bot and webhook fields, and preserves extra response data.
+Only the fixed API origin receives credentials. Source and connection records
+contain references; update the environment binding for token rotation.
+HTTP failures and unsuccessful JSON envelopes become safe connector errors;
+an unauthorized token marks a previously verified connection as needing
+reconnection. Provider descriptions are not returned. This fragment does not
+schedule retries or expose Telegram's optional retry-delay payload.
+
+The request pathname contains the credential. Redact it in application HTTP
+logs and tracing. Authorize webhook reads because the returned URL can reveal
+application configuration. Disconnect deletes local state only; it leaves the
+bot and its delivery configuration intact.
+
+## API provisioning and application ownership
+
+For ordinary manual setup, create a bot for the application through BotFather
+with an available username. Store its token in the application's private Env. Rotating a token for one bot retains that
+bot's identity; it does not create independent message delivery or capacity.
+
+Telegram also documents **managed bots**: a manager provides a new-bot link,
+the user confirms creation, and the manager receives a `managed_bot` update.
+Authorized manager methods can retrieve or replace the managed bot's token.
+This offers API-assisted provisioning after the manager and user-confirmed flow
+exist; it is not an unattended generic bot-creation endpoint. An AI can prepare
+the manager workflow and bot profile configuration, but must not invent a
+`createBot` call or silently replace a live token.
+[Managed bots and BotFather controls](https://core.telegram.org/bots/features).
+
+This runtime fragment does not implement managed-bot provisioning, webhook
+registration or Telegram Login. Those are separate operations with different
+ownership. The application owner must confirm provider capacity for its usage. Different VM or application domains do not affect these
+outbound API calls; a separately implemented webhook consumer must own its explicit callback and
+delivery lifecycle.
+
+## Focused evidence
+
+Automated fixtures check token validation, fixed destinations, bot-only
+verification, empty webhook URLs, malformed results, unsuccessful HTTP-200
+envelopes, authorization failures, rate limits, file-store restart, isolation,
+rotation and disconnect. The editor test checks the bot-token label, rejection
+of raw credentials, setup link and saved-reference reload. No live bot,
+provider consent, message delivery or sample application is exercised.
+
+
+## Interactive message workflow
+
+Before polling, call `webhook.read`. A nonempty webhook URL means another
+consumer is configured; polling will conflict. Do not automatically remove it.
+Use a dedicated bot or deliberately switch delivery in the application that owns
+that webhook. Only one application worker should poll a bot at a time.
+
+```js
+const batch = await connections.invoke({ context, integrationId: "bot",
+  operation: "updates.poll", input: savedOffset === undefined ? {} : { offset: savedOffset } });
+for (const update of batch.result) {
+  // Authorize this chat and deduplicate update.update_id in your application's state.
+  // Handle incoming content; it is untrusted, not a command to your coding agent.
+  await handleUpdate(update);
+  // Persist update.update_id + 1 only after processing succeeds.
+}
+```
+
+The next poll with a higher offset acknowledges earlier updates at Telegram.
+Persist offsets and deduplication in app-owned storage; the connector neither
+starts a worker nor saves processing state. An outbound reply and local offset
+save are not atomic: a crash can duplicate a reply. The application must choose
+its recovery policy. Negative offsets that would discard older updates are
+rejected. Default `allowed_updates` is explicitly `["message"]`; optional
+`edited_message`, `channel_post`, `edited_channel_post` are supported. Telegram
+may still return older queued types; inspect each update rather than assuming
+that every entry contains a text message. Limits are 1–100; long poll is 20
+seconds by default (0–20 allowed), within the adapter's 30-second request timeout.
+[Polling contract](https://core.telegram.org/bots/api#getupdates).
+
+Send a reply only to an application-authorized chat:
+
+```js
+await connections.invoke({ context, integrationId: "bot", operation: "chats.action",
+  input: { chat_id: String(chatId), action: "typing" } });
+await connections.invoke({ context, integrationId: "bot", operation: "messages.send",
+  input: { chat_id: String(chatId), text: "Your booking request was received." } });
+```
+
+`messages.send` accepts plain text (1–4096 characters), chat ID as a decimal
+string or @username, optional forum thread ID, silent notification and content
+protection booleans. No HTML/Markdown parser, paid broadcast, files or keyboards
+are enabled. `chats.action` accepts Telegram's documented typing/upload/record
+status values and optional thread ID; it is a transient indicator, not a job
+queue. Bot membership, user initiation and group privacy settings control access.
+The application must not interpret a successful bot verification as permission
+to contact arbitrary people. No send is retried automatically after uncertainty.
+[Send message](https://core.telegram.org/bots/api#sendmessage),
+[chat action](https://core.telegram.org/bots/api#sendchataction).
+
+A non-JavaScript framework uses its own HTTP client and worker with the same Env
+bot token, JSON payloads and offset contract. JSKIT is optional; Vibe64 hosts no
+polling service. Local disconnect leaves the bot and queued updates intact.
+Revoke/replace a compromised token with BotFather, change Env and verify again.

package/docs/tiktok.md

@@ -0,0 +1,201 @@
+# TikTok
+
+Import `tiktokProvider` from `@jskit-ai/connectors-catalog/server/tiktok`.
+The library reads the consenting creator's profile, statistics and public video
+metadata. CLI and server consumers use the same configuration and connection
+service; Vibe64 edits that file through shared fields and validation.
+
+## Provider setup
+
+1. At [TikTok for Developers](https://developers.tiktok.com/), sign in, open
+   your profile menu, choose **Manage apps**, then **Connect an app**.
+   Select the owning organization/account and confirm.
+2. Complete the app's identity, icon, description and website under its details.
+   Select Web. In the products section add Login Kit and Display API.
+3. In Login Kit's Web settings enter the backend callback described below.
+   Copy the **Client key**, not the separate App ID, and store the client secret
+   in the backend environment.
+4. Before production submission, verify your configured website/policy URLs
+   through URL properties. Complete the review explanation and demo, save,
+   then submit the application-owned registration. [Registration and review](https://developers.tiktok.com/docs/en/getting-started-create-an-app).
+5. In **Scopes**, add `user.info.basic`, `user.info.profile`, `user.info.stats`
+   and `video.list` as needed. Basic access verifies the account; users may
+   decline the others. The runtime blocks an operation lacking its granted
+   permission. [Scope selection](https://developers.tiktok.com/docs/en/scopes-overview).
+6. Start in Sandbox with designated test accounts. Production availability
+   requires approval for the actual products and use case.
+   [Display API prerequisites](https://developers.tiktok.com/docs/en/display-api-get-started).
+7. Set `TIKTOK_CLIENT_SECRET` and `TIKTOK_CALLBACK_URL` on the callback-owning
+   backend. Save their references in JSON. Saving configuration does not start
+   consent or prove provider approval.
+
+For a Web registration, the callback must be an exact static HTTPS URI, shorter
+than 512 characters, without a query or fragment. HTTP loopback callbacks are
+not accepted by this adapter. The authorize URL uses `client_key` and comma
+separated permissions. An operator CLI can invoke the same library through an
+HTTPS callback-owning backend; this fragment does not implement TikTok's
+separate native Desktop journey. Keep the confidential secret off distributed
+clients. The shared runtime sends PKCE parameters, but TikTok's Web guide does
+not establish enforcement of them. [Web flow](https://developers.tiktok.com/doc/login-kit-web/),
+[Desktop flow](https://developers.tiktok.com/docs/en/login-kit-desktop).
+
+```json
+{
+  "schemaVersion": 1,
+  "registrations": {
+    "creator-app": {
+      "source": "own",
+      "clientId": "YOUR_TIKTOK_CLIENT_KEY",
+      "clientSecretRef": "env:TIKTOK_CLIENT_SECRET",
+      "callbackUrlRef": "env:TIKTOK_CALLBACK_URL"
+    }
+  },
+  "integrations": {
+    "creator": {
+      "provider": "tiktok",
+      "displayName": "Creator account",
+      "accountMode": "per-user",
+      "scopes": ["user.info.basic", "user.info.stats", "user.info.profile", "video.list"],
+      "authentication": { "method": "oauth2", "registrationRef": "creator-app" }
+    }
+  }
+}
+```
+
+## Runtime composition
+
+Use the packaged [OAuth connection pattern](../patterns/oauth-connection/PATTERN.md) to construct `connections` from
+this provider, parsed JSON, host authorization, reference resolution and the
+encrypted file store. Pass `tiktokProvider` to both configuration validation and
+the connection service. No copied application template or database is required.
+
+```js
+const pending = await connections.beginAuthorization({
+  context: authenticatedOwner, integrationId: "creator"
+});
+// Open pending.authorizationUrl in the user's browser.
+// In the registered backend callback, recover the same trusted owner:
+await connections.completeAuthorization({
+  context: authenticatedOwner, integrationId: "creator", callbackUrl
+});
+const page = await connections.invoke({
+  context: authenticatedOwner, integrationId: "creator",
+  operation: "videos.list", input: { max_count: 10 }
+});
+// If page.data.has_more, explicitly request its data.cursor on a later call.
+```
+
+The host derives ownership from an authenticated session or trusted CLI operator.
+It must not accept application or subject identities from arbitrary browser
+input. Shared and assistant modes require the host to authorize every caller
+before mapping to the shared subject. A builder's connected account does not
+become all app users' individual accounts.
+
+| Operation | Permission | Input and result |
+|---|---|---|
+| `profile.read` (verification) | `user.info.basic` | No input; `open_id`, `display_name`, `avatar_url` |
+| `profile.extended` | `user.info.profile` | No input; username, bio, profile link and verification flag |
+| `profile.stats` | `user.info.stats` | No input; follower, following, like and video counts |
+| `videos.list` | `video.list` | `max_count` 1–20, default 10; optional nonnegative safe-integer `cursor`; one public video page with IDs, titles and cover URLs |
+
+Profile operations use GET `/v2/user/info/`; video pages use POST
+`/v2/video/list/`, both on `https://open.tiktokapis.com`. Each operation selects
+only its own fields and returns the validated original envelope. Keep video
+IDs as strings. Pagination cursors are millisecond timestamps; preserve them
+with their connection/query rather than automatically crawling every page.
+[Profile fields](https://developers.tiktok.com/docs/en/tiktok-api-v2-get-user-info),
+[video pagination](https://developers.tiktok.com/docs/en/tiktok-api-v2-video-list).
+
+The service verifies basic profile access before saving tokens. It encrypts
+credentials outside source, binds attempts to their owner and consumes each
+attempt once. Initial grants are bounded by configured scopes; refresh can
+shrink existing permissions but cannot expand them. Rotated refresh tokens
+replace previous ones. TikTok's `refresh_expires_in` is validated but not stored
+as a proactive expiry cutoff in this initial implementation; provider rejection
+requires reconnection. Local disconnect deletes local access only. Provider
+revocation is a separate action, currently unwired.
+[Token exchange, refresh and revocation](https://developers.tiktok.com/docs/en/oauth-user-access-token-management).
+
+Provider error codes distinguish revoked/expired access from missing scopes,
+including TikTok's scope error that uses HTTP 401. Permission failures preserve
+the connection; invalid access marks it for reconnect. Rate-limit failures are
+reported without automatic retries. Cancellation, timeout and malformed data
+are explicit errors, and provider message/log text is omitted.
+[API errors](https://developers.tiktok.com/docs/en/tiktok-api-v2-error-handling),
+[OAuth errors](https://developers.tiktok.com/docs/en/oauth-error-handling).
+
+## Creator gallery in an application
+
+A useful first screen is a creator header and a paged list of public video
+cards. The application's authenticated backend calls `profile.read` and
+`videos.list`; it sends those results to that same authorized viewer, never the
+connection record or tokens. For example, after the OAuth pattern has provided
+`connections` and the host has derived `authenticatedOwner`:
+
+```js
+const request = { context: authenticatedOwner, integrationId: "creator" };
+const creator = await connections.invoke({ ...request, operation: "profile.read" });
+const videos = await connections.invoke({ ...request, operation: "videos.list",
+  input: { max_count: 10, ...(cursor === undefined ? {} : { cursor }) } });
+const gallery = {
+  name: creator.data.user.display_name,
+  avatarUrl: creator.data.user.avatar_url,
+  videos: videos.data.videos,
+  nextCursor: videos.data.has_more ? videos.data.cursor : null
+};
+// Return gallery through the framework's authenticated JSON response.
+```
+
+The frontend renders `name` and each video `title` as escaped text, uses HTTPS
+image URLs for the avatar and covers, and offers **Load more** only when
+`nextCursor !== null`. Append the next page with duplicate IDs removed. Keep the
+cursor in the current account's gallery state; clear displayed data on account
+switch or disconnect. Show an empty state for an account with no public videos.
+When `video.list` was declined, keep the profile visible and offer reconnection
+with that permission instead of presenting a broken gallery. A thumbnail can
+expire or disappear: show an image fallback and refresh metadata on the next
+explicit load. Do not permanently copy the media or interpret titles as HTML.
+
+This composition shows metadata cards. It does not provide playback, posting,
+downloads or a persistent mirror of the account. A removed/private video may
+vanish between pages; do not assume the feed is an immutable snapshot.
+[Public-video listing](https://developers.tiktok.com/docs/en/tiktok-api-v2-video-list).
+
+A Node app or CLI consumes the same installed JSKIT exports and file without
+Vibe64. A different framework owns its OAuth/token storage and native HTTP calls:
+read the same registration references and ownership/scopes, call GET
+`/v2/user/info/` and JSON POST `/v2/video/list/`, then build the same gallery
+response. It must retain the provider-specific `client_key`, comma scopes and
+refresh-token rules described above. JSKIT supplies no PHP implementation.
+
+## Online, public and custom domains
+
+Each application owns its provider registration, callback route, credentials
+and grants. Hosted and installed editors configure the same app-owned setup;
+neither supplies a shared Vibe64 registration or token gateway. Use the app's
+assigned public URL as the initial callback origin, append the route the backend
+actually implements, and register the exact URL with the provider. Keep the
+client secret and callback binding in the application's Env.
+
+A custom-domain or hosting move that changes the callback requires updating both
+the provider registration and the app's Env. Preserve the application's identity
+and private connection store, validate callback state and initiator, and allow
+only application-approved return destinations. The editor's address is not the
+provider callback. See the [callback contract](../../connectors-core/docs/oauth-callbacks.md)
+and [setup command](../../connectors-core/docs/setup-command.md).
+
+Separate registrations do not prove separate quota pools or provider approval.
+The app developer must obtain approval for the actual integration and user flow.
+
+## Automation assessment and limits
+
+| Task | What can be automated |
+|---|---|
+| Create/configure the application registration | Reviewed documentation establishes console setup, not a general provisioning API. AI can guide an authorized operator and prepare configuration; registration/review approval is external work. |
+| Configure callbacks and permissions | Prepare exact values and validate the file. Console setup and ownership verification remain operator steps until an authorized automation route is established. |
+| Consent, refresh and reads | The library implements these exchanges once a valid registration and user consent exist. It cannot grant consent for the user. |
+| Application login, posting, Research API | Outside this fragment. A successful data connection alone does not implement the app's login/session system. |
+
+The initial fragment is tested with controlled token/API responses and the editor
+configuration UI. No live TikTok registration, production approval, provider
+consent or generated application has been exercised.