Volter World

Twins / GitHub / 3.0.8

@volter/twin-github

GitHub

volter-aiVolter maintainedv3.0.8

Local GitHub repository, issue, pull-request and git workflows over shared synthetic state. REST, GraphQL and Actions scope is documented in the README.

Setup gives the current installation instructions for @volter/twin-github 3.0.8. Open the published README for credentials, seeds, supported operations and limits.

README shipped with @volter/twin-github 3.0.8

These instructions were published with this package. Their tool versions may differ from the current starter cohort. Use Setup to install this version.

A local GitHub: the REST API the unmodified @octokit/rest and gh call (https://api.github.com), the GraphQL API beside it, git over smart HTTP, and the github.com pages an application sends a person through, over one state.

Use with an existing app

Use Node 22.6 or newer.

In an app that already uses this vendor, install this exact release and the product CLI:

npm install --save-dev --save-exact @volter/world@3.0.147 @volter/twin-github@3.0.7
./node_modules/.bin/volter world init --name my-app --twins github --source github=@volter/twin-github

Run the local executable from this app’s folder; if it is missing, complete the installation here before continuing.

Review 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:

./node_modules/.bin/volter world up
./node_modules/.bin/volter world run -- npm test
./node_modules/.bin/volter world log
./node_modules/.bin/volter world down

Here npm test is your app's existing command; replace it with your app or test command. down retains state. A later up resumes it; do not reset or initialize again merely to return.

Publisher and catalog contribution instructions: the public publisher guide.

A Protocol 3 derived pack (publisher guide): the REST surface is generated from GitHub's published OpenAPI description and the GraphQL schema beside it (spec/), plain reads and updates are the derived core's, the state machines are src/semantics/states.ts, handlers by operationId (src/semantics/<family>.ts) serve only what an operation does beyond them, the GraphQL resolvers are src/semantics/graphql.ts, and GitHub's own computation (workflow files, advisories, a README's Markdown, TOTP, a CVSS vector's score) is src/engine/. It serves what the applications call and what one customer's life sends (journeys/demand.json, journeys/decisions.json, journeys/customer-life.json); every other operation answers GitHub's own 404, and every other GraphQL root field GraphQL's undefinedField. GitHub's published examples for the operations served, and the rules its pages state, are replayed in journeys/vendor-examples.json (spec/doc-examples.json).

world-github serve [--port N] [--root DIR] [--read-only]

Point a client at it (new Octokit({ baseUrl }), GH_HOST), or run the application in a World, whose routing sends api.github.com, github.com (its sign-in, settings and app pages and git), uploads.github.com, raw.githubusercontent.com and token.actions.githubusercontent.com here.

What it models

  • Who it is for: Volter's own products (Open Autonomy's kit, setup and platform, the Volter Harness board and installer, the Volter Editor, Workbench's store, Twin's World action, Actions runner, catalog release and on-call recipe, Volter identity's sign-in), Dub's GitHub sign-in, Rallly's update check and Twenty's site; the opt-in GitHub features of LibreChat, Postiz and Twenty are listed apart (demand.json's optional).
  • Repositories: made by GraphQL createRepository (as gh repo create makes them), read with the caller's permissions, their README (and its HTML), contents committed through the API; rulesets, enforced on pushes, contents commits and merges; environments with their branch policies and secrets, repository variables and secrets (sealed to the repository's key), deploy keys; teams and their repositories.
  • Git: smart HTTP clone, fetch and push at github.com/<owner>/<repo>.git, contents, commits, compares, trees, blobs, refs and annotated tags read from the same objects, abbreviated SHAs resolved; a push a ruleset refuses is refused as GitHub refuses it (GH013).
  • Issues and pull requests: issues (read one by its number, as Octokit's issues.get), labels, milestones and comments; pull requests from branches of the repository, their reviews, and merges (GraphQL mergePullRequest, and REST's merge, squash or rebase) that close the issues their bodies name; a pull request closes with its deleted head branch.
  • Releases, statuses, webhooks and advisories: releases with uploaded assets, commit statuses, a repository's webhooks and their deliveries, repository security advisories (made and published).
  • Actions, as the World's runner works it: a push starts the workflows of its commit; the runner (twin-world's volter-world-actions-runner) finds its repositories and their queued runs, starts one through the World's door with its job token, the repository's secrets (sealed to its key) and variables and an OIDC request, and completes it with its jobs' conclusions and artifacts; the OIDC provider (token.actions.githubusercontent.com) signs the job's token, which Sigstore's Fulcio twin verifies.
  • Apps: GitHub Apps from a manifest or the World's door, installed from their installation page, their JWT, a repository's installation and its installation tokens (narrowed to permissions and repositories).
  • Sign-in: github.com's password and two-factor pages, OAuth apps' web flow, GitHub Apps' user tokens and refresh tokens (a refresh needs no secret and revokes the access token it replaces), and the device flow gh auth login runs.
  • GraphQL: repository with what Open Autonomy's community desk and gh pr create, gh pr view and gh pr merge read (its owner, default branch, the caller's permission, its parent, its discussions and their categories, its pull requests by branch with their commits' status rollup, review decision and merge state), the schema's own introspection, and the mutations they send: createRepository, createDiscussion, addDiscussionComment, createPullRequest and mergePullRequest.

Repository browser

The Code tab shows the stored repository files and README with GitHub’s familiar file-list and About layout. Select a branch, open folders and files, or follow Raw to the stored blob content. Branch selection changes only the viewed ref; mounted World URLs stay local. A Markdown file renders through the shared Markdown renderer; text files show line anchors.

Issues, pull requests, Actions, Projects, Security, Insights and Settings remain API capabilities rather than browser tabs. Those tabs and the clone dropdown and Blame controls are unavailable in this mirror. Symbol navigation and submodule navigation are outside this browser scope.

Events

A write GitHub reports sends its webhook (issues, pull_request, push, installation, …), declared as data the kernel renders, signs (X-Hub-Signature-256, and the SHA-1 X-Hub-Signature) and delivers: to the repository's and its organization's hooks whose events take it, and to each GitHub App whose installation covers the repository, with the installation in the payload. A hook's deliveries are GET /repos/{owner}/{repo}/hooks/{hook_id}/deliveries.

Vendor-backed. Each stored resource reads back by its list (under its repository, {owner}/{repo}) but installations, which only an App's own credentials list, GitHub's webhooks are ingested by X-Hub-Signature-256 (each event's object at its own key, its repository by repository.full_name; a push is acknowledged and folds nothing), and calls are charged against GitHub's documented limits (5,000 an hour, 900 points a minute).

Doors

The repository mirror opens its Code, Issues and Pull requests tabs. Code reads stored branches, files and README; Issues and Pull requests show open or closed lists and numbered conversations, including their API-created description and comments, labels, assignees and milestone. A pull request names its head and base branches. Its Files changed tab reads the same stored Git comparison as the API, including added and removed lines. These workspace views are read-only. Browser creation, comment editing, reviews, checks and merging are not implemented; use the existing API for writes. Private repositories keep the same signed-in membership requirement across all these pages.

What happens outside the API is the World's door (/_twin/…, declared in the manifest): signing up, choosing a password, turning on two-factor authentication and reading the authenticator's code, making a personal access token, an organization, a GitHub App or an OAuth app, and a runner starting and completing a workflow run.

What it leaves out

Every operation no in-scope application and no life step reaches: the manifest's unmodeled (the rest of Actions, Pages, deployments, attestations, Dependabot and code scanning, Projects, search, forks, transfers, branch protection, issue locks), the GraphQL root fields beyond repository and the five mutations, and the browser download of a release's latest asset, which install.sh fetches. Where GitHub documents more than the twin does, the twin 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 its own repository. Its standing is twin-packs-p3's generated STANDING.md.

Set up this release

Use Node 22.6 or newer. Install this exact starter cohort in your app folder:

npm install --save-dev --save-exact @volter/world@3.0.158 @volter/world-core@3.0.148 @volter/world-runtime@3.0.156 @volter/world-console@3.0.149 @volter/twin-github@3.0.8

In your app’s folder, initialize a World with this implementation:

./node_modules/.bin/volter world init --name my-app --twins github --source github=@volter/twin-github

Review the detected vendor and retain the generated bindings. The github service’s source must select this version:

{
  "source": {
    "package": "@volter/twin-github",
    "version": "3.0.8"
  }
}

This is the source field, not a complete config. Keep the installed version, lockfile and generated service source in agreement. Use the release README for throwaway SDK credentials, seeds and limits.

The assessment records its own earlier tool versions under Measurements. This setup uses the current starter cohort.

Run your app’s own test command inside the World:

./node_modules/.bin/volter world up
./node_modules/.bin/volter world run -- npm test
./node_modules/.bin/volter world log
./node_modules/.bin/volter world down

down stops compute and retains state.

Versions and implementations

Evidence for 3.0.8

Installed first use · Passed
Installed first use
Passed
Fresh app installation
Verified
Workflow scope
Exact installed artifact; normal CLI initialization, unchanged SDK, result assertions and retained-state read-only resume where applicable
Customer SDK versions
@octokit/rest@22.0.1
CLI, kernel and runtime versions
@volter/world@3.0.147 · @volter/world-core@3.0.147 · @volter/world-runtime@3.0.147
World clock
{"mode":"wall"}
Retained-state readback
Verified
Stopped compute
Verified
Customer journey failures
0
API coverage, replay and browser measurements

Counts describe the declared HTTP surface, not separate command tables or other protocols. Consult the release README for those workflows.

Assessment scope
packaged-customer-journey; in-process
Declared HTTP surface
94 served · 1433 gaps · 1527 declared operations
Exercised HTTP operation coverage
Not measured
Journey steps
333 answered / 360 steps
Replay
Equal across 2 runs
Journey failures
0
Browser target
Not measured
HTTP operations exercised through Chromium
Not measured
Chromium journey replay
Not measured
Browser response observation
Not recorded
Application-origin CORS coverage
Not measured
Native cookie-jar coverage
Not measured
DOM coverage
Not measured
Source code coverage
Not measured
State transition coverage
Not measured
Conformance results
  • decided: 0 failures · every served operation is decided with its demand; every demanded and every refreshed operation is served
  • published: 0 failures · what a release publishes holds every unit: its manifest, its spec and its journeys
  • cited: 0 failures · every vendor fact cited is recorded as a page that answered, each quote found on it
  • refresh: 0 failures · every stored resource of a vendor-backed unit declares how it is read back, and a unit that sends events ingests the vendor's
  • registered: 0 failures · a vendor-backed unit, lane or not, reaches the registered pack's state system
  • allowance: 0 failures · a rate budget above the fallback rests on the vendor's documented allowance, cited in its manifest
  • client: 0 failures · driven by the vendor's own client (its official SDK), served as a World runs it, the vendor's documented behaviour holds · 2 case(s) through the vendor's client
  • life: 0 failures · the life walked over HTTP against the pack served as a World runs it, with its scenario: every check held
  • standalone: 0 failures · served by its server.ts as a World runs it, the pack answers HTTP and the boot probe, and each declared socket upgrades
Publisher, admission and provenance
Source commit
3126733e2e8f157597cf50df0ab99d9b28b9f87e
Catalog record commit
a650bcea1c3c93375850e35c0c31aa8a0d143b6e
Package integrity
sha512-hef93gs6lT+FrALkl4dnR3KoSvrZh+wTTG2ZEdh+QO3THaDd5ruFgYJiIQnWzph0ptISVhCmpRWFrQ2Lt/i6eg==
Admission mode
Trusted internal publisher · maintainer merge
Catalog assessment
Bundled report checksum verified
Assessed at
Not recorded
Assessment input head
a650bcea1c3c93375850e35c0c31aa8a0d143b6e

Read the catalog snapshot

Catalog snapshot · @volter/twin-catalog@0.2.62
Source commit
2d891e44624083a0ee54c058f1a566f050f38f1e
Catalog digest
72cc7d129522aaa089c84552b9d0839ab4cb0924ee7bd56ab359f827cddaa258
Installer integrity
sha512-MelxBw6h8W8k67EMu7SlYXOPwg8Z0QVcpDNKEcMzB8gH4v0JfYK2vuL7WdXNY1epjPZqxyK/5pEvDCiRqU0nAA==

Snapshot identity and measurements