55 lines
3.4 KiB
Markdown
55 lines
3.4 KiB
Markdown
---
|
|
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.
|