# Cursor Forge

**In plain language:** GitHub remains the golden repository today. The longer-term forge represents proposals, reviews, checks, runner work, releases, and artifacts as signed cursor and mailbox records so the collaboration layer can replicate without depending on one forge host.

This is staged interoperability, not a plan to reimplement Git or expose repository credentials to a browser.

## Phase 1 — GitHub as the golden edge

- source objects remain ordinary Git commits and trees;
- a capability-scoped service may create only a branch and draft pull request;
- GitHub Actions produce check and artifact receipts;
- human review plus repository rules decide merge;
- a signed Cursors release head names the accepted Git commit and built content root.

The cockpit can discuss and package a proposal, but cannot push directly to `main`.

## Phase 2 — publish forge activity into Cursors

Adapters translate GitHub events into signed, non-secret records:

- change proposal with base and head object IDs;
- review statement and requested changes;
- check request, runner lease, logs, and result receipt;
- artifact content roots and reproducibility evidence;
- merge decision and release publication receipt.

Tokens remain inside the adapter that needs them. Cursor records contain identities, scopes, hashes, outcomes, and receipts—not credentials.

## Phase 3 — mailbox-native forge

Participants exchange proposals and reviews through admitted mailboxes. Runners claim narrowly scoped leases, fetch content-addressed inputs, execute in constrained bodies, publish immutable outputs, and return signed receipts. Multiple forge views can project the same records as pull requests, patch queues, issue boards, Smalltalk change sets, or causal conversations.

## Phase 4 — provider independence

Once behavior, recovery, moderation, revocation, indexing, and usability are proven, GitHub becomes one compatible carrier and mirror rather than the only collaboration authority. A resurrection capsule can recover the repository object graph, accepted release head, forge mailbox horizon, and runner compatibility requirements from independent peers.

## Security boundary

An agent receives an attenuated proposal capability, never the root release key. A runner receives one job lease, immutable inputs, resource budgets, and an output mailbox. Publishing canonical core material requires a separate short-lived delegate chained to an offline root and constrained to one reviewed release.

See [Cursor Workbench](workbench.md), [Capabilities](capabilities.md), and [Storage machinery](storage-machinery.md).