hq/01-RESEARCH/013-the-forge-and-the-registries/00-overview.md

status, initiated, touches

status	initiated	touches
active	2026-09-23	02-DECISIONS/0075-two-stores-and-which-provides-what.md 02-DECISIONS/0079-the-foundation-seats-are-named-after-their-servers.md 02-DECISIONS/0071-genesis-builds-from-a-mesh-that-already-exists.md 02-DECISIONS/0082-the-registry-is-reached-by-name-and-trusted-by-the-overlay.md 04-ISSUES/085-the-packages-port-given-at-genesis-is-not-a-setting/00-report.md 04-ISSUES/090-the-forge-module-does-not-take-over-the-forge-genesis-raised/00-report.md

013 — The forge and the registries: what a seat is for, and what it is not

The question, asked during the first migration: the mesh runs a forge that serves git and packages, an image registry, and a bootstrap forge genesis raises before any module exists. Should there be a mesh-scoped git seat, the way there is one for the store and the broker?

The short answer: no, and the question points at a different hole. A seat answers is there exactly one of you. Every symptom around the forge is about an address and a credential nobody resolves, which a seat does not answer. The mechanism that would answer it — a provision, with serves and a grant — already exists, is already used for the image store, and is already declared for packages. It simply has no consumer: the one module that needs it carries a literal instead.

See the survey for what the code does today, with evidence.

What was found

• A seat does exactly two things: it refuses a second claimant at resolution, and in one place it answers where is the broker. It is a resolution-time predicate; no host ever hears of it.
• Four mesh-scoped seats exist, all named after a singular server the mesh runs for its own working — controller, store, broker, catalogue. A forge is an application the world made, not part of that set.
• Nothing in the mesh requires git. There is no provision for it, and the forge's git service — over https and ssh — is declared nowhere. Only its npm half is a provision.
• package-registry is a fully built provision with zero consumers. The builder, its only real consumer, bypasses it with a file naming the module, the address 127.0.0.1 and the port.
• The builder is told where source lives, per build, by a person. The clone URL is an opaque string; each module remembers its own; no credential is ever attached; nothing polls a forge.
• A seat would forbid something the mesh should allow: a second forge — one for the mesh's own source, one for something else — which ADR 0075 already argues for against a node-scoped claim.

What this leaves open

• Should the forge's git service become a provision (source-forge), so the builder resolves the address and a credential the way it already resolves the image store? That is what would let a forge move, be renamed, or be replaced without editing every module's stored URL, and it is the unanswered half of issue 085.
• The obstacle is known and written down: such a requirement may go unanswered during genesis, and the mesh has no optional requirement. Deciding that is the real work.
• Should the mesh learn when a source moves? It records the fact and never discovers it: nothing polls, and there is no receiver for a forge's push. build --behind answers a question only a person can currently make true.