---
status: active
initiated: 2026-09-23
touches:
  - 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](the-survey.md) 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](../../04-ISSUES/085-the-packages-port-given-at-genesis-is-not-a-setting/00-report.md).
- 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.