Design 46: a settings walk sends the layer and no build, and stops before a data move (ADR 0344 v4)
mesh/merge-gate head 732e8bd4d940 merged into trunk 471f99344b8d — pass: the change touches no module of the mesh's graph
mesh/repo-check head 732e8bd4d940 merged into trunk 471f99344b8d — pass: its merge-check.sh passed
mesh/delivery delivered

This commit is contained in:
jochen
2026-10-13 16:50:09 +02:00
parent 417a50d06c
commit 732e8bd4d9
@@ -442,18 +442,21 @@ the factors are the router's state.
*2026-10-13, issue 641.* Approving a settings proposal is the act that makes it take effect. The
serving controller sets the layer and, in the same act, opens a **settings walk**: every machine
that runs the module and that the layer reaches, the control node last, each sent and its module
judged at the first-node gate before the next. The send keeps every module whose policy is `record`
at the build its machine was last sent, so a held build stays held while the settings go out. The
walk says its start and end like every walk, so the operator is told once when it has landed, or
why it failed. A failure stops the walk and leaves the layer as approved; the previous layer is in
the settings history. The ask says all this before the Approve, and no longer names a push.
judged at the first-node gate before the next. A settings walk sends the layer and no build: every
module on the machine stays at the build it was last sent, so a build held for a person, or waiting
for a first-node gate, stays where it is. A send that would move a running module's data stops the
walk and names the `push --move` that sends it. The walk says its start and end like every walk, so
its end is told as every walk's is. A failure stops the walk and leaves the layer as approved; the
previous layer is in the settings history. The ask says all this before the Approve, and no longer
names a push. A layer set by hand still waits for a push.
A delivered file is not yet an applied one: a module whose program reads its settings only when it
starts applies them itself (a service's `restart-on`, or a tool of its own). Betterbird is such a
module; issue 643 makes it restart Betterbird at a quiet moment.
How it is checked: the controller's tests open the walk on the warrant, send one machine at a time
judging the module, stop on a failure without holding other walks back, and read the ask's words.
with every build kept and the module judged, stop before a data move and on a failure without
holding other walks back, and read the ask's words.
### Proofs and tiers