@jskit-ai/connectors-catalog 0.1.1

package/docs/apify.md

@@ -0,0 +1,162 @@
+# Apify
+
+Import `apifyProvider` from `@jskit-ai/connectors-catalog/server/apify`.
+The adapter discovers Actors, starts bounded runs, reads status, requests cancellation,
+and retrieves dataset/storage results. Verification only lists Actors; it does not
+start runs, create schedules or spend compute credits.
+
+## Set up access
+
+1. Sign in to [Apify Console](https://console.apify.com/settings/integrations).
+   Select the account or organization that should own this connection.
+2. Open **Settings → API & Integrations** and find the API tokens section.
+3. Start creating a token. In **Description**, identify the application. For an
+   expiring token, enable **Set expiration date** and fill **Date**.
+   A standard token leaves **Limit token permissions** off. It has broad account
+   access, including capabilities beyond this adapter's operations; use this
+   documented setup only if the application owner accepts that access. Keep the
+   token exclusively in the trusted application backend. Choose **Create**, then
+   copy the issued token. Do not broaden an existing token just to pass a check.
+   A token created under your personal account does not cover organizations
+   you belong to. Switch into the organization first for its tokens; organization
+   personal tokens inherit the member's access, while organization tokens require
+   owner or Manage access tokens permission.
+4. Store the token outside application source as `APIFY_TOKEN`. Set the
+   configuration slot's provider to `apify`, mode to `shared` or `assistant`,
+   scopes to `[]`, and authentication to `api-key` with reference
+   `env:APIFY_TOKEN`. In Vibe64, enter that value in **API key reference**, save,
+   then use **Set credential in Env** to save the token as `APIFY_TOKEN`.
+   This mode has no callback/client registration.
+5. Save and choose **Connect account**, or **Verify again** for a connected
+   account. **Check connection** only reads its current status. CLI applications
+   call `connectApiKey`. Inspect the Actor list for the expected
+   account's resources. Revoke/replace the token through the same settings page.
+   See [Account settings](https://docs.apify.com/account/settings) and
+   [API integration](https://docs.apify.com/integrations/api).
+
+## Scoped tokens and failed checks
+
+The adapter accepts scoped tokens too, but this guide does not establish a
+minimum scoped permission set for `GET /v2/actors`. If your policy requires
+scoped access, enable **Limit token permissions** and establish Actor-list
+access with Apify before connecting. Storage Read alone is not proof of that
+access. A 403 during Connect account or Verify again means this read was denied; it does not
+prove the token is invalid or should be replaced with a broader token. A 401
+requires checking the token value, expiry and revocation. Never put the token
+in frontend code or source control.
+
+This guide's documented standard-token path is distinct from unverified
+least-privilege configuration. No live token issuance or permission test has
+been performed. The connection check remains the same authenticated Actor-list
+operation the fragment provides; it does not run Actors or spend compute.
+
+For a scoped token that runs Actors and retrieves output, grant **Run** on the
+chosen Actor and allow access to its default run storages. Without that storage
+access, a run can succeed while reading its output fails. Review the execution
+permission mode: **Full access** gives the running Actor account-wide access;
+**Restricted access** can require additional permissions for that Actor's work.
+These settings do not establish the separate minimum permission for Actor listing.
+See [scoped token execution](https://docs.apify.com/integrations/api#actor-execution).
+Disconnecting locally does not revoke the token: revoke it in Apify Console when
+provider access must end, including access from other applications using it.
+
+## Runtime and AI composition
+
+`actors.list` calls `GET /v2/actors` with Bearer authentication. Supported inputs
+are `limit` (1–1000, default 100), `offset` (default 0), and `desc` (default false).
+The list includes Actors the user created or used. The result retains the `data`
+envelope and its `items`, `total`, `offset`, `count` and `limit`. The caller
+requests subsequent pages. See [List Actors](https://docs.apify.com/api/v2/actors-get).
+
+Use the [API-key source pattern](../patterns/api-key-connection/PATTERN.md)
+with this provider. The application authorizer controls who can inspect the
+shared Actor list. CLI and UI configuration use the same file and secret
+reference; connection metadata uses the existing file-store adapter.
+
+## Provisioning automation and capacity
+
+Once a token exists, an AI can configure this adapter and query the list through
+documented APIs. This pass did not verify an API for issuing the initial token
+with equivalent normal-account permissions; use the console for that step.
+Actor creation and run APIs are separate capabilities, not evidence that token
+or organization creation can be automated without operator involvement.
+
+The application owner supplies its authorized Apify token and arranges the
+account or organization budget. Multiple tokens in one account do not reserve
+separate compute credits or concurrency. Private Actors still require explicit
+access; a configuration label cannot grant access to another account's resources.
+
+Fixtures cover authentication, pagination, malformed success, input validation,
+file-store restart, token rotation, owner isolation, disconnect and 401/403/429.
+No real Apify account or Actor was invoked.
+
+## Run an Actor and retrieve its output
+
+Select an Actor ID from `actors.list`, or an explicitly chosen Store Actor using
+`owner~actor-name`. Call `actors.get` with `{ actorId }` to inspect it. Review the
+Actor's own input documentation and price before submitting: Actor inputs and
+pricing vary; a token does not make every Actor free or accessible.
+
+```js
+const started = await connections.invoke({ context, integrationId: "scraper",
+  operation: "runs.start", input: { actorId: "owner~actor-name",
+    input: { query: "your actor-specific input" }, timeout: 120, maxTotalChargeUsd: 1 } });
+const runId = started.data.id;
+const current = await connections.invoke({ context, integrationId: "scraper",
+  operation: "runs.get", input: { runId } });
+```
+
+`runs.start` requires an Actor-specific JSON `input`, a timeout of 1–86400 seconds,
+and an explicit positive `maxTotalChargeUsd` (minimum 0.01). Optional `build`
+selects a version/tag. The adapter requests immediate return and disables
+restart-on-error. Persist `data.id` before subsequent work. Provider minimum
+charges or account policy can still reject a requested cap.
+[Start a run](https://docs.apify.com/api/v2/acts-runs-post).
+
+Poll `runs.get` on a bounded application schedule. `READY`/`RUNNING` are not
+completion; inspect `SUCCEEDED`, `FAILED`, `TIMED-OUT`, and `ABORTED`, retaining
+`statusMessage` for useful diagnostics. `runs.abort` takes `{ runId }` and requests
+graceful cancellation. An `ABORTING` response remains pending; check status again
+rather than immediately claiming cancellation finished. A lost start response has
+an uncertain outcome: inspect the account's runs before creating another paid run.
+[Read status](https://docs.apify.com/api/v2/actor-run-get),
+[abort](https://docs.apify.com/api/v2/actor-run-abort-post).
+
+For results, use `data.defaultDatasetId` from the run with `datasets.items`:
+`{ datasetId, offset: 0, limit: 100 }`. It returns JSON items. Advance offset by
+the received count until a short page after the run finishes. No cleaning or
+unwinding is applied, so pagination reflects raw items. A running Actor can append
+items; an empty page before completion does not establish final completion.
+[Dataset items](https://docs.apify.com/api/v2/dataset-items-get).
+
+Use `data.defaultKeyValueStoreId` with `stores.record` and `{ storeId, key }`,
+for example `key: "OUTPUT"` where that Actor documents OUTPUT. It returns
+`{ contentType, bodyBase64, size }` for JSON, text or binary records. Decode
+`bodyBase64` in the application; serve downloads with the application's own access
+checks and safe content-disposition policy. This bounded operation rejects records
+over 8 MiB; larger files require the framework's native streaming client. It does
+not follow provider redirects with credentials.
+[Stored record](https://docs.apify.com/api/v2/key-value-store-record-get).
+
+Authorize every run, cancellation and storage read against the application's
+owner and chosen resources. Connection success does not prove run or storage
+permission for every resource. The inline token guide retains the distinction
+between standard-token access and scoped permissions whose exact role mapping
+has not been live-verified. Surface denied permissions without silently replacing
+a restricted token with an unrestricted one.
+
+`test/apify.test.js` passes the actual connection-service workflow using controlled
+responses: actor selection, explicit budget/timeout, run terminal states, pending
+cancellation, dataset pagination, JSON/binary storage, 8 MiB bound, input and
+owner rejection, 403/429 and uncertain submissions without automatic retries.
+No live Actor or paid account operation was performed.
+
+## Limitations
+
+Vibe64 coding-assistant attachment is deferred. For example, the generated app
+can start an authorized scraper, show run progress and read the resulting dataset,
+but asking Vibe64's Codex/OpenCode assistant to scrape a site does not grant it
+access to this connection. The app composes its own input screen, bounded status
+polling and output presentation. This connector does not create Actors or schedules.
+Records over 8 MiB use the framework's native streaming client. Live token issuance,
+scoped permission checks and generated-app execution were not exercised.

package/docs/apollo-io.md

@@ -0,0 +1,200 @@
+# Apollo.io
+
+Import `apolloIoProvider` from `@jskit-ai/connectors-catalog/server/apollo-io`.
+This adapter searches prospects, enriches selected people/companies and reads or
+changes saved contacts, accounts and deals in an Apollo workspace.
+
+## Provider setup
+
+1. Sign into the intended Apollo workspace. Open **Settings → Integrations →
+   API Keys**, then **API Keys → Create new key**.
+2. Enter a name and description. Enable `api/v1/accounts/search` for this key.
+   Keep **Set as master key** off when the selected endpoint permissions suffice.
+   Add the endpoint permissions below only for capabilities the app will use.
+3. Choose **Create API key**, then **Copy**. Store the value under
+   `APOLLO_API_KEY` in the backend environment.
+4. Add Apollo.io in Vibe64, give the integration a display name and enter
+   `env:APOLLO_API_KEY` in **API key reference**. Save the file configuration,
+   use **Set credential in Env** to supply the value, then **Connect account**
+   (or **Verify again**). **Check connection** only reads current status.
+
+Key access also depends on the account's provider plan. Apollo's developer
+dashboard exposes key regeneration/deletion and a Usage screen for endpoint
+limits. A scoped key can receive 403 when an endpoint is not allowed.
+[Key creation and management](https://docs.apollo.io/docs/create-api-key).
+
+## Portable configuration and runtime
+
+```json
+{
+  "schemaVersion": 1,
+  "registrations": {},
+  "integrations": {
+    "companies": {
+      "provider": "apollo-io",
+      "displayName": "Saved sales accounts",
+      "accountMode": "shared",
+      "scopes": [],
+      "authentication": { "method": "api-key", "secretRef": "env:APOLLO_API_KEY" }
+    }
+  }
+}
+```
+
+Use the [API-key composition pattern](../patterns/api-key-connection/PATTERN.md)
+with `providers: [apolloIoProvider]`, environment-reference resolution and the
+file connection store. CLI and Vibe64 edit this same configuration. Runtime
+connection records remain encrypted JSON outside exported source.
+
+```js
+await connections.connectApiKey({ context, integrationId: "companies" });
+const page = await connections.invoke({
+  context, integrationId: "companies", operation: "accounts.search",
+  input: { page: 1, per_page: 25, q_organization_name: "Design" }
+});
+```
+
+The request is `POST https://api.apollo.io/api/v1/accounts/search`, with JSON
+search inputs and the credential in `X-Api-Key`. The fragment accepts integer
+`page` 1–500, integer `per_page` 1–100 and an optional nonempty name query up to
+256 characters. Defaults are page 1 and 25 results; the query-length cap is a
+local bound. The endpoint searches saved company accounts and currently
+documents zero credit consumption. Searching Apollo's prospect database or
+enriching people uses different endpoints.
+[Saved-account search](https://docs.apollo.io/reference/search-for-accounts).
+
+The adapter validates the `accounts` collection and preserves the result
+envelope. It performs one request, accepts an empty page, and does not assume
+that all matching records fit within the provider's display limit. Request
+pages explicitly and narrow the name query when needed. Additional operations are listed below. The app explicitly chooses each
+page; there is no automatic scan, enrichment or background synchronization.
+
+Verification uses the same saved-account operation, so a public health reply
+cannot mark this connection as verified. Keys are resolved per request, sent
+only to the fixed HTTPS origin, and never written into portable configuration.
+After provider-side regeneration, update the environment value and reverify.
+Disconnect removes local state; provider revocation is a separate key action.
+
+## Ownership, automation and application capacity
+
+Apollo API keys represent a workspace. Requests act as its longest-standing
+active administrator, so authorize CRM changes against the app owner and intended Apollo workspace.
+Partners accessing individual users use OAuth. That partner flow and app login
+are not implemented by this API-key fragment.
+[Authentication and request identity](https://docs.apollo.io/reference/authentication).
+
+An AI can prepare configuration, library calls and paging logic. The reviewed
+key-creation guide provides dashboard steps; an API for issuing initial keys
+was not verified. Treat that bootstrap as an owner/admin task. Partner OAuth
+would require separate registration work and an adapter rather than replacing
+an API key with an OAuth token in this module.
+
+Create an authorized key for the application, with a recognizable name for
+revocation and attribution. Customer-owned data
+requires keys for the appropriate customer workspace. These are key names,
+not universal OAuth app identities, and no callback URL is involved.
+
+Apollo limits are per team and endpoint, across minute/hour/day windows. All
+keys and users share those limits; child workspaces also share their parent's
+allowance. Separate keys therefore do not create independent capacity.
+The application owner must arrange the capacity and usage limits it needs. The runtime surfaces 429 failures and does not
+automatically retry requests.
+[Rate limits](https://docs.apollo.io/reference/rate-limits).
+
+## Focused evidence
+
+Tests use simulated provider replies and actual temporary encrypted JSON
+storage. They verify headers, POST bodies, empty accounts, page/name boundaries,
+malformed replies, provider failures, restart, rotation, ownership and
+disconnect. The editor case verifies secret references, setup links and reload.
+Live API calls, provider signup and sample-app generation are excluded.
+
+## Operations and endpoint permissions
+
+API-key permissions are provider settings, not OAuth scopes in `integrations.json`.
+Always keep `api/v1/accounts/search` for the harmless connection check. Add only
+rows your app needs. A 403 can mean key permission or plan access; do not silently
+switch to a master key. Current endpoint reference tables list scoped-key options,
+although some older response-example labels still mention master keys.
+
+| Operation | Endpoint permission | Inputs and behavior |
+| --- | --- | --- |
+| `people.search` | `api/v1/mixed_people/api_search` | Name/keyword, titles, locations, company IDs/domains; paged prospects without email/phone disclosure. |
+| `organizations.search` | `api/v1/mixed_companies/search` | Company name, domains, locations, page; requires `allowCreditConsumption: true`. |
+| `people.enrich` | `api/v1/people/match` | Apollo person `id` from search, `allowCreditConsumption: true`; personal email reveal defaults false. |
+| `organizations.enrich` | `api/v1/organizations/enrich` | Bare `domain` without scheme/www, `allowCreditConsumption: true`. |
+| `contacts.search` | `api/v1/contacts/search` | Keywords, stage/list IDs, page. |
+| `contacts.create` / `contacts.update` | `api/v1/contacts/create` / `api/v1/contacts/update` | Names, email, employer, title, account, stage, lists, phone/location; update takes contact `id`. |
+| `accounts.create` / `accounts.update` | `api/v1/accounts/create` / `api/v1/accounts/update` | Name/domain, owner, stage, phone/address; update takes saved account `id`. |
+| `deals.list` | `deals/api/v1/opportunities/search` | Page and optional amount/is_closed/is_won sort. |
+| `deals.create` / `deals.update` | `deals/api/v1/opportunities/create` / `deals/api/v1/opportunities/update` | Name, owner, amount, stage, close date; create can set account; update takes deal `id`. |
+| `dealStages.list` | `deals/api/v1/opportunity_stages/index` | Stage identifiers for this workspace. |
+| `users.list` | `api/v1/users/search` | Paged owner identifiers for this workspace. |
+
+Search pages use `page` 1–500 and `per_page` 1–100 (default 25). Preserve the raw
+provider envelope, including pagination or match information; an empty page is
+valid. Narrow filters before reaching the provider's result cap. A connected key
+does not prove that every optional endpoint or record is accessible.
+
+Sources: [people search](https://docs.apollo.io/reference/people-api-search),
+[company search](https://docs.apollo.io/reference/organization-search),
+[people enrichment](https://docs.apollo.io/reference/people-enrichment),
+[company enrichment](https://docs.apollo.io/reference/organization-enrichment),
+[contact search](https://docs.apollo.io/reference/search-for-contacts),
+[contact create](https://docs.apollo.io/reference/create-a-contact),
+[contact update](https://docs.apollo.io/reference/update-a-contact),
+[account create](https://docs.apollo.io/reference/create-an-account),
+[account update](https://docs.apollo.io/reference/update-an-account),
+[deal list](https://docs.apollo.io/reference/list-all-deals),
+[deal create](https://docs.apollo.io/reference/create-deal),
+[deal update](https://docs.apollo.io/reference/update-deal),
+[deal stages](https://docs.apollo.io/reference/list-deal-stages),
+[workspace users](https://docs.apollo.io/reference/get-a-list-of-users).
+
+## Compose a useful application workflow
+
+1. Search prospects, then let the authorized user choose the person/company.
+2. Before company search or enrichment, disclose provider credit usage. The app's
+   authorizer must enforce explicit user approval or an administrator-approved
+   budget policy; `allowCreditConsumption` is an input acknowledgement, not a
+   billing limit or authorization system. The adapter strips it from the request.
+3. Enrich only the selected identifier/domain. Preserve `match_confidence` and
+   null/no-match replies; a successful HTTP response need not identify a person.
+   Phone reveal and waterfall enrichment are disabled because they require a
+   separate asynchronous webhook workflow. No emails or phone numbers are
+   invented when Apollo does not return them.
+4. Let an authorized user save/update the desired CRM record. Contact creation
+   requires an explicit `run_dedupe` choice: false can create duplicates; true
+   can overwrite fields on an existing matched contact. Updating `label_names`
+   replaces its lists; omitted fields remain omitted. Account creation has no
+   automatic deduplication: search saved accounts first and retain returned IDs.
+5. Create or update a deal using an actual saved account ID and a stage from
+   `dealStages.list`. Owner IDs come from `users.list`. Deal amounts are decimal
+   strings without currency symbols/commas; currency comes from Apollo settings.
+   Close dates must be real `YYYY-MM-DD` dates. Persist the returned deal ID.
+
+```js
+const people = await connections.invoke({ context, integrationId: "companies",
+  operation: "people.search", input: { person_titles: ["Designer"], per_page: 10 } });
+// After application authorization and approval of provider credit use:
+const selected = await connections.invoke({ context, integrationId: "companies",
+  operation: "people.enrich", input: { id: selectedPersonId, allowCreditConsumption: true } });
+```
+
+The HTTP layer makes one request per invocation. After an uncertain create or
+enrichment response, inspect Apollo before retrying; retrying can duplicate a
+record or spend credits again. Handle 403/422 as permission/input failures and
+429 with a bounded app policy. Do not expose the workspace key to browser code.
+The same operations work in a CLI-owned Node app without Vibe64; other frameworks
+use their own HTTP client against the documented endpoints and read the same Env
+reference from project configuration.
+
+## Limitations
+
+Editor coding-assistant attachment is deferred. For example, a generated sales
+app can search, enrich approved leads and save deals, but asking Vibe64's coding
+assistant to find leads does not grant it this connection. The app owns lead and
+CRM screens, authorization and usage budgets. This adapter does not implement
+partner OAuth, outreach sequences, bulk jobs, deletion, custom-field discovery,
+or phone/waterfall webhooks. Native framework clients can compose those separate
+provider APIs when needed. Live accounts, charges and generated apps are untested.

package/docs/asana.md

@@ -0,0 +1,126 @@
+# Asana
+
+Import `asanaProvider` from `@jskit-ai/connectors-catalog/server/asana`.
+This adapter discovers workspaces/projects/tasks and creates or updates projects
+and tasks through a personal access token.
+
+## Configure access
+
+1. Sign into the intended Asana account and open the developer console. The
+   official developer guide links it under **My apps**.
+2. Create a personal access token and provide a description identifying this
+   application. Copy the generated token while available.
+3. Store it in backend Env as `ASANA_TOKEN`. Treat it as opaque; there is no
+   local prefix/length assumption about Asana's token format.
+4. Save provider `asana`, mode `shared` or `assistant`, `scopes: []`, and
+   authentication `{ "method": "api-key", "secretRef": "env:ASANA_TOKEN" }`.
+5. In Vibe64 use **Set credential in Env** to save the token, then
+   **Connect account** or **Verify again**. **Check connection** only reads
+   status. CLI applications verify with `connectApiKey`. Manage/deauthorize personal tokens from the
+   developer console. Organization policy can limit personal-token access.
+   [Token instructions](https://developers.asana.com/docs/personal-access-token).
+
+## Runtime and AI composition
+
+`workspaces.list` calls `GET https://app.asana.com/api/1.0/workspaces` using
+Bearer authorization. It accepts `limit` (1–100, default 50) and optional
+`offset`. Results contain compact workspace records under `data` and may
+include `next_page.offset`; pass that opaque offset to request another page.
+The verifier uses this list operation. If extended to OAuth, this endpoint's
+documented read scope is `workspaces:read`.
+[Workspace endpoint](https://developers.asana.com/reference/getworkspaces).
+
+The [API-key pattern](../patterns/api-key-connection/PATTERN.md) supplies the
+same portable JSON and server library wiring for CLI and editor consumers.
+The backend owns whether its users may access the shared account's workspaces.
+
+## Automation and application registrations
+
+An AI can prepare the configuration and runtime calls after a token is supplied.
+The verified personal-token creation path is the developer console; no API that
+creates the initial personal token was established in this pass. Asana recommends
+OAuth for applications acting for other users. That application-registration and
+consent flow remains separate from this personal-token fragment.
+
+Each application supplies its owner's token. Differently named personal tokens
+may still share workspace/user limits. Apps requiring individual user consent
+must implement the supported OAuth flow with their own registration.
+Automated fixtures cover authorization headers, pagination, file-store restart,
+credential replacement, cross-application isolation, disconnect and controlled
+provider failures. No workspace was accessed with a real token.
+
+## Project and task workflow
+
+The adapter uses these documented endpoints with Bearer authentication and
+`{ data: ... }` JSON for writes. A successful list of workspaces proves neither
+write permission nor access to every private project. Your backend authorizer
+must enforce who may invoke each operation for the shared account.
+
+| Operation | Required inputs and result |
+| --- | --- |
+| `projects.list` | `workspace`, optional `archived`, `limit`, opaque `offset`; returns project records. |
+| `projects.get` | Project `gid`; includes name, notes, owner, privacy, archive and dates. |
+| `projects.create` | `workspace`, `name`, explicit `privacy_setting` (`private` or `public_to_workspace`); optional owner, notes and dates. |
+| `projects.update` | Project `gid` and only changed fields; supports archive/unarchive. |
+| `users.list` / `teams.list` | `workspace`, page inputs; identifiers for assignment/sharing. Teams apply to organization workspaces. |
+| `projectMembers.add` | `project`, `member` (team or user GID), explicit `access_level` (`admin`, `editor`, `commenter`). |
+| `tasks.list` | `project`, page inputs, optional `completed_since` (date-time or `now` for incomplete tasks). |
+| `tasks.get` | Task `gid`; includes assignment, completion, due/start dates, notes and project IDs. |
+| `tasks.create` | `workspace`, `name`; optional `projects` GIDs, parent task, assignee GID, notes, dates and completed flag. |
+| `tasks.update` | Task `gid` plus changed work-tracking fields; omitted fields are not overwritten. |
+
+1. Choose a workspace from `workspaces.list` and a project from `projects.list`,
+   or explicitly create a project with the desired privacy setting. Persist its
+   returned `data.gid` before granting membership. Organization policy may deny
+   a privacy level or sharing action. If sharing fails after creation, show the
+   existing project and retry only the intended sharing action after resolution.
+2. For team sharing, use `teams.list` and `projectMembers.add` after the user
+   confirms the member and access level. The old project `team` argument and
+   `private_to_team` setting are deprecated; this adapter uses the documented
+   membership endpoint and `access_level`, not the deprecated membership `role`.
+3. Choose an assignee using `users.list`, then create a task in the workspace
+   and selected project. This adapter accepts user GIDs for assignment; use null
+   to unassign. Persist the returned task GID for subsequent changes.
+4. Change only the intended fields. `completed: true` completes a task; false
+   reopens it. Empty notes clear the description. Null dates clear dates. When
+   sending `start_on`, also send `due_on`; dates must be real `YYYY-MM-DD` values.
+   Project start must precede its due date; task start cannot follow its due date.
+   A task's workspace cannot change. The creation-only `projects` list is not
+   accepted by task update; native addProject/removeProject APIs handle moves.
+5. Request each next page using `next_page.offset`, not a returned URL. Read/list
+   operations request the task/project fields used for work tracking rather than
+   relying on Asana's compact default response. Stop when `next_page` is null.
+
+```js
+const created = await connections.invoke({ context, integrationId: "work",
+  operation: "tasks.create", input: { workspace: workspaceGid,
+    projects: [projectGid], name: "Review release", assignee: ownerGid,
+    due_on: "2026-12-31" } });
+await connections.invoke({ context, integrationId: "work", operation: "tasks.update",
+  input: { gid: created.data.gid, completed: true } });
+```
+
+A lost create response has an uncertain outcome. Inspect the project/task list
+before retrying; the adapter does not replay writes. Display permission failures,
+missing resources, invalid values and rate limits distinctly in the application.
+The same ordinary Node library works in CLI-built applications without Vibe64;
+other frameworks read the configuration/Env reference and use their native HTTP
+client for these endpoints. No Vibe64 server is needed at application runtime.
+
+Sources: [projects](https://developers.asana.com/reference/getprojects),
+[create project](https://developers.asana.com/reference/createproject),
+[update project](https://developers.asana.com/reference/updateproject),
+[membership](https://developers.asana.com/reference/createmembership),
+[project tasks](https://developers.asana.com/reference/gettasksforproject),
+[create task](https://developers.asana.com/reference/createtask),
+[update task](https://developers.asana.com/reference/updatetask),
+[official request/response schemas](https://github.com/Asana/openapi/blob/master/defs/asana_oas.yaml).
+
+## Limitations
+
+Editor coding-assistant attachment is deferred. For example, a generated app can
+create a release project, assign a task and mark it complete, but asking Vibe64's
+coding assistant to inspect your Asana backlog does not give it this connection.
+The app owns its work-tracking screens and resource permissions. OAuth user consent,
+attachments, comments, custom fields, task moves and destructive deletion are not
+implemented here. Live Asana access and generated-app execution were not exercised.