Order the records the way the system is learned

Jochen asked whether the order made sense. It did not -- it followed when
things happened to be decided, which after consolidation is fictional anyway
since record 5 alone folds decisions taken across a week.

Concretely wrong before: the domain statement sat at 8, after five engineering
rules; the constitution was scattered across 5, 12 and 17; the tiers landed at
15, 16, 21 and 22 with process records in between.

Now it walks: what the mesh is (1-3), its tiers from the bottom up (4-8), what
runs on them and how it gets there (9-10), how it is built (11-16), how it is
checked (17-18), how we work (19-23).

Two things made this safe rather than free. It is a permutation, not a
compaction, so the renames go through temporary names -- otherwise two files
want one slot and one is lost. And the reference rewrite is a single
simultaneous pass, because almost every number moved into a slot another number
was vacating; replacing one at a time would have cascaded and pointed things at
the wrong record while still resolving.

Verified: 284 [ADR NNNN](path) links across the repository, all with matching
text and target.

The ordering principle is now stated in 19 rather than left implicit -- the
repository already said "the numbering is the flow" about its folders, and
there was no reason for the records to be the exception.

01-RESEARCH/011-the-module-graph/00-overview.md

@@ -2,14 +2,14 @@
 status: graduated
 initiated: 2026-08-25
 became:
-  - 02-DECISIONS/0019-modules-and-the-graph.md
-  - 02-DECISIONS/0020-a-context-owns-its-store.md
+  - 02-DECISIONS/0009-modules-and-the-graph.md
+  - 02-DECISIONS/0008-a-context-owns-its-store.md
   - 03-DESIGN/01-to-be/06-the-control-plane.md
   - 03-DESIGN/01-to-be/07-the-substrate.md
 touches:
-  - 02-DECISIONS/0019-modules-and-the-graph.md
-  - 02-DECISIONS/0019-modules-and-the-graph.md
-  - 02-DECISIONS/0015-a-node-and-how-it-joins.md
+  - 02-DECISIONS/0009-modules-and-the-graph.md
+  - 02-DECISIONS/0009-modules-and-the-graph.md
+  - 02-DECISIONS/0004-a-node-and-how-it-joins.md
   - 03-DESIGN/00-as-is/02-modules-and-manifests.md
   - 03-DESIGN/00-as-is/10-module-catalogue.md
   - 04-ISSUES/007-an-installed-package-is-not-a-capability/00-report.md
@@ -21,9 +21,9 @@ touches:
 > *instantiation*, and both are **runtime** edges — they answer *what does this need in order to
 > run*. Delivery needs a different question answered — *what has to be rebuilt when this changes*
 > — and that is a **build** edge, fixed inside an artifact rather than negotiated when it runs.
-> Recorded by [ADR 0019](../../02-DECISIONS/0019-modules-and-the-graph.md), which also
+> Recorded by [ADR 0009](../../02-DECISIONS/0009-modules-and-the-graph.md), which also
 > notes what this effort's three entities turn out to be good for
-> ([ADR 0019](../../02-DECISIONS/0019-modules-and-the-graph.md)).
+> ([ADR 0009](../../02-DECISIONS/0009-modules-and-the-graph.md)).
 
 ## What is being investigated
 
@@ -74,12 +74,12 @@ What survives is narrower: three declarations that do not exist (`excludes`, a r
 capability, an interface with adapters), and two defects worth fixing whatever else is
 concluded — `provider:` is a dependency edge that is not read as one, which makes the closure
 for a working mesh come out without a database; and the resolver continues past a cycle and
-past a missing dependency, contrary to ADR 0008.
+past a missing dependency, contrary to ADR 0001.
 
-[ADR 0019](../../02-DECISIONS/0019-modules-and-the-graph.md) proposes
+[ADR 0009](../../02-DECISIONS/0009-modules-and-the-graph.md) proposes
 grouping modules by domain. [Research 005](../005-domain-grouping/analysis.md) measured that
 proposal and found its evidence holds in exactly one place — reachability — which
-[ADR 0016](../../02-DECISIONS/0016-the-node-host.md) has since absorbed
+[ADR 0005](../../02-DECISIONS/0005-the-node-host.md) has since absorbed
 into the host. The measured case for domain grouping has therefore been consumed by a decision
 taken for unrelated reasons, and what remains is fifty modules that co-change with nothing.
 
@@ -102,7 +102,7 @@ and abandoned in favour of one concept with facets, for a reason worth keeping:
 Filing decisions that follow from nothing are the disease research 005 measured. A second
 taxonomy would reproduce it.
 
-So [ADR 0019](../../02-DECISIONS/0019-modules-and-the-graph.md) survives, and the question
+So [ADR 0009](../../02-DECISIONS/0009-modules-and-the-graph.md) survives, and the question
 becomes what a module must be able to **declare**.
 
 ## The shape being investigated
@@ -111,7 +111,7 @@ Five declarations, of which two exist today.
 
 | Declaration | Today | Notes |
 |---|---|---|
-| **requires a resource** — a database, a bucket | yes | provisioning, [ADR 0019](../../02-DECISIONS/0019-modules-and-the-graph.md) |
+| **requires a resource** — a database, a bucket | yes | provisioning, [ADR 0009](../../02-DECISIONS/0009-modules-and-the-graph.md) |
 | **provides a resource** | yes | as above |
 | **requires another module** | **no** | the dependency edge — the graph's substance |
 | **excludes another module** | **no** | installing A makes B unavailable |
@@ -174,12 +174,12 @@ Struck-through rows are answered, with where. The rest are live.
 | ~~What does the graph **delete**?~~ | For the existing system: nothing, it is already there ([`analysis.md`](analysis.md)). For the design: the module/resource distinction, the interface as a kind of thing, capability checking as a separate mechanism, domain grouping, and — the first clear deletion — **grant kinds**, once a module may only be granted what it exclusively owns ([`worked-provider.md`](worked-provider.md)). |
 | ~~Is an interface a module, or a name?~~ | A **name**, and only where providers are genuinely substitutable. The adapter is what creates one; without an adapter there is a **tag**, which describes and does not bind ([`proposal.md`](proposal.md)). |
 | ~~Where do domain modules fit?~~ | They do not. There is core infrastructure — concrete modules named individually, not flavourable, nothing standing in front of them. |
-| ~~What happens to domain grouping?~~ | Superseded. Folders assert relationships; edges record them. What grouping was for is a tag and a query. [ADR 0019](../../02-DECISIONS/0019-modules-and-the-graph.md) is `proposed` and should be superseded rather than narrowed. |
+| ~~What happens to domain grouping?~~ | Superseded. Folders assert relationships; edges record them. What grouping was for is a tag and a query. [ADR 0009](../../02-DECISIONS/0009-modules-and-the-graph.md) is `proposed` and should be superseded rather than narrowed. |
 | ~~Is there one kind of edge?~~ | **No — two.** *Presence*, where a thing must exist, and *instantiation*, where a provider makes something for a consumer and hands back credentials. Instantiation implies presence, not the reverse. |
 | ~~When two modules provide one name, who chooses?~~ | Neither the consumer naming a node nor the consumer not caring. The consumer declares the **scope of its own need** — shared across its instances, or one each — the mesh binds, and the binding is written down and sticky. Where it is written follows the scope. |
 | ~~Can several modules share one database?~~ | **No.** A module is granted only what it exclusively owns — no shared writes and no read role on another's store, because reading couples you to its layout just as firmly. |
 | ~~What about a dashboard reading a dozen stores?~~ | **The rule is about contexts, not processes.** The mesh's own board reading the mesh's own store is the mesh showing its own data — not a boundary crossing. Everything inside a context reads its store freely; what is forbidden is a *different* context reading it. An earlier answer here was wrong. |
-| ~~Can every registry consumer be served another way?~~ | **Largely dissolves.** Of eighteen direct consumers, the owner keeps its database, node appliers are already stopped by ADR 0016, and the bulk are **foreign tenants** — thirteen tables across three contexts — who need to move out rather than read differently. |
+| ~~Can every registry consumer be served another way?~~ | **Largely dissolves.** Of eighteen direct consumers, the owner keeps its database, node appliers are already stopped by ADR 0005, and the bulk are **foreign tenants** — thirteen tables across three contexts — who need to move out rather than read differently. |
 
 ### Live
 
@@ -190,10 +190,10 @@ Struck-through rows are answered, with where. The rest are live.
 | What does a provider hand back? | Credentials and an address for a store; a command for a terminal. Same relation, different shape crossing it. |
 | Is provisioning one mechanism or two? | The mesh's own registry is provisioned **before there is a mesh**, so provisioning is part of the bootstrap and part of what the carried bundle expresses. At bootstrap the store is local; afterwards it is on another node. Same operation, both sides of a tier boundary. |
 | Is a tool surface one relation with two audiences, or two? | 56 of 126 modules carry tools — more than carry a service — and what consumes them is an **agent**, not a module. |
-| ~~Do the remaining cross-context reads want an interface or events?~~ | **Derived, not chosen.** Neither is SQL — that only ever runs against your own store. ADR 0015 makes disconnection ordinary, so anything that must work while disconnected cannot use a request and needs a local copy: a subscription. Anything where a stale answer is worse than none cannot use a subscription. |
+| ~~Do the remaining cross-context reads want an interface or events?~~ | **Derived, not chosen.** Neither is SQL — that only ever runs against your own store. ADR 0004 makes disconnection ordinary, so anything that must work while disconnected cannot use a request and needs a local copy: a subscription. Anything where a stale answer is worse than none cannot use a subscription. |
 | What does a consumer do about events it missed while disconnected? | Replay from a point, ask once for a full picture and resume, or rebuild. The question every projection has, and unanswered here. |
-| What happens to a grant when its consumer is removed? | Dropping is data loss; keeping is a leak. ADR 0016's removal rule does not obviously carry, because the thing lives inside another module's state. |
-| Is a declaration composed per node, from what that node reported? | Some configuration follows the hardware. Either the host fills a blank — deciding, against ADR 0016 — or the control plane composes from the node's inventory first. |
+| What happens to a grant when its consumer is removed? | Dropping is data loss; keeping is a leak. ADR 0005's removal rule does not obviously carry, because the thing lives inside another module's state. |
+| Is a declaration composed per node, from what that node reported? | Some configuration follows the hardware. Either the host fills a blank — deciding, against ADR 0005 — or the control plane composes from the node's inventory first. |
 | Would `excludes` and capability requirements actually be used? | Zero manifests declare either, which is equally consistent with *nobody needs them* and *nobody can express them*. |
 | What does an exclusion mean for something already installed? | Refuse the install, or surface the conflict and let it be decided. |
 | Are tiers a view of the graph, or a constraint on it? | If a tier is a computed level the word is a convenience. If *a tier may depend only on tiers below it* is to be enforced, it is a constraint and must be stated as one. |