@volter/twin-catalog 0.2.39 → 0.2.41

package/README.md

@@ -63,6 +63,10 @@ node bin/twin-catalog.mjs build --out /tmp/new-catalog-output
 The build requires committed admission records and a new output directory. It generates data without importing packs.
 The website and hosted runtime consume this artifact independently; publishing it does not deploy either.
 
+Maintainers use `node bin/twin-catalog.mjs capture-content` to retain the exact artifacts' manifests and READMEs
+in a maintenance change. The distributed reader exposes them as release documentation, separate from assessment
+measurements. See [release information](docs/process.md#release-information-for-users).
+
 For discovery, use the JSON-only reader against an installed index:
 
 ```sh

package/bin/twin-catalog.mjs

@@ -11,6 +11,7 @@ import { persistEvidence } from '../lib/evidence.mjs';
 import { propose } from '../lib/propose.mjs';
 import { browse } from '../lib/browse.mjs';
 import { register } from '../lib/register.mjs';
+import { captureContent } from '../lib/content.mjs';
 
 const [command, ...args] = process.argv.slice(2);
 const arg = (name, fallback) => { const at = args.indexOf(`--${name}`); if (at < 0) return fallback; requireThat(args[at + 1] && !args[at + 1].startsWith('--'), `--${name} needs a value`); return args[at + 1]; };
@@ -63,6 +64,7 @@ try {
       break;
     }
     case 'build': result = build(root, resolve(arg('out', 'dist'))); break;
+    case 'capture-content': result = await captureContent(root, builtIndex(root), policy().registry); break;
     case 'publish': {
       const client = github();
       const policyClient = process.env.CATALOG_READ_TOKEN ? new GitHub(client.repository, process.env.CATALOG_READ_TOKEN) : client;
@@ -73,7 +75,7 @@ try {
       result = await publish(output, policy().registry);
       break;
     }
-    default: throw new Error('usage: twin-catalog register --source <id> --source-repository <owner/repo> --scope <@scope> [--out <sources.json>] | submit --source <id> --vendor <vendor> --package <@scope/name> --version <exact> | browse [--root <installed-index>] [--vendor <vendor>] [--package <@scope/name>] | assess-pr --pr <number> | check | defaults | build --out <new-directory> | publish | configure [--apply] | propose --from <submission-directory> --send');
+    default: throw new Error('usage: twin-catalog register --source <id> --source-repository <owner/repo> --scope <@scope> [--out <sources.json>] | submit --source <id> --vendor <vendor> --package <@scope/name> --version <exact> | browse [--root <installed-index>] [--vendor <vendor>] [--package <@scope/name>] | capture-content | assess-pr --pr <number> | check | defaults | build --out <new-directory> | publish | configure [--apply] | propose --from <submission-directory> --send');
   }
   console.log(JSON.stringify(result, null, 2));
 } catch (error) { console.error(`twin-catalog: ${error.message ?? error}`); process.exitCode = 1; }

package/catalog.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 1,
-  "sourceCommit": "8cc7194bdc4e9bb5c481d862684ebf5f7e75a7ba",
-  "digest": "b24bd5b8f97b7054833cb45fd84ed20361a08eff401aaf0c04b3fd89fda3d945",
+  "sourceCommit": "a4c5e0664985a7f5a173b58cd307b88a7ddd2795",
+  "digest": "5103e721dd9632a05ec4d5348d1b9e668ee092b3edf634c0e4b08f08efb76527",
   "versions": [
     {
       "vendor": "tavily",
@@ -53,6 +53,31 @@
       },
       "assessed": true
     },
+    {
+      "vendor": "slack",
+      "package": "@volter/twin-slack",
+      "source": "twin-packs-open",
+      "version": "3.0.5",
+      "status": "live",
+      "integrity": "sha512-P8jzf8Ss3MsXG+bc+uX9QBfYu4R74tmHgeOuSyJ8WjrsfvbJzBGZHQPGV50qUDTHD6vuh17bDqTaTsesK58aZw==",
+      "submission": "1fa7500b80e0c420b91e602419e1185bb2b2871c338e74eb7d5d20845e167e3c",
+      "commit": "6c08177e4ef0c57c56b5b614f2260ab86d40e065",
+      "at": "2026-10-07T17:40:47Z",
+      "by": "moderated-merge",
+      "evidence": {
+        "submission": "1fa7500b80e0c420b91e602419e1185bb2b2871c338e74eb7d5d20845e167e3c",
+        "admissionCommit": "6c08177e4ef0c57c56b5b614f2260ab86d40e065",
+        "pullRequest": 40,
+        "url": "https://github.com/volter-ai/twin-catalog-open/releases/tag/evidence-1fa7500b80e0c420b91e602419e1185bb2b2871c338e74eb7d5d20845e167e3c-d94ccd13d2b147887bb72c3b4bddc2c05917582a2be3e2b7d29908ec264fb0ec",
+        "reportSha256": "d94ccd13d2b147887bb72c3b4bddc2c05917582a2be3e2b7d29908ec264fb0ec",
+        "reportPath": "evidence/1fa7500b80e0c420b91e602419e1185bb2b2871c338e74eb7d5d20845e167e3c.json",
+        "moderation": {
+          "mode": "internal-maintainer-merge",
+          "mergedBy": "yueranyuan"
+        }
+      },
+      "assessed": true
+    },
     {
       "vendor": "slack",
       "package": "@volter/twin-slack",
@@ -378,5 +403,71 @@
       },
       "assessed": true
     }
-  ]
+  ],
+  "content": {
+    "100cf4069352dee18bcb1f8ef9198c637ce1842d42f66477a6a62702c24f9f13": {
+      "path": "content/100cf4069352dee18bcb1f8ef9198c637ce1842d42f66477a6a62702c24f9f13.json",
+      "sha256": "0a28646b4c4e9f7ce2d83cee9e1374954bf5407fc92f1fb6f7f50838ca331e5d"
+    },
+    "1f197a74b85508b9af3089c0a8807580b479c90f5ad38d1cb0413d7ef4b06861": {
+      "path": "content/1f197a74b85508b9af3089c0a8807580b479c90f5ad38d1cb0413d7ef4b06861.json",
+      "sha256": "d4580f49ef0fa050b3cb9b0f074e485ec35b53155ce932bd495916bb5196ec04"
+    },
+    "1fa7500b80e0c420b91e602419e1185bb2b2871c338e74eb7d5d20845e167e3c": {
+      "path": "content/1fa7500b80e0c420b91e602419e1185bb2b2871c338e74eb7d5d20845e167e3c.json",
+      "sha256": "36fe599b2d4ef0b664e5a17fe73dde972843c8f7cd64772c2fa23fb63bb5b885"
+    },
+    "298a3364ab17a8b5c8b07b21d7ff83c9402108bccabc6287ced0431890c7eda9": {
+      "path": "content/298a3364ab17a8b5c8b07b21d7ff83c9402108bccabc6287ced0431890c7eda9.json",
+      "sha256": "78e6efd8b0f164441f56367901ab4e371fe0dd830cc5725368f694d7965236a0"
+    },
+    "32255ffe1d7c2e67218d1a05799128096033136f9d4963b0d55fcb8b71c09e89": {
+      "path": "content/32255ffe1d7c2e67218d1a05799128096033136f9d4963b0d55fcb8b71c09e89.json",
+      "sha256": "fb0285fee0dbc55de661f355baf7b7bff9476ca78774e2d9b0c30a8fba8e0c86"
+    },
+    "2c123aa480c3d787e21218b005870509fe48379ba534df5a2eed8d2db5956596": {
+      "path": "content/2c123aa480c3d787e21218b005870509fe48379ba534df5a2eed8d2db5956596.json",
+      "sha256": "26748a27ddf964f25736515bb262a61eeaa78839ed9694a74fe687aa70b7555f"
+    },
+    "2f905a18997aea40b709c4d4ea7adce45d4b080cf2216353d09b0cb6a910c3f7": {
+      "path": "content/2f905a18997aea40b709c4d4ea7adce45d4b080cf2216353d09b0cb6a910c3f7.json",
+      "sha256": "77a9116b10b6e3c1581e04d790fa9a5fbc161870bef9ccea2eb87e772bf9f9a6"
+    },
+    "4edaec8cd2e55c04f66245309742a63c36f102320ef221927ff93d97b3b268b9": {
+      "path": "content/4edaec8cd2e55c04f66245309742a63c36f102320ef221927ff93d97b3b268b9.json",
+      "sha256": "e1fd483c0fd2ff0dda4a399adeaa5691d106e034d18544c0624ce094ac3cc4af"
+    },
+    "66285aa1b8bccb8fe943294975108f303bc51ee310c33633d7454afa631e913b": {
+      "path": "content/66285aa1b8bccb8fe943294975108f303bc51ee310c33633d7454afa631e913b.json",
+      "sha256": "bfb8d61110d948197d89218f38bb6a5f38f3a7c140ac61de77132016d16a9bf1"
+    },
+    "5eeaa5e7c2a08c8c0818489c40e7b818c114bd74f5c1b8186e0de69f8792049c": {
+      "path": "content/5eeaa5e7c2a08c8c0818489c40e7b818c114bd74f5c1b8186e0de69f8792049c.json",
+      "sha256": "08a5ac8f9d52cd2780b9833837cb87e63e3bdd394891196ad2a808011b2378be"
+    },
+    "d66776b9b0d4c8b19b09a012f455f5b6697b39fc2205b2bb64e7a3855e734e84": {
+      "path": "content/d66776b9b0d4c8b19b09a012f455f5b6697b39fc2205b2bb64e7a3855e734e84.json",
+      "sha256": "5f8815c56807a3e2965b499923b5fcec12fc697b074b4c96c3ba23f5c2886f72"
+    },
+    "6f9f4c4659dc8d86e42363050c0ee444e4f1e05409866bf4ee3b54d12a3c2cc2": {
+      "path": "content/6f9f4c4659dc8d86e42363050c0ee444e4f1e05409866bf4ee3b54d12a3c2cc2.json",
+      "sha256": "074d17670ee8aca87995d7f3b0be7f59889b9bd85a39cf12a2705df41c92ea9c"
+    },
+    "871d902e2c0d3e14a5a9c90fca585f47f5e0989442abe099ec185b5541c54e14": {
+      "path": "content/871d902e2c0d3e14a5a9c90fca585f47f5e0989442abe099ec185b5541c54e14.json",
+      "sha256": "992429eb3a85b381fa1b10691bcdc6f432e5d0dc4104dc01f3c39b27462af809"
+    },
+    "8c35ee3b7e5272a335eccc4e2527b8135eebaeee75c1aab1f874f520fe97de71": {
+      "path": "content/8c35ee3b7e5272a335eccc4e2527b8135eebaeee75c1aab1f874f520fe97de71.json",
+      "sha256": "73757b2d430bc03a0061b66c30a4c0aab004fe7b45b6b0fa7f0ba8f789cefc76"
+    },
+    "a37094107a6552d8cb5b49011973a76330b48d392f66a21ec957923c3c0641fd": {
+      "path": "content/a37094107a6552d8cb5b49011973a76330b48d392f66a21ec957923c3c0641fd.json",
+      "sha256": "d3b5649170d0209717e45b880dad7269b67351737ee3247bc0fd2a34dcf8aea5"
+    },
+    "fa756dfc21662a70679a660dd88fcb2b4f8bad30f408f1134cd87b0668289fc6": {
+      "path": "content/fa756dfc21662a70679a660dd88fcb2b4f8bad30f408f1134cd87b0668289fc6.json",
+      "sha256": "b62cbb2e36a4602b19a99fa6e03cb421850ed6b32012084da61b6b412880ad6e"
+    }
+  }
 }

package/content/100cf4069352dee18bcb1f8ef9198c637ce1842d42f66477a6a62702c24f9f13.json

@@ -0,0 +1,27 @@
+{
+  "schemaVersion": 1,
+  "release": {
+    "schemaVersion": 1,
+    "source": "twin-packs-open",
+    "vendor": "tavily",
+    "package": "@volter/twin-tavily",
+    "version": "1.0.1",
+    "integrity": "sha512-ABLgHRXQAk3LjrdP5bWBXhS4WW+w5/KyuL9UrPREgJc+nhE/Sd8bR+EZha0qaFFzaQIHqfuo9yPlxA/O3fMqlQ=="
+  },
+  "packageMetadata": {
+    "description": "Tavily twin (Protocol 3): search over the World's web by lexical overlap, with a labeled stub answer (no web is searched, no model runs), and API keys. Built on @volter/world-core.",
+    "license": "Apache-2.0",
+    "engines": {
+      "node": ">=22.3"
+    },
+    "peerDependencies": {
+      "@volter/world-core": "^3.0.59"
+    },
+    "repositoryDirectory": "tavily",
+    "bugs": null
+  },
+  "readme": {
+    "path": "package/README.md",
+    "markdown": "# @volter/twin-tavily\n\nTavily Search (`POST /search`) and Extract (`POST /extract`) at `api.tavily.com`, for Postiz's shipped post-generator research and LibreChat's agent tools. Postiz's deployment key authorizes that feature; its caller is recorded in [demand.json](./journeys/demand.json). LibreChat users select and authenticate Tavily extraction in the in-app scraper key dialog; the exact caller commits are in [demand.json](./journeys/demand.json).\n\nThe World supplies a synthetic web corpus. Search ranks its pages by lexical overlap, with topic, domain restriction/preference, date, country, language, exact-phrase and safety options. It returns requested chunks, Markdown/text raw content, images/descriptions, favicon, publication date and usage. Answer and automatic-parameter judgment are scripted by the World or labeled deterministic stubs; no model or live web search runs. Advanced depth changes documented credit usage, and ultra-fast uses the corpus's supplied summary.\n\nExtract reads held corpus pages or a source the World routes through `ctx.vendorFetch`, including the application's own pages. An unregistered, failing or simulated slow source becomes a per-URL failure. Depth selects supplied advanced content; query/chunk limits, Markdown/text, images, favicon and timeout options apply to each URL. Credit accounting follows successful extractions, in groups of five per depth.\n\nAuthentication accepts the World-issued key in `Authorization: Bearer` or `api_key` in the body. The key is held by its hash and regenerated from the World's secret. No real credentials are needed.\n\nThe doors are:\n\n- `POST /_twin/app-credentials {}`: the dashboard's first key, returned identically on subsequent boots and wired to `TAVILY_API_KEY`.\n- `POST /_twin/pages {url, title, content, ...}`: a synthetic source page; the same URL replaces its record. Optional fields are `raw_content`, `text_content`, `advanced_content`, `summary`, `images` (URLs or `{url, description}` objects), `favicon`, `topic`, `published_date`, `country`, `language` (an ISO code), `unsafe` and `fetch_seconds`. These supply facts about a source that Tavily's API cannot create.\n\nThe World scenario supports `operationEquals` and `queryEquals`, status faults in Tavily's envelope, and search judgment `{parameters: {topic?, search_depth?}, answer?}`. Explicit input overrides automatic judgment; size options stay explicit. Source pages and their metadata are supplied through the door.\n\nCrawl, Map, Research, Feedback, Usage and Logs answer the gap: no measured caller, life act or refresh brings them into scope. This compute API has no vendor-backed deployment/refresh half; keys, corpus pages, request ids and extraction counts are private World bookkeeping. Real semantic ranking, crawling, model answers and billing are outside this deterministic corpus.\n\n[The life](./journeys/customer-life.json), [published examples](./journeys/vendor-examples.json), [coverage](./journeys/coverage.json) and [score](./journeys/score.json) retain their measured results. SDK cases are not owed by the measured clients: LibreChat uses raw fetch/axios for both operations, without the official `@tavily/core` SDK.\n"
+  }
+}

package/content/1f197a74b85508b9af3089c0a8807580b479c90f5ad38d1cb0413d7ef4b06861.json

@@ -0,0 +1,27 @@
+{
+  "schemaVersion": 1,
+  "release": {
+    "schemaVersion": 1,
+    "source": "twin-packs-open",
+    "vendor": "stripe",
+    "package": "@volter/twin-stripe",
+    "version": "3.0.2",
+    "integrity": "sha512-5fkYOftyC6qC6kuO/q1VhXVjxHx0HIuiX0dtZj3BaE+L1UA1VeJvNzq5u/lT/rNSPQSYllfeKYZ4ZtM9GYGgzQ=="
+  },
+  "packageMetadata": {
+    "description": "Local Stripe customer, checkout and billing workflows with synthetic state and the real Stripe SDK. Supported operations and hosted-page limits are documented in the README.",
+    "license": "Apache-2.0",
+    "engines": {
+      "node": ">=22.3"
+    },
+    "peerDependencies": {
+      "@volter/world-core": "^3.0.68"
+    },
+    "repositoryDirectory": "stripe",
+    "bugs": "https://github.com/volter-ai/twin-packs-open/issues"
+  },
+  "readme": {
+    "path": "package/README.md",
+    "markdown": "# @volter/twin-stripe\n\nA local Stripe: the REST API the unmodified `stripe` SDK calls (`https://api.stripe.com/v1`), the hosted pages an\napplication sends a person through, and Stripe.js, over one 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-stripe@3.0.2\nnpx volter world init --name my-app --twins stripe --source stripe=@volter/twin-stripe\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\ngenerated from Stripe's published OpenAPI document (`spec/`). The derived core serves plain reads, writes and deletes.\nHandlers are in `src/semantics/<family>.ts`, the state machines in `src/semantics/states.ts`, and Stripe's own\ncomputation (money and declines, billing, the ledger, the API versions) in `src/engine/`.\n\n```bash\nworld-stripe serve [--port N] [--root DIR] [--read-only]\n```\n\n## What it models\n\nWhat the demand reaches (`journeys/demand.json`: Open Autonomy, Twin, Volter Harness, and the stripe-node applications\nCal.com, Dub, Postiz, Rallly and Twenty, with their frontends' Stripe.js), the life (`journeys/customer-life.json`) and a\nvendor-backed World's refresh; each served operation is decided in `journeys/decisions.json`:\n\n- **Customers**: created, updated, searched, listed by email, deleted; their balance transactions and payment methods,\n  and their active entitlements (read). Balance-transaction writes answer the gap.\n- **Catalog**: products and prices created and listed, prices retrieved, coupons and promotion codes managed. Product search and administrative product/price updates answer the gap.\n- **Checkout Sessions** and the customer portal (sessions and configurations): pay, add a card, pay an open invoice,\n  cancel at the period's end or at once.\n- **Subscriptions**: created (charged at once, trialing, `default_incomplete` or `error_if_incomplete`), updated (items,\n  discounts, a trial ended early or added), searched, canceled; their items, schedules (made, updated, released),\n  renewals on the World clock, and a renewal declined and paid later.\n- **Invoices**: invoice items, drafts, finalize, pay (a draft is finalized on the way), void, delete, lines,\n  previews and their payments. Invoice lines are read in the invoice; the standalone lines endpoint answers the gap.\n- **Intents**: payment and setup intents, confirmed on the server or by Stripe.js with the publishable key and the\n  client secret, through the testing page's cards (declines, 3-D Secure) and test bank accounts (ACH debits that settle,\n  micro-deposit verification asked), a hold confirmed under manual capture and canceled, a bank transfer that waits for\n  funds; payment methods attached and detached; refunds (held for want of balance, with a destination charge's\n  transfer reversed and its application fee refunded); the charges, disputes and Radar reviews the testing page's cards\n  bring.\n- **Apps secret store**; existing Radar value lists and their items (reads and item insertion).\n- **Connect**: Express and Custom accounts, account links (Stripe's hosted onboarding) and login links, transfers (from\n  a charge's funds too), payouts, the balance and its transactions, application fees and their refunds, and Connect\n  OAuth (cal.com's).\n- **Issuing** (Open Autonomy's card rail): cardholders and cards (a card is `inactive` unless its create names a status;\n  its number and CVC drawn from the World and shown only when expanded), activated, frozen and canceled; authorizations\n  asked of the real-time endpoint, approved or declined within the window or decided by Stripe when it ends, and\n  received from the vendor and closed by its transactions. Their published fixtures are recorded notReplayed because authorization creation and capture test helpers remain outside demand.\n- **Webhook endpoints** made through the API, each with its own signing secret; events listed.\n\n**Keys.** The platform's secret and publishable keys, and its webhook secret, are issued by the credential door and\nheld by their SHA-256. A request with no key, or with one Stripe never issued, is refused 401. A connected account's\nOAuth key acts as that account.\n\n**The gap.** Operations outside application demand and the declared refresh reads answer Stripe's unknown-URL 404\n(the manifest's literal `unmodeled` list). This includes administrative catalog updates and deletion, direct\nPaymentMethod creation and attachment, send-invoice, balance-credit writes, test clocks and Issuing test helpers,\ntop-ups, Plans, meter and entitlement-feature setup, Radar-list creation, and separate products such as Terminal,\nTreasury, Tax, Climate, Identity and Financial Connections. Reading an already declared resource for vendor-backed\nrefresh remains served; declaring an unused product does not establish application demand.\n\n**Vendor-backed.** Every stored resource declares its `refresh` (the list that reads it back, under its parent where it\nhas one); Stripe's webhooks are ingested by their `Stripe-Signature` (`type`, `data.object`); calls are charged against\nStripe's documented limit (25 requests a second in a sandbox).\n\n## Events\n\nEvery write Stripe reports sends its event (`payment_intent.succeeded`, `customer.subscription.created`,\n`invoice.paid`, …; a charge sends `charge.succeeded` or `charge.failed`, never an invented `charge.created`), declared as data the kernel renders, stores, signs (`Stripe-Signature: t=…,v1=…`, which the\nSDK's `constructEvent` verifies) and delivers to the account's enabled webhook endpoints whose `enabled_events` take it\n(`*`, `<family>.*` or the type). Each event is rendered in the writing request's API version.\n\n- **Connect**: an event of a connected account (a write made with its `Stripe-Account` header, its own\n  `account.updated`, or a row kept on its books, such as the payout time makes for it) carries the top-level `account`\n  and reaches only endpoints created with `connect=true`; the platform's reach only the others.\n- **Signing secrets in a World**: the credential door issues the application its keys and two signing secrets, its\n  account's (`STRIPE_WEBHOOK_SECRET` and the other names an application reads it by) and its Connect endpoint's\n  (`STRIPE_CONNECT_WEBHOOK_SECRET`), the same on every boot; an endpoint made on the Webhooks page (a door) is signed\n  with the one of its kind. The twin reads no env.\n\n## Screens\n\nStripe's own pages, at their vendor urls (`src/screens/`):\n\n- **Checkout** (`checkout.stripe.com/c/pay/{session}`): the customer pays; the session completes and\n  `checkout.session.completed` fires.\n- **Customer portal** (`billing.stripe.com/p/session/{session}`): cancel or renew a plan, update the card, pay an\n  open invoice.\n- **Connect onboarding** (`connect.stripe.com/setup/…`): an Account Link's hosted onboarding.\n- **Connect OAuth** (`connect.stripe.com/oauth/authorize`, `/oauth/token`, `/oauth/deauthorize`; Standard accounts,\n  docs.stripe.com/connect/oauth-reference). The platform's client_id is `ca_twin_self` in every World (a test\n  client_id; the platform account is `acct_twin_self`), shown on the Dashboard's Connect OAuth settings page in\n  `<code data-testid=\"connect-client-id\">`. OAuth starts off: a runner POSTs that page as a browser does,\n  `oauth_enabled=on&redirect_uris=<one per line>`. The authorize page offers the test-mode **Skip this form** (a new\n  Standard account, connected) and **Deny access**; the token endpoint exchanges a code once, within 5 minutes (a\n  reused code revokes the connection), and refreshes to an equal or lesser scope; after a deauthorization the\n  account's `Stripe-Account` header is refused 403 `account_invalid`. The deprecated `access_token` and\n  `stripe_publishable_key` act as the connected account. Not modelled: connecting an existing Stripe account, the full\n  account application, holding a `read_only` connection to reads.\n- **Stripe.js** (`js.stripe.com/v3/`, `/v3/stripe.js`, `/<release train>/stripe.js`): `redirectToCheckout({ sessionId })`\n  goes to the hosted Checkout page; any other member\n  throws, naming itself.\n- **Dashboard** (`dashboard.stripe.com/settings/public`, `/settings/connect/onboarding-options/oauth`): Public details\n  (the business name Checkout and the portal show) and the Connect OAuth settings.\n\n## Doors\n\nThe World's hands where Stripe's API has no act (`src/semantics/doors.ts`), refused on a read-only twin:\n\n- `POST /_twin/app-credentials`: the platform's keys and webhook secret, as the runtime issues them to a World's\n  applications.\n- `POST /_twin/webhook-endpoints {url, events, connect?}`: an endpoint added on the Dashboard's Webhooks page.\n- `POST /_twin/account {settings?, business_profile?, …}`: the platform's own account settings, as the Dashboard\n  changes them.\n- `POST /_twin/drain`: time's events, sent when a runner drives them (`payout.paid`, `balance.available`).\n\n## Published examples\n\n`journeys/vendor-examples.json` replays Stripe's published examples for the operations the pack serves: the fixtures\nbeside its spec (`spec/fixtures3.json.gz`), and the requests and rules its documentation pages publish\n(`spec/doc-examples.json`: the testing page's cards and test bank accounts, the payment lifecycle's states, and each\nreference page's stated rule). Examples whose preconditions require an unserved setup operation are recorded notReplayed naming that operation and its pinned-spec citation. Served preconditions replay through vendor APIs, including customer balance changes and their immutable ledger entries. Coverage remains missing where no application call or published replay reaches it.\n"
+  }
+}

package/content/1fa7500b80e0c420b91e602419e1185bb2b2871c338e74eb7d5d20845e167e3c.json

@@ -0,0 +1,27 @@
+{
+  "schemaVersion": 1,
+  "release": {
+    "schemaVersion": 1,
+    "source": "twin-packs-open",
+    "vendor": "slack",
+    "package": "@volter/twin-slack",
+    "version": "3.0.5",
+    "integrity": "sha512-P8jzf8Ss3MsXG+bc+uX9QBfYu4R74tmHgeOuSyJ8WjrsfvbJzBGZHQPGV50qUDTHD6vuh17bDqTaTsesK58aZw=="
+  },
+  "packageMetadata": {
+    "description": "Local Slack twin — a faithful, stateful local Slack Web API your real Slack SDKs talk to unmodified, with its OAuth install, pages and incoming webhooks. Built on @volter/world-core.",
+    "license": "Apache-2.0",
+    "engines": {
+      "node": ">=22.3"
+    },
+    "peerDependencies": {
+      "@volter/world-core": "^3.0.127"
+    },
+    "repositoryDirectory": "slack",
+    "bugs": "https://github.com/volter-ai/twin-packs-open/issues"
+  },
+  "readme": {
+    "path": "package/README.md",
+    "markdown": "# @volter/twin-slack\n\nSlack's Web API, workspace invitations and member pages, app configuration and OAuth install pages, incoming\nwebhooks and signed app deliveries. The pinned API and corrections are in spec/; provenance is spec/SOURCE.md.\nThe current product callers, operation decisions and customer story are in journeys/.\n\n## Use with an existing app\n\nIn an app that already uses Slack, install the product CLI and this exact twin release:\n\n```console\nnpm install --save-dev --save-exact @volter/world@3.0.127 @volter/world-core@3.0.127 @volter/twin-slack@3.0.5\nnpx volter world init --name my-app --twins slack --source slack=@volter/twin-slack\n```\n\nReview the detected vendor and bindings before booting. The World issues throwaway bot, Socket Mode and signing\ncredentials using the names listed below. Run the app's own 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\nReplace `npm test` with your app or test command. `down` retains state and a later `up` resumes it.\nPublisher and catalog contribution instructions: [the public publisher guide](https://github.com/volter-ai/twin-catalog-open/blob/main/docs/contributing.md).\n\nThe pack models an ordinary workspace with people, channels, timestamped messages and threads, files, normal workspace\nuser groups, apps and their scoped grants. Its APIs keep Slack's ok/error envelope, cursor paging and caller visibility.\nOAuth codes and grants have their own secrets, expiry and revocation. File bytes use the kernel blob seam. Scheduled\nmessages use the World clock.\nConversation workspace identity uses Slack's `context_team_id`, including channel visibility after vendor refresh\nand shared-World cloning. Existing local rows that carry `team_id` remain readable.\n\nA person creates the workspace at slack.com/get-started and joins through invitation mail and the Join page. Workspace\nadmins manage members and invitation requests at slack.com/admin. Developers configure their app at api.slack.com/apps;\ninstallation uses slack.com/oauth/v2/authorize and oauth.v2.access. Program calls use their own issued tokens; a person's\nsynthetic client session is xoxp-<user-id>. Real credentials are never needed.\nFresh local Worlds seed a synthetic workspace named World with its owner and #general through that signup flow.\nThe default seed is copied into the application's `.volter/seeds/` by init and remains editable there. Use the CLI and core versions pinned above for this release.\n\nWorld doors represent acts the API does not perform: an externally developed distributed app (/_twin/apps), a client\nslash command, Home opening, link share or action (/_twin/client/*), and observation of app deliveries or invitation mail\n(/_twin/deliveries and /_twin/mail). The application's own credentials come from /_twin/app-credentials, which the\nWorld asks at every boot: its own app, installed in its workspace, with a bot token (`SLACK_BOT_TOKEN`), an app-level\nSocket Mode token (`SLACK_APP_TOKEN`) and the app's signing secret. It is subscribed to every event the twin sends (link_shared\naside: it names no unfurl domain) and receives them over Socket Mode (it has no Request URL); its bot holds every scope Slack's methods name. Stored vendor mutations still use the API or vendor pages.\n\nIts callers are journeys/demand.json's: RH2's Slack app and channel bridge, Volter Harness's Slack platform (the Chat\nSDK in Socket Mode), Twin's on-call recipe, Dub's Slack integration and Postiz's Slack channel. Enterprise Grid\nadministration, SCIM provisioning and legacy OAuth are outside the modeled slate. Every Web API operation no demand,\nlife step or refresh reaches answers the gap (unknown_method), files.upload among them. The upload flow is\nfiles.getUploadURLExternal, its returned byte-upload URL and files.completeUploadExternal.\n\nPublishing and catalog process: [the public publisher guide](https://github.com/volter-ai/twin-catalog-open/blob/main/docs/contributing.md). Standing is the Protocol 3 grade and score-pack report, recorded after the whole\nslate is written. No result here asserts that the final walk or independent review has run.\n\nDub priority support can create a channel and send a recipient-specific Slack Connect email invitation. The stored\npending invitation is read through conversations.listConnectInvites with count/cursor pagination and retained in the\nlocal mail outbox. Receiving-workspace acceptance, approval, user-id recipients and join links are outside this\nworkflow; the twin sends no real invitation mail. Targeted invitation responses disclose no shareable URL.\n"
+  }
+}

package/content/298a3364ab17a8b5c8b07b21d7ff83c9402108bccabc6287ced0431890c7eda9.json

@@ -0,0 +1,27 @@
+{
+  "schemaVersion": 1,
+  "release": {
+    "schemaVersion": 1,
+    "source": "twin-packs-open",
+    "vendor": "slack",
+    "package": "@volter/twin-slack",
+    "version": "3.0.4",
+    "integrity": "sha512-cYc12HiTysiGgX1sHXqTUAVe3uPSAFKfTcf761LU3SnqEmnIQmgulnRxeZb1lbTN7GDo30E2spjxqVcUdErvEw=="
+  },
+  "packageMetadata": {
+    "description": "Local Slack twin — a faithful, stateful local Slack Web API your real Slack SDKs talk to unmodified, with its OAuth install, pages and incoming webhooks. Built on @volter/world-core.",
+    "license": "Apache-2.0",
+    "engines": {
+      "node": ">=22.3"
+    },
+    "peerDependencies": {
+      "@volter/world-core": "^3.0.87"
+    },
+    "repositoryDirectory": "slack",
+    "bugs": "https://github.com/volter-ai/twin-packs-open/issues"
+  },
+  "readme": {
+    "path": "package/README.md",
+    "markdown": "# @volter/twin-slack\n\nSlack's Web API, workspace invitations and member pages, app configuration and OAuth install pages, incoming\nwebhooks and signed app deliveries. The pinned API and corrections are in spec/; provenance is spec/SOURCE.md.\nThe current product callers, operation decisions and customer story are in journeys/.\n\n## Use with an existing app\n\nIn an app that already uses Slack, install the product CLI and this exact twin release:\n\n```console\nnpm install --save-dev --save-exact @volter/world@3.0.87 @volter/twin-slack@3.0.3\nnpx volter world init --name my-app --twins slack --source slack=@volter/twin-slack\n```\n\nReview the detected vendor and bindings before booting. The World issues throwaway bot, Socket Mode and signing\ncredentials using the names listed below. Run the app's own 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\nReplace `npm test` with your app or test command. `down` retains state and a later `up` resumes it.\nPublisher and catalog contribution instructions: [the public publisher guide](https://github.com/volter-ai/twin-catalog-open/blob/main/docs/contributing.md).\n\nThe pack models an ordinary workspace with people, channels, timestamped messages and threads, files, normal workspace\nuser groups, apps and their scoped grants. Its APIs keep Slack's ok/error envelope, cursor paging and caller visibility.\nOAuth codes and grants have their own secrets, expiry and revocation. File bytes use the kernel blob seam. Scheduled\nmessages use the World clock.\n\nA person creates the workspace at slack.com/get-started and joins through invitation mail and the Join page. Workspace\nadmins manage members and invitation requests at slack.com/admin. Developers configure their app at api.slack.com/apps;\ninstallation uses slack.com/oauth/v2/authorize and oauth.v2.access. Program calls use their own issued tokens; a person's\nsynthetic client session is xoxp-<user-id>. Real credentials are never needed.\nFresh local Worlds seed a synthetic workspace named World with its owner and #general through that signup flow.\nThe default seed is copied into the application's `.volter/seeds/` by init and remains editable there. Use `@volter/world` 3.0.88 or later, which emits the working seed runner.\n\nWorld doors represent acts the API does not perform: an externally developed distributed app (/_twin/apps), a client\nslash command, Home opening, link share or action (/_twin/client/*), and observation of app deliveries or invitation mail\n(/_twin/deliveries and /_twin/mail). The application's own credentials come from /_twin/app-credentials, which the\nWorld asks at every boot: its own app, installed in its workspace, with a bot token (`SLACK_BOT_TOKEN`), an app-level\nSocket Mode token (`SLACK_APP_TOKEN`) and the app's signing secret. It is subscribed to every event the twin sends (link_shared\naside: it names no unfurl domain) and receives them over Socket Mode (it has no Request URL); its bot holds every scope Slack's methods name. Stored vendor mutations still use the API or vendor pages.\n\nIts callers are journeys/demand.json's: RH2's Slack app and channel bridge, Volter Harness's Slack platform (the Chat\nSDK in Socket Mode), Twin's on-call recipe, Dub's Slack integration and Postiz's Slack channel. Enterprise Grid\nadministration, SCIM provisioning and legacy OAuth are outside the modeled slate. Every Web API operation no demand,\nlife step or refresh reaches answers the gap (unknown_method), files.upload among them. The upload flow is\nfiles.getUploadURLExternal, its returned byte-upload URL and files.completeUploadExternal.\n\nPublishing and catalog process: [the public publisher guide](https://github.com/volter-ai/twin-catalog-open/blob/main/docs/contributing.md). Standing is the Protocol 3 grade and score-pack report, recorded after the whole\nslate is written. No result here asserts that the final walk or independent review has run.\n\nDub priority support can create a channel and send a recipient-specific Slack Connect email invitation. The stored\npending invitation is read through conversations.listConnectInvites with count/cursor pagination and retained in the\nlocal mail outbox. Receiving-workspace acceptance, approval, user-id recipients and join links are outside this\nworkflow; the twin sends no real invitation mail. Targeted invitation responses disclose no shareable URL.\n"
+  }
+}

package/content/2c123aa480c3d787e21218b005870509fe48379ba534df5a2eed8d2db5956596.json

@@ -0,0 +1,27 @@
+{
+  "schemaVersion": 1,
+  "release": {
+    "schemaVersion": 1,
+    "source": "twin-packs-open",
+    "vendor": "anthropic",
+    "package": "@volter/twin-anthropic",
+    "version": "1.0.3",
+    "integrity": "sha512-B7n7lnObG0nsmpkb4urtxZVixhmw4Gg1B8Xh13Oj2qj2WUulymAjpJ0sghCTdFUi+RXX/tSY43rDX1AWTJexJQ=="
+  },
+  "packageMetadata": {
+    "description": "Local Anthropic Messages, streaming and tool-use workflows. Replies use configured scenarios or labeled deterministic stubs; no model runs.",
+    "license": "Apache-2.0",
+    "engines": {
+      "node": ">=22.3"
+    },
+    "peerDependencies": {
+      "@volter/world-core": "^3.0.68"
+    },
+    "repositoryDirectory": "anthropic",
+    "bugs": "https://github.com/volter-ai/twin-packs-open/issues"
+  },
+  "readme": {
+    "path": "package/README.md",
+    "markdown": "# @volter/twin-anthropic\n\nA local Claude API. It serves Messages (`api.anthropic.com/v1/messages`, streamed and not), token counting and the\nmodel list, the calls Dub, Twenty, LibreChat and Claude Code make ([journeys/demand.json](./journeys/demand.json)). Around it are the Console's pages\n(`platform.claude.com`) where the API keys are made. The twin runs no model: a turn is the World's scenario's, else a\nlabeled deterministic stub.\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-anthropic@1.0.3\nnpx volter world init --name my-app --twins anthropic --source anthropic=@volter/twin-anthropic\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 the OpenAPI document Anthropic's TypeScript SDK is generated from (`spec/`). Handlers are in\n`src/semantics/messages.ts` and `src/semantics/models.ts`, the key front in `src/semantics/around.ts`, the scenario adapter in\n`src/semantics/scenario.ts`, and pages in `src/screens`.\n\n```bash\nworld-anthropic serve [--port N] [--root DIR] [--read-only]\n```\n\n## What it models\n\n- **Keys**:\n  - `Authorization: Bearer` or the legacy `x-api-key`. A missing, mistyped, disabled, deleted or expired key is `401\n    authentication_error`.\n  - `anthropic-version` is required.\n  - Every answer carries a request id.\n- **Messages**:\n  - the request checked as the API checks it (the model in the workspace catalog and released on the World clock, `max_tokens`, the thinking budget's rules,\n    manual thinking refused on Claude 4.7 and later, `tool_choice` naming an offered tool);\n  - the answer (`msg_…`, content blocks, `stop_reason`, `usage`) or its server-sent events: `message_start`, each\n    block's start, deltas (`text_delta`, `thinking_delta` and `signature_delta`, `input_json_delta`) and stop,\n    `message_delta` and `message_stop`;\n  - each also as its `?beta=true` operation.\n- **The turn**: the scenario's `respond` (`text`, `toolUses`, `serverTools`, `thinking`, `stopReason`), or a stub that:\n  - calls the chosen (else the first) tool while no tool result is pending;\n  - answers a value the structured output's schema admits (`output_config.format`, or the beta's `output_format`);\n  - otherwise echoes the last message, labeled.\n- **Tokens**: text at four characters a token, an image at `⌈width/28⌉ × ⌈height/28⌉` visual tokens (read from a PNG's\n  or JPEG's header, at most the model's limit). Token counting (`?beta=true`, as Claude Code sends it) answers the same count with no message made.\n- **The prompt cache**, per workspace:\n  - a prefix per `cache_control` breakpoint, in the order tools, system, messages;\n  - written with its lifetime (5 minutes, or 1 hour) and read while live, each read refreshing it;\n  - a prefix under the model's minimum is not cached.\n  - `usage` reports `cache_creation_input_tokens`, `cache_read_input_tokens` and `cache_creation`.\n- **Models**: `GET /v1/models`, the models an organization can use, newest first, paged by `after_id`/`before_id`,\n  each released by the World clock, with its limits, thinking and effort as its documentation page states them.\n- **The Console**: sign-in by an emailed code; the API keys page (create with an expiration, shown once; disable,\n  re-enable, delete).\n\nA scenario's `toolUses` is an array of `{ name, input }` calls; `thinking` is a string. For synthetic web search,\n`serverTools` is an array of `{ name: \"web_search\", input: { query: \"...\" }, results: [...] }`. Each result has\n`type: \"web_search_result\"`, `url`, `title`, `encrypted_content` and optional `page_age`. These scripts describe\nlocal fixture output and must match a tool the request offers; tool choice and parallel-use restrictions still apply.\n\n## Doors\n\n- `POST /_twin/users/{email} {organization}`: a person's sign-up, admin of a new organization and its Default workspace.\n- `GET /_twin/mailbox/{email}`: the mail the Console sent them.\n- `POST /_twin/api-keys {email, organization?, name?}`: issue a workspace key without driving the incidental Console.\n- `POST /_twin/app-credentials {}`: issue or resume the World application's key.\n\n## Not yet\n\nMessage Batches, Files, Skills, Managed Agents, the Admin API, the non-beta token count and the other beta surfaces:\nno application calls them. Web search can be scripted as synthetic server_tool_use/web_search_tool_result blocks using respond.serverTools; no hosted search runs. Unconfigured hosted tools, code execution and trusted-access Mythos models answer the documented error class.\n\nThe Console pages model only credential setup and revocation already required by the customer life. The served API is stateless; Console setup stays local and this pack has no vendor-backed deploy or refresh. The product's core work is its API; this pack adds no chat or generation dashboard. Text token counts and signatures are deterministic local approximations, not a tokenizer or valid model-generated reasoning.\n"
+  }
+}

package/content/2f905a18997aea40b709c4d4ea7adce45d4b080cf2216353d09b0cb6a910c3f7.json

@@ -0,0 +1,27 @@
+{
+  "schemaVersion": 1,
+  "release": {
+    "schemaVersion": 1,
+    "source": "twin-packs-open",
+    "vendor": "supabase",
+    "package": "@volter/twin-supabase",
+    "version": "1.0.3",
+    "integrity": "sha512-UO5MsMinW6IeZhG92HewkmYVhlM6I4lH8EWMOhNks5Dax0IUQjYJPWdPo9TSqXj0IzDI7luE2nge+p1+5F9Fjw=="
+  },
+  "packageMetadata": {
+    "description": "Local Supabase twin: a project's Postgres database, the World's own managed Postgres, whose URL the twin hands the application; the Management API, PostgREST, Storage and Auth answer the gap. Built on @volter/world-core.",
+    "license": "Apache-2.0",
+    "engines": {
+      "node": ">=22.3"
+    },
+    "peerDependencies": {
+      "@volter/world-core": "^3.0.92"
+    },
+    "repositoryDirectory": "supabase",
+    "bugs": null
+  },
+  "readme": {
+    "path": "package/README.md",
+    "markdown": "# @volter/twin-supabase\n\nA local Supabase project's **Postgres database**: in a World it is the World's own managed Postgres, and the twin hands\nthe application its URL. A Protocol 3 derived pack (twin-world's\narchitecture, \"Protocol 3: the derived pack\"); no real Supabase is contacted.\n\nInstall the exact twin and World CLI in your app:\n\n```sh\nnpm install --save-dev --save-exact @volter/world@3.0.92 @volter/twin-supabase@1.0.3\n```\n\nFollow [Run a full stack](https://github.com/volter-ai/twin-world/blob/main/docs/guides/run-a-full-stack.md#a-real-database)\nto configure the World-owned Postgres and run your migrations and app inside the World. Keep your native Postgres\nclient unchanged. This release does not implement Supabase's HTTP APIs or make supabase-js calls work.\n\nFor an operator calling the server directly:\n\n```sh\nbun run src/cli.ts serve --database <postgres url>   # without --database the project has no database to hand out (503)\n```\n\n## For whom\n\nRH2 (Volter's product), whose authority store is a Supabase project's Postgres, reached over the Postgres wire alone:\n\"no PostgREST, no Supabase client library, no anon session\" (`journeys/demand.json`). Its release migrates the database\nand its Worker queries it; both are answered by Postgres itself, the World's database (`journeys/customer-life.json`\nwalks RH2's own statements on it).\n\n## What is served\n\n- **The database.** The runtime binds the twin to the World's managed Postgres (`managedDatabase`: `serve --database\n  <url>`), and the application connects to that database with any Postgres client. Under the containerless backing its\n  clock follows the World clock. Database-generated randomness belongs to the backing and is not pinned; use explicit\n  stable fixture IDs when comparing fresh Worlds (twin-world architecture, SQL steps).\n- **The door.** `POST /_twin/app-credentials` (the descriptor's `credentialDoor`, called by the runtime at every boot):\n  makes the World's project `world` the first time and answers `{ ref, database_url }`, filling `SUPABASE_DB_URL`.\n- **Not served** (the gap): every operation of the Management API (`api.supabase.com/v1`), PostgREST (`/rest/v1`),\n  Storage (`/storage/v1`) and Auth (`/auth/v1`), each answering its unit's own unknown-route error\n  (`journeys/decisions.json`); Realtime and Edge Functions (their paths are not claimed, so the injector refuses them).\n\n## Units\n\n| Unit | Spec | Serves |\n|---|---|---|\n| `supabase` (`src/`) | `spec/openapi.json.gz`, api.supabase.com's own document (170 operations) | the door; the Management API is the gap |\n| `supabase/rest` | `rest/spec/client-ops.json`, the calls `@supabase/postgrest-js` makes | the gap |\n| `supabase/storage` | `storage/spec/openapi.json`, storage-api's document as Supabase's docs publish it | the gap |\n| `supabase/auth` | `auth/spec/openapi.yaml`, GoTrue v2.197.0's document | the gap |\n\n## Evidence\n\nThe vendor's documents and recordings are under each unit's `spec/` (its `SOURCE.md`).\n"
+  }
+}

package/content/32255ffe1d7c2e67218d1a05799128096033136f9d4963b0d55fcb8b71c09e89.json

@@ -0,0 +1,27 @@
+{
+  "schemaVersion": 1,
+  "release": {
+    "schemaVersion": 1,
+    "source": "twin-packs-open",
+    "vendor": "slack",
+    "package": "@volter/twin-slack",
+    "version": "3.0.3",
+    "integrity": "sha512-KXepCGDooRc7u6QRU9nwoFJ8oeC8Fg16MoTn9YiIqissQsGUvAoCZ0Zs39qvq/wq3m+pmjVtsvv7a2fPd6aOtg=="
+  },
+  "packageMetadata": {
+    "description": "Local Slack twin — a faithful, stateful local Slack Web API your real Slack SDKs talk to unmodified, with its OAuth install, pages and incoming webhooks. Built on @volter/world-core.",
+    "license": "Apache-2.0",
+    "engines": {
+      "node": ">=22.3"
+    },
+    "peerDependencies": {
+      "@volter/world-core": "^3.0.87"
+    },
+    "repositoryDirectory": "slack",
+    "bugs": "https://github.com/volter-ai/twin-packs-open/issues"
+  },
+  "readme": {
+    "path": "package/README.md",
+    "markdown": "# @volter/twin-slack\n\nSlack's Web API, workspace invitations and member pages, app configuration and OAuth install pages, incoming\nwebhooks and signed app deliveries. The pinned API and corrections are in spec/; provenance is spec/SOURCE.md.\nThe current product callers, operation decisions and customer story are in journeys/.\n\n## Use with an existing app\n\nIn an app that already uses Slack, install the product CLI and this exact twin release:\n\n```console\nnpm install --save-dev --save-exact @volter/world@3.0.87 @volter/twin-slack@3.0.3\nnpx volter world init --name my-app --twins slack --source slack=@volter/twin-slack\n```\n\nReview the detected vendor and bindings before booting. The World issues throwaway bot, Socket Mode and signing\ncredentials using the names listed below. Run the app's own 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\nReplace `npm test` with your app or test command. `down` retains state and a later `up` resumes it.\nPublisher and catalog contribution instructions: [the public publisher guide](https://github.com/volter-ai/twin-catalog-open/blob/main/docs/contributing.md).\n\nThe pack models an ordinary workspace with people, channels, timestamped messages and threads, files, normal workspace\nuser groups, apps and their scoped grants. Its APIs keep Slack's ok/error envelope, cursor paging and caller visibility.\nOAuth codes and grants have their own secrets, expiry and revocation. File bytes use the kernel blob seam. Scheduled\nmessages use the World clock.\n\nA person creates the workspace at slack.com/get-started and joins through invitation mail and the Join page. Workspace\nadmins manage members and invitation requests at slack.com/admin. Developers configure their app at api.slack.com/apps;\ninstallation uses slack.com/oauth/v2/authorize and oauth.v2.access. Program calls use their own issued tokens; a person's\nsynthetic client session is xoxp-<user-id>. Real credentials are never needed.\n\nWorld doors represent acts the API does not perform: an externally developed distributed app (/_twin/apps), a client\nslash command, Home opening, link share or action (/_twin/client/*), and observation of app deliveries or invitation mail\n(/_twin/deliveries and /_twin/mail). The application's own credentials come from /_twin/app-credentials, which the\nWorld asks at every boot: its own app, installed in its workspace, with a bot token (`SLACK_BOT_TOKEN`), an app-level\nSocket Mode token (`SLACK_APP_TOKEN`) and the app's signing secret. It is subscribed to every event the twin sends (link_shared\naside: it names no unfurl domain) and receives them over Socket Mode (it has no Request URL); its bot holds every scope Slack's methods name. Stored vendor mutations still use the API or vendor pages.\n\nIts callers are journeys/demand.json's: RH2's Slack app and channel bridge, Volter Harness's Slack platform (the Chat\nSDK in Socket Mode), Twin's on-call recipe, Dub's Slack integration and Postiz's Slack channel. Enterprise Grid\nadministration, SCIM provisioning and legacy OAuth are outside the modeled slate. Every Web API operation no demand,\nlife step or refresh reaches answers the gap (unknown_method), files.upload among them. The upload flow is\nfiles.getUploadURLExternal, its returned byte-upload URL and files.completeUploadExternal.\n\nPublishing and catalog process: [the public publisher guide](https://github.com/volter-ai/twin-catalog-open/blob/main/docs/contributing.md). Standing is the Protocol 3 grade and score-pack report, recorded after the whole\nslate is written. No result here asserts that the final walk or independent review has run.\n\nDub priority support can create a channel and send a recipient-specific Slack Connect email invitation. The stored\npending invitation is read through conversations.listConnectInvites with count/cursor pagination and retained in the\nlocal mail outbox. Receiving-workspace acceptance, approval, user-id recipients and join links are outside this\nworkflow; the twin sends no real invitation mail. Targeted invitation responses disclose no shareable URL.\n"
+  }
+}

package/content/4edaec8cd2e55c04f66245309742a63c36f102320ef221927ff93d97b3b268b9.json

@@ -0,0 +1,27 @@
+{
+  "schemaVersion": 1,
+  "release": {
+    "schemaVersion": 1,
+    "source": "twin-packs-open",
+    "vendor": "github",
+    "package": "@volter/twin-github",
+    "version": "3.0.5",
+    "integrity": "sha512-uoGcRonDjul+8ITbYnSFanDzaQUMdFuLb2IWSTgydvIVuSeA1dato358ST5cjv/nelMgrRi3yr9fyUklw+Fh7A=="
+  },
+  "packageMetadata": {
+    "description": "Local GitHub repository, issue, pull-request and git workflows over shared synthetic state. REST, GraphQL and Actions scope is documented in the README.",
+    "license": "Apache-2.0",
+    "engines": {
+      "node": ">=22.3"
+    },
+    "peerDependencies": {
+      "@volter/world-core": "^3.0.68"
+    },
+    "repositoryDirectory": "github",
+    "bugs": "https://github.com/volter-ai/twin-packs-open/issues"
+  },
+  "readme": {
+    "path": "package/README.md",
+    "markdown": "# @volter/twin-github\n\nA local GitHub: the REST API the unmodified `@octokit/rest` and `gh` call (`https://api.github.com`), the GraphQL API\nbeside it, git over smart HTTP, and the github.com pages an application sends a person through, over one 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-github@3.0.5\nnpx volter world init --name my-app --twins github --source github=@volter/twin-github\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 derived pack ([publisher guide](https://github.com/volter-ai/twin-catalog-open/blob/main/docs/contributing.md)): the REST surface is generated from GitHub's published OpenAPI description and the GraphQL schema beside it\n(`spec/`), plain reads and updates are the derived core's, the state machines are `src/semantics/states.ts`,\nhandlers by operationId (`src/semantics/<family>.ts`) serve only what an operation does beyond them, the GraphQL\nresolvers are `src/semantics/graphql.ts`, and GitHub's own computation (workflow files, advisories, a README's\nMarkdown, TOTP, a CVSS vector's score) is `src/engine/`. It serves what the applications call and what one customer's\nlife sends ([journeys/demand.json](./journeys/demand.json), [journeys/decisions.json](./journeys/decisions.json),\n[journeys/customer-life.json](./journeys/customer-life.json)); every other operation answers GitHub's own 404, and every\nother GraphQL root field GraphQL's undefinedField. GitHub's published examples for the operations served, and the rules\nits pages state, are replayed in [journeys/vendor-examples.json](./journeys/vendor-examples.json)\n([spec/doc-examples.json](./spec/doc-examples.json)).\n\n```bash\nworld-github serve [--port N] [--root DIR] [--read-only]\n```\n\nPoint a client at it (`new Octokit({ baseUrl })`, `GH_HOST`), or run the application in a World, whose routing sends\n`api.github.com`, `github.com` (its sign-in, settings and app pages and git), `uploads.github.com`,\n`raw.githubusercontent.com` and `token.actions.githubusercontent.com` here.\n\n## What it models\n\n- **Who it is for**: Volter's own products (Open Autonomy's kit, setup and platform, the Volter Harness board and\n  installer, the Volter Editor, Workbench's store, Twin's World action, Actions runner, catalog release and on-call\n  recipe, Volter identity's sign-in), Dub's GitHub sign-in, Rallly's update check and Twenty's site; the opt-in GitHub\n  features of LibreChat, Postiz and Twenty are listed apart (`demand.json`'s `optional`).\n- **Repositories**: made by GraphQL `createRepository` (as `gh repo create` makes them), read with the caller's\n  `permissions`, their README (and its HTML), contents committed through the API; rulesets, enforced on pushes,\n  contents commits and merges; environments with their branch policies and secrets, repository variables and secrets\n  (sealed to the repository's key), deploy keys; teams and their repositories.\n- **Git**: smart HTTP clone, fetch and push at `github.com/<owner>/<repo>.git`, contents, commits, compares, trees,\n  blobs, refs and annotated tags read from the same objects, abbreviated SHAs resolved; a push a ruleset refuses is\n  refused as GitHub refuses it (GH013).\n- **Issues and pull requests**: issues (read one by its number, as Octokit's `issues.get`), labels, milestones and\n  comments; pull requests from branches of the repository, their reviews, and merges (GraphQL `mergePullRequest`, and\n  REST's merge, squash or rebase) that close the issues their bodies name; a pull request closes with its deleted head\n  branch.\n- **Releases, statuses, webhooks and advisories**: releases with uploaded assets, commit statuses, a repository's\n  webhooks and their deliveries, repository security advisories (made and published).\n- **Actions, as the World's runner works it**: a push starts the workflows of its commit; the runner (twin-world's\n  `volter-world-actions-runner`) finds its repositories and their queued runs, starts one through the World's door\n  with its job token, the repository's secrets (sealed to its key) and variables and an OIDC request, and completes it\n  with its jobs' conclusions and artifacts; the OIDC provider (`token.actions.githubusercontent.com`) signs the job's\n  token, which Sigstore's Fulcio twin verifies.\n- **Apps**: GitHub Apps from a manifest or the World's door, installed from their installation page, their JWT, a\n  repository's installation and its installation tokens (narrowed to permissions and repositories).\n- **Sign-in**: github.com's password and two-factor pages, OAuth apps' web flow, GitHub Apps' user tokens and\n  refresh tokens (a refresh needs no secret and revokes the access token it replaces), and the device flow\n  `gh auth login` runs.\n- **GraphQL**: `repository` with what Open Autonomy's community desk and `gh pr create`, `gh pr view` and `gh pr merge`\n  read (its owner, default branch, the caller's permission, its parent, its discussions and their categories, its pull\n  requests by branch with their commits' status rollup, review decision and merge state), the schema's own\n  introspection, and the mutations they send: `createRepository`, `createDiscussion`, `addDiscussionComment`,\n  `createPullRequest` and `mergePullRequest`.\n\n## Events\n\nA write GitHub reports sends its webhook (`issues`, `pull_request`, `push`, `installation`, …), declared as data the\nkernel renders, signs (`X-Hub-Signature-256`, and the SHA-1 `X-Hub-Signature`) and delivers: to the repository's and\nits organization's hooks whose events take it, and to each GitHub App whose installation covers the repository, with\nthe installation in the payload. A hook's deliveries are `GET /repos/{owner}/{repo}/hooks/{hook_id}/deliveries`.\n\n**Vendor-backed.** Each stored resource reads back by its list (under its repository, `{owner}/{repo}`) but installations,\nwhich only an App's own credentials list, GitHub's\nwebhooks are ingested by `X-Hub-Signature-256` (each event's object at its own key, its repository by\n`repository.full_name`; a push is acknowledged and folds nothing), and calls are charged against GitHub's documented\nlimits (5,000 an hour, 900 points a minute).\n\n## Doors\n\nWhat happens outside the API is the World's door (`/_twin/…`, declared in the manifest): signing up, choosing a\npassword, turning on two-factor authentication and reading the authenticator's code, making a personal access token,\nan organization, a GitHub App or an OAuth app, and a runner starting and completing a workflow run.\n\n## What it leaves out\n\nEvery operation no in-scope application and no life step reaches: the manifest's `unmodeled` (the rest of Actions,\nPages, deployments, attestations, Dependabot and code scanning, Projects, search, forks, transfers, branch\nprotection, issue locks), the GraphQL root fields beyond `repository` and the five mutations, and the browser\ndownload of a release's `latest` asset, which `install.sh` fetches. Where GitHub documents more than the twin does, the\ntwin does less: a rebase merge is one commit, a CVSS 4.0 vector is not scored, and a pull request's head is a branch of\nits own repository. Its standing is twin-packs-p3's generated `STANDING.md`.\n"
+  }
+}

package/content/5eeaa5e7c2a08c8c0818489c40e7b818c114bd74f5c1b8186e0de69f8792049c.json

@@ -0,0 +1,27 @@
+{
+  "schemaVersion": 1,
+  "release": {
+    "schemaVersion": 1,
+    "source": "twin-packs-open",
+    "vendor": "linear",
+    "package": "@volter/twin-linear",
+    "version": "3.0.3",
+    "integrity": "sha512-3V84nwtDUtwgyZOXzclEZMCZqjEeidbSH32okOm+pUk6z9RqaSHJN87gVdXJht8UYh3sUnr2fYiCA1mK2w75Uw=="
+  },
+  "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/66285aa1b8bccb8fe943294975108f303bc51ee310c33633d7454afa631e913b.json

@@ -0,0 +1,27 @@
+{
+  "schemaVersion": 1,
+  "release": {
+    "schemaVersion": 1,
+    "source": "twin-packs-open",
+    "vendor": "github",
+    "package": "@volter/twin-github",
+    "version": "3.0.6",
+    "integrity": "sha512-NNv6Lc3XWjNTqT2l/I+ha8wcnO/7kDtI8+oybYvbngxL389iQc99MvrSIdcdv9AkISrcvIvd8SiQpfsDu16V7w=="
+  },
+  "packageMetadata": {
+    "description": "Local GitHub repository, issue, pull-request and git workflows over shared synthetic state. REST, GraphQL and Actions scope is documented in the README.",
+    "license": "Apache-2.0",
+    "engines": {
+      "node": ">=22.3"
+    },
+    "peerDependencies": {
+      "@volter/world-core": "^3.0.127"
+    },
+    "repositoryDirectory": "github",
+    "bugs": "https://github.com/volter-ai/twin-packs-open/issues"
+  },
+  "readme": {
+    "path": "package/README.md",
+    "markdown": "# @volter/twin-github\n\nA local GitHub: the REST API the unmodified `@octokit/rest` and `gh` call (`https://api.github.com`), the GraphQL API\nbeside it, git over smart HTTP, and the github.com pages an application sends a person through, over one 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.127 @volter/twin-github@3.0.6\nnpx volter world init --name my-app --twins github --source github=@volter/twin-github\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 derived pack ([publisher guide](https://github.com/volter-ai/twin-catalog-open/blob/main/docs/contributing.md)): the REST surface is generated from GitHub's published OpenAPI description and the GraphQL schema beside it\n(`spec/`), plain reads and updates are the derived core's, the state machines are `src/semantics/states.ts`,\nhandlers by operationId (`src/semantics/<family>.ts`) serve only what an operation does beyond them, the GraphQL\nresolvers are `src/semantics/graphql.ts`, and GitHub's own computation (workflow files, advisories, a README's\nMarkdown, TOTP, a CVSS vector's score) is `src/engine/`. It serves what the applications call and what one customer's\nlife sends ([journeys/demand.json](./journeys/demand.json), [journeys/decisions.json](./journeys/decisions.json),\n[journeys/customer-life.json](./journeys/customer-life.json)); every other operation answers GitHub's own 404, and every\nother GraphQL root field GraphQL's undefinedField. GitHub's published examples for the operations served, and the rules\nits pages state, are replayed in [journeys/vendor-examples.json](./journeys/vendor-examples.json)\n([spec/doc-examples.json](./spec/doc-examples.json)).\n\n```bash\nworld-github serve [--port N] [--root DIR] [--read-only]\n```\n\nPoint a client at it (`new Octokit({ baseUrl })`, `GH_HOST`), or run the application in a World, whose routing sends\n`api.github.com`, `github.com` (its sign-in, settings and app pages and git), `uploads.github.com`,\n`raw.githubusercontent.com` and `token.actions.githubusercontent.com` here.\n\n## What it models\n\n- **Who it is for**: Volter's own products (Open Autonomy's kit, setup and platform, the Volter Harness board and\n  installer, the Volter Editor, Workbench's store, Twin's World action, Actions runner, catalog release and on-call\n  recipe, Volter identity's sign-in), Dub's GitHub sign-in, Rallly's update check and Twenty's site; the opt-in GitHub\n  features of LibreChat, Postiz and Twenty are listed apart (`demand.json`'s `optional`).\n- **Repositories**: made by GraphQL `createRepository` (as `gh repo create` makes them), read with the caller's\n  `permissions`, their README (and its HTML), contents committed through the API; rulesets, enforced on pushes,\n  contents commits and merges; environments with their branch policies and secrets, repository variables and secrets\n  (sealed to the repository's key), deploy keys; teams and their repositories.\n- **Git**: smart HTTP clone, fetch and push at `github.com/<owner>/<repo>.git`, contents, commits, compares, trees,\n  blobs, refs and annotated tags read from the same objects, abbreviated SHAs resolved; a push a ruleset refuses is\n  refused as GitHub refuses it (GH013).\n- **Issues and pull requests**: issues (read one by its number, as Octokit's `issues.get`), labels, milestones and\n  comments; pull requests from branches of the repository, their reviews, and merges (GraphQL `mergePullRequest`, and\n  REST's merge, squash or rebase) that close the issues their bodies name; a pull request closes with its deleted head\n  branch.\n- **Releases, statuses, webhooks and advisories**: releases with uploaded assets, commit statuses, a repository's\n  webhooks and their deliveries, repository security advisories (made and published).\n- **Actions, as the World's runner works it**: a push starts the workflows of its commit; the runner (twin-world's\n  `volter-world-actions-runner`) finds its repositories and their queued runs, starts one through the World's door\n  with its job token, the repository's secrets (sealed to its key) and variables and an OIDC request, and completes it\n  with its jobs' conclusions and artifacts; the OIDC provider (`token.actions.githubusercontent.com`) signs the job's\n  token, which Sigstore's Fulcio twin verifies.\n- **Apps**: GitHub Apps from a manifest or the World's door, installed from their installation page, their JWT, a\n  repository's installation and its installation tokens (narrowed to permissions and repositories).\n- **Sign-in**: github.com's password and two-factor pages, OAuth apps' web flow, GitHub Apps' user tokens and\n  refresh tokens (a refresh needs no secret and revokes the access token it replaces), and the device flow\n  `gh auth login` runs.\n- **GraphQL**: `repository` with what Open Autonomy's community desk and `gh pr create`, `gh pr view` and `gh pr merge`\n  read (its owner, default branch, the caller's permission, its parent, its discussions and their categories, its pull\n  requests by branch with their commits' status rollup, review decision and merge state), the schema's own\n  introspection, and the mutations they send: `createRepository`, `createDiscussion`, `addDiscussionComment`,\n  `createPullRequest` and `mergePullRequest`.\n\n## Events\n\nA write GitHub reports sends its webhook (`issues`, `pull_request`, `push`, `installation`, …), declared as data the\nkernel renders, signs (`X-Hub-Signature-256`, and the SHA-1 `X-Hub-Signature`) and delivers: to the repository's and\nits organization's hooks whose events take it, and to each GitHub App whose installation covers the repository, with\nthe installation in the payload. A hook's deliveries are `GET /repos/{owner}/{repo}/hooks/{hook_id}/deliveries`.\n\n**Vendor-backed.** Each stored resource reads back by its list (under its repository, `{owner}/{repo}`) but installations,\nwhich only an App's own credentials list, GitHub's\nwebhooks are ingested by `X-Hub-Signature-256` (each event's object at its own key, its repository by\n`repository.full_name`; a push is acknowledged and folds nothing), and calls are charged against GitHub's documented\nlimits (5,000 an hour, 900 points a minute).\n\n## Doors\n\nWhat happens outside the API is the World's door (`/_twin/…`, declared in the manifest): signing up, choosing a\npassword, turning on two-factor authentication and reading the authenticator's code, making a personal access token,\nan organization, a GitHub App or an OAuth app, and a runner starting and completing a workflow run.\n\n## What it leaves out\n\nEvery operation no in-scope application and no life step reaches: the manifest's `unmodeled` (the rest of Actions,\nPages, deployments, attestations, Dependabot and code scanning, Projects, search, forks, transfers, branch\nprotection, issue locks), the GraphQL root fields beyond `repository` and the five mutations, and the browser\ndownload of a release's `latest` asset, which `install.sh` fetches. Where GitHub documents more than the twin does, the\ntwin does less: a rebase merge is one commit, a CVSS 4.0 vector is not scored, and a pull request's head is a branch of\nits own repository. Its standing is twin-packs-p3's generated `STANDING.md`.\n"
+  }
+}

package/content/6f9f4c4659dc8d86e42363050c0ee444e4f1e05409866bf4ee3b54d12a3c2cc2.json

@@ -0,0 +1,27 @@
+{
+  "schemaVersion": 1,
+  "release": {
+    "schemaVersion": 1,
+    "source": "twin-packs-open",
+    "vendor": "openai",
+    "package": "@volter/twin-openai",
+    "version": "3.0.2",
+    "integrity": "sha512-DbNSre3DPt6mY1VKRX9Tdevl2Gg0l2vi9Jx7FGH23Xl3WEV+tWCyiUMDSDc8uoCBT0p1VUR7xz8svjRDukDORw=="
+  },
+  "packageMetadata": {
+    "description": "Local OpenAI Responses, Chat Completions and tool-use workflows. Replies use configured scenarios or labeled deterministic stubs; no model runs.",
+    "license": "Apache-2.0",
+    "engines": {
+      "node": ">=22.3"
+    },
+    "peerDependencies": {
+      "@volter/world-core": "^3.0.87"
+    },
+    "repositoryDirectory": "openai",
+    "bugs": "https://github.com/volter-ai/twin-packs-open/issues"
+  },
+  "readme": {
+    "path": "package/README.md",
+    "markdown": "# @volter/twin-openai\n\nA local OpenAI API. It serves the calls the applications make (`journeys/demand.json`):\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.92 @volter/twin-openai@3.0.2\nnpx volter world init --name my-app --twins openai --source openai=@volter/twin-openai\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\n- the Responses API (Twenty, Rallly, Postiz and LibreChat, through the AI SDK's OpenAI provider and the openai SDK);\n- Chat Completions (Workbench's agent, the on-call cookbook, Postiz, LibreChat), the models list, Files, Images (generations\n  and edits), moderations, transcriptions and text to speech;\n- LibreChat's Assistants v2: assistants, threads, messages, runs and their steps and tool outputs.\n\nAround it are the dashboard pages (`platform.openai.com`: the log in and a project's API keys). The twin runs no model:\na turn is the World's scenario's, else a deterministic stub labeled `[twin-stub:<model>]`.\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 OpenAI's published OpenAPI document (`spec/`). The derived core serves plain reads and writes. Handlers are in\n`src/semantics/<family>.ts`, the scenario adapter in `src/semantics/scenario.ts`, and pages in `src/screens`.\n\n```bash\nworld-openai serve [--port N] [--root DIR] [--read-only]\n```\n\n## What it models\n\n- **Keys**:\n  - A project key is made on the project's API keys page (shown once, held by its SHA-256), or issued to a World's\n    applications by the credential door.\n  - A request with no key, or one the organization never made, is refused 401 `invalid_api_key`. So is a revoked key,\n    or one of an archived project.\n- **Responses**:\n  - `POST /v1/responses`, streamed (named events, ending with `response.completed`) or not.\n  - Function tools the stub calls while no tool output is pending; `previous_response_id` carrying the conversation.\n  - Structured output (`text.format` with a JSON schema) the stub answers with a value the schema admits.\n- **Chat Completions**: the answer or its `chat.completion.chunk` stream ending with `[DONE]`, and tool calls.\n- **Assistants v2**:\n  - A run is worked when a read first looks at it.\n  - A run with function tools stops at `requires_action` for their outputs, then completes with a stub reply. A run\n    in flight can be cancelled. A run still waiting on its outputs at its `expires_at`, ten minutes after it was\n    created, expires and refuses them.\n  - The thread's messages and the run's steps are kept.\n- **Files**: uploaded (multipart), read, downloaded, deleted. Missing locally held bytes are refused; refreshed file metadata does not supply content.\n- **Images**: `POST /v1/images/generations` and `POST /v1/images/edits` answer a labeled placeholder image. DALL-E default URLs serve those bytes through the media lane for 60 minutes.\n- **Moderations**: `POST /v1/moderations` classifies each input deterministically: text naming a category's own words is\n  flagged in it, with its categories and scores; no model runs.\n- **Speech**: `POST /v1/audio/speech` answers an audio file in the format asked (mp3 unless named), billed by the\n  characters it reads.\n- **Transcriptions**: `POST /v1/audio/transcriptions` answers a labeled stub transcript, with the WAV duration from its header; other formats use a synthetic one-second duration.\n- **Models**: a static catalog.\n- **Realtime**: `wss://api.openai.com/v1/realtime` (Volter Harness's voice): every client event the reference lists: the\n  session, the input audio buffer (append, commit, clear; no speech is detected in it), conversation items (create,\n  retrieve, truncate, delete) and responses as events; `output_audio_buffer.clear`, WebRTC's and SIP's, is refused on the\n  WebSocket. A response is the World's scenario's turn, else the labeled stub, spoken as silence with its transcript.\n\nThe subscription surface serves Open Autonomy, RH2, Browser Substrate and Volter Harness. On `auth.openai.com` it supplies browser consent with localhost callback, state and S256 PKCE, device user-code polling, authorization-code exchange, refresh and revocation. On `chatgpt.com/backend-api/codex` it serves Responses over HTTP/SSE and WebSocket, compaction and per-account model discovery. The native TUI’s `/backend-api/wham` usage, token activity, workspace-message and reset-credit views use a synthetic Plus account with no purchased credits. Account limits and expiry are explicit local policy where the private documentation gives no number. HTTP and socket model turns use configured scenarios or labeled deterministic stubs.\n\n## Doors\n\n- `POST /_twin/accounts {email, name, password, role?}`: a person of the World's organization, who logs in to the\n  dashboard.\n- `POST /_twin/app-credentials`: the Default project and a key for it, as the runtime issues them to a World's\n  applications. It also issues the World’s synthetic subscription account and signed tokens; `CODEX_HOME` is filled with a private directory containing Codex’s `auth.json` and file-storage config. The hosted browser/device pages accept the door’s `codex_email` and `codex_password`. No production account or key is used.\n\n## Not yet\n\nEmbeddings, fine-tuning, batches, uploads, evals, containers and the Admin API answer the documented gap.\nVector stores supply the empty store and its readbacks that the published file-search examples require; the twin\nperforms no embedding or retrieval. Stored chat completions and Responses support their published readbacks.\nThe dashboard is limited to credential issuance; model calls are the product surface.\n\nUndemanded private cloud tasks, remote configuration, account checks and workspace policy settings answer HTTP 404 in the pinned client’s accepted error envelope. Native cloud commands, remote control and experimental voice/plugin flows are outside these products’ configured subscription runtime; independently demanded REST and Realtime calls are described above.\n"
+  }
+}