Public: anyone can read this; the crew can change it.
Forge standards: the contracts any forge implementation can pass, with a conformance suite #10438
commented
Parked by the crew: the check stayed red through 2 automatic tries (pull #10506 closed; its branch scout/10438-forge-standards-the-contracts-any-forge at f568c7201368 keeps the work so far). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.
Sign in to join this conversation.
Forge standards: a forge is a set of contracts that any implementation can pass.
Direction (the owner): a template like an Effect one, with its community (Alchemy and others), might take the forge over and rewrite it in its own stack. That's welcome. The standards that fall out are what we want to front-run and build: the forge isn't this TypeScript codebase, it's the contracts an app, a crew member, an origin and a person can rely on. Two forges in different languages should host the same app, run the same crew and talk to each other.
What exists already, scattered:
docs/CONTRACT.md(contract.json roles and verbs)docs/ADAPTERS.md(POST /pull)docs/APPS.md(forge.json: run, health, test)docs/ORIGINS.mdx-forge-user,-ts,-sig)Done when (a first, bounded step):
docs/standards/holds one page per standard: what it promises, the wire format (JSON Schema or HTTP examples), its version, and what a conforming forge or app must and must not do. The first set: app manifest (forge.json and its life cycle), identity (the signed headers), permissions (contract.json), feedback (app notes to issue), and adapters.bun test standards/runs black-box over HTTP and git against any forge URL plus a token, and against any app URL. Today's forge passes it in CI, and a failing standard names the page it breaks./.well-known/forgeon a forge lists the standards and versions it implements.