@jskit-ai/connectors-catalog 0.1.1

package/docs/posthog.md

@@ -0,0 +1,227 @@
+# PostHog
+
+Import `posthogProvider` from `@jskit-ai/connectors-catalog/server/posthog`.
+This fragment implements the public project-token form, flag evaluation and
+explicit event capture. Private analytics, OAuth, MCP, browser autocapture,
+session replay and automatic event batching are not implemented here.
+
+## Create and configure a project manually
+
+1. Sign into the intended PostHog Cloud region. Open the project switcher in
+   the top bar and select the analytics project, or use its create control.
+   An organization's first project is created during setup; additional projects
+   may depend on its plan. Choose an appropriate project name and complete the
+   creation controls shown for your organization.
+2. Open that project's settings from the switcher or sidebar. Copy its numeric
+   **Project ID** and public **Project token** beginning with `phc_`.
+3. In Vibe64, add PostHog. Set the display name, select **Region**, and paste the
+   ID into **Project ID**. The form defaults to Europe; choose United States
+   for a US project.
+4. Store the token under `POSTHOG_PROJECT_TOKEN` in the application environment.
+   Put `env:POSTHOG_PROJECT_TOKEN` in **Project token reference**, then save.
+   CLI users write the same configuration below and resolve the same reference.
+5. For rotation, regenerate the project token in PostHog settings, then update
+   the environment binding. Regeneration invalidates the old token. Check all
+   applications using it before rotating. Local connector disconnect only
+   removes local connection state.
+
+Projects own their data and token; they are distinct from organizations.
+[Project settings](https://posthog.com/docs/settings/projects).
+
+## Portable configuration
+
+```json
+{
+  "schemaVersion": 1,
+  "registrations": {},
+  "integrations": {
+    "analytics": {
+      "provider": "posthog",
+      "displayName": "Product analytics",
+      "accountMode": "shared",
+      "scopes": [],
+      "authentication": {
+        "method": "api-key",
+        "secretRef": "env:POSTHOG_PROJECT_TOKEN"
+      },
+      "settings": {
+        "region": "eu",
+        "projectId": "12345"
+      }
+    }
+  }
+}
+```
+
+Replace the example ID. The local schema accepts a positive decimal ID of up
+to 20 characters and regions `eu` or `us`. This is a fragment validation limit,
+not a claim about the maximum ID PostHog can issue. The token selects the
+project for these operations. Saving the ID preserves the UI configuration,
+but verification cannot establish that the separately saved ID matches the
+token. The form explicitly explains this limit. Changing either setting
+requires verification again.
+
+This token is public and may deliberately be used by a frontend analytics
+client. Keeping its reference in configuration is an ownership convention,
+not a claim that it is secret. The adapter rejects personal (`phx_`), project
+secret (`phs_`), and OAuth (`pha_`/`phr_`) credentials in this field. They belong
+to different APIs. A public token cannot authenticate an application user or
+read private analytics.
+[API authentication](https://posthog.com/docs/api).
+
+## JSKIT library and AI wiring
+
+Use the [API-key composition pattern](../patterns/api-key-connection/PATTERN.md)
+with this provider, a file connection store, environment-reference resolution,
+and the application's authorization policy. Both configuration and runtime
+state remain text files. The editor is not required by a CLI-built application.
+
+```js
+await connections.connectApiKey({
+  context, integrationId: "analytics",
+  verificationInput: { distinct_id: selectedUserId }
+});
+const result = await connections.invoke({
+  context, integrationId: "analytics", operation: "flags.evaluate",
+  input: {
+    distinct_id: selectedUserId,
+    groups: { company: selectedCompanyId },
+    person_properties: { plan: "paid" }
+  }
+});
+const checkoutVariant = result.flags.checkout?.variant;
+```
+
+The caller supplies `selectedUserId` and optional group identity from its own
+authorized context. Verification requires a nonempty `distinct_id`; it never
+creates a fake subject or sends an analytics event. The same input is accepted
+by the JSKIT `verifyApiKey` action. It is not stored in connection state.
+IDs have a local 200-character limit. `groups` and `person_properties` are
+optional objects; the latter overrides properties for this evaluation.
+
+`flags.evaluate` posts JSON to `/flags?v=2` on the chosen regional ingestor.
+It preserves structured flag values, variants, reasons and metadata. Empty
+flags are valid. HTTP-200 responses with a feature-flag quota limit or partial
+evaluation error fail explicitly in this fragment. Applications must handle
+those failures rather than assuming every missing flag is disabled.
+[Flag evaluation](https://posthog.com/docs/api/flags).
+
+The server request identifies itself as `jskit-connectors` and includes the
+documented `posthog-node/` server-runtime marker. It does not load PostHog's SDK.
+This avoids treating backend calls as an unidentified runtime when flags have
+server-only targeting. The adapter supplies no browser origin or forwarding-IP
+headers. It does not create flag-exposure events or implement a fallback cache;
+the application owns those choices.
+
+Event capture is a separate, explicit call:
+
+```js
+const accepted = await connections.invoke({
+  context, integrationId: "analytics", operation: "events.capture",
+  input: {
+    event: "checkout_completed",
+    distinct_id: selectedUserId,
+    properties: { value: 19, currency: "EUR" }
+  }
+});
+```
+
+`events.capture` sends JSON to `/i/v0/e/`. It requires `event` and `distinct_id`,
+with optional `properties`. The library supplies the configured `api_key` in
+the body, after checking the exact origin. Callers cannot override the token,
+destination or identity through reserved property fields. The fragment uses
+one request per call and performs no retries, timestamp backfill or batching.
+[Capture API](https://posthog.com/docs/api/capture).
+
+A successful `status: "Ok"` indicates request acceptance, not final ingestion.
+The returned `quota_limited` field is preserved for the caller to inspect.
+An HTTP success must not be presented as proof that the event reached analytics.
+The application also owns event consent, identity selection and location
+attribution. This fragment does not forward a visitor IP; provider defaults
+apply to requests made from the backend.
+[API response semantics](https://posthog.com/docs/api).
+
+## Automation feasibility and application ownership
+
+An AI can write the configuration, environment names, file-store composition
+and operation calls without accessing an account. Initial organization signup,
+billing and authority to create projects still belong to the operator.
+
+After an authorized private API credential exists, project creation can be
+automated using `POST /api/organizations/{organization_id}/projects/` on the
+regional private API host. Its documented scope is `project:write`; the request
+accepts `name` and project settings, and the response includes the new ID and
+`api_token`. Use distinct project names when separate analytics destinations
+are intended. This provisioning API needs a private credential and is not
+implemented by this public-token runtime.
+[Project management API](https://posthog.com/docs/api/projects).
+
+The application owner supplies its PostHog project and token. Separate
+PostHog projects can provide different tokens and datasets. Two tokens
+inside one organization do not establish independent budgets: flag quota limits
+are organization-level. The application owns its usage accounting
+and credential selection. Provider account/billing
+arrangements determine actual capacity isolation.
+
+An assistant that needs private analytics access requires a separate credential
+flow. A future OAuth implementation can use PostHog's Client ID Metadata
+Document registration model:
+
+1. Prepare separate HTTPS metadata URLs under the operator's domain for public
+   and online, if separate client identities are desired.
+2. At each URL, serve JSON containing that URL as `client_id`, a `client_name`
+   and an exact `redirect_uris` list; optionally add a logo. Publishing those
+   documents requires control of the domain.
+3. Use PostHog's authorization-server metadata and the metadata URL as client
+   ID. PostHog retrieves the document; there is no mandatory dashboard
+   preregistration. Scope selection and account consent are separate steps.
+4. If organization verification is needed, open organization settings and
+   **CIMD verification tokens**, then place the issued value under
+   `com.posthog.verification_token` in the metadata. App verification is
+   optional; its support path is documented separately by PostHog.
+
+[OAuth and metadata registration](https://posthog.com/docs/api/oauth).
+AI can prepare these documents and callback configuration, but these steps do
+not enable OAuth in the implemented fragment. A separate OAuth implementation
+must register the application's actual callback, bind consent to its authenticated
+user and own its grants. That consent journey remains unfinished.
+
+## Focused evidence
+
+Nine tests exercise simulated PostHog responses with actual temporary encrypted
+JSON files: both regions, restart, rotation, ownership, disconnect, settings,
+explicit verification input, public-token validation, request boundaries,
+flag results, capture acceptance, quota and HTTP errors. No live provider
+account, consent, event submission or generated application is used.
+
+
+## Existing-scope closeout — 13 September 2026
+
+Supported: public Cloud project-token verification through explicit-subject flag
+evaluation, `flags.evaluate` and `events.capture`, EU/US region configuration,
+Env references, encrypted local connection state, token rotation and disconnect.
+Nine controlled source tests and nine installed-package tests pass. Existing
+phone/desktop configuration evidence is retained; no new browser run was made
+for this closeout and no runtime/form behavior changed.
+
+Limitations and deferred work:
+
+- No private analytics querying, dashboards, project provisioning, personal API
+  credentials, OAuth, MCP or self-hosted/custom ingestion domains.
+- No browser SDK initialization, SPA navigation hooks/cleanup, autocapture,
+  session replay, automatic identify/alias calls, automatic exposure events,
+  batching, retries, timestamp backfill or offline cache.
+- The application owns consent, subject/group identity, browser/server wiring,
+  event deduplication and handling unavailable flags. A public project token
+  neither authenticates users nor authorizes private data access.
+- The token selects the destination project. The separately saved numeric
+  project ID is not verified against it. A successful capture response means
+  acceptance, not final ingestion; callers must inspect preserved quota fields.
+- Flag quota or partial-evaluation failures are errors, with no automatic
+  fallback value. The backend supplies no visitor IP forwarding.
+- Disconnect removes local state only; rotate the token in PostHog when needed.
+  Editor coding-agent tool attachment is deferred. No live token, tracking,
+  ingestion, provider quota behavior or generated application was exercised.
+
+The broader browser lifecycle/analytics backlog stays deferred under the user's
+existing-capability milestone; this closeout does not claim full Lovable parity.

package/docs/prestashop.md

@@ -0,0 +1,151 @@
+# PrestaShop
+
+Import `prestashopProvider` from `@jskit-ai/connectors-catalog/server/prestashop`.
+This fragment reads products and orders through the store's Webservice API.
+The application's authenticated policy controls access to this shared store;
+it is not shopper login or a connection to each shopper's store account.
+
+## Manual setup
+
+1. Sign into the store's back office. Open **Advanced Parameters → Webservice**,
+   enable **PrestaShop Webservice**, and save.
+2. Choose **Add new webservice key → Generate**. Add a recognizable description
+   and enable the key.
+3. Grant **GET** for **products**. Add **GET** for **orders** if needed. In
+   multistore mode, select the intended shop association. Save.
+4. Store the generated key in your backend environment as
+   `PRESTASHOP_WEBSERVICE_KEY`. Keep it out of application source.
+5. In the integration form enter **Store URL** and **Webservice API key
+   reference** (`env:PRESTASHOP_WEBSERVICE_KEY`), then save configuration.
+
+Disable or replace keys through the same Webservice screen.
+[Webservice setup](https://devdocs.prestashop-project.org/9/webservice/tutorials/creating-access/).
+
+Use the final HTTPS store address before `/api`, including any installation
+subdirectory. The webserver must route that API path correctly and forward
+Authorization. The adapter sends the key as a Basic-auth username with an empty
+password, requests `output_format=JSON`, and rejects redirects. It has no
+URL-credential fallback. JSON is an output format for this API; this fragment
+implements no XML writes.
+[Webservice protocol](https://devdocs.prestashop-project.org/9/webservice/getting-started/).
+
+## Portable configuration and CLI wiring
+
+```json
+{
+  "schemaVersion": 1,
+  "registrations": {},
+  "integrations": {
+    "store": {
+      "provider": "prestashop",
+      "displayName": "Store catalogue",
+      "accountMode": "shared",
+      "scopes": [],
+      "authentication": {
+        "method": "api-key",
+        "secretRef": "env:PRESTASHOP_WEBSERVICE_KEY"
+      },
+      "settings": { "siteUrl": "https://merchant.example/store/" }
+    }
+  }
+}
+```
+
+Compose the [API-key source pattern](../patterns/api-key-connection/PATTERN.md)
+with `providers: [prestashopProvider]`. CLI and editor use the same configuration
+parser and provider definition. `createFileConnectionStore` keeps runtime state
+in encrypted JSON outside application source; no editor or database is needed.
+Supply the application's authorization policy and environment reference resolver.
+
+```js
+await connections.connectApiKey({ context, integrationId: "store" });
+const products = await connections.invoke({
+  context, integrationId: "store", operation: "products.list",
+  input: { offset: 0, limit: 25, language: 1 }
+});
+const orders = await connections.invoke({
+  context, integrationId: "store", operation: "orders.list",
+  input: { offset: 0, limit: 10 }
+});
+```
+
+Verification performs `products.list`. It proves that request succeeded, not
+order access. Both operations request full records sorted by ascending ID.
+Inputs are `offset` (0–1000000, default 0), `limit` (1–100, default 20), and
+optional positive integer `language`. These are fragment bounds. Offset and
+limit become the provider's `limit=offset,limit` parameter. Each call fetches
+one page; the caller decides whether to request another.
+[List parameters](https://devdocs.prestashop-project.org/9/webservice/tutorials/advanced-use/additional-list-parameters/).
+
+Responses remain unchanged: usually `{ products: [...] }` or `{ orders: [...] }`.
+An empty `[]` is also valid. PrestaShop's JSON writer can emit that shape when
+there are no resource nodes. Multilingual fields may be strings or language
+arrays, and IDs/decimal values can be strings. Preserve them when displaying
+or processing the result; associated resources are not fetched automatically.
+[Provider JSON writer](https://github.com/PrestaShop/PrestaShop/blob/9.0.0/classes/webservice/WebserviceOutputJSON.php).
+
+Changing the store URL or credential reference requires verification again.
+Environment key rotation takes effect on the next request. Disconnect removes
+the local grant; it does not revoke the store key. HTTP permission, credential,
+quota and transport failures remain errors; no request is replayed automatically.
+
+The store URL may contain a private host, port or installation path. The shared
+validator rejects embedded credentials, query, fragment and parent-path
+segments. It does not perform DNS filtering. The application controls who can
+edit this credential destination and what networks its backend can reach.
+Operation input cannot substitute a different URL.
+
+## Automation and Online ownership
+
+An AI can prepare the JSON and runtime wiring. With authorized access to the
+store's PHP runtime, provider APIs can enable `PS_WEBSERVICE`, create a
+`WebserviceKey`, and assign resource methods using
+`WebserviceKey::setPermissionForAccount`. This is local store administration,
+not an unauthenticated remote registration endpoint. This fragment does not
+execute provisioning PHP or alter shop permissions.
+[Programmatic setup](https://devdocs.prestashop-project.org/9/webservice/tutorials/creating-access/).
+
+There is no universal OAuth callback for this mode. Each merchant owns its
+store key. Separate application keys can separate access and revocation, but do not create
+separate store capacity. Two keys on one server are not evidence of separate
+provider quotas.
+
+The editor VM and application custom domain need no provider redirect
+registration. If the store itself changes address, update `siteUrl` and
+re-verify it. The application retains its credential in private Env and enforces
+access through its own authorization policy. See the
+[application setup contract](../../connectors-core/docs/online-setup.md).
+
+## Focused proof and remaining work
+
+Automated tests use controlled HTTP and real encrypted temporary files. They
+cover Basic headers, subdirectories, restart, rotation, isolation, policy,
+changed destinations, bounded pages, empty/malformed replies, permission errors
+and interruption without replay. Editor checks cover required URL validation,
+raw-secret rejection, references, setup guidance and save/reload.
+
+Live stores and sample application generation are outside this proof. Product
+writes, order processing, stock changes, additional filters, explicit multistore
+selection per request, webhooks and complete account-connection UI
+remain outside this fragment. The newer Admin API is a separate protocol.
+
+
+## Existing-scope closeout — 13 September 2026
+
+The supported surface is `products.list` and `orders.list` with explicit
+pagination/language, a merchant-owned Webservice key and the configured HTTPS
+store path. Source and offline installed-package tests each pass 7/7. Historical
+editor form checks are retained; no fresh browser run or runtime/form change was
+made for this closeout. This is not full commerce or Lovable parity.
+
+Full deferred work: product/order writes and XML write composition, customer and
+inventory resource operations, stock updates, checkout/payments, fulfilment,
+refunds, carts, additional search/filter/detail operations, automatic traversal
+of associations, webhooks, automatic pagination, retries and newer Admin API
+support. Multistore association belongs to the key configuration; there is no
+per-request shop selector. No OAuth, shopper authentication or per-shopper grants.
+The application owns business UI, routes, access policy and native framework
+composition. Verification reads products only and cannot establish order access.
+Disconnect removes local state; disable/revoke the key in the merchant back office.
+Editor coding-agent attachment remains deferred. Live store compatibility,
+actual permissions/data and generated-app execution have not been verified.

package/docs/replicate.md

@@ -0,0 +1,60 @@
+# Replicate
+
+Import `replicateProvider` from `@jskit-ai/connectors-catalog/server/replicate`.
+This adapter verifies the account and supports asynchronous model predictions.
+
+## Configure access
+
+1. Sign into Replicate and select the user or organization intended to own usage.
+2. Open [API tokens](https://replicate.com/account/api-tokens). Create a token
+   with a descriptive application name and copy it into backend Env as
+   `REPLICATE_API_TOKEN`. The default account token also exists, but named tokens
+   make subsequent replacement easier to track.
+3. Save provider `replicate`, account mode `shared` or `assistant`, `scopes: []`,
+   authentication
+   `{ "method": "api-key", "secretRef": "env:REPLICATE_API_TOKEN" }`.
+4. Run `connectApiKey`; inspect the returned account through `account.read` to
+   check that it is the intended owner. To revoke a token, return to the token
+   page and use its disable control. Local disconnect does not disable it at
+   Replicate. [Token guide](https://replicate.com/docs/topics/security/api-tokens).
+
+## Runtime and AI composition
+
+`account.read` calls `GET https://api.replicate.com/v1/account`. It returns
+the user/organization type and username, plus any optional profile fields.
+`hardware.list` calls `GET https://api.replicate.com/v1/hardware`, returning
+hardware names and SKU identifiers. Both use Bearer authorization and accept
+no inputs. Listing hardware does not reserve it. Prediction operations are explicit; connecting does not generate output. Model/deployment creation is outside this adapter.
+[HTTP reference](https://replicate.com/docs/reference/http/),
+[provider schema](https://api.replicate.com/openapi.json).
+
+Compose the [API-key pattern](../patterns/api-key-connection/PATTERN.md) with
+this provider and the private JSON file store. The same configuration can be
+written by hand, by an AI or through the editor. The application owns model-specific input validation, job lifecycle and spending.
+
+## Automation and application ownership
+
+The initial token creation path verified here is the web account page. An AI
+can prepare the portable configuration and library wiring after that bootstrap;
+no token-creation API was established in this pass. Replicate's API supports
+additional model and prediction operations, but those are not verification steps.
+
+The application owner supplies the Replicate account and token. Differently
+named tokens in one account are not evidence of independent rate limits or
+billing. The editor does not provision or allocate inference capacity.
+
+Fixtures cover both requests, empty hardware lists, invalid responses, private
+file-store restart, rotation, isolation and HTTP failures. No model was run.
+
+## Prediction workflow
+
+1. Open the model's API tab. Copy its owner/name and input fields. Call `models.get({owner,name})` to inspect `latest_version.openapi_schema` or use the pinned version's documented schema.
+2. Invoke `models.predict({owner,name,input})` for an official model, or `predictions.create({version,input})` with its 64-character version ID (optionally `owner/name:version`). Inputs remain provider-shaped JSON, bounded to 256 KiB; use HTTP/data URLs for files. Never put the token into a file URL.
+3. Save the returned ID under the authorized app user. Poll `predictions.get({id})` on your application's schedule. Starting/processing are pending; succeeded exposes output; failed exposes error; canceled is terminal. `predictions.cancel({id})` explicitly requests cancellation. Do not resubmit a timed-out creation automatically: its outcome may be unknown.
+4. Output is preserved, including strings, arrays, structured JSON and image/audio/video URLs. The app renders the result and, when needed, saves files before the provider's retention window expires (normally one hour for API predictions). The adapter never fetches arbitrary result URLs.
+
+For CLI or another framework, use the same project slot and Env reference with these documented HTTP endpoints and ownership checks. JSKIT invokes them through the existing connection service; no Vibe64 execution service is required.
+
+**LIMITATIONS:** No media studio, background polling/history service, training, deployment administration, file uploader or editor-tool attachment. Example: an app can request a generated image and poll its ID, but must show progress and save/display the resulting image itself. Backend authorization must restrict prediction IDs to their initiating users; a shared provider token alone does not provide app-user isolation.
+
+Sources: [HTTP operations](https://replicate.com/docs/reference/http), [prediction lifecycle](https://replicate.com/docs/topics/predictions/lifecycle), [retention](https://replicate.com/docs/reference/how-does-replicate-work). Fixtures exercise requests and result handling; no paid prediction or generated app was run.

package/docs/resend.md

@@ -0,0 +1,153 @@
+# Resend setup and implementation
+
+Documentation checked: 8 September 2026. Console navigation is documented from
+public guidance, not tested in a signed-in account. Tests use simulated API
+responses; no email is sent.
+
+## Initial capability and input ownership
+
+`resendProvider` verifies an API key by listing sending domains. `domains.list`
+returns domain status and cursor pagination (`limit`, `after`, `has_more`,
+`data`). Use the last returned domain ID as `after` for the next page. The limit
+is 1–100. The separate `emails.send` operation sends transactional plain-text
+messages. Contacts, segments and draft broadcasts are supported below. Incoming mail, attachments and a hosted-template catalogue are not implemented.
+
+| Input | Destination | Rule |
+|---|---|---|
+| Display name | integration `displayName` | Optional, 1–200 characters when present |
+| API key | Server environment/secret store | Never include the raw value in application source |
+| API key reference | `authentication.secretRef` | For example `env:RESEND_API_KEY` |
+| Shared account / assistant | `accountMode` | Existing application policy authorizes the caller |
+| People with access | Host's membership/grant policy | Checked by `authorize`; a source field cannot grant workspace membership |
+| Billing and quota | Application administrator’s Resend account | Editor edition does not supply account capacity |
+
+## Manual setup
+
+1. Sign in at [Resend](https://resend.com/) and select the account/team that should
+   own the application's usage. Account creation, payment and domain ownership
+   remain operator decisions.
+2. Open **API Keys** in the dashboard, then **Create API key**. The official
+   [key guide](https://resend.com/docs/dashboard/api-keys/introduction) describes
+   the permission choices and one-time key display.
+3. Give the key a recognizable environment/application name. Choose **Full
+   access** for domain verification and marketing operations. **Sending access** cannot
+   perform the verification read. Domain-limited sending keys belong to a later
+   sending-only fragment; do not silently broaden a supplied key.
+4. Create the key and immediately store its value in the application's secret
+   store or private environment as `RESEND_API_KEY`. If the value is lost,
+   create a replacement rather than placing it in chat or source.
+5. In the integration form, set the display name and account use, and enter
+   `env:RESEND_API_KEY` as the key reference. Save the configuration. A CLI user
+   writes the same `authentication: { method: "api-key", secretRef: "env:RESEND_API_KEY" }`.
+6. Authorize the application caller and invoke `connectApiKey`. A successful
+   [domain-list response](https://resend.com/docs/api-reference/domains/list-domains)
+   has `object: "list"`, `data` and `has_more`; an empty list is valid. This read
+   needs no recipient, callback URL, OAuth app, client secret or verified domain.
+7. If denied, check the selected account, key value and Full access permission.
+   A 401 requires reconnecting; a 403 is permission denied; a 429 is rate
+   limited. Fix the cause and retry explicitly. The runtime does not resend or
+   retry writes automatically.
+8. Rotate by creating a replacement key, updating the same secret binding and
+   verifying it before revoking the previous key in **API Keys**. Disconnect
+   removes the application's local connection; revoking a provider key affects
+   every caller that shares it. Treat the provider's expiration rules as
+   authoritative; the runtime does not invent an expiration time.
+
+## Automation and application ownership
+
+Classification: **assisted API automation**. An authorized operator supplies an
+existing administrative key. The official [create-key API](https://resend.com/docs/api-reference/api-keys/create-api-key)
+accepts a name and permission and returns the new key. Use `GET /api-keys` to
+find a previously provisioned named key before considering `POST /api-keys`;
+the secret cannot be reconstructed from the list. Save returned secrets once
+and do not print response bodies. If a named key exists without its stored
+secret, report it for rotation rather than silently creating duplicates.
+
+The API recipe is: resolve the administrative key privately, list keys, find the
+application's stored key ID/name, create only when absent, and persist the new ID
+and secret through the operator's secret store. Key creation does not automate
+account signup, billing or domain verification. DNS records must be installed at your DNS host and verified by Resend; the editor does not change DNS.
+
+Each application administrator supplies its own Resend key through the app's
+private Env. Hosted and installed editors use the same configuration and runtime;
+neither supplies shared sending capacity. Independent keys in one Resend account
+do not prove independent quotas. Check the provider's [usage limits](https://resend.com/docs/api-reference/rate-limit)
+before promising isolation. Moving the app to another host requires preserving
+its Env and runtime connection state, not an editor gateway.
+
+For CLI or editor setup, compose the existing connection service with the
+[application-owned setup command](../../connectors-core/docs/setup-command.md).
+The app owns operator authorization; JSKIT supplies JavaScript libraries. Other
+frameworks implement their own command and runtime through native tooling.
+
+## Transactional email and recovery wiring
+
+Sending contract checked against the official
+[send API](https://resend.com/docs/api-reference/emails/send-email) and
+[idempotency guide](https://resend.com/docs/dashboard/emails/idempotency-keys)
+on 11 September 2026. `emails.send` requires `from`, `to` (an array of 1–50 email
+addresses), `subject`, `text` and `idempotencyKey`. This adapter bounds text at
+1,000,000 characters and requires an ASCII key of 1–256 characters using letters,
+numbers, underscores, dots, slashes, colons or hyphens. These are adapter limits,
+not a claim to implement every Resend sending option.
+
+The request goes to `POST /emails`; the key goes in `Idempotency-Key`, not the
+message body. The application owns verified sender/domain setup, recipients,
+content and authorization. Connection verification remains a domain read and
+never sends a test message. This connection mode still requires a Full access
+key for that read; sending-only keys need a separately designed verification
+mode and are not silently accepted as fully verified here.
+
+Resend retains idempotency keys for 24 hours. Reuse the same key and identical
+body when deliberately retrying an uncertain result within that window. Do not
+reuse the key for a changed message. The library makes one request and does not
+automatically retry; a successful API response is acceptance, not proof of inbox
+delivery. The application owns any durable delivery workflow.
+
+An application can provide local auth's recovery sender using its existing
+connection service and a fixed, trusted administrator context:
+
+```js
+import { createHash } from "node:crypto";
+
+function createRecoverySender({ connections, context, integrationId, from }) {
+  return async ({ email, recoveryUrl }) => {
+    // Stable for this exact recovery message; do not put the token in a header.
+    const idempotencyKey = `recovery/${createHash("sha256")
+      .update(JSON.stringify([from, email, recoveryUrl])).digest("hex")}`;
+    await connections.invoke({
+      context, integrationId, operation: "emails.send",
+      input: {
+        from, to: [email], subject: "Reset your password",
+        text: `Open this link to reset your password:\n\n${recoveryUrl}\n`,
+        idempotencyKey
+      }
+    });
+  };
+}
+```
+
+Supply the returned function as `auth.local.recovery-sender` or the direct
+`createLocalAuthService({ recoverySender, ... })` argument. This snippet belongs
+in the application; auth does not import Resend or connectors. The context must
+come from trusted backend composition, never from the public password-reset
+request. Do not log recovery content or provider request bodies.
+
+`test/resend.test.js` uses controlled HTTP to verify the read-only connection
+check, explicit POST/body/header, input rejection, application isolation and
+absence of automatic retries on uncertain delivery. No email is sent.
+
+## Marketing workflow (current segments API)
+
+1. In **Domains → Add domain**, enter your sender domain. Copy the displayed SPF/DKIM records exactly into your DNS host, then return to Resend and verify. Use a From address on that verified domain. `domains.get({id})` retrieves status and records; a saved key does not establish domain readiness.
+2. In **Contacts**, create a **Segment** for recipients who opted into this communication. Older instructions call these Audiences; this adapter uses current segments. Use `segments.list({limit,after})` or `segments.create({name})`. Lists use the last item's ID as the next `after`; preserve `has_more` when supplied.
+3. `contacts.create({email,first_name,last_name,unsubscribed,segments:[{id}]})` requires an explicit subscription decision. `contacts.list({limit,after,segment_id})`, `contacts.get({id})`, `contacts.update({id,unsubscribed,...names})`, `contacts.addSegment({id,segmentId})` and `contacts.removeSegment({id,segmentId})` manage ordinary recipients. Never reset an existing opt-out merely because somebody signs in again. The app owns consent and tenant-to-contact authorization.
+4. Render your template to HTML using your framework or write it in Resend's **Broadcasts** editor. Include an actual unsubscribe link, e.g. `<a href="{{{RESEND_UNSUBSCRIBE_URL}}}">Unsubscribe</a>`. Provider variables such as `{{{contact.first_name|there}}}` are resolved by Resend. No hosted template ID is required for this HTML path.
+5. Call `broadcasts.create({segment_id,from,subject,html,name?,text?,preview_text?})`. It always saves `send:false`; it cannot silently send. Read back with `broadcasts.get({id})`, list with `broadcasts.list({limit,after})`, or replace the editable content with `broadcasts.update({id,segment_id,from,subject,html,...})`. Review sender, recipient segment and rendered content in the app or Resend dashboard. For preview, use your framework's renderer; use a separate segment containing only your test addresses for an explicit test send.
+6. After the operator approves the selected recipients/content, invoke `broadcasts.send({id})`. This affects the whole selected segment. The application must authorize this operation separately from draft editing and restrict IDs to its tenant. API acceptance is not delivery proof. Creation/sending each make one request, with no automatic retries; inspect provider status after an uncertain outcome rather than creating duplicate campaigns.
+
+JSKIT uses the same connection slot and backend Env for these operations through `connections.invoke`. CLI apps compose that service directly; other frameworks use their own Resend client/HTTP implementation with the same project-owned configuration. Vibe64 edits setup; it does not run a shared sending service or own recipient lists.
+
+**LIMITATIONS:** No visual campaign builder, hosted-template catalogue, topic/custom-property administration, automation engine, scheduling UI, inbound mail, attachments, delivery-webhook processor, analytics dashboard or automatic coding-assistant attachment. Example: the app can create a newsletter draft and explicitly send it to a reviewed segment, but its own UI or Resend dashboard supplies preview and reporting. Transactional `emails.send` remains plain text with the existing idempotency-key contract. The unsubscribe marker check cannot verify the quality/visibility of rendered HTML; review the actual content.
+
+Sources checked 13 September 2026: [segments](https://resend.com/docs/api-reference/segments/create-segment), [contacts](https://resend.com/docs/api-reference/contacts/create-contact), [broadcast creation](https://resend.com/docs/api-reference/broadcasts/create-broadcast), [explicit send](https://resend.com/docs/api-reference/broadcasts/send-broadcast), [provider OpenAPI](https://github.com/resend/resend-openapi/blob/main/resend.yaml). Controlled tests exercise this journey; no real emails or generated applications were run.