@jskit-ai/connectors-catalog 0.1.1

package/docs/brevo.md

@@ -0,0 +1,122 @@
+# Brevo
+
+Import `brevoProvider` from `@jskit-ai/connectors-catalog/server/brevo`.
+The adapter uses an ordinary Brevo API key for contacts, transactional email/SMS,
+marketing campaigns, sender/domain setup and automation events.
+
+## Set up access
+
+1. Sign in to the intended Brevo account with API-key management permission.
+2. Open the account dropdown and choose **Settings → SMTP & API → API Keys & MCP**.
+3. Generate a new API key and give it a name identifying the application and
+   environment. Copy the full value while it is shown.
+4. Store it outside source, for example as `BREVO_API_KEY` in the backend's
+   environment. An SMTP key is a different credential.
+5. In `integrations.json`, choose provider `brevo`, mode `shared` or `assistant`,
+   empty `scopes`, and `authentication: { "method": "api-key", "secretRef":
+   "env:BREVO_API_KEY" }`. This slot needs no OAuth registration.
+6. In Vibe64 save configuration, choose **Set credential in Env**, save the key,
+   return and choose **Connect account** or **Verify again**. **Check connection**
+   reloads status only. CLI apps call `connectApiKey`. Manage/revoke keys through
+   the same console; disconnect only removes the local runtime grant.
+   See [Brevo key management](https://help.brevo.com/hc/en-us/articles/209467485-Create-and-manage-your-API-keys).
+
+## Runtime and AI composition
+
+`contacts.list` calls `GET /v3/contacts` with the `api-key` header. Inputs are
+`limit` (1–1000, default 50), `offset` (nonnegative, default 0), and `sort`
+(`asc`/`desc`, default `desc`). The result keeps `contacts` and `count`; advance
+the offset in application code when another page is needed. The verifier uses
+this operation, avoiding an account-details response that may contain unrelated
+provider credentials. See [Get contacts](https://developers.brevo.com/reference/get-contacts).
+
+Use the [API-key source pattern](../patterns/api-key-connection/PATTERN.md).
+The application owns access to contact information and sending
+workflows. A CLI and Vibe64 configure the same slot and reference; connection
+metadata lives in the chosen runtime file directory.
+
+## Provisioning automation and capacity
+
+An AI can wire the adapter and read contacts after an operator supplies a key.
+No API for ordinary-account key creation was verified in this pass. Enterprise
+subaccount provisioning must not be assumed available to normal accounts.
+Operator setup therefore follows the console steps above.
+
+Each application supplies its own account credentials. Two API keys under
+one account do not establish separate sending credits or capacity. Reading contacts does not prove sending readiness; authenticate the sender
+domain and complete the account/sender requirements before sending.
+
+Fixtures verify headers, pagination, invalid inputs, storage restart, key
+rotation, isolation, disconnect and provider failures. No contacts were read
+from a real account.
+
+## Sender and delivery setup
+
+For email, open **Settings → Senders, Domains, IPs → Domains → Add a domain**.
+Add the sending domain you control. Use automatic authentication when offered,
+or copy every displayed DNS record into that domain's DNS provider. Keep the
+exact host, type and value: DKIM may use TXT or multiple CNAME records. Return
+and choose **Authenticate this email domain** after manual setup. DNS propagation
+may take time; recheck status. Never replace an existing DMARC policy blindly.
+[Domain setup](https://help.brevo.com/hc/en-us/articles/12163873383186-Authenticate-your-domain-with-Brevo-Brevo-code-DKIM-DMARC).
+
+Then open **Settings → Senders, Domains, IPs → Senders → Add a sender**, enter
+From name/email and Save. If prompted, enter the six-digit code emailed to that
+address and choose **Verify sender**. The adapter can create/read sender/domain
+records, but it does not edit DNS or approve your account.
+[Sender setup](https://help.brevo.com/hc/en-us/articles/208836149-Create-a-new-sender-From-name-and-From-email).
+
+For SMS, inspect your account's recipient-country sender requirements. The
+registration UI, when available for your account, is **Settings → Campaigns →
+SMS Sender ID → Configure → Request Sender ID**. Choose the country, provide
+company/Sender ID and message details, submit and wait for approval. Check SMS
+credits before enabling sending. The API key alone does not establish readiness.
+[Country Sender ID setup](https://help.brevo.com/hc/en-us/articles/28255350696466-Register-a-Sender-ID-to-send-SMS-messages).
+
+## App operations
+
+The [official API description](https://api.brevo.com/v3/swagger_definition_v3.yml)
+was inspected on 12 September 2026. Paths below are relative to
+`https://api.brevo.com/v3`; all requests use the backend's `api-key` header.
+
+| Operations | Path / behavior |
+|---|---|
+| email.send | POST /smtp/email. sender, to, and either templateId/params or subject plus htmlContent/textContent. Returns messageId, not proof of delivery. |
+| sms.send | POST /transactionalSMS/sms. Explicit sender, recipient with country code, type transactional/marketing, and content or templateId/params. Long/Unicode content can consume multiple credits. |
+| contacts.get/create/update | GET/PUT /contacts/{email}, POST /contacts. Existing defined attributes, list membership, email/SMS blacklist flags. Create defaults updateEnabled false; no automatic force merge or unsubscription reset. |
+| folders.list; lists.list/create | GET /contacts/folders, GET/POST /contacts/lists. Creating a list needs its parent folderId. |
+| lists.addContacts/removeContacts | POST /contacts/lists/{id}/contacts/add or remove; 1–150 email addresses. Preserve successes and failures separately. Removing list membership does not erase or unsubscribe a contact. |
+| senders.list/create | GET/POST /senders. Creation takes name/email; retain returned SPF/DKIM error flags and complete provider verification. |
+| domains.create/get/authenticate | POST /senders/domains, GET /senders/domains/{domain}, PUT /senders/domains/{domain}/authenticate. Preserve DNS records and actual verified/authenticated flags. Authentication request is followed by a status read. |
+| campaigns.list/get/create | GET/POST /emailCampaigns, GET /emailCampaigns/{id}. Create a draft with name, sender, content/template and explicit recipient lists; exclusions supported. No automatic send/schedule. |
+| campaigns.sendTest/sendNow | POST /emailCampaigns/{id}/sendTest with emailTo, or /sendNow. The app must authorize either send explicitly; test recipients may need to be configured in Brevo. |
+| email.events / sms.events | GET /smtp/statistics/events or /transactionalSMS/statistics/events. Offset pagination, days and messageId/email or phoneNumber filters. Preserve bounce/rejection details. |
+| events.create | POST /events. event_name, identifiers.email_id and optional event/contact properties/date. Events can trigger existing active automations; they do not create a workflow. |
+
+Call path IDs are passed as `resource` (number for lists/campaigns; email for
+contacts; bare domain for domains). The same key and configuration are used
+from CLI through the [API-key pattern](../patterns/api-key-connection/PATTERN.md).
+Other frameworks use their native HTTP, Env and app authorization with these
+contracts; Vibe64 and a Node service are not required at runtime.
+
+For an appointment reminder, confirm sender readiness, authorize the recipient,
+call email.send, save messageId and read email.events later. For a newsletter,
+maintain consenting contacts/lists, create a draft, review a test, then explicitly
+sendNow. For automation, configure and activate the matching event-triggered
+workflow in Brevo before sending events.create from the application. The app owns
+scheduling, consent/unsubscribe UI, delivery reporting and duplicate-send prevention.
+No ambiguous send or creation request is automatically retried.
+
+## LIMITATIONS
+
+Editor coding-assistant attachment is deferred. For example, the app can send a
+booking email and show its bounce status, but Vibe64's Codex/OpenCode cannot inspect
+Brevo merely because this connector is configured. The app owns message content,
+recipient authorization and scheduling. This does not supply a template/automation
+visual designer, webhook receiver, SMTP service, WhatsApp integration or account
+approval. Advanced batch sends and attachments use native provider wiring.
+No real messages, domain changes, purchased credits or generated apps were tested.
+
+Focused fixtures cover sends, draft/test/sendNow separation, contacts/list results,
+DNS pending state, delivery failures, organization policy denial and no replay after
+an uncertain send, alongside existing file restart/rotation/disconnect tests.

package/docs/calendly.md

@@ -0,0 +1,158 @@
+# Calendly
+
+Import `calendlyProvider` from `@jskit-ai/connectors-catalog/server/calendly`.
+This adapter uses an owner's personal token or project-owned web OAuth registration
+to read schedules and invitees, create links, book and cancel appointments.
+It does not implement application login. Shared and assistant connections are supported.
+
+## Configure access
+
+1. Sign in to the intended Calendly account. Open **Integrations → API & Webhooks**.
+2. Under **Personal Access Tokens**, choose **Get a token now** or
+   **Generate new token** if tokens already exist.
+3. Name the token for this application. Grant `users:read` and
+   `event_types:read`; newly scoped tokens require explicit permissions.
+4. Create and copy the token while it is displayed. Store it in backend Env
+   as `CALENDLY_API_KEY`.
+5. Save a slot with provider `calendly`, mode `shared` or `assistant`,
+   `scopes: ["users:read", "event_types:read"]`, and authentication `{ "method": "api-key", "secretRef":
+   "env:CALENDLY_API_KEY" }`. No registration entry is needed for a personal token.
+6. Verify using `connectApiKey`. Manage tokens on the same provider page.
+   [Token setup](https://developer.calendly.com/how-to-authenticate-with-personal-access-tokens),
+   [provider scope requirements](https://developer.calendly.com/docs/authentication/scopes).
+
+## Runtime and CLI composition
+
+`profile.read` calls `GET https://api.calendly.com/users/me`; its `resource.uri`
+is the required `user` input for `eventTypes.list`. The latter calls
+`GET /event_types`, accepting `count` (1–100, default 20), `page_token` and
+optional `active`. Omit `active` to include both active and inactive types.
+Pass `pagination.next_page_token` to request another page; do not follow a
+returned URL with credentials. Results retain the provider envelope.
+[Profile API](https://developer.calendly.com/api-docs/calendly-api/users/get-current-user),
+[event-type API](https://developer.calendly.com/api-docs/calendly-api/event-types/list-event-types).
+
+Use the [API-key pattern](../patterns/api-key-connection/PATTERN.md) with this
+provider. Configuration and encrypted connection state remain separate files.
+Provider-side token grants determine access; the configuration scope list
+does not grant provider permissions. For pre-release configurations created
+before OAuth support, replace Calendly’s empty scope list with users:read and
+event_types:read; no compatibility reader is provided.
+
+## Automation and application registrations
+
+An AI can prepare configuration and requests after token creation. The verified
+personal-token creation flow is interactive. A public integration instead needs
+a developer account and OAuth application: sign into the developer portal,
+create an OAuth app, and set its name, client type and authorized callback.
+The generated application owns that registration and its callback. Hosted and
+installed editors do not supply shared Vibe64 registrations. These OAuth
+credentials are consumed by the web OAuth mode described below.
+[OAuth app setup](https://developer.calendly.com/docs/authentication/creating-an-oauth-app).
+
+Use the application's own account token and respect its provider rate limits;
+do not share one person's token across unrelated applications.
+Automated fixtures cover headers, required inputs, pagination, storage restart,
+rotation, isolation and failure handling. No live scheduling data was accessed.
+
+## Web OAuth setup and delivery status
+
+The captured connection experience uses OAuth scopes. Personal tokens above
+are a separate setup choice. OAuth uses the existing connection service and
+the project-owned registration; it needs no Vibe64 authentication gateway.
+
+Provider setup, checked against the official guide on 12 September 2026:
+
+1. Open the [developer portal](https://developer.calendly.com/docs/authentication/creating-an-oauth-app)
+   and sign in or create a developer account. This is separate from the normal
+   Calendly user account.
+2. Create an OAuth application. Supply its name, select **web**, and choose
+   **Sandbox** for development or **Production** for production. Calendly
+   recommends separate applications for those environments.
+3. Copy the generated application's exact callback URL from Vibe64 into
+   **Redirect URI**. Production requires HTTPS. Sandbox permits HTTP localhost;
+   a hosted development URL should still use its actual HTTPS address.
+4. Select **users:read** for the profile check and **event_types:read** for
+   event-type listing. Add scheduled_events:read for meetings/invitees, availability:read for slots,
+   scheduling_links:write for single-use links, and scheduled_events:write for
+   booking/cancellation/no-shows. Grant the same scopes on personal tokens.
+   Selecting a scope grants no app-user authorization; the app must enforce that.
+5. Continue and copy the Client ID, Client Secret and Webhook signing key.
+   The secret and signing key are shown only at creation. Save the Client ID
+   in project registration configuration and the Client Secret in private Env.
+   The current fragment has no webhook receiver; its signing key must not be
+   confused with the OAuth Client Secret.
+6. Configure the registration with `tokenEndpointAuthMethod: client_secret_basic`
+   for a web client. Its secret belongs to the generated app's backend, never
+   the browser or Vibe64's platform account. The shared provider metadata selects Basic authentication for web OAuth.
+7. Register a changed custom-domain callback in the provider application before
+   reconnecting. The provider application's menu offers **Edit**, including
+   Redirect URI, followed by **Save**.
+
+Runtime endpoints: authorization at `https://auth.calendly.com/oauth/authorize`
+and token exchange at `https://auth.calendly.com/oauth/token`. Use the existing
+state and S256 PKCE lifecycle. Web token requests authenticate the client with
+HTTP Basic; native clients have a different contract and are not covered by
+these web-application instructions. Persist each replacement refresh token
+under the existing grant lock rather than replaying a consumed refresh token.
+The profile and event-type operations retain their current fixed API origin.
+
+Required focused proof before marking this provider complete: OAuth configuration
+and captured scope choices, Basic authentication on code exchange and refresh,
+PKCE/state checks, rotated-token persistence, denial/cancel/reconnect/disconnect,
+and the existing personal-token flow. Live consent and scheduling remain outside
+the controlled-test scope.
+
+Sources: [OAuth app creation](https://developer.calendly.com/docs/authentication/creating-an-oauth-app),
+[token endpoint](https://developer.calendly.com/api-docs/calendly-o-auth/o-auth/post-oauth-refresh-token).
+
+The focused `test/calendly.test.js` fixture passes Basic code exchange, S256
+PKCE, concurrent refresh serialization, replacement refresh persistence across
+a new service instance, personal-token connection and local disconnect. This does not establish live Calendly consent or token issuance.
+
+## Scheduling operations and application ownership
+
+Both authentication methods use these same operations through `service.invoke`.
+A CLI Node app installs the provider and composes the normal file connection service;
+Vibe64 is not required. Other frameworks use their native HTTP/OAuth library and the
+same project configuration, Env references and callback contract.
+
+| Operations | Input / useful result | Scope |
+| --- | --- | --- |
+| `eventTypes.get`, `eventTypes.list` | Type UUID / profile user URI; scheduling URLs and type details | event_types:read |
+| `availability.list` | Event-type URI, UTC start/end within 31 days; available times | availability:read |
+| `events.list`, `events.get` | User/organization/group URI or event UUID; meeting status, times, pagination | scheduled_events:read |
+| `invitees.list`, `invitees.get` | Event UUID and optional invitee UUID; answers, status, cancellation/reschedule URLs | scheduled_events:read |
+| `schedulingLinks.create` | Event-type URI as `owner`; single-use booking URL, fixed max_event_count=1 | scheduling_links:write |
+| `invitees.create` | Event-type URI, UTC start time, invitee email/name/IANA timezone; optional answers and guests | scheduled_events:write |
+| `events.cancel` | Event UUID, optional reason; cancellation confirmation | scheduled_events:write |
+| `noShows.create`, `noShows.get`, `noShows.delete` | Full invitee URI / no-show UUID; mark/read/undo no-show | scheduled_events:read or write |
+
+Example: DogAndGroom reads its owner profile, lists active event types, then creates
+one link for its grooming event type and sends that URL to the customer. The customer
+selects and confirms the time on Calendly. A created link is not a scheduled event.
+For an app-owned booking form, fetch future availability then submit `invitees.create`;
+this requires Calendly Standard or higher. Slots may disappear between these calls;
+handle the provider rejection and offer fresh availability. Booking triggers the event
+type's normal confirmations and workflows. Do not automatically retry uncertain writes.
+
+Pass pagination tokens back to the same operation. Do not fetch returned links with
+an Authorization header. Organization/group access still depends on the owner's role.
+Cancelling an event cancels the entire event, including a group event; it is not an individual group-invitee cancellation. Use the invitee’s hosted cancellation URL when appropriate.
+The application owns who can read whose invitee data, booking confirmation, timezone
+display, cancellations, persistence and polling. Reschedule using the invitee's returned
+`reschedule_url`; this adapter does not invent a reschedule API.
+
+**LIMITATIONS:** Public Vibe64 coding-assistant attachment is deferred. For example,
+connecting Calendly does not let the editor's assistant inspect tomorrow's appointments;
+the generated app's backend can use the scheduling operations above. Webhook receivers,
+organization administration and advanced location/routing/customized event-type creation
+are not supplied here. For example, a custom meeting-location booking form must use
+native provider API handling, or send the customer through the hosted booking link.
+No live consent, token issuance, booking or notification has been exercised.
+
+Sources checked 12 September 2026:
+[booking API](https://developer.calendly.com/api-docs/calendly-api/scheduled-events/create-event-invitee),
+[scheduled events](https://developer.calendly.com/api-docs/calendly-api/scheduled-events/list-scheduled-events),
+[no-show deletion](https://developer.calendly.com/api-docs/calendly-api/scheduled-events/delete-invitee-no-show),
+[scopes](https://developer.calendly.com/docs/authentication/scopes).

package/docs/canva.md

@@ -0,0 +1,191 @@
+# Canva assistant MCP
+
+Import `canvaProvider` from `@jskit-ai/connectors-catalog/server/canva` and
+`createCanvaClientMetadata` from `@jskit-ai/connectors-catalog/shared`. This
+fragment uses Canva's recommended Client ID Metadata Document (CIMD) flow.
+The client identifier is a hosted JSON URL; this client has no secret.
+
+## Manual setup and approval
+
+1. Open the [Canva MCP guide](https://www.canva.dev/docs/mcp/), find **Getting
+   started → Register your redirect URI**, and open **Waitlist form**.
+2. Supply the company/integration details and exact callback URL requested by
+   the form. Wait for Canva's eligibility decision and callback allowlisting.
+   This is a real provider prerequisite. Publishing metadata or entering a URL
+   in Vibe64 does not grant access, and JSKIT cannot approve an application.
+3. Choose a public HTTPS URL that your assistant host controls, including a
+   document path, such as `https://assistant.example/oauth/canva.json`.
+4. Generate the client metadata with the library helper below, or fill the metadata
+   URL and suggested callback in Vibe64 and choose **Copy client metadata** in
+   the setup section. Serve that JSON
+   at exactly the chosen URL with `Content-Type: application/json`, without
+   authentication. The document contains public client information only.
+5. In Vibe64 open **Integrations → Add Canva → Credentials**. Enter **Client
+   metadata URL** and the **Callback URL reference**, for example
+   `env:CANVA_CALLBACK_URL`. Store the actual callback through Env. No Client
+   secret input is shown. **Display name** can supply the name used when
+   generating your metadata.
+6. Open **Permissions**. Profile, design information/content and folder reads
+   start selected. Select further content permissions only when needed; all
+   writes start unselected. Save configuration.
+7. The assistant host opens the URL returned by `beginAuthorization`. The owner
+   signs into Canva and approves access. Complete the callback under that same
+   authenticated owner with `completeAuthorization`. The runtime initializes
+   MCP and lists tools before storing its grant. Consent screens were not
+   exercised here, so their precise controls are not represented as verified.
+
+Canva documents individual authentication and content permissions in its
+[troubleshooting guide](https://www.canva.dev/docs/mcp/troubleshooting/).
+Each person connects their own account; this does not turn one person's Canva
+account into a workspace service account.
+
+## Metadata builder and automation
+
+```js
+const document = createCanvaClientMetadata({
+  clientId: "https://assistant.example/oauth/canva.json",
+  clientName: "Design assistant",
+  callbackUrl: "https://assistant.example/connections/canva/callback"
+});
+```
+
+The helper validates the URL/name/callback and returns ordinary serializable
+JSON containing `client_id`, `client_name`, one `redirect_uris` entry, code and
+refresh grants, code response type and `token_endpoint_auth_method: "none"`.
+The identifier matches the document URL exactly. It performs no network call,
+file write, registration, deployment or consent. The host owns where the
+returned document is served and must regenerate it when its registration
+configuration changes. Derive the identifier, display name and resolved
+callback from the same portable configuration; do not keep competing copies.
+
+The [MCP authorization specification](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#client-id-metadata-documents)
+explains metadata URL identities and matching callbacks. Canva's public
+[authorization metadata](https://mcp.canva.com/.well-known/oauth-authorization-server)
+advertises metadata documents, S256 and clients without secrets. Its
+[resource metadata](https://mcp.canva.com/.well-known/oauth-protected-resource)
+advertises 16 supported scopes and resource `https://mcp.canva.com`. Public
+metadata was inspected on 9 September 2026 without creating a client or account.
+
+AI can prepare and validate metadata/configuration and wire the host's existing
+static response. Publishing that response, submitting the approval application
+and approving account consent require their respective owners. The initial
+fragment does not automate the approval form. Canva still documents dynamic
+registration as a deprecated compatibility route; this implementation follows
+its recommended metadata-document path instead.
+
+## Portable configuration
+
+```json
+{
+  "schemaVersion": 1,
+  "registrations": {
+    "canva": {
+      "source": "own",
+      "clientId": "https://assistant.example/oauth/canva.json",
+      "tokenEndpointAuthMethod": "none",
+      "callbackUrlRef": "env:CANVA_CALLBACK_URL"
+    }
+  },
+  "integrations": {
+    "design": {
+      "provider": "canva",
+      "displayName": "Design assistant",
+      "accountMode": "assistant",
+      "scopes": ["profile:read", "design:meta:read", "design:content:read", "folder:read"],
+      "authentication": { "method": "oauth2", "registrationRef": "canva" }
+    }
+  }
+}
+```
+
+CLI and UI use the same schema. `tokenEndpointAuthMethod: "none"` must be
+explicit, the provider must declare support, and `clientSecretRef` is forbidden
+for this client. Existing confidential registrations retain `client_secret_post`
+when the field is omitted. Switching client authentication invalidates pending
+attempts and requires reconnection for existing grants.
+
+Compose the [OAuth file pattern](../patterns/oauth-connection/PATTERN.md) with
+`providers: [canvaProvider]` and the
+[assistant OAuth pattern](../patterns/assistant-mcp-oauth/PATTERN.md).
+Code exchange and refresh send the metadata URL as `client_id`, without a client
+secret. Authorization/code/refresh include Canva's resource identifier; tokens
+and pending PKCE attempts remain encrypted text files under the existing owner.
+The runtime does not download metadata from arbitrary client URLs: Canva's
+authorization server validates the hosted document and approved callback.
+
+`tools.list` accepts a cursor; `tools.call` accepts `name` and `arguments`.
+Calls target only `https://mcp.canva.com/mcp`. The host must authorize exact tool
+names and design/content ownership, handle tool `isError`, and decide which
+returned content to display. Discovery does not establish every tool or plan
+permission. No tool is executed by saving or verifying the configuration.
+The provider has a 60-second request budget, matching Canva's documented advice
+for design generation; OAuth requests retain the core's 15-second budget.
+Cancellation stops waiting and attempts MCP session cleanup; it does not undo
+accepted edits. Local disconnect does not revoke every Canva authorization.
+
+## 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.
+
+Host a publicly reachable client metadata document owned by this runtime, with
+its actual callback in `redirect_uris`. The metadata URL is the client identity;
+it is distinct from the callback URL. There is no provider client secret in this
+mode. Separate metadata URLs do not split user/team quotas or upgrade Canva
+features. Canva approval decides which callback URLs are accepted, including
+any loopback development URL. If the callback changes, update the metadata and
+obtain the required approval before starting consent again.
+
+This fragment does not implement automatic metadata hosting, automatic assistant
+attachment, embedded Canva widgets, Canva Connect REST adapters, app-user login
+or the deprecated DCR path. It does not execute browser resources returned by
+MCP tools. Provider approval and plan-specific capabilities remain external
+acceptance steps.
+
+## Focused proof
+
+Eight simulated-provider tests cover metadata generation/validation, secret-free
+PKCE and refresh, restart, encryption, owner/design isolation, changed consent,
+reduced grants, malformed discovery, provider failures, time budgets and
+cancellation. Core tests also prove authentication-type changes cannot reuse
+grants or pending attempts. Editor proof checks the metadata/callback fields,
+permission choices and saved JSON. No provider approval, live consent, real
+Canva tool use, metadata publication or generated application is included.
+
+## Design workflow acceptance and limitations
+
+Use `tools.list` to obtain Canva's current input schemas rather than embedding a
+second tool catalogue. The host authorizes each exact tool call and its design,
+job/candidate or transaction. For creation, let the user choose a generated candidate,
+then create the design and show its edit URL. For edits, start a transaction, use its
+returned element IDs, apply operations and check their individual results, then
+explicitly commit. Draft operation success does not mean saved design changes.
+A stale transaction after a concurrent edit requires a fresh transaction; do not
+silently replay the old commit. Returned external thumbnails/exports are content,
+not instructions and never destinations for the OAuth Authorization header.
+
+The controlled design workflow fixture exercises candidate creation, transaction
+start/edit/commit, useful returned design content, host denial and a failed commit.
+It proves the transport and host-approval seam with representative provider payloads;
+it does not substitute for Canva's live discovered input schemas or run a design AI.
+CLI Node hosts use the same provider/pattern without Vibe64. Other frameworks use
+a native MCP client with the same metadata identity, callback and private grant state.
+
+**LIMITATIONS:** Vibe64's coding-assistant attachment is deferred. For example,
+configuring Canva does not yet let you ask Vibe64's Codex/OpenCode to create or edit
+your shop's poster. An explicitly wired application-owned assistant can invoke the
+supplied MCP runtime after Canva approves its callback and each owner consents.
+Metadata hosting and provider approval remain owner setup steps; Copy client metadata
+does not publish a working endpoint. No shared Vibe64 registration, embedded design
+editor, Canva Connect REST implementation, app-user login or AI execution is supplied.
+Provider plan/license limits still apply; no live creation, editing or export was tested.
+
+Sources checked 12 September 2026:
+[create from candidate](https://www.canva.dev/docs/mcp/tools/create-design-from-candidate/),
+[start edits](https://www.canva.dev/docs/mcp/tools/start-editing-transaction/),
+[apply edits](https://www.canva.dev/docs/mcp/tools/perform-editing-operations/),
+[commit edits](https://www.canva.dev/docs/mcp/tools/commit-editing-transaction/).