@volter/twin-catalog 0.2.39 → 0.2.41

package/content/871d902e2c0d3e14a5a9c90fca585f47f5e0989442abe099ec185b5541c54e14.json

@@ -0,0 +1,27 @@
+{
+  "schemaVersion": 1,
+  "release": {
+    "schemaVersion": 1,
+    "source": "twin-packs-open",
+    "vendor": "upstash",
+    "package": "@volter/twin-upstash",
+    "version": "1.0.1",
+    "integrity": "sha512-/0qbzpyAMt+lRa5Cl4+hgCRCGH5fSxWiD0bY4Haj5yZD6Y4W+67LQRllb5wUiYsqkSE33HOn5nbkvzUwMix9JA=="
+  },
+  "packageMetadata": {
+    "description": "Deterministic Upstash Redis over REST, rate-limit client calls, and QStash workflows; no live Upstash calls.",
+    "license": "Apache-2.0",
+    "engines": {
+      "node": ">=22.3"
+    },
+    "peerDependencies": {
+      "@volter/world-core": "^3.0.68"
+    },
+    "repositoryDirectory": "upstash",
+    "bugs": "https://github.com/volter-ai/twin-packs-open/issues"
+  },
+  "readme": {
+    "path": "package/README.md",
+    "markdown": "# @volter/twin-upstash\n\nA local Upstash: Redis over Upstash's REST API, the one the unmodified `@upstash/redis` and `@upstash/ratelimit` call\n(`https://<endpoint>.upstash.io`, this unit), the console where a database and QStash's credentials are made\n(`console.upstash.com`, the `api/` lane, beside the Developer API's spec), and QStash with Workflow\n(`https://qstash[-<region>].upstash.io`, the `qstash/` lane), over one vendor state.\n\n## Use with an existing app\n\nFor an app using the supported Redis REST or QStash workflows, install the exact release:\n\n```console\nnpm install --save-dev --save-exact @volter/world@3.0.68 @volter/twin-upstash@1.0.1\nnpx volter world init --name my-app --twins upstash --source upstash=@volter/twin-upstash\n```\n\nReview the detected vendor and generated bindings before booting. The World supplies throwaway credentials;\nseed stored data through the unchanged vendor SDK, then run your app's existing test command inside the World.\n\n```console\nnpx volter world up\nnpx volter world run -- npm test\nnpx volter world log\nnpx volter world down\n```\n\nUse your app's test command in place of `npm test`. Ordinary `down` retains state for the next `up`.\n\n\nA Protocol 3 pack ([publisher guide](https://github.com/volter-ai/twin-catalog-open/blob/main/docs/contributing.md)). The Redis\nunit's surface is Redis's command table (`spec/commands`), and its front (`src/semantics/around.ts`) reads Upstash's REST\nforms and runs the commands with the kernel's Redis core under Upstash's dialect (`src/semantics/shared.ts`). Each lane's\nsurface is generated from its own spec, with handlers in `<lane>/src/semantics/<family>.ts` and state machines in\n`<lane>/src/semantics/states.ts`.\n\n```bash\nworld-upstash serve [--port N] [--root DIR] [--read-only]\n```\n\n## The World's Upstash\n\nA person signs in to the console and creates a Redis database there (name, primary region, the free plan). The\ndatabase's page shows `UPSTASH_REDIS_REST_URL`, `UPSTASH_REDIS_REST_TOKEN` and the Read Only token. On a first visit to\nQStash they pick a region; the page then shows `QSTASH_URL`, `QSTASH_TOKEN` and the two signing keys, and can reset the\ntoken and roll the keys.\n\n## What it models\n\n- **Redis over REST**: a command in the path (`/set/foo/bar`, a POST body as its last argument) or the body\n  (`[\"SET\", \"foo\", \"bar\"]`), `/pipeline` and `/multi-exec`, `{result}` / `{error}`, `Upstash-Encoding: base64`, `Upstash-Response-Format: resp2`\n  (RESP2 bytes, but at `/multi-exec`), and a\n  database's Standard and Read Only tokens (the Read Only one refuses writes, SCAN and KEYS).\n- **Redis's semantics** are the kernel's (`@volter/world-core/redis`), for the commands Dub sends and the life sends\n  (`src/semantics/shared.ts`, SERVED): SET, GET, GETDEL, DEL, EXISTS, EXPIRE, PEXPIRE, INCR, INCRBY, RENAME; HSET,\n  HSETNX, HGET, HGETALL, HMGET, HDEL, HINCRBY; LPUSH, RPUSH, LPOP, LRANGE; SADD, SREM, SMEMBERS, SISMEMBER, SMISMEMBER;\n  ZINCRBY, ZRANGE; XADD, XRANGE, XREVRANGE, XDEL; SCAN; EVAL and EVALSHA running the script's Lua (`@upstash/ratelimit`'s\n  windows verbatim). Every other command is refused as Upstash refuses one it does not have, in a request or a script.\n- **QStash**:\n  - Publishing: publish with method, timeout, delay, not-before, retries, deduplication (ten minutes), flow control's\n    keyed rate, period and parallelism (a key alone keeps its limits), durations as `<number><unit>` or compound\n    (`1d1h30m`), retry-delay expressions, comma-separated labels,\n    callbacks and failure callbacks, each configured by its own `Upstash-Callback-*` / `Upstash-Failure-Callback-*`\n    options; batch; enqueue into a queue, and a queue's upsert; the token as a bearer header or `qstash_token`.\n    A destination that is not a URL is a URL Group the account does not hold (404).\n  - Messages: a message's read with configured body/header redaction; cancellation by message ids, filters, or all pending messages in the account. Redaction preserves the original payload for delivery.\n  - Delivery: each message is delivered when due, signed (`Upstash-Signature`, HS256 with the current key), and\n    retried on QStash's backoff, each attempt waiting at most its timeout (the account's Pay as you go plan's two hours,\n    which an `Upstash-Timeout` only shortens). Once out of retries, or answered 489 with `Upstash-NonRetryable-Error:\n    true`, it goes to the DLQ and its failure callback is called. A queue delivers in order, as many at a time as its\n    parallelism; the attempts due at one instant are sent at once, and a call holds its key's slot until its answer\n    arrives.\n- **Workflow**: a run is started by its first invocation, and each later call carries the run's steps so far. It ends\n  when `serve()` ends it or when it is cancelled; when a step is out of retries it fails.\n\n## Doors\n\n- `POST /_twin/users/{email} {password}` (console.upstash.com): a person who can sign in.\n- `POST /_twin/app-credentials {owner?}` (console.upstash.com): a World application's database and QStash credentials,\n  as the runtime issues them (the descriptor's credential door).\n- `POST /_twin/destinations {url, status, headers?, body?, takes?, when?}` (QStash): how an application the World does\n  not run answers at a URL, and after how long on the World's clock.\n- `GET /_twin/deliveries?to=<url>[&run=<id>][&message=<id>]` (QStash): every request QStash made there, with its\n  answer's status once it arrived, or what was missed (`timeout`, `unreachable`).\n\n## Who it is for\n\nDub, as it ships (`journeys/demand.json`): its Redis caches, locks, streams and imports, its rate limits, its QStash jobs,\nqueues and Workflow runs, and the deliveries its routes verify. Rallly and Cal.com use Upstash Redis only when their\nvariables are set. The life (`journeys/customer-life.json`) is one studio's quarter on one account: Kiln on Redis,\nLooplinks on QStash and Workflow.\n\n## Not yet\n\n- The Developer API (`api.upstash.com/v2`): no application calls it; the console makes what they use.\n- QStash's schedules, URL groups, the DLQ's API, waiting for events, flow control's management API; a message\n  read only while it is delivered or retried, as QStash keeps it.\n- Every Redis command no demand or life sends (Upstash's table holds 248).\n- Upstash Vector (Dub's docs embeddings): another product with its own wire.\n"
+  }
+}

package/content/8c35ee3b7e5272a335eccc4e2527b8135eebaeee75c1aab1f874f520fe97de71.json

@@ -0,0 +1,28 @@
+{
+  "schemaVersion": 1,
+  "release": {
+    "schemaVersion": 1,
+    "source": "twin-packs-open",
+    "vendor": "cloudflare",
+    "package": "@volter/twin-cloudflare",
+    "version": "3.0.11",
+    "integrity": "sha512-8JrSDMxmxzNy4Qkf4dLeaAU24tGDcW98vcjswh2XZLaGOjqWpxScT8IISWieaKz28wY4Om/xARADJZUrRlSdFg=="
+  },
+  "packageMetadata": {
+    "description": "Local Cloudflare DNS, R2 and Worker deployment configuration. Worker programs are not executed; static asset behavior and API limits are documented in the README.",
+    "license": "Apache-2.0",
+    "engines": {
+      "node": ">=22.3"
+    },
+    "peerDependencies": {
+      "@volter/world-core": "^3.0.68",
+      "@volter/world-ui": "*"
+    },
+    "repositoryDirectory": "cloudflare",
+    "bugs": "https://github.com/volter-ai/twin-packs-open/issues"
+  },
+  "readme": {
+    "path": "package/README.md",
+    "markdown": "# @volter/twin-cloudflare\n\nFor Open Autonomy, RH2, the platform callers and the shipped storage, custom-domain and CAPTCHA features of Dub, Twenty, Cal.com, Rallly and LibreChat. Postiz’s alternative storage driver and Twenty’s optional CAPTCHA driver are recorded in `journeys/demand.json` and exercised by the customer life. A local Cloudflare: the API v4 that the unmodified `cloudflare` SDK and wrangler call (`api.cloudflare.com/client/v4`,\nthe `api/` lane), and R2 over its S3 API (`<account>.r2.cloudflarestorage.com`, the `r2/` lane). It also covers the\ndashboard's sign-in and its API Tokens pages (My Profile's and R2's, `dash.cloudflare.com`), and Turnstile's `api.js`,\nits challenge frame and siteverify (`challenges.cloudflare.com`), all over one vendor state.\n\n## Use with an existing app\n\nIn an app that already uses this vendor, install this exact release and the product CLI:\n\n```console\nnpm install --save-dev --save-exact @volter/world@3.0.68 @volter/twin-cloudflare@3.0.11\nnpx volter world init --name my-app --twins cloudflare --source cloudflare=@volter/twin-cloudflare\n```\n\nReview the detected vendor and generated bindings before booting. Read the credential names and limitations below; the World supplies throwaway credentials. Then run your app's own command through the World:\n\n```console\nnpx volter world up\nnpx volter world run -- npm test\nnpx volter world log\nnpx volter world down\n```\n\nHere `npm test` is your app's existing command; replace it with your app or test command. `down` retains state.\nA later `up` resumes it; do not reset or initialize again merely to return.\n\nPublisher and catalog contribution instructions: [the public publisher guide](https://github.com/volter-ai/twin-catalog-open/blob/main/docs/contributing.md).\n\n\nA Protocol 3 pack of lanes ([publisher guide](https://github.com/volter-ai/twin-catalog-open/blob/main/docs/contributing.md)). Each lane's surface is generated from its own spec (`api/spec`: Cloudflare's OpenAPI document; `r2/spec`:\nS3's model with R2's differences). Its handlers are in `<lane>/src/semantics/<family>.ts`, its state machines in\n`<lane>/src/semantics/states.ts`, and operations outside scope answer the lane's gap (API \"No route for the URI\", R2 NotImplemented).\n\n```bash\nworld-cloudflare serve [--port N] [--root DIR] [--read-only]\n```\n\n## The World's Cloudflare\n\nThe application's account comes from the World's credential door (`/_twin/app-credentials`). A zone is added through\nthe API (`POST /zones`) and turns active when the registrar's nameservers are published (the `dns` door).\n\n- **API tokens**: one model for both lanes. A token is a set of policies, each allowing permission groups\n  (`Workers Scripts Write`, `DNS Write`, `Workers R2 Storage Bucket Item Read`, …) over an account, a zone (or every\n  zone of an account), R2 buckets or the person.\n- **Where tokens are made**: on R2's API Tokens page, or on My Profile's API Tokens page from a template URL\n  (`permissionGroupKeys`), as Open Autonomy's setup links it.\n- **Checking**: a token is kept by its SHA-256. The API refuses an operation whose permission group the token lacks on\n  the account or zone it names (403, code 10000), and a disabled or expired token (401).\n- **R2 credentials**: R2's S3 credentials are the token's id and the SHA-256 of its value.\n\n## What it models\n\n- **Workers**: a module upload with its assets (multipart, deployed at once) and its Durable Object migrations (classes\n  made, renamed and deleted), the service read, the workers.dev subdomain and a script's route on it, its settings read,\n  Cron Trigger schedules installed and read back, secrets put (their text never answered, kept across uploads), the deployments and versions lists, a version's detail\n  and the account's scripts, as wrangler deploys and the platform's deploy rehearsal reads back.\n- **R2**: buckets through the API and the S3 API (with a location hint, or made by an upload's\n  `cf-create-bucket-if-missing`); objects (their checksums checked), presigned URLs, CORS and lifecycle configurations\n  (R2's default rule aborting an upload after seven days), listings by delimiter and continuation token, multipart\n  uploads (large-part completion, composite/full-object checksums and SSE-C key-gated objects), custom domains attached and listed through the API, and public reads at them.\n- **Workers static assets and Custom Domains**: the files `wrangler deploy` uploads through an assets upload session\n  (each kept with the content type it was uploaded with), a version's assets served once a deployment sends it the\n  traffic (a new version upload and a deployment are wrangler's path for a Worker it has deployed before), the config's\n  `html_handling`, `not_found_handling`, `_redirects` and `_headers` (parsed as the API parses them), and a hostname in\n  one of the account's active zones attached as the Worker's Custom Domain (the Domains API, or wrangler's changeset and\n  domain records); a hostname the zone holds DNS records at is refused, as Cloudflare refuses it. Inside the World the\n  hostname answers as Cloudflare's asset worker does (`src/semantics/shared.ts`, ported from Cloudflare's\n  `workers-shared`).\n- **Zones**: a zone's DNS records listed, made and deleted, with vendor timestamps and type-dependent proxy capability; the internal zone parent never appears in the record reply; Cloudflare for SaaS custom hostnames (listed, made, edited, deleted). A\n  hostname's ownership and certificate validation records are computed for the method chosen, and it turns active\n  when its customer publishes them.\n- **Turnstile**: widgets made through the API (sitekey and secret), the `api.js` widget and its challenge, a visitor's token checked once at siteverify\n  within 300 seconds (`timeout-or-duplicate` after).\n- **Tokens**: verification (`/user/tokens/verify`), an account's tokens listed, and a token rolled or revoked on the\n  dashboard's token pages.\n- **A vendor-backed World**: every stored resource is read back (the account, zones and custom hostnames, the account's\n  tokens, each zone's DNS records retaining their vendor IDs, Workers with each version's detail, deployments and secrets, Durable Object namespaces, the workers.dev\n  subdomain, Turnstile widgets from their secret-free listings, Notifications destinations and policies, buckets per\n  jurisdiction and their custom domains, objects with their bytes and headers, in-progress uploads and their parts);\n  the API's calls are sent with the root's token, R2's to the account's own host signed with SigV4 under the root's R2\n  keys (the descriptor's `lanes` strategy). A widget's live secret is not read back; its synthetic secret remains available through the detail API. A person and their memberships are not read back: the root's account token\n  acts as no user. A deploy sends the World's account as the one the root's token reaches (`account`), and a script or\n  version upload with static assets runs Cloudflare's upload protocol again (`performs`, `uploadWithAssets`: the session\n  opened with the manifest the World's session held, the files from the World's blobs with the JWT Cloudflare issues,\n  then the upload with its completion token).\n- **Notifications**: webhook destinations and policies made and listed; the SSL for SaaS Custom Hostnames alert\n  (validation, issuance, deployment, deletion) sent to a policy's webhooks with `cf-webhook-auth`, the destination's\n  secret, as Twenty's guard reads it.\n\n## Doors\n\n- `POST /_twin/users/{email} {password}` (dash.cloudflare.com): a person who can sign in.\n- `POST /_twin/app-credentials`: the application's account and token.\n- `POST /_twin/dns {name, type, value}`: a record published at a DNS host outside Cloudflare (a SaaS customer's own\n  domain, or a registrar's nameservers for a zone), which Cloudflare's checks then see.\n- `GET /_twin/deliveries?to=&type=`: every notification sent, as the receiving server got it.\n- `GET /_twin/hosts`: the hostnames the World routes here: custom domains connected to R2 buckets, Workers Custom\n  Domains and enabled `workers.dev` deployment URLs.\n\n## Not yet\n\n- A Worker's requests: the World's Workers are uploaded and deployed, never run; at a Custom Domain or `workers.dev` URL only the Worker's\n  static assets answer (a request its script would take is refused with 501).\n- A vendor-backed refresh reads a bucket, not its CORS or lifecycle configuration, and a part, not its bytes (no S3\n  operation answers a part's bytes): an observed part completes nothing until it is uploaded again.\n"
+  }
+}

package/content/a37094107a6552d8cb5b49011973a76330b48d392f66a21ec957923c3c0641fd.json

@@ -0,0 +1,27 @@
+{
+  "schemaVersion": 1,
+  "release": {
+    "schemaVersion": 1,
+    "source": "twin-packs-open",
+    "vendor": "resend",
+    "package": "@volter/twin-resend",
+    "version": "1.0.1",
+    "integrity": "sha512-rorxvx2YrMhmwB+bouDvfqY1ykbkWE4BDgjWFD6ZAFLmEwCsxxbcRy+lqGWo3hwQaCRMxdxP+KHn6bnIMlowcA=="
+  },
+  "packageMetadata": {
+    "description": "Local Resend transactional email, delivery events, domains and inbox inspection. Delivery is simulated; no real email is sent.",
+    "license": "Apache-2.0",
+    "engines": {
+      "node": ">=22.3"
+    },
+    "peerDependencies": {
+      "@volter/world-core": "^3.0.64"
+    },
+    "repositoryDirectory": "resend",
+    "bugs": "https://github.com/volter-ai/twin-packs-open/issues"
+  },
+  "readme": {
+    "path": "package/README.md",
+    "markdown": "# @volter/twin-resend\n\nA local Resend. Its API (`api.resend.com`) serves the calls Dub, Twenty, Postiz and Volter World's platform make: emails\nsent singly and in batches and listed, sending domains (created, read, listed, updated, verified, removed), and received\nemails and their list. Resend's webhooks go to a team's\nendpoints, signed as svix signs them. The inbound CDN (`inbound-cdn.resend.com`) serves a received email's raw message.\n\n## Use with an existing app\n\nIn an app that already uses this vendor, install this exact release and the product CLI:\n\n```console\nnpm install --save-dev --save-exact @volter/world@3.0.67 @volter/twin-resend@1.0.1\nnpx volter world init --name my-app --twins resend --source resend=@volter/twin-resend\n```\n\nReview the detected vendor and generated bindings before booting. Read the credential names and limitations below; the World supplies throwaway credentials. Then run your app's own command through the World:\n\n```console\nnpx volter world up\nnpx volter world run -- npm test\nnpx volter world log\nnpx volter world down\n```\n\nHere `npm test` is your app's existing command; replace it with your app or test command. `down` retains state.\nA later `up` resumes it; do not reset or initialize again merely to return.\n\nPublisher and catalog contribution instructions: [the public publisher guide](https://github.com/volter-ai/twin-catalog-open/blob/main/docs/contributing.md).\n\n\nA Protocol 3 pack ([publisher guide](https://github.com/volter-ai/twin-catalog-open/blob/main/docs/contributing.md)). Its surface is generated\nfrom Resend's OpenAPI document (`spec/`). Handlers\nare in `src/semantics/<family>.ts`, the key front in `src/semantics/around.ts`, the lifecycle in\n`src/semantics/clock.ts`, and state machines in `src/semantics/states.ts`.\n\n```bash\nworld-resend serve [--port N] [--root DIR] [--read-only]\n```\n\n## What it models\n\n- **Keys**:\n  - A key is made on the API Keys page (a door) and held by its SHA-256.\n  - A request with none is `401 missing_api_key`, an unknown one `400`, and a deleted one `403 restricted_api_key`.\n  - Everything a key does is its team's.\n- **Sending**:\n  - `from`, `to` (at most 50), `subject` and a body are required.\n  - The sender must be at a verified domain of the team, or at `resend.dev` sending only to the team owner's address.\n  - A batch of up to 100 is checked whole before any is sent.\n  - Attachment bytes are held in blobs and retained for inbox observation. Dub's ISO scheduled sends wait until their requested time before following the ordinary delivery lifecycle.\n- **An email's life**: `queued`, then `sent` at once. Five seconds later it is `delivered`, or `bounced` when a\n  recipient's server refuses its domain's mail (a door). A recipient may then open it (on a domain with open tracking)\n  or mark it as spam (doors).\n- **Domains**:\n  - Each has its DKIM, SPF MX and TXT, Tracking and Receiving records.\n  - Verifying makes it pending. It is verified ten minutes after the later of the verify and its last record at the\n    owner's DNS host (a door), or failed after 72 hours without them.\n  - Updated: open and click tracking, TLS, the tracking subdomain and capabilities.\n- **Receiving**: mail to a verified receiving domain (a door) is a received email, with attachment metadata and bytes retained, read with its pre-signed raw\n  download URL, which lasts an hour.\n- **Webhooks**:\n  - Sent for `email.sent`, `email.delivered`, `email.bounced`, `email.opened`, `email.complained` and `email.received`.\n  - Each goes to the team's endpoints that subscribe to it, signed with `svix-id`, `svix-timestamp` and\n    `svix-signature`.\n\n## Doors\n\n- `POST /_twin/api-keys {name, team, owner}` and `DELETE /_twin/api-keys/{id}`: the API Keys page.\n- `POST /_twin/webhooks {team, endpoint, events}`: the Webhooks page; answers the signing secret.\n- `POST /_twin/dns {name, type, value}`: a record at the owner's DNS host. Supply its fully qualified name: for a domain `example.com`, returned `send` means `send.example.com` and `resend._domainkey` means `resend._domainkey.example.com`; use the returned value unchanged.\n- `POST /_twin/recipients/{domain} {rejects}`: an outside server that refuses mail.\n- `POST /_twin/mail/{email_id}/open` and `/complain` `{to}`: a recipient's act.\n- `POST /_twin/inbound {from, to, subject, text?, html?, inReplyTo?, headers?, received_for?, authentication?, attachments?}`: mail from outside to a receiving domain.\n- `GET /_twin/mail?to=`: an inbox.\n- `GET /_twin/deliveries?to=[&type=][&email=]`: the webhooks sent.\n\n## Not yet\n\nBroadcasts, segments, topics, templates,  suppressions, audiences and contacts, the API\nKeys and Webhooks APIs and contact properties: no application here calls them.\n\n## Vendor-backed\n\nLists are newest first, paged by `limit`, `after` and `before`. A refresh reads sent emails, received emails and domains back from their\nlists and detail operations; Resend's signed email events are ingested (each folded into its email by `email_id`, its type the email's\n`last_event`); calls are charged within a fixed allowance of 120 per minute, below the documented 600 per minute.\n"
+  }
+}

package/content/d66776b9b0d4c8b19b09a012f455f5b6697b39fc2205b2bb64e7a3855e734e84.json

@@ -0,0 +1,27 @@
+{
+  "schemaVersion": 1,
+  "release": {
+    "schemaVersion": 1,
+    "source": "twin-packs-open",
+    "vendor": "linear",
+    "package": "@volter/twin-linear",
+    "version": "3.0.4",
+    "integrity": "sha512-OHqIROUZYb5mlceMPRrjDNpycvRahII+2xh/B461bUREXFY7pKszUy3AwlQmAG+0bdYb3qFWf5JmRYhJn1uavw=="
+  },
+  "packageMetadata": {
+    "description": "Protocol 3 Linear twin for the official SDK viewer, team and issue workflow and the documented issue-filing integration.",
+    "license": "Apache-2.0",
+    "engines": {
+      "node": ">=22.3"
+    },
+    "peerDependencies": {
+      "@volter/world-core": "^3.0.105"
+    },
+    "repositoryDirectory": "linear",
+    "bugs": null
+  },
+  "readme": {
+    "path": "package/README.md",
+    "markdown": "# @volter/twin-linear\n\nA Protocol 3 Linear twin for a workspace’s issue-filing integration and the Linear SDK\ninstalled by Twin ([demand](./journeys/demand.json)). It serves Linear’s GraphQL endpoint,\nOAuth authorization-code installation, token refresh and configured client-credentials grants,\nworkspace/team/project discovery,\nworkflow states, issue creation/update/archive, labels and comments. The customer life and\npublished-example journey define the modeled scope ([decisions](./journeys/decisions.json)).\n\nResources are read back with declared GraphQL refresh queries, including archived issues.\nMutation deployment uses the vendored schema to adopt the resource returned by Linear.\nRefresh-token retries preserve the returned pair during Linear’s documented 30-minute grace.\nThe executor budget stays below the documented API-key request quota.\n\nThe World’s doors represent settings/UI actions Linear’s API does not expose:\n`POST /_twin/workspaces`, `POST /_twin/workspaces/{urlKey}/people`,\n`POST /_twin/app-credentials` and `POST /_twin/api-keys`. The local credential door\n`POST /_twin/local-credentials` uses those same settings actions to make an idempotent synthetic\nstarter workspace/owner, issue its personal key and register a World OAuth client. It supplies\n`LINEAR_API_KEY`, `LINEAR_CLIENT_ID` and `LINEAR_CLIENT_SECRET`; the personal key names a stored\nowner and is retained across stop/resume. Teams and projects are created through the\nvendor API. The authorize screen uses the registered callback and carries its state back.\n\nThe published relation, logical, date, label, comment, estimate and project-lead filters are served.\nOther GraphQL fields, private-team access management, webhook configuration, PKCE and OAuth\nrevocation are outside this modeled scope and are refused. The SDK’s default\nviewer, team and issue selections are modeled for the official SDK 86.0.0's create/update/read flow\nin [the installed customer entry](./journeys/first-use.json). This does not claim every SDK method.\nNo webhook subscription is made by this life;\nthere is no invented webhook delivery. Release assessments are retained by\n[the independent catalog](https://github.com/volter-ai/twin-catalog-open).\n\nInstall the selected release in your app with `npm install --save-dev @volter/twin-linear@3.0.3`.\nThe app keeps its real `@linear/sdk`; the packaged customer entry pins 86.0.0.\nFor local setup, use the app folder’s `volter world init`, review the detected vendors,\nand keep Linear when the app needs it. Start with `volter world up`, run the app or seed\nthrough `volter world run -- <command>`, and stop with `volter world down`. The World’s\n`GET /twin` describes identity, time, and the available doors.\n\nThe workspace door takes `{ \"name\": \"Example\", \"urlKey\": \"example\", \"owner\": { \"name\": \"Ada\", \"email\": \"ada@example.invalid\", \"password\": \"example-password\" } }`.\nThe people door takes `{ \"name\", \"email\", \"password\" }`; the key door takes `{ \"email\", \"label\" }`.\nThe app door takes `{ \"name\", \"redirect_uris\": [\"https://app.example/callback\"] }`;\nits optional `client_credentials: { workspace: \"example\", teamIds: [...] }` represents\nthe settings toggle and the app user’s configured team access. All credentials are synthetic.\n\nProfiles, public-team settings, empty optional-feature state, issue relations and counts are stored\nin their vendor response shapes and preserved by the declared refresh queries. `isMe` is resolved\nfor the current caller. Creator counts include archived issues; team counts exclude them unless\n`includeArchived: true` is requested. The kernel maintains these counters on recorded writes.\nThe starter leaves cycles, triage, integrations, sharing and automation unconfigured. Its inactive\nnumeric settings, avatar colors, invitation hashes, app actor email addresses and branch naming are\nexplicitly synthetic choices where upstream documentation does not declare production defaults.\nMutations for those additional features remain outside scope; absent feature state does not claim\nthat their behavior is implemented.\n"
+  }
+}

package/content/fa756dfc21662a70679a660dd88fcb2b4f8bad30f408f1134cd87b0668289fc6.json

@@ -0,0 +1,27 @@
+{
+  "schemaVersion": 1,
+  "release": {
+    "schemaVersion": 1,
+    "source": "twin-packs-open",
+    "vendor": "clerk",
+    "package": "@volter/twin-clerk",
+    "version": "1.0.2",
+    "integrity": "sha512-3HZEt5czGpF/wEWcoDk+1/2Ln6J4Tg00kqFbgWTJ6VP8th5myZ1c9x2QowBmFcSdmdp0U00HMMxD7VJ4ucSkxw=="
+  },
+  "packageMetadata": {
+    "description": "Local Clerk twin — a faithful, stateful local Clerk Backend API your real `@clerk/backend` SDK talks to unmodified. Users, sessions, orgs, real signed JWTs + a JWKS endpoint. Mirror, simulate, and fork. Built on @volter/world-core.",
+    "license": "Apache-2.0",
+    "engines": {
+      "node": ">=22.3"
+    },
+    "peerDependencies": {
+      "@volter/world-core": "^3.0.96"
+    },
+    "repositoryDirectory": "clerk",
+    "bugs": null
+  },
+  "readme": {
+    "path": "package/README.md",
+    "markdown": "# @volter/twin-clerk\n\nA local Clerk instance: the **Backend API** an application's server calls (`@clerk/backend`, unmodified, at\n`https://api.clerk.com/v1`) and the **Frontend API** the unmodified `@clerk/clerk-js` bundle calls from the browser (the\ninstance's own host, `twin.clerk.accounts.dev`), over one state. A user made through the Backend API signs in through\nclerk-js; a session clerk-js starts is one the Backend API lists and mints tokens for.\n\nThe Frontend API also answers at `frontend-api.clerk.dev`, the destination of Clerk’s documented same-site proxy and vgauth’s Worker. That host routes directly to the Frontend API lane, with the same instance state and browser credentials.\n\nA Protocol 3 derived pack ([publisher guide](https://github.com/volter-ai/twin-catalog-open/blob/main/docs/contributing.md), \"Protocol 3\" and \"Creating a\npack\"): the surface is generated from Clerk's published OpenAPI documents (`spec/`, `fapi/spec/`), plain reads, writes\nand deletes are the derived core's, the state machines are `src/semantics/states.ts`, and handlers by operationId\n(`src/semantics/<family>.ts`) serve only what an operation does beyond them. Every other operation answers Clerk's own\n404. The immutable catalog assessment records the declared surface, measured journeys and remaining gaps.\n\n```bash\nworld-clerk serve [--port N] [--root DIR] [--read-only]\n```\n\nA World makes its people through the Backend API's own `POST /users`. Nothing is signed in.\n\n## What it models\n\n- **Backend API**: users (made, updated, their metadata merged or replaced, listed and counted with Clerk's filters,\n  deleted), sessions (made for a test, listed, revoked, their tokens), sign-in tokens (made,\n  revoked, used once by the Frontend API), an instance's organization settings (Organizations are off until\n  turned on, as on a new Clerk instance), custom permissions and roles beside the system ones, organizations with\n  their memberships and invitations, JWT templates, SAML enterprise configuration and the instance's public keys.\n- **Frontend API** (what clerk-js needs to boot and what the applications measured drive through it): the environment,\n  the dev browser, the client and its `__client` cookie, sign-up by email and password (the address verified by an\n  emailed code) and by an invitation's ticket, sign-in by password, by an emailed code and by ticket, sessions (touched,\n  read and their tokens), an\n  invitation's link, and `/.well-known/jwks.json`. Clerk's published clerk-js bundle (5.127.2,\n  `vendor/clerk-js/`, with its SOURCE.md) is served as published at the `/npm/@clerk/clerk-js` loader path.\n- **Webhooks**: user.deleted, Svix-signed, to the instance's webhook endpoints. The payload includes timestamp, instance_id, request event_attributes and the deleted user's external_id. Each delivery is recorded; the Dashboard endpoint is set through `POST /_twin/webhook-endpoints`.\n\nThe OAuth identity-provider flow serves the account worker used by Volter Editor: authorization redirects to sign-in and explicit consent, then a registered callback receives a single-use code bound to S256 PKCE. The worker exchanges it at `/oauth/token`; refresh grants retain the user and selected organization. Access tokens use the `at+jwt` header type Clerk's SDK expects; OpenID Connect ID tokens use `JWT`. Register the public OAuth application with `POST /v1/oauth_applications` before using it. Codes expire after ten minutes, access and ID tokens after one day, and refresh tokens after ten years in the pinned Frontend API spec.\n\nThe Frontend API accepts the documented `clerk.<application domain>` host family and `frontend-api.clerk.dev`; proxy calls require a held instance secret key in `Clerk-Secret-Key`, the full `Clerk-Proxy-Url`, and `X-Forwarded-For`.\n\nOrganization settings are stored as the Backend API's `OrganizationSettings` singleton and read back through `GET /v1/instance/organization_settings`; the Frontend environment renders its domain fields in the Frontend shape. Dashboard-only sign-in configuration remains private bookkeeping. Memberships retain the Backend API's `public_user_data.user_id` reference, including after refresh. The known-resource scopes read JWT templates, enterprise connections and their SAML children without promising enumeration for those types.\n\n## Keys\n\nThe Backend API takes only the keys the instance holds: the application's, which the World issues when it boots\n(`POST /_twin/app-credentials`, the descriptor's credential door, with the publishable key, the `CLERK_JWT_KEY` a\nbackend verifies session tokens with and the webhook signing secret), and every key the API Keys page's door made. No\n`Authorization` header is Clerk's 401 `authorization_header_format_invalid`, and any other key, whatever its shape, is\nits 401 `clerk_key_invalid`. A request with no secret key is never the Backend API's: on a Frontend API path it is the\nbrowser's, answered by the Frontend API.\n\n**Each World signs with its own key.** Session tokens, the tokens of JWT templates without a key of their own, and\ninvitation tickets are signed with an RSA key the World makes once at random (`ctx.signingKey`), served as the\ninstance's JWKS, so a token verifies only against the World that issued it and no one can mint one from this package.\nA template with its own signing key signs with that key, in its algorithm (RSA or HMAC, SHA-256 to 512; others are\nrefused).\n\n## Doors\n\nThe World's hands on the instance, standing in for the Clerk Dashboard (`src/semantics/doors.ts`); the `POST` doors are\nrefused on a read-only twin:\n\n- `POST /_twin/secret-keys {name}`: a secret key, as the API Keys page shows it once (`sk_test_…` on a development\n  instance); the twin keeps its hash.\n- `POST /_twin/webhook-endpoints {url, events, signing_secret?}`: a webhook endpoint and its `whsec_…` signing secret\n  (the one given, when the World's application already holds one).\n- `POST /_twin/instance {…}`: the instance's sign-up settings (password on or off, legal consent, organization\n  membership optional or required, the Frontend API host, the Native API on or off).\n- `POST /_twin/native-applications {platform, …}`: an iOS app (`app_id_prefix`, `bundle_id`) or Android app\n  (`package_name`) registered on the Native applications page. A native client's request (`_is_native=true`, its client\n  token in `Authorization`) is Clerk's 400 `native_api_disabled` until the Native API is on.\n- `GET /_twin/emails?to=<address>`: what Clerk sent an address (verification codes, invitations), oldest first.\n- `GET /_twin/webhook-messages?type=<event>`: what was delivered to the webhook endpoints, oldest first.\n\n## Not modelled\n\nOAuth device authorization, token exchange, dynamic registration, userinfo and revocation; SSO sign-in (an enterprise connection is configured, never signed in through) and passkeys; multi-factor authentication; phone numbers; application-invitation acceptance and revocation,\nallowlist and blocklist, actor tokens, redirect URLs, domains, OAuth application updates and deletion, and the webhook\nendpoints API; uploaded logos and profile images; standalone SAML mutations and enumeration (known connections are readable), permission/role deletion, UserProfile and client session removal, and every Frontend API route clerk-js's organization components drive. Each\nanswers the gap, never a fabricated success.\n\nThe first-party account broker’s production share invitation calls Backend API `CreateInvitation`; the companion stores that application invitation, sends its ticket to the modeled recipient inbox, and exposes `ListInvitations` for read-back. These operations honor notification, metadata, expiration and duplicate handling. Application-invitation acceptance, revocation and bulk creation remain separate gaps.\n"
+  }
+}

package/docs/operations.md

@@ -61,6 +61,17 @@ Untrusted-account submissions need genuine current-head non-author human moderat
 
 ## Recover index publication
 
+To retain workflow documentation for recorded releases, run the data-only capture in a catalog checkout:
+
+```sh
+node bin/twin-catalog.mjs capture-content
+```
+
+It reads immutable tarballs at their recorded integrity and writes `content/<release-id>.json`.
+Existing receipts are reused. Commit them through the maintainer maintenance path before publishing;
+this neither assesses a candidate nor changes an admission record. The publisher includes the receipts
+in the index and binds their hashes to its snapshot. A missing README remains missing.
+
 Retry current protected main after resolving the recorded cause:
 
 ```sh

package/docs/process.md

@@ -52,6 +52,16 @@ The JSON-only reader also projects installed customer scope, pinned SDK dependen
 Historical assessments without these retained fields show them as unavailable; current registry metadata does not
 fill missing historical evidence. A provenance link establishes source and build identity, not vendor fidelity.
 
+Maintainers can retain release documentation with `twin-catalog capture-content`. This reads each recorded
+package/version's tarball from the policy registry, verifies its recorded SHA-512 integrity, and captures its
+manifest listing facts and README as data in `content/`. It never installs, imports or executes a pack. The
+published snapshot binds those receipts by SHA-256; its reader checks both the receipt and release identity.
+Consumers can display that version's README without fetching a publisher's current branch. Missing README
+content stays unavailable. Artifact facts can supply older listings, but never supply missing assessment,
+customer, browser or provenance evidence. Capture is an explicit maintenance action, not a test trigger.
+New assessments retain the same README from the already unpacked artifact during preparation; the reader can
+use that existing checksum-bound report directly. No additional assessment or documentation workflow runs.
+
 Publishers describe useful workflows, setup and throwaway credential requirements, companion services, supported
 SDK/API versions and explicit limitations in the package README. Model replies, simulated email/search and partial
 interfaces are labeled. Declared gaps remain in the coverage denominator. No publisher badge or aggregate grade