0042 and 0043, as approved

0042 becomes the operator's own rule and stops there: every merge into the main branch is notified and approved. Notified means proposed and said out loud, not performed and mentioned; approved means a person says yes to THAT merge. Who performs it is not the thing worth constraining, which is what makes an agent merging its own work unremarkable — the checkpoint already happened. 0043 answers the question it did not: where the ordered list comes from. By hand today, in substrate.lock, because the first node has no control plane to derive anything from. Afterwards the control plane derives it from module assignments, resolved configuration, and what each module declares it needs — ordered by the dependency graph, which is research 011. So the record is complete on the consumer side and deliberately silent on the producer side, and that is a legitimate order to settle them in: the host must refuse what it does not understand whoever wrote it. One consequence that only appeared when the question was asked: if the graph turns out not to determine a total order, that is 011's problem and not the host's. The host is still handed a list and still applies it as given. Recorded because it is the seam where a future difficulty would otherwise try to migrate into tier 0. Both were marked accepted before they had been read. Approved now, so the field is true — which it was not when it was written.
2026-08-26 20:37:13 +02:00
parent bea052753e
commit 00d5ba8376
2 changed files with 36 additions and 10 deletions
@@ -28,25 +28,24 @@ approval."*
   which is worse, because the record then claims a review that did not happen.
 2. **Drop the rule for agents.** Rejected: the rule is right, and the failure it prevents —
   work merged with nobody having looked — is not one an agent is less prone to.
-3. **Name what the checkpoint actually is.** Chosen.
+3. **Require notification and approval, and stop there.** Chosen. Who performs the merge is
+   not the thing worth constraining.

 ## Decision

-**The checkpoint is a person deciding, not a person clicking.**
+**Every merge into the main branch is notified and approved.** Stated by the operator in
+exactly those terms, and the whole of the rule.

-An agent may merge its own work **when a human has explicitly approved that merge**. The
-approval is the review; the merge is bookkeeping that follows it.
+Notified: the merge is proposed and said out loud, not performed and mentioned. Approved: a
+person says yes to *that merge*. Who then performs it does not matter, which is what makes an
+agent merging its own work unremarkable — the checkpoint already happened.

-Without an explicit approval, nothing changes: the agent does not merge, and
-[§2](../00-META/how-we-build.md)'s *never open a pull request unprompted* continues to mean
-that a permissions list is not a request.
-
-**What "explicit" excludes**, because this is the half that can rot:
+**What approval is not**, because this is the half that can rot:

 - A standing permission granted once and cited forever.
 - An instruction to do the work, read as approval to merge it.
 - Silence.
- The agent's own judgement that the work is ready.
+- The author's own judgement that the work is ready.

 ## Consequences

@@ -85,6 +85,33 @@ A declaration names who it is for. A host that has an identity refuses one addre
 A host that has no identity yet — the first node, applying the bundle it carries — has nothing
 to check against and applies it.

+## Where the list comes from
+
+This record specifies what the host **accepts**. What produces a declaration is deliberately
+not settled here, and the reason is worth stating rather than leaving as an omission.
+
+**Today, and at stage 2: by hand.** `substrate.lock` is authored and pinned — a person writes
+the resources and writes the order. That is the first node's path, where there is no control
+plane to derive anything from.
+
+**Afterwards: the control plane derives it**, from three things it already holds — which
+modules are assigned to this node, what those modules' configuration resolves to, and what each
+module declares it needs.
+
+**And the order comes from the graph.** Each module expands to resources; the modules are
+ordered by their declared dependencies on one another. That is
+[research 011](../01-RESEARCH/011-the-module-graph/00-overview.md) — `requires`, `provides`,
+`excludes` — and a declaration is the graph's output, flattened for one node.
+
+So this record is complete on the consumer side and silent on the producer side, because the
+producer does not exist and its shape is what 011 is investigating. The consumer can be settled
+first because the host must refuse what it does not understand whoever wrote it.
+
+**What this means for ordering.** [ADR 0037](0037-the-host-applies-it-does-not-decide.md) puts
+the ordering decision in the control plane; 011 decides how the control plane makes it. If the
+graph turns out not to determine a total order, that is 011's problem to solve and not the
+host's — the host will still be handed a list, and will still apply it as given.
+
 ## Consequences

 - **Ordering is now a control-plane responsibility**, and getting it wrong is a class of bug