Design 47: the operator confirmed the releases as milestones (2026-10-18); release 1-2's issues and their order
This commit is contained in:
@@ -603,8 +603,8 @@ From ADR 0429 (research 063's done-when, and the live proof each of its releases
|
||||
|
||||
Milestones 1 to 6 were confirmed by the operator on 2026-10-17 (playbook 04), and 5b on 2026-10-18. Releases 1
|
||||
to 6 of ADR 0429 follow milestone 5b in its order, releases 1 and 2 as one milestone (ADR 0429 §7 allows it:
|
||||
they need nothing of each other); they wait for the operator's confirmation (playbook 04 step 5), and their
|
||||
issues are opened once it is given. Each milestone is one release of playbook 07; the next starts when the
|
||||
they need nothing of each other), and milestone 6 folded into release 4: confirmed by the operator on 2026-10-18
|
||||
(playbook 04 step 5). Release 1-2's issues are opened; each later release's are opened when it is prepared. Each milestone is one release of playbook 07; the next starts when the
|
||||
previous one's delivery is done, and a release's clauses of ADR 0429 hold from its delivery (§21). Every
|
||||
release reports the controller's code lines against research 063's baseline (acceptance test 20).
|
||||
|
||||
@@ -619,13 +619,13 @@ release reports the controller's code lines against research 063's baseline (acc
|
||||
| 5 | One read of a module on a node names the commit, build and rollout that put it there | 10, 12 | mesh-controller, mesh-catalog (mesh-config, nats) | 981 |
|
||||
| 5b | Decided: building and delivering leave the controller for parts that watch and write keys in the repository `mesh-delivery`, landing in six releases (ADR 0429); the forge module makes that repository from its config, protected before any team reaches it (ADR 0428) | — (ADR 0429 names them: 13 to 20) | hq, mesh-catalog (gitea) | 1117, 1124, 1128 |
|
||||
| 6 | Folded into release 4 by ADR 0429 §10: installed toolchains, builders fetching over SSH with their own key, and an SDK change shipping with its users are built in the builder's new home, so the builder is changed once | (2, 4: proved by release 4) | — | 979, 971 (moved to release 4) |
|
||||
| R1–2 | The operator sees every module on every node, with its fingerprint, phase and health, in `mesh-delivery-cli` and its web view, and a part that stops moving is raised as a condition within two minutes without a timer | 13, 14 | mesh-delivery (view, watchman), the node-engine (`mesh-host`: have keys; its alive message deleted), mesh-sdk (key layouts), mesh-controller (its silence timers deleted), mesh-catalog (zsh's `nox-delivery`) | opened once confirmed |
|
||||
| R3 | A group reaches the mesh as one source revision written by the gate, the operator's asks come through the teller and can be answered in the view, but for the merge's Approve, answered on the phone until its way in proves who answered (issue 953), and today's module mesh-delivery is split into its parts and ends | 15 | mesh-delivery (forge bridge, gate, teller, indexer), mesh-catalog (mesh-delivery split), mesh-sdk | opened once confirmed |
|
||||
| R4 | The controller asks no build: a build is keyed by its fingerprint, so a merge builds nothing its check built; with milestone 6, toolchains are installed, builders fetch over SSH, and an SDK change ships with its users | 16, 2, 4 | mesh-delivery (builder, checker), mesh-controller (build dispatch deleted; build-agent leaves), mesh-catalog (build modules, ssh-client, gitea), mesh-sdk | 979, 971; the rest opened once confirmed |
|
||||
| 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 | 17 | mesh-delivery (assigner), mesh-controller (grants keys) | opened once confirmed |
|
||||
| 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 once confirmed |
|
||||
| R1–2 | The operator sees every module on every node, with its fingerprint, phase and health, in `mesh-delivery-cli` and its web view, and a part that stops moving is raised as a condition within two minutes without a timer | 13, 14 | mesh-delivery (view, watchman), the node-engine (`mesh-host`: have keys; its alive message deleted), mesh-sdk (key layouts), mesh-controller (its silence timers deleted), mesh-catalog (zsh's `nox-delivery`) | 1131 (key layouts), 1132 (have keys), 1136 (credentials), 1134 (the view), 1135 (the watchman), 1137 (the alias) |
|
||||
| R3 | A group reaches the mesh as one source revision written by the gate, the operator's asks come through the teller and can be answered in the view, but for the merge's Approve, answered on the phone until its way in proves who answered (issue 953), and today's module mesh-delivery is split into its parts and ends | 15 | mesh-delivery (forge bridge, gate, teller, indexer), mesh-catalog (mesh-delivery split), mesh-sdk | opened when it is prepared |
|
||||
| R4 | The controller asks no build: a build is keyed by its fingerprint, so a merge builds nothing its check built; with milestone 6, toolchains are installed, builders fetch over SSH, and an SDK change ships with its users | 16, 2, 4 | mesh-delivery (builder, checker), mesh-controller (build dispatch deleted; build-agent leaves), mesh-catalog (build modules, ssh-client, gitea), mesh-sdk | 979, 971; the rest opened when it is prepared |
|
||||
| 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 | 17 | mesh-delivery (assigner), mesh-controller (grants keys) | opened when it is prepared |
|
||||
| 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 |
|
||||
|
||||
The issues are linked `depends-on` in this order; 976 depends on 975, and 979 also on 971. 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
|
||||
The issues are linked `depends-on` in this order; 976 depends on 975, and 979 also on 971. 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. 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
|
||||
operator on 2026-10-17), so the unit level holds its bound of ADR 0391; the integration level's sixty seconds
|
||||
|
||||
Reference in New Issue
Block a user