Design 47: release 1-2 is the six milestones R1a to R2c, each one release; playbook 04 splits a milestone that holds a release order (the operator, 2026-10-19)

2026-10-19 00:11:02 +02:00
parent f7915f7f29
commit d10965a341
2 changed files with 18 additions and 6 deletions
@@ -17,7 +17,11 @@ A design becomes **milestones**, and each milestone becomes **issues**:
 - **Milestones are cut by release order.** A milestone ends where one repository's change must be released before
  another can use it (a new manifest word before the catalogue reads it, an SDK change before its users, until
  design 47's milestones 3 and 6 lift those orders); the lead checks this when cutting, so no milestone needs a
-  second release.
+  second release. The orders to look for are those playbook [07](07-feature-branches.md) step 0 item 6 names (an SDK
+  change before its users, a new wire key before the node that reads it, the first module of a repository the catalogue
+  never built, a part that needs a decision first); a milestone cut by such an order may be usable only by the next one,
+  and says so in its outcome. A milestone the prepare step finds holding such an order is split into milestones in the
+  design, each one release, never carried as parts of one (2026-10-18: design 47's release 1-2 became six).
 - **An issue is one repository's part of a milestone,** sized so a fixing agent finishes it inside the
  milestone's development time. Issues that must land in order are linked `depends-on`.

@@ -4,6 +4,9 @@ status: in-progress
 code: [mesh-controller, mesh-catalog modules/mesh-delivery, mesh-delivery, mesh-host, mesh-sdk]
 updated: 2026-10-18
 decisions:
+  - "ADR 0435"
+  - "ADR 0434"
+  - "ADR 0433"
  - "ADR 0431"
  - "ADR 0429"
  - "ADR 0428"
@@ -603,9 +606,9 @@ From ADR 0429 (research 063's done-when, and the live proof each of its releases
 ## Milestones

 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), 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
+to 6 of ADR 0429 follow milestone 5b in its order, releases 1 and 2 first confirmed as one milestone (ADR 0429 §7 allows it:
+they need nothing of each other) and then split by their release orders into R1a to R2c (below), and milestone 6 folded into release 4: confirmed by the operator on 2026-10-18
+(playbook 04 step 5). The issues of R1a to R2c 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).

@@ -620,13 +623,18 @@ 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`) | cut A: 1131 (key layouts); cut B, one group of the node-engine and mesh-controller: 1132 (have keys), 1142 (the node-engine's check, its tests half), 1136 (the have bucket and its grants), 1145 (a module and a build per resource), 1146 (a new repository's first module registered at its merge's Approve), 1147 (the bus's connect events for the watchman); cut C: 1134 (the view), 1137 (the alias, in the view's manifest); cut D: 1153 (the stuck keys), then 1135 (the watchman) and the alive message's deletion |
+| R1a | The node-engine, the controller and the parts can read one layout of the have, presence, pulse and stuck keys: mesh-sdk ships it before its users | — (13, 14 need it) | mesh-sdk | 1131 (key layouts) |
+| R1b | Every node writes what it runs of each module, on its own keys and nobody else's, and the bus says to one part when a connection opens and closes | 13 in part | the node-engine (`mesh-host`), mesh-controller | 1132 (have keys), 1142 (the node-engine's check, its tests half), 1136 (the have bucket and its grants), 1145 (a module and a build per resource), 1146 (a new repository's first module registered at its merge's Approve), 1147 (the bus's connect events for the watchman), 1160 (a plan passes a machine silent at a middle tier), 1162 (the have bucket takes a node's facts) |
+| R1c | The operator sees every module on every node, with its build, phase and health, in `mesh-delivery-cli` (aliased `nox-delivery`) and its web view | 13 | mesh-delivery (view) | 1134 (the view), 1137 (the alias, in the view's manifest) |
+| R2a | The watchman and the controller can read one layout of the stuck keys: mesh-sdk ships it before its users | — (14 needs it) | mesh-sdk | 1153 (the stuck keys) |
+| R2b | A part, node or check that stops moving is raised as a condition within two minutes, with no timer in a part | 14 | mesh-delivery (watchman), mesh-controller | 1135 (the watchman), 1154 (a bucket whose keys expire), 1155 (running checks readable, with their start), 1156 (stuck keys raised; the silent check from presence), 1157 (a refused send key raised), 1159 (a long check is not stuck) |
+| R2c | The node-engine sends no alive message, and the controller reads presence alone | 14 | the node-engine (`mesh-host`), mesh-controller | 1158 |
 | 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. 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. Its prepare step on 2026-10-18 found three orders the cut had hidden, and the operator chose at 18:52 to cut it by them: an SDK change still ships before its users until release 4 (ADR 0429 §10), so the key layouts are cut A; a new repository's first module was registered only at the controller's terminal, so cut B also teaches the controller to register it at its merge's Approve (ADR 0432, proposed); and the bus had no system account, so the watchman could hear no connection open or close (ADR 0431, issue 1147). Release 2's other gaps (a bucket whose keys expire, a module raising a condition, the silent check without the alive message, a plan's wait for a report) are settled by ADR 0433, proposed, and built as cut D, its SDK part first. 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. 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 six milestones R1a to R2c above, each one release (the operator, 2026-10-19: a milestone is one release): an SDK change still ships before its users until release 4 (ADR 0429 §10); 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
 operator on 2026-10-17), so the unit level holds its bound of ADR 0391; the integration level's sixty seconds