2026-08-26 18:37:43 +00:00
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