From 24fd567c31ba8000354fb99f73ea30ae38810ab1 Mon Sep 17 00:00:00 2001 From: jochen Date: Sun, 18 Oct 2026 00:29:35 +0200 Subject: [PATCH 1/2] Design 47: milestone 4 delivered and split; a fix of milestone 3 comes next. Playbook 07: new integration tests are read against the code before the first push (issues 980, 1082) --- 00-META/process/07-feature-branches.md | 5 +++-- 03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md | 7 ++++--- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index c9d4d8a5..b8528887 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -146,9 +146,10 @@ never into the running one, unless it blocks the running one. It says which round it is in ("round 1 of at most 3"). 3. **The report goes to the same fixing agents** that wrote the code, continued by their ids, so they fix with the context they already hold. Each answers the reviewer: what it changed, per finding, or why not. -4. **The reviewer reads the answers and the new commits**, and approves or reports again (step 5 says what a round +4. **Every new integration test is read against the code it drives before the first push.** It has never run: fixing agents only compile it, and its first run is the merge check, so each fault it hides costs a whole check. The reviewer traces each step of each new integration test through the code (fixtures against the manifest rules, what the store keeps and reads back, who holds a seat), and says which steps it could not trace. On 2026-10-17 a new test failed on its first three runs, a fixture and two faults of the change that reading it found only after a failed check. +5. **The reviewer reads the answers and the new commits**, and approves or reports again (step 6 says what a round may ask). After round 3 the lead stops and brings the operator what is left, with a recommendation. -5. **A finding outside the issues' done-when is never a change asked, in any round.** More hardening, a +6. **A finding outside the issues' done-when is never a change asked, in any round.** More hardening, a further case, a nicer form: the reviewer opens it with `issue-tracker.open` and names the number in its report, and the round does not wait for it. What a round asks is only what makes the change wrong against its issues and its decisions. 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 71cacbdc..5dd3506d 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] -updated: 2026-10-17 +updated: 2026-10-18 decisions: - "ADR 0421" - "ADR 0420" @@ -551,11 +551,12 @@ when the previous one's delivery is done. | 2 | A ready mark is acted on within seconds, and each pull request has at most one waiting check | 5, 6, 7 | mesh-controller, mesh-catalog (mesh-delivery, gitea) | 974, 975, 976 | | 2b | build-agent and route-proxy live whole in mesh-controller (ADR 0420, accepted 2026-10-17): the controller accepts a reviewed move, mesh-delivery announces each merge with its Approve, and the two modules move; built as two releases before the rule that a milestone is one release | — | mesh-controller, mesh-catalog (mesh-delivery, build-agent, route-proxy) | release 1: 1025; release 2: 1019 | | 3 | A feature with a new seat verb across the controller and the catalogue is one group, one batch, one delivery plan and one Approve: no order lines, no ready mark, each module built and sent once | 1, 6 | mesh-controller, mesh-catalog (mesh-delivery, gitea) | 977, 978, 1022, 895 (with 1046 folded into it: unit and integration tests split, each level within its bound); 605 (1021 closed as its duplicate) is resolved by this build (ADR 0419 §7) | -| 4 | A delivery backs up the data it moves first, and a failed backup holds it and is said | 3 | mesh-controller, mesh-catalog (mesh-delivery, the backup seat's holder) | 980 | +| 4 | A delivery backs up the data it moves first, and a failed backup holds it and is said | 3 | mesh-controller, mesh-catalog (mesh-delivery, the backup seat's holder) | 980, split into 1065, 1066, 1067, 1068 | +| 3 fix | A group approved together merges in one pass and goes out in one delivery plan, also when its members' tests read each other's repositories | 1 | mesh-catalog (mesh-delivery), mesh-controller | 1082, 1049, 1047, 1083, 1084 | | 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 | | 6 | Builds use installed toolchains with no container, builders fetch over SSH with their own key, and an SDK change ships in one group with its users | 2, 4 | mesh-catalog (build modules, build-agent, ssh-client, gitea), mesh-controller, mesh-sdk | 979, 971 | -The issues are linked `depends-on` in this order; 976 depends on 975, and 979 also on 971. Milestone 2b was +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. 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 From c10efa4d8c8f82e10a422544acc4f4716154a041 Mon Sep 17 00:00:00 2001 From: jochen Date: Sun, 18 Oct 2026 00:30:29 +0200 Subject: [PATCH 2/2] Playbook 07: the new test failed on its first two runs, not three --- 00-META/process/07-feature-branches.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index b8528887..8e64fef2 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -146,7 +146,7 @@ never into the running one, unless it blocks the running one. It says which round it is in ("round 1 of at most 3"). 3. **The report goes to the same fixing agents** that wrote the code, continued by their ids, so they fix with the context they already hold. Each answers the reviewer: what it changed, per finding, or why not. -4. **Every new integration test is read against the code it drives before the first push.** It has never run: fixing agents only compile it, and its first run is the merge check, so each fault it hides costs a whole check. The reviewer traces each step of each new integration test through the code (fixtures against the manifest rules, what the store keeps and reads back, who holds a seat), and says which steps it could not trace. On 2026-10-17 a new test failed on its first three runs, a fixture and two faults of the change that reading it found only after a failed check. +4. **Every new integration test is read against the code it drives before the first push.** It has never run: fixing agents only compile it, and its first run is the merge check, so each fault it hides costs a whole check. The reviewer traces each step of each new integration test through the code (fixtures against the manifest rules, what the store keeps and reads back, who holds a seat), and says which steps it could not trace. On 2026-10-17 a new test failed on its first two runs, on a fixture and then on a fault of the change; reading it against the code after the first failure found another fault, which would have failed a run too. 5. **The reviewer reads the answers and the new commits**, and approves or reports again (step 6 says what a round may ask). After round 3 the lead stops and brings the operator what is left, with a recommendation. 6. **A finding outside the issues' done-when is never a change asked, in any round.** More hardening, a