From c255fd071cbc0d426e2f14bef8e94d4ee5e0f8f6 Mon Sep 17 00:00:00 2001 From: jochen Date: Mon, 26 Oct 2026 01:21:42 +0100 Subject: [PATCH] Describe delivery after release 6: as-is 04 and 13 follow wants, compositions and haves, design 47's acceptance tests restated (issue 1130) Release 6 is delivered, so the as-is designs still describing the controller's plans were wrong, and design 47's tests 1 to 12 named batches, plans and the merge window that no longer exist. --- 03-DESIGN/00-as-is/04-delivery.md | 140 ++++++++++++------ 03-DESIGN/00-as-is/13-the-console.md | 25 ++-- .../47-delivery-from-commit-to-delivered.md | 77 +++++----- 3 files changed, 150 insertions(+), 92 deletions(-) diff --git a/03-DESIGN/00-as-is/04-delivery.md b/03-DESIGN/00-as-is/04-delivery.md index 88141b40..c9cef330 100644 --- a/03-DESIGN/00-as-is/04-delivery.md +++ b/03-DESIGN/00-as-is/04-delivery.md @@ -1,12 +1,11 @@ --- layer: as-is status: implemented -code: [mesh-controller, mesh-delivery, mesh-catalog modules/gitea, mesh-catalog modules/mesh-build-go] -updated: 2026-10-24 +code: [mesh-delivery, mesh-catalog modules/mesh-delivery-gate, mesh-catalog modules/gitea, mesh-catalog modules/mesh-build-go, mesh-catalog modules/messenger, mesh-catalog modules/mesh-issues, mesh-controller, mesh-host, mesh-sdk] +updated: 2026-10-26 decisions: - "ADR 0239" - "ADR 0267" - - "ADR 0276" - "ADR 0282" - "ADR 0289" - "ADR 0304" @@ -17,71 +16,114 @@ decisions: - "ADR 0382" - "ADR 0395" - "ADR 0398" + - "ADR 0429" - "ADR 0524" - "ADR 0525" - "ADR 0527" - "ADR 0528" - "ADR 0529" + - "ADR 0539" + - "ADR 0547" --- # Delivery — from a merge to the nodes, as it runs -What runs on 2026-10-24, after the delivery of release 4 and release 5's first half (milestone R4g, design 47), -read from the live controller (`mesh-controller.modules`, `.seats`, `.plans`), the delivery checker's `checker_status` -and the machines' module lists. It is what [to-be 47](../01-to-be/47-delivery-from-commit-to-delivered.md) has not yet -finished: the node agent applying wants and the deletion of plans are release 6, and the controller still plans, -orders and sends a delivery's builds to the machines. Until 2026-10-23 this document described the pipeline with the -build agent, the build queue and the two statuses `mesh/merge-gate` and `mesh/repo-check`, which no longer run. +What runs on 2026-10-26, after the delivery of release 6 (milestone R6 of +[to-be 47](../01-to-be/47-delivery-from-commit-to-delivered.md), ADR 0539), read from the code on each repository's +main (`mesh-delivery`, the gate in `mesh-catalog`, the node agent in `mesh-host`, `mesh-controller`) and from the live +mesh: the controller's seat verbs, `mesh-controller.modules`, the gate's `table`, and the view's `assigner_wants` and +`node_haves`. Until 2026-10-26 this document described release 5, in which the controller still made a delivery plan +for each merge, ordered it in tiers and sent whole declarations to the machines; none of that runs any more. ## Who does what - **The parts of `mesh-delivery`** are modules of one repository, each a process with its own bus credential that - watches keys and writes keys (design 47, ADR 0429). Running now: the forge bridge (`mesh-delivery-forge-bridge`), - the indexer, the checker, the gate (`mesh-delivery-gate`, which holds the seat `mesh-delivery`), the teller and - the watchman on the control-node; the builder (`mesh-delivery-builder`) and the status view on the workstation; - and the assigner (`mesh-delivery-assigner`) on the home server (ADR 0524, ADR 0528). -- **The forge bridge** turns the forge's events into stream messages and is the only part that calls the forge. The - forge module (`gitea`, on the control-node) still announces them through the forge's system webhook. -- **The indexer** computes each module's fingerprint at the merge preview; **the builder** claims a build once per - fingerprint and orders it as an ask on the stream of the artifact's language. -- **The build modules** (`mesh-build-go` and `mesh-build-node` on three machines, `mesh-build-image` on one; ADR 0525) hold the - node seats `node-build-go`, `node-build-node` and `node-build-image`. Each pulls asks from the bus's work-queue - streams (deliveries first, then checks, then re-checks) while its node has a free slot of build capacity; no part - chooses the node. The seat `node-build-agent` and the module `build-agent` have no holder any more, and the seat - `mesh-build-machine` has none either. -- **The checker** (`mesh-delivery-checker`) runs the merge check: a change's tests through the build module of each - language, running only packages whose inputs changed, and writes the one status `mesh/check`. It also serves a - **try** (`checker_try`, `checker_try_read`): the same check on a pushed branch, before a pull request. `checker_status` - shows the steps in flight by node and the candidates still without a verdict. -- **The gate** merges a delivery group's pull requests once the check, the review and the operator's Approve agree on - the same heads. The forge requires no status on any repository (ADR 0534). The scripts `merge-check.sh` are gone from every repository (ADR 0529). -- **The assigner** composes the machines a change touches (the composition check the checker reads) and writes which - fingerprint each node should want, by its six rules; it only compares wants with what the controller sends. -- **The controller** (`mesh-controller`, on the control-node) plans, orders, sends and judges. It computes a delivery plan for the - files a merge changes, moves only modules whose build source changed with their build dependents, and writes the - chain's links it owns. On 2026-10-24 the seat still lists 64 verbs, `queue` and `replay` among them; whether - those still do work was not read here, and the build agent they served has no holder. + watches keys and writes keys (ADR 0429). Running now: the forge bridge, the indexer, the checker, the teller and the + watchman on the control-node; the builder and the status view (`mesh-delivery-view`) on the workstation; and the + assigner on the home server. The gate (`mesh-delivery-gate`, holding the seat `mesh-delivery`) is a module of + `mesh-catalog` and runs on the control-node. +- **The forge bridge** turns the forge's events into stream messages and is the only part that calls the forge; the + forge module (`gitea`) still announces them through the forge's system webhook. +- **The indexer** writes each module's fingerprint at the merge preview and at a trunk merge; **the builder** claims a + build once per fingerprint and orders it as an ask on the stream of the artifact's language. +- **The build modules** (`mesh-build-go` on all four machines, `mesh-build-node` on three, `mesh-build-image` on one; + ADR 0525) hold the node seats `node-build-go`, `node-build-node` and `node-build-image` and pull asks from the bus's + work-queue streams (deliveries first, then checks, then re-checks) while their node has a free slot of build + capacity. +- **The checker** runs the merge check and writes the one status `mesh/check`, and serves a **try** on a pushed + branch. The forge requires no status on any repository (ADR 0534), and no repository holds a `merge-check.sh` + (ADR 0529). +- **The gate** keeps one key per pull request and the merge's states only: `proposed`, `ready`, `rejected`, `held`, + `merged` and `closed`, read from its `table` verb. On the operator's Approve it merges a delivery group's pull + requests in one pass and writes their merged heads as one revision of `source.main`. It sends nothing to a + machine and asks the controller nothing. +- **The controller** (`mesh-controller`, on the control-node) keeps registration, placement in its assignments + bucket and every node's inputs, and composes: on events it writes each module's signed composition for each node at + each fingerprint into the node's bucket `composed-`, with its digest and its judgement of the move in + `mesh-controller_composed`, and it issues a module's credential and grant when its build is done. It plans, + orders and sends nothing: of its seat's 65 verbs, 20 are refused by name with their replacement, among them + `plans`, `plan`, `push`, `deliver`, `delivery-stop`, `delivery-order` and `delivery-walks` (read 2026-10-26 01:20). +- **The assigner** writes each node's want of each module, `want..`, naming a fingerprint and the + digest of the one composition it allows, when its seven rules hold: the build is done, the fingerprint is not + held, the node is the module's canary or the canary runs it healthy, at most `step` others ahead, every provider + runs healthy, the grant exists and the composition exists. In the code the canary is the first of the module's + nodes by name that is online (one ring), and rule 4 always holds, because the mesh keeps no `step`. It also runs + the composition check the checker reads. Its differences bucket, from release 5's comparison with what the + controller sent, is no longer written. +- **The node agent**, a process of the node-engine (`mesh-host`) on every node, watches its node's wants and its + bucket of compositions, and applies a module only when the want's fingerprint or digest differs from what runs, + and only the composition whose digest the want names, after checking its signature. It asks its node's + `node-backup` seat to back up a data module first and waits for the backup's end. It writes the have, + `have..` in `node-engine_have`, with the fingerprint, the composition's digest, the phase and the + health. A failed apply is retried by the next change of the want or the composition; an apply that failed only + because the bus did not answer for a moment is retried with a bounded backoff, and at once when the bus is back. +- **The watchman** mirrors every want as a pulse owed by that node's agent until its have names the want's + fingerprint, so a node that does not move shows as a stall. +- **The status view** derives from `source.main`, the wants and the haves whether the source revision is + delivered, and says the event `delivered` once per revision, and `moving`, `settled` and `stuck` once for a + module on a node at one composition. The messenger holds the operator's notices on those events, and the issue + tracker hears `delivered`. +- **The grants part** (`mesh-grants`, on the control-node; ADR 0547) publishes each assignment's membership on the + assignments stream when it differs from the one last published. The bus's user list, assertions and grants it + composes only in its own state, compared with what the bus holds, and they take no effect; the controller still + composes the user list the bus loads. -## From a merge to a delivery plan +## From a merge to the nodes -- A pull request's head is built and checked as it comes in. One status, `mesh/check`, carries the verdict; a delivery - group has one verdict for every member. A move of the trunk asks the checks again, and a running check stops itself - when its head or trunk commit moves. -- A merge is made by the gate on the operator's Approve; the controller then makes a delivery plan, tiered along the - module graph, and sends it. `mesh-controller.plans` lists the plans and the delivery plans' tiers; a plan that - fails on a node says so and is retried by hand. +- A pull request's head is built and checked as it comes in; one status, `mesh/check`, carries the verdict, and a + delivery group has one verdict for every member. A move of the trunk asks the checks again, and a running check + stops itself when its head or trunk commit moves. +- The gate merges on the operator's Approve and moves the source revision in one write. Nothing collects merges or + waits for others: the indexer writes the new fingerprints, the builder claims each new one once, the controller + composes and grants on the done build, and the assigner writes each want once its rules hold, the canary first. +- Each node applies its own wants one module at a time and writes its haves; the source revision is delivered when + every want equals its module's fingerprint and every have equals its want, running and healthy. Read on + 2026-10-26 at 01:20: 303 wants, every one equal to its node's have in fingerprint and composition digest, and 12 + fingerprints held. - **hq** builds no module: the checker runs hq's Go tests (`go test ./...`) as its check (ADR 0527). ## Where the record of what runs lives -Fingerprints, builds, verdicts and wants are keys in the bus's key-value buckets of the parts; builds' files are in -the artifact store by digest; packages are versions in the package registry. Plans, rollouts with their tiers, -assignments and settings are still rows in the controller's store. An assignment names its module and node but not -the build, artifact or plan that put it there. +Fingerprints, builds, verdicts, wants and haves are keys in the parts' buckets on the bus; compositions are in each +node's `composed-` bucket, readable only by that node, with a file over 64 KiB in the object store; builds' +files are in the artifact store by digest; packages are versions in the package registry. The controller's +assignments bucket keeps placement alone, and its rollouts bucket keeps the record of releases 1 to 5 read-only; +nothing writes it now. ## What is not covered -The node agent does not yet apply wants: a node runs what the controller sent. The checker's left-running keys of -build modules that stopped (`checker_status`'s `left_running`) are listed and hold no place. The integration tests run -in each repository's check; there are no end-to-end tests of delivery yet, and the lab is not used (the operator, -2026-10-16). +Nothing checks the delivery budget: the over-budget condition and the gate's `times` went with release 6, and no +reader of the view's `settled` and `delivered` events measures it yet (issue 1945, note 10). The bus's own move stays +a person's step through the controller's `bus` verb (ADR 0539 §15). The checker's left-running keys of build modules +that stopped (`checker_status`'s `left_running`) are listed and hold no place. There are no end-to-end tests of +delivery, and the lab is not used (the operator, 2026-10-16). + +## How it is checked + +- `mesh-delivery-view.assigner_wants` and `mesh-delivery-view.node_haves`: each want beside its have; `indexer_modules` + and `builder_builds` for the fingerprints and builds they name. +- `mesh-delivery.table`: the gate's states and transitions; `mesh-delivery.deliveries` and `show` for one delivery. +- `mesh-controller.seats` and `mesh_overview`: the controller's verbs, and which are refused by name. +- The code: `mesh-delivery` (`modules/mesh-delivery-assigner/internal/assign`, `modules/mesh-delivery-view/internal/view`, + `modules/mesh-delivery-watchman/internal/watch`, `modules/mesh-grants`), `mesh-host` (`internal/agent`, + `cmd/mesh-host/nodeagent.go`), and the gate in `mesh-catalog` (`modules/mesh-delivery-gate`). diff --git a/03-DESIGN/00-as-is/13-the-console.md b/03-DESIGN/00-as-is/13-the-console.md index 1412a7a5..2e4de918 100644 --- a/03-DESIGN/00-as-is/13-the-console.md +++ b/03-DESIGN/00-as-is/13-the-console.md @@ -2,8 +2,10 @@ layer: as-is status: implemented code: [mesh-tools, mesh-host, mesh-controller] -updated: 2026-10-24 +updated: 2026-10-26 decisions: + - "ADR 0539" + - "ADR 0360" - "ADR 0524" - "ADR 0525" - "ADR 0152" @@ -21,17 +23,20 @@ decisions: through `mesh_overview`, `mesh_machine`, `mesh_runtimes` and `mesh_describe`. Checked: the catalogue (`mesh-catalog`) carries no module named `mesh-console` any more — the name survives only in the glossary's retired-words list and in a test fixture — and none of the four nodes answers a -module of that name. +module of that name. How the tool runner reaches a node, its count of modules and tools and the +controller's verbs were read again on 2026-10-26, after the delivery of release 6 (ADR 0539). ## What it is now **The tool runner is one of the mesh's core components**, named `node-tools` beside `mesh-controller`, `mesh-host` (the node-engine) and `nats` (the bus) — the mesh's own repositories' check treats the four the same way, as the core whose health the mesh itself defines rather than a -module's own. `mesh-host` and `mesh-controller` supervise, compose and account for it as a core -process rather than as an ordinary assignment (`ComponentNodeTools`/`BusNodeTools` in both, the -witness and lease code that restarts and rolls it back, the account named `.node-tools` on -the bus). +module's own. Since release 6 it reaches each node the way every module does: the controller composes +and signs its composition for that node, the assigner writes the node's want of it, and the +node-engine's node agent applies it and writes its have. What stays particular to it is the account +named `.node-tools` on the bus (`BusNodeTools` in `mesh-controller`) and the node-engine's +witness and lease code that puts back a tool runner that does not come up (`ComponentNodeTools` in +`mesh-host`, ADR 0360 §9). **It still carries a manifest, `node-tools/module.json` in `mesh-tools`,** and that manifest is where its grants live: `invokes` names `*`, so its account may call every tool on the mesh; @@ -60,7 +65,7 @@ body per request, no session and no event stream (`node-tools/internal/console/m `mesh_machine`, `mesh_search`, `mesh_describe`, `mesh_call`, `mesh_runtimes` and `mesh_wait`. The handshake's `instructions` text names all seven and the four address forms. `mesh_overview` is where the mesh-wide count of modules and tools is read live — a number copied into this document -would drift; asked on 2026-10-17 it answered 103 modules and 645 tools across the whole mesh, with +would drift; asked on 2026-10-26 it answered 115 modules and 714 tools across the whole mesh, with two module instances (`route-proxy` on two of the nodes) named as not answering rather than silently absent. @@ -94,8 +99,10 @@ command, not inline, because one call blocks until it answers or times out. **These already answer directly, not as a stated future.** Beside every assigned module's tools, the tool runner asks the `mesh-controller` seat for its own verbs the same way (ADR 0154): measured -live, the mesh-controller runtime is one instance, mesh-wide, and it answers 64 verbs for that one -seat (`status`, `push`, `assign`, `build`, `artifacts` and the rest), and the `mesh-controller` +live on 2026-10-26, the mesh-controller runtime is one instance, mesh-wide, and it answers 65 verbs for +that one seat (`status`, `assign`, `modules`, `artifacts` and the rest), of which 20 are refused by +name with what replaces them: the delivery verbs release 6 removed (`plans`, `plan`, `push`, +`deliver` among them) and the build verbs of release 4 (`build`, `queue` among them). The `mesh-controller` *module* answers none of its own — it serves no module tools, only its seat's, exactly as design 33 described while it was still only designed. The 56-to-93 seat-verb counts each node's tool runner answers (below) are a different thing: the tool runner serves the verbs of whichever node-scoped diff --git a/03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md b/03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md index c23482c3..a9c78ddb 100644 --- a/03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md +++ b/03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md @@ -2,7 +2,7 @@ layer: to-be status: in-progress code: [mesh-controller, mesh-catalog modules/mesh-delivery-gate, mesh-delivery, mesh-host, mesh-sdk, hq 00-META/checks] -updated: 2026-10-24 +updated: 2026-10-26 decisions: - "ADR 0539" - "ADR 0536" @@ -172,8 +172,8 @@ It lands in six releases, each leaving the mesh working, each one milestone belo 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). Release 6's were -rewritten when it was prepared, from ADR 0539: until its delivery the plans of release 5 run, as the as-is -design says, and ADR 0539's clauses hold from that delivery (ADR 0539 §20). +rewritten when it was prepared, from ADR 0539, and its acceptance tests restated after its delivery; release 6 +is delivered, so ADR 0539's clauses hold (ADR 0539 §20), and the as-is design describes the delivery as it runs. ## The parts @@ -740,23 +740,22 @@ the operator for the bus node's want (ADR 0539 §15). - **A build before its want.** 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 under the assigner's first rule and fails nothing (ADR 0524 §7, ADR 0539 §18). -- **The switch to release 6 is one plan, release 5's last.** Release 5's controller runs the group's plan with - the new node-engine and the new controller in one tier (issue 1942), so every node's last declaration names - the new node-engine and carries the operator's public key, and the control-node's names the new controller - too. Each node applies it with the node-engine it runs; the new controller writes every composition at its - start, and the assigner's wants equal what runs. For that plan one machine at a time yields: each new - node-engine is judged by its launcher, and the new controller by the node-engine's witness. A node away during +- **The switch to release 6 was one plan, release 5's last** (history: it is delivered). Release 5's controller ran + the group's plan with the new node-engine and the new controller in one tier (issue 1942), so every node's last + declaration named the new node-engine and carried the operator's public key, and the control-node's named the new + controller too. Each node applied it with the node-engine it ran; the new controller wrote every composition at + its start, and the assigner's wants equalled what ran. For that plan one machine at a time yielded: each new + node-engine was judged by its launcher, and the new controller by the node-engine's witness. A node away during the switch finds its last declaration on the bus's stream of declarations when it returns; the controller - deletes that stream and the nodes' consumers only once every node's have names the new node-engine. The - merge waits until every node is present (ADR 0539 §11). The switch works only because the bus's user list that - release 5's controller composes already grants what release 6 uses: the controller writing compositions and + deletes that stream and the nodes' consumers only once every node's have names the new node-engine. The merge + waited until every node was present (ADR 0539 §11). The switch worked only because the bus's user list that + release 5's controller composed already granted what release 6 uses: the controller writing compositions and their digests, each node-engine reading its own compositions and wants, asking its backup holder and hearing the - backup's end, the assigner reading the digests, and the operator's account writing the hand path. That grant is - delivered first by release 5's controller, like issue 1942, as issue 1945's fix before the switch. The - node-engine's setting `operator-signers` must hold the operator's public key before the switch, or no operator - key is trusted and the hand path cannot work (ADR 0539 §3). At its first start the new controller deletes the - buckets of plan state (the merge window's, the silent sends' and the building plan's hold) and says each - deletion as its event (ADR 0539 §13). + backup's end, the assigner reading the digests, and the operator's account writing the hand path; that grant was + delivered first, as issue 1945's fix before the switch. The node-engine's setting `operator-signers` holds the + operator's public key, or no operator key is trusted and the hand path cannot work (ADR 0539 §3). At its first + start the new controller deleted the buckets of plan state (the merge window's, the silent sends' and the + building plan's hold) and said each deletion as its event (ADR 0539 §13). ### Delivering the controller, the builder or a build module without the builder @@ -790,28 +789,37 @@ way is written down before the switch (ADR 0526, which ADR 0522 §6 asked of R4g What the build proves before this design is implemented (research 055's direction): 1. A feature across the controller and the catalogue with a new seat verb is delivered as one group, with no - `after:` line, one composed check, one Approve and one delivery plan: its merges are one batch, each module is - built once and sent once, its commits are carried by that one plan, and the plan names the edge that placed - each tier. + `after:` line, one composed check and one Approve: its merges move one source revision, each module it changes + is built once, and every want naming one of those fingerprints is written by the assigner's seven rules, with + no order written by anyone. 2. An SDK change and a Go module using it are delivered as one group. -3. A data module is backed up before a delivery moves it, and a failed backup holds the delivery. +3. A data module is backed up by its node's backup seat before the node agent applies a new fingerprint of it, + and a failed backup holds that module on that node, its have in phase `held`, while every other want moves. 4. A build on any builder uses the installed toolchain with no container, and a toolchain update rebuilds only modules of that language when its version changes. 5. Two merges into one repository within a minute leave each open pull request with one queued check, by the stream's rule. 6. The operator's Approve is asked within seconds of the event of a pull request's checks passing, with no ready mark, label or comment written by anyone. -7. A controller replaced in the middle of a rollout resumes it with no step lost or repeated. -8. The merge window closes by its key's expiry. -9. A hotfix to a module the running feature's delivery does not touch reaches the machines in minutes, beside it. -10. For any module on any node, one read of its assignment names the commit, build, artifact or package and the - rollout that put it there, and one read of that rollout lists every assignment it changed. -11. Two merges into one repository while a delivery of that repository runs are both delivered by the next plan, - with no person's release and nothing held in mesh-delivery. -12. No table in the controller's store holds builds, rollouts or assignments. +7. A controller, an assigner or a node agent replaced while a source revision is being delivered carries on from + its keys: no composition, want or have is lost, and no module is applied again whose have already equals its + want. +8. Nothing collects merges: a merge moves the source revision in one write, and the assigner writes the wants it + allows with no window, no key's expiry and no timer between them. +9. A hotfix to a module that the source revision being delivered does not touch reaches the machines in minutes, + beside it: its wants move on its own build, canary and providers. +10. For any module on any node, one read of its have names the fingerprint and composition it runs, one read of + its want the same or what it should run, and the fingerprint names the source revision, the build and its + artifact or package. +11. Two merges into one repository while its modules are moving are two source revisions: a node is wanted the + newer fingerprint once its rules hold, a fingerprint nobody wants any more is never applied, and nothing is + released by a person or held in the gate. +12. No table in the controller's store holds builds, deliveries or assignments: builds are the builder's keys, + wants the assigner's, haves the node agents', and placement the controller's assignments bucket. -Tests 1, 3, 7, 8, 9, 10 and 11 were proved by the milestones that built them, on the plans and rollouts of their -time; from release 6, tests 18 and 19 prove what of them still holds without a plan. +Tests 1 to 12 are stated as they hold from release 6. Tests 1, 3, 7, 8, 9, 10 and 11 were first proved by +milestones 1 to 5 in the shape of their time, the controller's plans and what it sent (the milestones table keeps +it); restated, they are proved again by release 6's tests 18 and 19. From ADR 0429 (research 063's done-when, and the live proof each of its releases names): @@ -821,8 +829,9 @@ From ADR 0429 (research 063's done-when, and the live proof each of its releases 15. A group of two repositories merges as one source revision, and every module's fingerprint the indexer writes equals the controller's source fingerprint. 16. A merge builds nothing its check built, and a hotfix's build waits for no other build. -17. A day of deliveries shows no difference between the assigner's wants and what the controller sent that the - six rules do not explain. +17. A day of deliveries in release 5 showed no difference between the assigner's wants and what the controller + sent that the six rules then in force do not explain; the differences bucket is kept read-only as that + evidence (ADR 0539 §8). 18. On the live mesh a milestone of three repositories reaches every node through the keys alone (research 063's scenario A), and the assigner replaced in the middle of it resumes with nothing lost or repeated (scenario D, once).