@jskit-ai/connectors-catalog 0.1.64 → 0.1.65

package/docs/wordpress-com.md

@@ -112,9 +112,10 @@ supported public API for provisioning OAuth clients. Initial registration and
 provider consent remain owner steps; do not invent a client-creation endpoint.
 
 The application owner creates the provider registration and stores its secret
-in the application's private Env. Public Vibe64, Vibe64 Online and CLI users use
-this same ownership model. The configuration file holds the client ID and Env
-references; the editor does not own the application's grants.
+in the application's private Env. Every editor and CLI uses this same
+[ownership model](../../connectors-core/docs/online-setup.md): the configuration
+file holds the client ID and Env references; the editor does not own the
+application's grants.
 
 Register the exact callback implemented by the application. For a hosted project,
 start with its assigned application URL and append the implemented callback path.
@@ -131,16 +132,6 @@ or infrastructure boundaries. Automattic's guidelines prohibit excessive API
 traffic and allow access limits.
 [API usage guidance](https://developer.wordpress.com/docs/api/guidelines-for-responsible-use-of-automattics-apis/).
 
-## Focused evidence
-
-Six provider tests use simulated HTTP and real encrypted JSON files. They cover
-client verification, reduced scopes, cancellation, replay, persistence, owner
-isolation, post paging, malformed replies and reconnect/error behavior. The
-shared OAuth test additionally proves that refresh cannot restore permissions
-removed during verification. Editor proof covers registration references,
-permission selections and reload. No live signup, consent, provider calls or
-sample-app generation are included. Login is not supplied. Publishing, media, comments, statistics, taxonomy and bounded batches have additional controlled fixtures; final package/UI acceptance is recorded separately.
-
 ## Post and page publishing
 
 `posts.get` retrieves one numeric `siteId`/`postId`, defaulting to `context: edit`.

package/docs/workday.md

@@ -137,9 +137,10 @@ updates, employment changes, bulk sync or automatic pagination.
 ## Application ownership, callbacks and capacity
 
 The application owner creates the provider registration and stores its secret
-in the application's private Env. Public Vibe64, Vibe64 Online and CLI users use
-this same ownership model. The configuration file holds the client ID and Env
-references; the editor does not own the application's grants.
+in the application's private Env. Every editor and CLI uses this same
+[ownership model](../../connectors-core/docs/online-setup.md): the configuration
+file holds the client ID and Env references; the editor does not own the
+application's grants.
 
 Register the exact callback implemented by the application. For a hosted project,
 start with its assigned application URL and append the implemented callback path.
@@ -166,18 +167,15 @@ for creating these tenant OAuth clients has not been established by this packet;
 do not promise autonomous registration, licensing or security-policy activation.
 An authorized administrator owns tenant access, consent and policy decisions.
 
-## Evidence and testing boundary
+## Sources
 
 - [Workday REST API fundamentals](https://developer.workday.com/documentation/GUID-85810465-bcfb-4fdf-a26d-55eaff3968a8-enHYPHENus/) documents tenant base paths, paging and worker identifiers.
 - [Workday REST API security](https://developer.workday.com/documentation/dan1370797986071/) distinguishes REST Report/Task policies from SOAP permissions.
 - [Official Staffing v7 specification](https://community.workday.com/sites/default/files/file-hosting/restapi/staffing_v7_20260905_oas2.json) defines the implemented worker endpoints and functional areas.
 - [Workday's tenant token exchange example](https://doc.workday.com/admin-guide/en-us/workday-ai/agents/external-agents/register-and-define-your-agent-through-an-api.html) documents the `/ccx/oauth2/{tenant}/token` client-secret exchange; its ASOR operations are not implemented here.
-- [Workday OAuth client setup example](https://doc.workday.com/peakon/en-us/workday-peakon-employee-voice/integrations/workday-integration/nfa1667304944189.html) describes tenant OAuth enablement and registration.
-- [Lovable's Workday setup](https://docs.lovable.dev/integrations/workday) documents the captured per-user fields and non-PKCE confidential registration.
+- [Workday OAuth client setup example](https://doc.workday.com/peakon/en-us/workday-peakon-employee-voice/integrations/workday-integration/nfa1667304944189.html) describes tenant OAuth enablement and the Register API Client task with Authorization Code Grant; the editor links it as the provider setup guide.
 
-Protocol, storage, ownership, validation and editor tests use controlled fixtures.
-No live Workday account, administrator task, provider consent or generated app is
-part of this proof. The host application must still compose its authentication,
+The host application must compose its authentication,
 callback and connection screens using its framework; saving the editor form does
 not generate or run those screens.
 
@@ -290,3 +288,24 @@ The [OpenAI Workday integration example](https://github.com/openai/openai-cookbo
 documents these OAuth functional-area settings and a RaaS report evaluated as
 the authenticated user. It supports the registration guidance; the operation
 schemas here follow the Workday contracts above, not its illustrative schema.
+
+## OAuth pattern composition: Workday
+
+Import `workdayProvider` from `@jskit-ai/connectors-catalog/server/workday` and
+use the portable file and administrator steps in this guide. This is a
+per-user tenant connection with three endpoint fields, Client ID and secret and
+callback references. Its confidential flow omits PKCE and URL scope strings;
+Staffing functional areas and user domain permissions are configured in Workday.
+Keep that provider exception inside the library. Other providers retain S256.
+
+Use `workers.me` for the connected worker and `workers.list` for explicit pages
+with limit, offset, optional name/worker-ID search and visibility flags. The
+library selects Staffing v7 on the configured API host, path prefix and tenant;
+never substitute another user's token or derive ownership from request input.
+An account without a visible worker record cannot pass the initial check.
+
+Every customer tenant needs its own registration and the application's actual
+callback URL. Distinct client IDs do not imply separate tenant quotas.
+The CLI composes the same server APIs and encrypted file store. App login,
+Workday Extend, ISU, SOAP, writes and bulk sync are outside
+this initial fragment. Consent and live tenant testing require separate access.

package/docs/x-twitter.md

@@ -146,15 +146,6 @@ Token issuance is documented in [application-only authentication](https://docs.x
 Do not infer unattended account creation or provider approval from an available
 token endpoint.
 
-## Verification boundary
-
-Focused fixtures cover file persistence, ownership, rotation, strict inputs and
-responses, paging, errors, cancellation and the guide's actual JSON. Editor
-checks cover token references, ownership, setup guidance and reload persistence.
-These checks use controlled responses; no live X token, registration, generated
-application has been exercised.
-
-
 ## Recent-search display recipe
 
 ```js

package/docs/xero.md

@@ -385,12 +385,10 @@ or automatic public invoice attachment sharing. CLI consumers use the same
 base64 input/output contract; other frameworks can use their native byte streams
 against these provider endpoints with the same project-owned credentials.
 
-## Closeout scope and remaining work
+## Not implemented
 
-This provider is being closed against the September 13 existing-capability
-milestone, not complete Xero API coverage or exact Lovable parity. The operation
-index above is the supported runtime surface. The following work remains outside
-that surface:
+The operation index above is the supported runtime surface. The following work
+remains outside that surface:
 
 - Authentication: no secret-free native registration, Custom Connections,
   client-credentials accounting access, or application sign-in. Each project
@@ -420,10 +418,40 @@ that surface:
   business validations and operation calls. Installing the provider or saving the
   editor form does not generate an accounting application. Assistant tool
   attachment requires explicit host integration.
-- Verification: controlled fixtures establish request/response and local lifecycle
-  behavior. Live OAuth, actual Xero organisations, provider tiers, production
-  permissions, accounting outcomes and generated-app execution are unverified.
 
-Future work should address these items only when a concrete application requires
-them. Do not present an unsupported operation as available merely because its
-OAuth scope can be selected.
+Do not present an unsupported operation as available merely because its OAuth
+scope can be selected.
+
+## OAuth pattern composition: Xero
+
+Import `xeroProvider` from `@jskit-ai/connectors-catalog/server/xero` and use
+the exact portable configuration in this guide. Its registration requires
+`tokenEndpointAuthMethod: "client_secret_basic"`; code exchange and refresh
+stay in JSKIT. Use an HTTPS callback or Xero's permitted `http://localhost`
+callback for local CLI work; `127.0.0.1` is not accepted by this provider.
+
+```js
+const tenants = await connections.invoke({
+  context, integrationId: "xero", operation: "connections.list"
+});
+// The app displays permitted ORGANISATION entries, takes an explicit choice,
+// and authorises that choice against its own workspace/account policy.
+const tenantId = await choosePermittedOrganisation(tenants, context);
+const contacts = await connections.invoke({
+  context, integrationId: "xero", operation: "contacts.list",
+  input: { tenantId, page: 1, pageSize: 50 }
+});
+```
+
+`choosePermittedOrganisation` is application-owned selection and policy, not a
+JSKIT export. Never select the first tenant automatically or trust a submitted
+ID merely because it has UUID syntax. Runtime reads additionally check that the
+current token still has an ORGANISATION connection before sending a tenant
+header. This does not replace the application's own authorisation boundary.
+The same pattern applies to `organisation.read` and `invoices.list` with their
+required read scopes. Follow page numbers explicitly; the library performs no
+automatic crawl, calculations, writes or login. Present private data only to
+the authorised caller. Refresh and encrypted file state remain library code.
+
+The guide covers the manual developer-app setup, connection tiers and
+application callback requirements. The application supplies its own registration.

package/docs/zoho-books.md

@@ -155,9 +155,10 @@ refresh tokens. [Token lifecycle and revocation](https://www.zoho.com/books/api/
 ## Application ownership, callbacks and capacity
 
 The application owner creates the provider registration and stores its secret
-in the application's private Env. Public Vibe64, Vibe64 Online and CLI users use
-this same ownership model. The configuration file holds the client ID and Env
-references; the editor does not own the application's grants.
+in the application's private Env. Every editor and CLI uses this same
+[ownership model](../../connectors-core/docs/online-setup.md): the configuration
+file holds the client ID and Env references; the editor does not own the
+application's grants.
 
 Register the exact callback implemented by the application. For a hosted project,
 start with its assigned application URL and append the implemented callback path.
@@ -191,15 +192,13 @@ provider revocation, writes and the remaining Books APIs are separate unfinished
 work. The initial adapter and its broader scope configuration do not imply full
 API coverage.
 
-
-## Existing-scope closeout — 13 September 2026
+## Scope and limitations
 
 Supported: regional server OAuth, organisation discovery, configured or explicit
 organisation selection, contact and invoice page reads, encrypted file grants
-and refresh. Source 12/12 and installed-package 12/12 tests passed. Historical
-editor form evidence is retained; no fresh browser run or runtime/form change.
+and refresh.
 
-Deferred work and limitations: no contact/invoice writes, customer payments,
+Not implemented: contact/invoice writes, customer payments,
 credit notes, estimates, sales/purchase orders, bills, expenses, projects or
 other Books resource operations. No record detail/search, attachments, webhooks,
 automatic pagination, accounting calculations or processing of payments. Broader
@@ -209,5 +208,37 @@ Organisation discovery does not prove contact/invoice permissions; an unconfigur
 integration requires an explicit organisation per operation. The host must enforce
 its own organisation/user policy in addition to provider permissions. Callback
 routes, business/end-user connection UI and native framework wiring belong to the
-application. Disconnect is local. Assistant tool attachment requires explicit host integration. Live regional
-consent/permissions/accounting outcomes and generated-app execution remain unverified.
+application. Disconnect is local. Assistant tool attachment requires explicit host integration.
+
+## OAuth pattern composition: Zoho Books
+
+Import `zohoBooksProvider` from `@jskit-ai/connectors-catalog/server/zoho-books`
+and use the same connection service, file store and owner policy of the [OAuth pattern](../patterns/oauth-connection/PATTERN.md). See
+this guide for the JSON and regional client setup. Match the selected
+region to the account. Keep `ZohoBooks.settings.READ` for verification.
+
+```js
+const result = await connections.invoke({
+  context: authenticatedOwner, integrationId: "books", operation: "organizations.list"
+});
+// Present active organisations from result.organizations. The application
+// validates the user's choice and any narrower organisation access policy.
+const invoices = await connections.invoke({
+  context: authenticatedOwner, integrationId: "books", operation: "invoices.list",
+  input: { organization_id: selectedOrganizationId, page: 1, per_page: 50 }
+});
+```
+
+Never pick the first or default organisation automatically. A configured
+`settings.organizationId` fixes the organisation and can supply the operation's
+ID; an input attempting to override it fails. With no configured ID the caller
+must supply one. Zoho enforces resource access; the host must enforce any
+narrower per-user policy, especially when deliberately sharing one connection.
+`organizations.list` verifies access to a configured active organisation but
+returns the account's organisation list for discovery. It does not select one.
+
+The library owns regional OAuth, PKCE, refresh, API-domain validation and token
+headers. Lists make one request and preserve `page_context`; use its
+`has_more_page` value for explicit continued paging. IDs stay strings. The host
+owns callbacks, presentation and selection. Configuration save does not grant
+provider access or implement app login. Registrations remain application-owned.

package/docs/zoho-crm.md

@@ -133,9 +133,10 @@ Revocation is separate from deleting this integration's configuration.
 ## Application ownership, callbacks and capacity
 
 The application owner creates the provider registration and stores its secret
-in the application's private Env. Public Vibe64, Vibe64 Online and CLI users use
-this same ownership model. The configuration file holds the client ID and Env
-references; the editor does not own the application's grants.
+in the application's private Env. Every editor and CLI uses this same
+[ownership model](../../connectors-core/docs/online-setup.md): the configuration
+file holds the client ID and Env references; the editor does not own the
+application's grants.
 
 Register the exact callback implemented by the application. For a hosted project,
 start with its assigned application URL and append the implemented callback path.
@@ -168,17 +169,13 @@ applications are outside this test pass. Complete connection UI, native/self
 client grants, additional regions, arbitrary CRM modules, mutations and provider-side
 revocation remain unfinished; the initial read adapter does not imply full API coverage.
 
-
-## Existing-scope closeout — 13 September 2026
+## Scope and limitations
 
 Supported: current user and paged leads, contacts, accounts and deals through
 project-owned server OAuth, seven configured data centres and three environments,
-explicit fields/page tokens, encrypted local grants and refresh. Source and
-offline installed-package tests each pass 11/11. Historical editor form evidence
-is retained; the added inline sentence clarifying read-only operation scope was
-source-reviewed, not freshly browser-tested.
+explicit fields/page tokens, encrypted local grants and refresh.
 
-Full limitations/deferred work: no create/update/delete, relationships mutations,
+Not implemented: create/update/delete, relationships mutations,
 arbitrary modules, required-field/module metadata discovery, search/query APIs,
 bulk jobs, attachments, webhooks or automatic pagination. Full-access scopes do
 not add these operations. Named record lists have the documented field/page
@@ -188,5 +185,32 @@ seven, region auto-discovery or provider-side revocation. Current-user verificat
 does not prove module/field permissions. The application supplies callbacks,
 organisation/user policy, end-user connection screens and native framework wiring;
 connecting CRM is not app sign-in. Disconnect is local. Assistant tool attachment
-requires explicit host integration. Live regional OAuth/permissions/data and
-generated-app execution remain unverified.
+requires explicit host integration.
+
+## OAuth pattern composition: Zoho CRM
+
+Import `zohoCrmProvider` from `@jskit-ai/connectors-catalog/server/zoho-crm` and
+pass it to the existing connection service. Follow this guide for registration, references and portable configuration.
+Choose the account's data center and CRM environment explicitly. Do not follow
+callback-supplied hosts or choose another organisation on the user's behalf.
+
+```js
+const page = await connections.invoke({
+  context: authenticatedOwner,
+  integrationId: "crm",
+  operation: "leads.list",
+  input: { fields: "Last_Name,Email", per_page: 50, page: 1 }
+});
+```
+
+The library owns comma-separated scopes, PKCE, token exchange/refresh, API-domain
+validation and `Zoho-oauthtoken` headers. `users.current` verifies the connection;
+`contacts.list`, `accounts.list` and `deals.list` are also available. Keep page
+tokens associated with the same authenticated owner and query, and request later
+pages explicitly. HTTP204 becomes an empty page. The host owns data presentation,
+record access policy and the OAuth callback. Reference secrets instead of putting
+them in JSON; use the same file and connection service for a trusted CLI.
+
+A shared connection shares one organisation's CRM access. Personal connections
+require the host's per-user policy. The application owns its registration and callback. These data scopes do not
+implement app sign-in or promise independent provider quotas.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/connectors-catalog",
-  "version": "0.1.64",
+  "version": "0.1.65",
   "description": "Provider definitions and focused API operations for JSKIT connectors.",
   "type": "module",
   "exports": {
@@ -123,14 +123,14 @@
     "@aws-sdk/client-redshift-data": "3.1128.0",
     "@aws-sdk/client-s3": "3.1128.0",
     "@aws-sdk/s3-request-presigner": "3.1128.0",
-    "@jskit-ai/connectors-core": "0.1.62",
+    "@jskit-ai/connectors-core": "0.1.63",
     "@modelcontextprotocol/sdk": "1.32.1",
     "@smithy/fetch-http-handler": "5.8.0",
     "jose": "^6.1.3",
     "json-rest-schema": "^1.0.17"
   },
   "peerDependencies": {
-    "@jskit-ai/kernel": "0.1.245"
+    "@jskit-ai/kernel": "0.1.246"
   },
   "jskit": {
     "kind": "runtime",