novox/hq
18
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Design 47 says what R4g and R5 build as one milestone: asks on streams, the assigner's wants, hq's Go tests, the hand path (issue 1130)

Browse Source
This commit is contained in:
jschoubben
2026-10-23 15:15:18 +02:00
parent 47e78d8ff4
commit 75056fa931
1 changed files with 104 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files
03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md
+104 -38
View File
@@ -1,9 +1,16 @@
---
layer: to-be
status: in-progress
code: [mesh-controller, mesh-catalog modules/mesh-delivery, mesh-delivery, mesh-host, mesh-sdk]
updated: 2026-10-21
code: [mesh-controller, mesh-catalog modules/mesh-delivery, mesh-delivery, mesh-host, mesh-sdk, hq 00-META/checks]
updated: 2026-10-23
decisions:
- "ADR 0536"
- "ADR 0530"
- "ADR 0528"
- "ADR 0527"
- "ADR 0526"
- "ADR 0525"
- "ADR 0524"
- "ADR 0494"
- "ADR 0493"
- "ADR 0491"
@@ -109,8 +116,15 @@ source revision is derived from the keys: every **want** equals its module's **f
forge.
- **The indexer** computes each module's fingerprint at the merge preview and writes the candidates of each
group and the modules of the trunk.
- **The builder** claims a build by creating its key, once per fingerprint, and builds it; the builder is made in R4c from
build-agent's code, and build-agent builds the builder's own module beside it until R4g, then leaves (ADR 0453 clause 5). The builder builds only on nodes given a capacity above zero, which two nodes have at first; a capacity of 0 means never chosen (ADR 0478 §3, ADR 0485).
- **The builder** claims a build by creating its key, once per fingerprint, and orders it as an ask on the stream of the artifact's
language; it makes no artifact's bytes since R4e and chooses no node, because the build modules pull the asks (ADR 0498 §1, ADR 0525 §1, §4). From R4g it
delivers its own module, the build modules and the controller from its keys, and nothing falls back to build-agent, which is removed
in that milestone (ADR 0453 clause 5, ADR 0524 §5, §7).
- **The build modules** (`mesh-build-go`, `mesh-build-node`, `mesh-build-image`) each claim a node seat of their language
(`node-build-go`, `node-build-node`, `node-build-image`) and pull its asks on their node while the node has a free slot of its
**build capacity**, a setting of the node that the build modules read; a node at capacity 0, the control-node among them, pulls nothing
(ADR 0525 §2, §4, §5). One ask is one whole job on one node: the fetch, the build and the push of a fingerprint, or the fetch, the digest and
the levels of a check (ADR 0525 §3). A session may call a build module's tools on a named node (ADR 0525 §8).
- **The checker** runs the merge check on built artifacts: a change's tests, through the build module of each
module's language and by that language's convention, running only the packages whose inputs changed and
taking the kept verdict of the rest; it writes the change's one status (ADR 0444, ADR 0445, ADR 0447); it runs dark in R4c-5 (ADR 0484).
@@ -123,7 +137,9 @@ source revision is derived from the keys: every **want** equals its module's **f
It also runs the **composition check**: whether the machines a change touches still compose with it, read
from the keys the indexer and the builder hold and from what the controller keeps of machines, settings and
grants, with the composition it sends with (ADR 0446). Its module
is made in R4c for that check alone; its wants come in release 5.
is made in R4g, in one milestone with release 5: it writes `want.<node>.<module>` by the six rules in its own bucket, never deletes one, and
writes every difference between a want and what the controller sends with the rule that explains it (wants are only compared; the node agent
applying them is release 6); the controller writes `grants.<module>.<fingerprint>` where it issues a credential (ADR 0524 §4, ADR 0528).
- **The node agent**, the node-engine's own process, applies its wants one module at a time, backs up a data
module first, and writes its haves. A node's declaration is not bounded by one bus message: a file over 64 KiB
travels by digest in the bus's object store, in a bucket of that node's own that no other node can read, and a
@@ -137,7 +153,8 @@ Nine of these are modules of the repository `mesh-delivery`, prefixed `mesh-deli
repository is made by the forge module from its config (ADR 0428; issue 1128 makes the config value reach the
node at once). The reviewer stays the review agent's session.
It lands in six releases, each leaving the mesh working, each one milestone below (ADR 0429 §7). Until the
It lands in six releases, each leaving the mesh working, each one milestone below (ADR 0429 §7); releases 4 and 5 end in one milestone, R4g,
with one switch-over and no rehearsal (ADR 0524 §1). Until the
release that replaces it is delivered, each section from here to *The bootstrap* stays this design and its rule
(ADR 0429 §21); each is rewritten when the release that replaces it is prepared (issue 1130).
@@ -152,7 +169,7 @@ release that replaces it is delivered, each section from here to *The bootstrap*
(deliveries, groups, a key per │
pull request, the state table) ▼
node-engine on every node
builders (build seat) ◄── work queues: delivery builds, approve-asked checks, other checks ───────────────── (reports; backups first)
build modules (build seats) ◄── asks on streams: delivery, check, recheck ────────────────────────────── (reports; backups first)
```
- **mesh-delivery** (the seat `mesh-delivery`) owns hotfixes, features and milestones as deliveries and delivery
@@ -162,9 +179,8 @@ release that replaces it is delivered, each section from here to *The bootstrap*
- **The controller** keeps planning, ordering, registration, sending and judging. It writes the chain's
links it owns — builds, rollouts with their tiers, assignments — and the merge window's
keys, all on the bus, by compare-and-set, while it holds the lease.
- **The builders**, the holders of the build seat, build and check with toolchains installed on their node, as
the build seat's own account, and take their jobs from the bus's work queues, delivery builds first
(ADR 0405, ADR 0406).
- **The build modules** build and check with toolchains installed on their node, each as an account of its own, and pull
their asks from the bus's streams, deliveries first (ADR 0405, ADR 0525).
- **The forge module** (`gitea`) publishes every forge event on the bus through the forge's system webhook
(issue 729): pull requests updated, synchronized, merged and closed, and commit statuses; no label or comment
moves a delivery, and mesh-delivery subscribes to none (ADR 0421 §11). It sets statuses, keeps the delivery's view as one comment on the pull request, and appends
@@ -298,21 +314,25 @@ commit on the SDK's trunk or the head of an SDK pull request the forge holds, op
*ADR 0323, ADR 0350, ADR 0395, ADR 0406.*
- **Three work queues, taken in order.** Delivery builds go on a work-queue stream of their own; checks of pull
requests whose Approve is asked or given on a second (ADR 0421 §10); every other check on a third. A builder takes from the first, then the
second, then the third. Each check stream has one subject per pull request and keeps only the newest request:
a newer request replaces one still waiting, by the stream's rule. The fresh check of such a pull request, asked
on the merge path, is published on the second stream; a request left behind on the third for a head and trunk commit already
judged or running is acknowledged and dropped when taken, by reading the pull request's key. Nothing pauses the
worker or deletes and republishes a request (issue 558).
- **A delivery builds first.** While a delivery builds, the build seat takes no new check or try, so an Approve ask
may come later; a check already running finishes, and the oldest waiting check that has waited 30 minutes
runs next, one at a time (ADR 0483, which changes ADR 0406 §3).
- **Asks on streams, taken in order.** A build or a check step is an ask, a message on one of the work-queue streams of
the artifact's language, which the build modules of that language claim as the accepted kinds of their node seat: `delivery` for the
build of a trunk fingerprint, `check` for the build of a candidate's fingerprint, a new head's check and the checker's steps (a try is a
check ask), and `recheck` for the checker's re-judges after a move of the trunk (ADR 0525 §1, §2, ADR 0536 §4). A build module pulls
`delivery`, then `check`, then `recheck`, while it has a free slot of its node's build capacity, and no part chooses the node (ADR 0525 §4).
Each check stream has one subject per pull request and keeps only the newest request: a newer request replaces one still waiting, by the
stream's rule; a request left behind for a head and trunk commit already judged or running is acknowledged and dropped when taken, by
reading the pull request's key. Nothing pauses the worker or deletes and republishes a request (issue 558). The controller's three work
queues, `mesh-controller.queue` and its verbs are deleted; each stream's backlog and the age of its oldest ask are read from its
consumers, shown in the delivery view and watched by the watchman (ADR 0525 §9).
- **Nothing holds a check while a delivery builds.** The order of the streams is the only priority deliveries have: the controller's
key saying that a delivery builds, and the let-through of a check that waited 30 minutes, are gone, so during a large delivery an
Approve ask may come later (ADR 0525 §7, which supersedes ADR 0483).
- **A running check stops itself.** It watches its pull request's key and stops when the head or the trunk
commit in it moves, without asking the forge (issue 726). An ended check delivers no verdict, so none of its
builds is reused.
- **A failed builder loses nothing.** A job a builder took and never acknowledged goes to another builder
after its wait.
- **A failed build node loses nothing.** An ask a build module took and never acknowledged goes to another node by the
stream's own acknowledgement wait, with no timer of a part; a step's end is written on the build module's step key named
by the ask's id (ADR 0525 §6).
- **A change is built once** (ADR 0350). A check that passes also builds what its merge would move into the
artifact store's scratch namespace under a reuse key, and the plan of the merge commit copies the build of the
same key, named by the check's verdict, instead of building.
@@ -363,6 +383,13 @@ From its delivery, a check is this:
`mesh/merge-gate` and `mesh/repo-check`; the forge requires it and the gate reads it from R4f, the delivery in which
the checker's line is the only one (ADR 0447 §5); the checker writes it unrequired from R4c (ADR 0453 clause 4). ADR 0484 builds the dark half, the verdict, its line and its status, in R4c-5, as one delivery group of four repositories with the shared library a member, one composed check, one Approve and one delivery plan; for this milestone only, before R4e, a group may hold a mesh-sdk member (ADR 0494 §1, §2, which replace ADR 0484 §1 and change ADR 0482 §7): the checker records the status as an act it owes in its own bucket and the forge bridge, the only part that calls the forge, performs it; the checker judges the head merged onto the trunk, for pull requests into the trunk named main only and for hq none, and until the isolated run step exists (issue 1309) it runs a change's code without the sandbox, as today's checks do (ADR 0484 §2, §3, §5, §8, §11). `mesh/delivery-group` stays the delivery's view, not a required check. Wherever
this design says both checks passed, they read this one status.
- **hq is checked like any repository, by Go tests.** hq's four checks (records, the reading order's index, the development cycle and
the words) are Go tests in one package at hq's root module, which holds no other Go code; the checker runs them through the Go build
module at the unit level and within its bound (ADR 0527 §1, §4). The checker's exception for hq goes: an hq pull request gets a verdict
and `mesh/check` like any other, the forge requires `mesh/check` on hq's trunk in place of `mesh/repo-check`, and, with build-agent
removed, no part writes `mesh/repo-check` for any repository (ADR 0527 §2). hq's own pull request in R4g's group is judged by the script
on hq's main, run as today, so it adds the Go tests beside the Python checks; once the delivery is done and hq's trunk requires `mesh/check`,
a small fix deletes the Python checks and `merge-check.sh` (ADR 0527 §3, issue 1296).
- **What the status says.** Its line says the verdict, the tests run and kept at each level, the machines
composed, and how long each part took: waiting in the queue, cloning, the unit level, the integration level's
setup and its running, and the composition. A failure names the test or the machine first. The line links to
@@ -375,8 +402,7 @@ From its delivery, a check is this:
judged by its own bounds: the unit level by its running time (five seconds), the integration level by its
setup (thirty seconds) and its tests' running time (sixty seconds), measured and judged apart; the integration level's bounds fail a repository from its
first check that meets them (ADR 0453 clause 9). A
repository's `merge-check.sh` goes in R4g (ADR 0453 clause 8); hq, which builds no module, keeps its script until issue 1296 settles how
it is checked (ADR 0445).
repository's `merge-check.sh` goes in R4g (ADR 0453 clause 8). hq, which builds no module, is checked the same way (next bullet).
- **Only what changed runs.** The build module names, from the toolchain, everything each package's tests read,
and the checker keeps a package's passing verdict at each level under the digest of those inputs. A check
runs a package only when no passing verdict is kept under its digest; a check asked again after a failure
@@ -400,6 +426,8 @@ From its delivery, a check is this:
controller's self-check raises a condition until they agree. No judge is built from a change: a change to the
composition is proved by its own tests, a field only a newer composition reads goes out as optional first, and
the running composition refuses a manifest that uses a field it does not read, naming the field. What it fails on, and its warning past twelve rebuilt modules, are the composition check's, as they were the controller's composing check's (ADR 0446, ADR 0237 §2).
The assigner writes the verdict under the checker's hash of the heads it judged, in its own bucket, and the checker reads it into the
composition of its verdict, which says "not run" until the assigner's module exists (ADR 0528 §5).
## The Approve and the merge
@@ -539,24 +567,29 @@ delivery time.
*ADR 0267, ADR 0350, ADR 0405.*
- **One build module per language** (Go; Node and TypeScript) installs its toolchain as a declared package on
every node holding the build seat, pinned to one version that is the same on every builder. The toolchain
image and its module retire.
- **Every builder runs the same toolchain, and says so.** Each builder names its toolchain versions with every
build outcome, and the controller's self-check raises a condition while two builders differ.
- **Builds and tests run directly**, as the build seat's own account on its node, in no container. The
every node holding its node seat, pinned to one version that is the same on every build node. The toolchain
image and its module are removed in R4g: mesh-tools's module whose images hold the toolchains and the module of
the repository mesh-tools-go go, so no toolchain image and no module providing one remains (ADR 0524 §5, issue 979).
- **Every build node runs the same toolchain, and says so.** Each build module names its toolchain version with every
step outcome, and the controller's self-check raises a condition while two nodes differ.
- **Builds and tests run directly**, as the build module's own account on its node, in no container. The
build module of each module's language runs its tests by that language's convention; no repository's
script or toolchain line decides it, hq's alone excepted until issue 1296 (ADR 0445).
script or toolchain line decides it, hq's included (ADR 0527).
- **A judge has an account of its own, until release 4 is delivered (R4f).** Until then, a judge built from a sibling's
merge (ADR 0382 §3) is built and run as a second account of the Go build module, whose home, configuration and
cache the build seat's account cannot write, so a check's script cannot change it. From R4f no judge is
built from a change and the account is not made (ADR 0446 §5).
- **A module may ship its own Dockerfile.** A build module of its own builds the module's `image` artifact from it, rootless, with no root and no container runtime socket on the build node; a pull request's image is built and thrown away, and only a merged trunk commit's image reaches the registry, by digest. Until that module has taken over, build-agent builds images (ADR 0487).
- **A module may ship its own Dockerfile.** A build module of its own builds the module's `image` artifact from it, rootless, with no root and no container runtime socket on the build node; a pull request's image is built and thrown away, and only a merged trunk commit's image reaches the registry, by digest. From R4g that module is the only part that builds an image, and build-agent builds none (ADR 0487 §7, ADR 0524 §5); the other builds
are Go and Node programs, which their build modules build.
- **Every dependency comes by the version its lock file names**, checked against its checksum: the mesh's own
code from the mesh's forge, its own packages from its package registry, any other from its public source.
- **A builder fetches from the forge over SSH with a key of its own**, as the build seat's account, under a forge
account for that builder that reads the mesh's repositories and pushes nothing.
- **A build module fetches from the forge over SSH with a key of its own**, as its own account, under a forge
account for that module that reads the mesh's repositories and pushes nothing.
- **A build's reuse key** holds the installed toolchain's version and the build module's recipe version in place
of the toolchain image's digest, so a toolchain update rebuilds only the modules of that language.
of the toolchain image's digest, so a toolchain update rebuilds only the modules of that language. From R4g no
module's fingerprint takes the builder as an input: a change of the builder rebuilds nothing, and a change of how an
artifact is built is a change of the build module's recipe version; the switch itself rebuilds every module once and
moves only the modules whose artifact digest changed (ADR 0530).
## One chain, on the bus alone
@@ -641,6 +674,31 @@ and its files). A person has `plans go <plan> --why`.
- Any other plan waits for `deliver` while the seat has a holder on record; with none, the controller starts it.
- A replaced controller or mesh-delivery carries on from the bus: the keys, the queues and the durable
consumers hold every step, so nothing is lost or repeated (ADR 0406 §6).
- The controller takes every module, the builder's own and the build modules among them, from the builder's done key whose artifacts
all name a reference; a module whose key is not yet done waits, named in the plan, and never fails it (ADR 0524 §7).
### Delivering the controller, the builder or a build module without the builder
With build-agent removed, the mesh has no builder outside the cycle, so the way to deliver a part that cannot be delivered the usual
way is written down before the switch (ADR 0526, which ADR 0522 §6 asked of R4g's record). In this order, each step recorded:
1. **A revert, with no build.** A broken builder or build module is undone by reverting its change: the earlier source's fingerprint has a done
key naming references, so the delivery of the revert builds nothing. It needs the earlier artifact in the artifact store, which keeps a
recorded build's artifact while it is among its module's five newest or a definition names it (ADR 0526 §1).
2. **A build by a session's call.** A session calls the build module's fetch and build tools on one named build node (for Go, a fetch and then
a build with publishing on); the build module pushes the artifact to the artifact store and answers its reference, as it does for the
builder (ADR 0526 §2, ADR 0525 §8). `mesh-pack`, in mesh-sdk, builds and packs a Go bundle with the Go build module's recipe, so a hand
build has the build module's form; with the same Go version it has the build module's digest (ADR 0526 §5).
3. **A registration by reference, at the controller's terminal only.** The operator names the module, its repository, its path and each
artifact's reference at the controller's terminal, and the controller registers it with no builder key, recording the act with its why;
no verb reaches it (ADR 0526 §3).
4. **A controller that cannot take its own fix** is put on the control-node by hand: its hand build is registered as in step 3 and the
control-node is pushed with its plan read first. In the worst case the operator sends the control-node a declaration whose source and
digest are the hand build's, recorded as a declaration sent by hand, and registers it as in step 3 so that the next push keeps it
(ADR 0526 §4; the bootstrap of issue 1886).
5. **Copies kept outside the store.** Before a switch that moves the controller, the builder or a build module, the artifacts of the
running versions are kept outside the artifact store on two nodes, each by digest with its module, artifact, commit, Go version and the
steps that put it back, because the store's nightly collection removes a blob the controller did not record (ADR 0526 §6).
## Acceptance tests
@@ -720,10 +778,16 @@ development, the check's share about a minute):
- The controller's tables of builds, build requests, rollouts and their tiers, batches and merges, and
assignments; the record mirrors, probe D17's audit and healer H6 for those kinds (ADR 0408).
- At release 4's deliveries (R4f for the composing check, the judge and the two statuses; R4g for the scripts): `merge-check.sh` and its `# mesh-check-toolchain` line in every repository a module is
built from, hq's alone kept until issue 1296 (ADR 0445 §6); the controller's composing check, composing every
built from, hq's included once the delivery is done (ADR 0445 §6, ADR 0527 §3); the controller's composing check, composing every
machine from clones and throwaway stores (ADR 0446 §1, §6); the judge built from a change and the Go build
module's second account for it (ADR 0446 §5); and the two statuses `mesh/merge-gate` and `mesh/repo-check`
(ADR 0447 §1).
(ADR 0447 §1, ADR 0527 §2).
- At R4g's delivery (ADR 0524, ADR 0525): build-agent, its program, its module and its Dockerfile code; mesh-tools's toolchain
image module and the module of the repository mesh-tools-go; the seat `node-build-agent`, retired for the build modules' seats;
the controller's build queue, its three work queues and their verbs, the key saying that a delivery builds and the let-through of a
check after 30 minutes (ADR 0483, superseded); the fallback to build-agent for a module whose builder does not say it writes
references; the builder as an input of every module's fingerprint (ADR 0530); and the controller's per-node capacity choice, which the
build modules' own pull replaces.
## Milestones
@@ -763,10 +827,12 @@ release reports the controller's code lines against research 063's baseline (acc
| R4d | Four modules stop being built from a Dockerfile: route-proxy, nats, n8n and mail's autoconfiguration module (automx, replaced by a Go program), each rework its own release step, nats in a delivery of its own; free between R4a and R4e and never in the same delivery as another release (ADR 0452, ADR 0453 clauses 13, 14, 16) | — | mesh-catalog, mesh-controller (route-proxy), the node-engine (`mesh-host`: n8n's supplementary group) | the four image reworks, opened when it is prepared |
| R4e | The controller asks no build: a build is keyed by its fingerprint, the new form becomes the only one as one group, and a merge builds nothing its check built; builders fetch over SSH, so an SDK change ships with its users; the vendored copies leave mesh-controller and mesh-sdk; delivered only once the builder's artifact digests equal build-agent's (ADR 0453 clauses 2, 4, 5, 6) | 16, 2, 4 in part | mesh-controller (builds are no longer asked), mesh-delivery (builder), mesh-sdk | 979 (the installed toolchains; closed with the toolchain images in R4g), 1304, the controller asking no build (opened when it is prepared) |
| R4f | A pull request carries one required status that says what it proved and how long each part took; the controller's composing check and its replays are deleted with the two old statuses; the controller's deletions R3e makes possible go; each level's times are measured, and a bound fails a repository from the first check that meets it (ADR 0447, ADR 0450 §8, ADR 0453 clauses 4, 9, 10) | 21, 22, 23, 24 (the status; the scripts' absence is proved in R4g) | mesh-delivery (checker, assigner), mesh-controller (composing check, replays, `delivery-plan`, `forget-checks`, the asker `mesh-delivery` deleted), mesh-catalog (gitea) | 1299 (the composing check deleted; closes issue 709, the replays' socket), 1300, 1301, 1302 (one status), 1305 (ADR 0482 §8), 1318 |
| R4g | The clean-up: the scripts of the repositories a module is built from, build-agent with its socket and Dockerfile code, the toolchain images and the retired word for the composition check go; the builder's own module is delivered from the builder's keys (ADR 0453 clauses 5, 8, 10) | 4 (from R4g mesh-build-image, rootless, is the only part that builds an image: ADR 0487 §7), 24 (no `merge-check.sh` in a repository a module is built from) | mesh-controller (build-agent removed), mesh-catalog, mesh-delivery, mesh-tools (scripts deleted), hq | 1295 (`merge-check.sh` goes; the tests of 1293 and 1294 are R4c to R4e's), 979 (closed with the toolchain images), 1303 (the composition check's old word struck); 1296 (how hq is checked) is the operator's and undated by this release |
| R5 | The assigner writes what each node should run by its six rules, compared with what the controller sends, and the view shows every difference; the operator answers the asks that need no proof of who answered in the view (ADR 0437 §10) | 17 | mesh-delivery (assigner), mesh-controller (grants keys) | opened when it is prepared |
| R4g | The last milestone of release 4 and release 5 as one, with one switch-over and no rehearsal (ADR 0524 §1): builds and checks are asks on streams that each build node pulls when it has a free slot, deliveries first, with nothing holding checks and no controller queue (ADR 0525); the assigner is made with its composition check, writes each node's wants compared with what the controller sends and every difference, and the view answers the asks that need no proof of who answered (ADR 0528, ADR 0437 §10); no module's fingerprint takes the builder (ADR 0530); the scripts of the repositories a module is built from, build-agent with its socket and Dockerfile code, the toolchain images and the controller's build code go, and the builder delivers its own module, the build modules and the controller from its keys (ADR 0453 clauses 5, 8, 10; ADR 0524 §5, §7); the ways to deliver without the builder are recorded (ADR 0526); hq's four checks are Go tests (ADR 0527); the word for the composition check's predecessor is struck. Its pull requests are opened only after five readings, the revert path read, not shown on a test merge (ADR 0524 §3) | 4 (from R4g mesh-build-image, rootless, is the only part that builds an image: ADR 0487 §7), 17, 24 (no `merge-check.sh` in a repository a module is built from) | mesh-sdk, mesh-controller (build-agent removed), mesh-delivery, mesh-catalog, mesh-tools, mesh-tools-go, the node-engine (`mesh-host`), mesh-media-catalog, okioki, hq | 1887 (the flow), 1297 (the assigner), 1295 (`merge-check.sh` goes), 979 (closed with the toolchain images), 1296 and 1303 (hq's check, the old word struck), 1299, 1305, 1294, 1318 (the controller's deletions) |
| R6 | Each node applies from its wants, a new version reaches the module's canary first and the rest once it is healthy there, and the plans are deleted from the code | 18, 19 | the node-engine (`mesh-host`: the node agent), mesh-controller (plans deleted), mesh-delivery (the gate's delivery states go) | opened when it is prepared |
Release 5 (the assigner's wants, compared only) is not a milestone of its own: ADR 0524 §1 folds it into R4g, whose row above holds
it; release 6, the node agent applying the wants, stays the next milestone.
The issues are linked `depends-on` in this order; 976 depends on 975, and 979 also on 971. R3's prepare step on 2026-10-19 found ADR 0429 §20 contradicting itself and four release orders; ADR 0437 (accepted, the operator's Approve) cuts release 3 into R3a to R3d, each one release, and moves answering asks in the view to R5. R2c's prepare step on 2026-10-19 found one more order: the alive message is the only source of when the controller last heard a machine, which `nodes`, `node` and `status` read, so the controller takes that from presence (1183, R2c) and is delivered before the node-engine stops sending (1158, R2d); 1158 depends on 1183. In release 1-2, 1132 and 1136 depend on 1131, 1134 and 1135 on 1136, 1134 also on 1132 and 1128, and 1137 on 1134. Release 1-2 was confirmed as one milestone; its prepare step on 2026-10-18 found the release orders hidden in it, and the operator chose at 18:52 to cut it by them, so it is the milestones R1a to R2d above, each one release (the operator, 2026-10-19: a milestone is one release): an SDK change still ships before its users until R4e (ADR 0429 §10, ADR 0453 clause 2); a new key on the wire goes only to a node that says it reads it; a new repository's first module registers at its merge's Approve (ADR 0432, issue 1146); the bus gives the watchman connect events only through a system account (ADR 0431); and release 2's other gaps are settled by ADR 0433 and ADR 0434. A node that is down has no effect on a delivery and plays what it missed when it returns (ADR 0435, the operator, 2026-10-18; issues 1160, 1161). Milestone 3's first live group (milestone 4's, on 2026-10-17) held one Approve but merged in two passes and went out in two delivery plans: a member's tests read the other member's repository, so the first merge made the second's verdict out of date, and a closed group never asked its composed verdict again (issues 1049, 1082). The operator put a fix of milestone 3 after milestone 4 and before milestone 5 on 2026-10-18; acceptance test 1 is proved again by it. The operator put milestone 5b after milestone 5 and before milestone 6 on 2026-10-18, as an issue rather than a research effort; where the planning goes is settled by a decision record before it is built (issue 1117), and milestone 6's build changes are read against it. Milestone 2b was
put before milestone 3 by the operator on 2026-10-17. Milestone 3 builds ADR 0418, ADR 0419 and ADR 0421
(issues 977, 978 and 1022), and splits mesh-controller's unit tests from its integration tests (issue 895, the