From 1d7cfed47a57634b866c886994bfb5593129334a Mon Sep 17 00:00:00 2001 From: mesh-tools Date: Tue, 20 Oct 2026 17:57:57 +0000 Subject: [PATCH 1/2] Name ADR 0457 and ADR 0463 in design 47, and write the day's delivery lessons into playbook 07 Design 47's catch-up of merges nobody heard is decided by ADR 0457 and bounded by ADR 0463, so other sessions read them from its frontmatter. Playbook 07 gains four lessons from 2026-10-20: a Retry is never asked beside an Approve (issue 1408), an ask is named only after it is read on the router, a check's wait is read from its delivery and not the build queue, and a catalogue change removing a module is tried against the controller (issue 1406). --- 00-META/process/07-feature-branches.md | 16 +++++++++++++++- .../47-delivery-from-commit-to-delivered.md | 2 ++ 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index b0d12c06..e820c3aa 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -225,6 +225,10 @@ never into the running one, unless it blocks the running one. `Reviewed-by: at ` (the issue 1022 note gives its form). mesh-delivery reads it at every new head and puts it in the Approve's ask; a missing line, or one naming another commit, is said first in the ask. It is never a gate. + **A catalogue pull request that removes a module, or a subject a module names, is also tried against the + controller** (`mesh-controller.try` with mesh-controller's main), because the controller's own tests read the + catalogue: on 2026-10-20 mesh-catalog #381 removed the old delivery module, and every controller check failed + afterwards on a test of the catalogue's subjects until issue 1406 removed the name mesh-issues still listened to. 2. **The forge's merge checks run the integration tests again, as the gate** (`mesh/merge-gate`, `mesh/repo-check`). No second review: step 2 reviewed this tree. 3. **A check that fails** goes back to the same reviewer, continued by its id, with the failure, for **one more cycle** of step 2 with @@ -277,6 +281,12 @@ delivery: no machine receives it (issue 889 while it still starts one). The lead naming its pull requests, and removes what is left: no `feat/` branch and no `.work/` worktree survive. +**A failed plan's Retry is asked of the operator alone, never beside an Approve.** An Approve's merge starts a +plan, and the controller refuses a Retry while another plan runs; on 2026-10-20 the operator chose both at once, +the merge's plan started first, the chosen Retry was refused and nobody asked it again (issue 1408). So the lead +never tells the operator to answer a Retry while an Approve is open, and reads the failed plan again after the +answer: a Retry refused is asked again once the other plan ends. + ## Models | Who | Model | Why | @@ -300,7 +310,7 @@ on, with when it started and its bound. |---|---|---| | a fixing agent's issue | 30 minutes | ask it where it stands; split or take over | | the review | 15 minutes a round | ask the reviewer; stop at round 3 | -| a merge check | 15 minutes | read the build queue (`mesh-controller.queue`) and the check's log | +| a merge check | 15 minutes | read `mesh-delivery.show` (its state and verdict), then the check's log; the build queue (`mesh-controller.queue`) never lists a running check | | the Approve's ask | 5 minutes after both checks pass | read `mesh-delivery.show`: an ask not raised is a fault, said to the operator | | a merge after the Approve | 5 minutes | read `mesh-delivery.show` for the delivery | | a delivery plan | its class's budget (`mesh-delivery.times`), at most 30 minutes | read `mesh-controller.plans`, then `mesh-delivery.stalled` | @@ -319,6 +329,10 @@ the lead, when the state changes or the wait passes its bound. The lead never sl 2026-10-19 one watcher sent on to three pull requests in turn missed that the third's checks had passed at 04:58, and the lead told the operator for 15 minutes that they were still running. The next wait gets a fresh watcher, and before a report the watcher reads the owning verb once more and says only what it says now. +**An ask is said to exist only after it is read on the router.** Before the lead tells the operator that an +Approve, a Retry or a Release waits for them, it reads `operator-channel.asks` and finds that ask open by its key; +on 2026-10-20 an ask was named to the operator that the router did not hold. A merge the gate passed but whose +ask is not on the router is the fault of the Approve's wait in the table above. **Every ten minutes (the operator, 2026-10-17), every two minutes while a delivery plan runs, and at once when something lands, stops or needs the operator,** the lead reports, in one of the two layouts below (the operator, 2026-10-16: an overview 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 c4539db9..ff5655c8 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 @@ -4,6 +4,8 @@ status: in-progress code: [mesh-controller, mesh-catalog modules/mesh-delivery, mesh-delivery, mesh-host, mesh-sdk] updated: 2026-10-20 decisions: + - "ADR 0463" + - "ADR 0457" - "ADR 0453" - "ADR 0452" - "ADR 0450" From 5705da30c006b436e43aaf60e4a2fb513acd6823 Mon Sep 17 00:00:00 2001 From: mesh-tools Date: Tue, 20 Oct 2026 17:59:47 +0000 Subject: [PATCH 2/2] Judge a catalogue removal by the controller's unit tests against the catalogue's branch, not by a try A controller try reads the catalogue's main, so it would have passed for mesh-catalog #381 (review round 1). --- 00-META/process/07-feature-branches.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index e820c3aa..4f04439b 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -225,10 +225,14 @@ never into the running one, unless it blocks the running one. `Reviewed-by: at ` (the issue 1022 note gives its form). mesh-delivery reads it at every new head and puts it in the Approve's ask; a missing line, or one naming another commit, is said first in the ask. It is never a gate. - **A catalogue pull request that removes a module, or a subject a module names, is also tried against the - controller** (`mesh-controller.try` with mesh-controller's main), because the controller's own tests read the - catalogue: on 2026-10-20 mesh-catalog #381 removed the old delivery module, and every controller check failed - afterwards on a test of the catalogue's subjects until issue 1406 removed the name mesh-issues still listened to. + **A catalogue pull request that removes a module, or a subject a module names, is also judged by the + controller's unit tests against the catalogue's branch**, because those tests read the catalogue and no check + of the catalogue runs them: on 2026-10-20 mesh-catalog #381 removed the old delivery module, and every + controller check failed afterwards on a test of the catalogue's subjects until issue 1406 removed the name + mesh-issues still listened to. A controller try does not find it, since a check reads the catalogue's main + (also in a delivery group that holds the catalogue's pull request); the lead runs mesh-controller's unit + suite with `MESH_CHECK_BESIDE` naming a directory that holds the catalogue's branch, as mesh-controller's + `internal/beside` says. 2. **The forge's merge checks run the integration tests again, as the gate** (`mesh/merge-gate`, `mesh/repo-check`). No second review: step 2 reviewed this tree. 3. **A check that fails** goes back to the same reviewer, continued by its id, with the failure, for **one more cycle** of step 2 with