self-hosting, provisioning and delivery efforts, and the dotfiles origin

The identity provider is settled as not-substrate: the mesh does not
require one, tier 2 authenticates natively, and it is a hosted service
like any other. Four substrate services, not five. The tier test's second
step gains the verb that matters — can the control plane START without it,
not function fully without it.

That verb answers the forge and the registries. They are not substrate and
they are not duplicated: the control plane starts and manages nodes
without a forge, it just cannot change itself. One gitea module, tier 4,
and the mesh's own instance is distinguished by what it is bound to rather
than by being a different module — the same answer as postgres, from the
same test. It also buys a property worth having: if the forge dies the
mesh keeps running.

Delivery needing them is not an upward dependency, resolved the way the
constitution already says to: tier 2 declares requirements, tier 4
provides implementations, the binding is data. The mechanism is
provisioning, and the new idea is that the control plane is itself a
consumer.

Self-hosting therefore becomes a state the mesh REACHES, not a
precondition. A first node comes up from pinned external artifacts and
re-binds to internal providers once they exist. Today's mesh assumes the
second state from the first moment, which is why the first-node path needs
a script that papers over an impossibility and is the least-exercised code
in the system. Made explicit, the transition is also reversible.

Research 007 and 008 opened for the two areas flagged as important and
complex, scoped from the weaknesses the as-is layer already documents
rather than started blank.

And the origin: this began as a dotfiles repository. The first two days
adopt dotfiles, add per-node overrides, and introduce service symlinking
with an ignore file. The flat one-directory-per-tool catalogue, linking
over copying, adoption of already-configured machines, per-node overrides
and the desktop modules are all inherited rather than chosen for a mesh.
That is the single most useful fact for anyone changing the catalogue, it
strengthens ADR 0018 — the case for links was never made for a mesh — and
it explains research 005's silent fifty: dotfiles-era entries for one tool
never shared a domain because they never had one.

03-DESIGN/00-as-is/10-module-catalogue.md

@@ -62,6 +62,42 @@ addressed in principle by
 [ADR 0017](../../02-DECISIONS/0017-modules-outside-the-core-are-grouped-by-domain.md), which
 deliberately does not yet settle the domain list.
 
+## Where the shape came from
+
+The catalogue's shape is not arbitrary and it is not a series of mistakes. **This repository
+began as a dotfiles repository**, and most of what looks inexplicable is inherited from that
+directly.
+
+The evidence is in the first two days of history: *adopt desktop dotfiles and scripts from the
+original dotfiles repository*; *per-node dotfile overrides*; *service symlinking, node
+`.dfignore`, headless server support* — all on 2026-02-24 and 2026-02-25, before anything
+resembling a mesh existed. Forty-five commits mention dotfiles.
+
+Read that way, several things stop being puzzles:
+
+| Feature of today's shape | Dotfiles ancestor |
+|---|---|
+| One flat directory per piece of software | Exactly how a dotfiles repository is organised |
+| **Linking rather than copying** as a stated design principle | How every dotfiles manager works — the whole category is built on it |
+| **Adoption** — taking over a machine that already exists, with its own configuration | The core dotfiles verb, and the reason a machine could be brought in at all |
+| **Per-node overrides** | Per-host dotfile overrides, generalised into per-node module settings |
+| Desktop and workstation modules — browser, file manager, editors, session, audio, personal scripts | Dotfiles content that became "modules" when modules became the only unit |
+| An ignore file controlling what is placed on a machine | A dotfiles manager's ignore file |
+
+The generalisation from *place files on my machines* to *manage a mesh of nodes* was the right
+move and it worked. What it did not do is revisit the assumptions underneath, because they were
+never stated as assumptions — they were just how the thing already worked.
+
+**This is the most useful single fact for anyone changing the catalogue**, and it is why the
+linking principle in particular reads as a deliberate architectural choice when it is an
+inheritance. See [ADR 0018](../../02-DECISIONS/0018-the-mesh-creates-no-symlinks.md), whose case
+this strengthens: the argument for links was never made *for a mesh*.
+
+It also explains the measurement in
+[research 005](../../01-RESEARCH/005-domain-grouping/analysis.md). Fifty modules that never
+change alongside anything are not fifty missing domains — many are dotfiles-era entries for one
+piece of software, which never shared a domain because they never had one.
+
 ## Two properties worth keeping
 
 Whatever replaces the shape, two things about it are right.