From f89b8599c60625e9891cf55b244a8cdaa73f2e60 Mon Sep 17 00:00:00 2001 From: jochen Date: Tue, 27 Oct 2026 22:50:43 +0100 Subject: [PATCH 1/4] =?UTF-8?q?Playbooks=2007=20and=2008=20name=20the=20tr?= =?UTF-8?q?y=20by=20the=20checker's=20seat:=20mesh-delivery-checker.try=20?= =?UTF-8?q?replaces=20mesh-controller.try=20(ADR=200547=20=C2=A710,=20issu?= =?UTF-8?q?e=20774)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 00-META/process/07-feature-branches.md | 6 +++--- 00-META/process/08-small-fixes.md | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index 4efea1f2..50f636cc 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -206,7 +206,7 @@ issue whether it is being fixed in between, after the delivery, or waits, and on - **Nothing is pushed and no pull request is opened in this step, and there is no try** (ADR 0548; the operator, 2026-10-26: "every release should only run 1 check or 1 try"). When every issue is committed, the lead brings each feature branch up to the current trunk (fetch by name, then merge) and the review reads the local commits. Never call - `mesh-controller.try` or `mesh-delivery-checker.checker_try`; one is run only when the operator asks for it. A reviewer + `mesh-delivery-checker.try` or `mesh-delivery-checker.checker_try`; one is run only when the operator asks for it. A reviewer or a session that wants the code on the forge may push a branch that has no pull request: it runs nothing. Never land on a red check: read the result, then land in a separate step. - **The fixing agent's brief** (the lead gives it with the context file): name your issue in every step and @@ -310,7 +310,7 @@ issue whether it is being fixed in between, after the delivery, or waits, and on processing power"). The integration tests run once, in the checker's merge check on the merge with the trunk's head, at the unit and the integration level, through the build module of the repository's language and by that language's convention (ADR 0445, ADR 0529); the check waits on the language's check stream until a build node has a free slot - (ADR 0525 §1). **No try:** never call `mesh-controller.try` or `mesh-delivery-checker.checker_try`, except when the + (ADR 0525 §1). **No try:** never call `mesh-delivery-checker.try` or `mesh-delivery-checker.checker_try`, except when the operator asks for one. While developing, no `go test -tags integration` run of a whole module or level, and no store or bus started by hand on the machine (the operator, 2026-10-18). **Before a group's single push, the integration tests that exercise the change are run locally against an embedded @@ -661,7 +661,7 @@ issues in `fixing` that nobody works on reads to the operator as stuck work. - **One release, one check** (ADR 0548): `gitea.gitea_get_pull_request` shows each pull request created after its review record's time, and `mesh-delivery.show` shows one check per head and, for a group, one head per member; a pull request that existed before its review approved it, a second head with no failed check before it, or a check of a - head asked more than once, is this rule skipped. A call of `mesh-controller.try` or `checker_try` that the operator + head asked more than once, is this rule skipped. A call of `mesh-delivery-checker.try` or `checker_try` that the operator did not ask for shows in the checker's asks and is the same breach. - A milestone that adds or changes a module whose pull request has no integration test that starts the module whole is the failure of the check step's fourth item. diff --git a/00-META/process/08-small-fixes.md b/00-META/process/08-small-fixes.md index 1e29dbdf..4a08918e 100644 --- a/00-META/process/08-small-fixes.md +++ b/00-META/process/08-small-fixes.md @@ -52,7 +52,7 @@ processing power"). Everything before the push is local and fast, and no try is The tests are written from the acceptance criteria, at least one per criterion at its level, each citing the criterion it proves by its label (`/AC`, playbook 07 step 0 item 5). Commit, naming the issue. For a playbook or design edit, run the repository's own checks (in hq, `go test ./...` at the root). The integration tests are compiled (`go vet -tags integration ./...`) and not run: - nothing is pushed, no pull request is opened and no try (`mesh-controller.try`, `mesh-delivery-checker.checker_try`) is called, unless the operator asks for + nothing is pushed, no pull request is opened and no try (`mesh-delivery-checker.try`, `mesh-delivery-checker.checker_try`) is called, unless the operator asks for one. A single integration test may be run locally against an embedded bus when it is the fastest way to find a cause; before the push, the integration tests that exercise the change are run that way, by name (playbook 07 step 3), and the pull request names them and their results. A test fixture writes state in the form its real @@ -141,7 +141,7 @@ reading itself and uses one subagent only for the review. - A pull request merged by hand in a temporary mode names the verdict of its one check in its description on the forge (`gitea.gitea_get_pull_request`); one without is the step skipped. - One fix, one check (ADR 0548): a pull request that existed before its review approved the head, or a head whose check was - asked more than once with no new reviewed head, is steps 4 and 5 skipped; so is a `mesh-controller.try` the operator did not ask for. + asked more than once with no new reviewed head, is steps 4 and 5 skipped; so is a `mesh-delivery-checker.try` the operator did not ask for. - Its issue moves to `resolved` within the hour the view says its source revision `delivered`. - A pull request with no review record at its head (the Approve's ask says so first), a fix to a module's running pushed with no integration test of the module whole, or a review report -- 2.54.0 From 7d022710b34ba3ee64eb895600f45e76636183f4 Mon Sep 17 00:00:00 2001 From: jochen Date: Tue, 27 Oct 2026 23:01:25 +0100 Subject: [PATCH 2/4] Playbooks 07 and 08: name the controller's try too while its verb exists (issue 774) --- 00-META/process/07-feature-branches.md | 6 +++--- 00-META/process/08-small-fixes.md | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index 50f636cc..998b2241 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -206,7 +206,7 @@ issue whether it is being fixed in between, after the delivery, or waits, and on - **Nothing is pushed and no pull request is opened in this step, and there is no try** (ADR 0548; the operator, 2026-10-26: "every release should only run 1 check or 1 try"). When every issue is committed, the lead brings each feature branch up to the current trunk (fetch by name, then merge) and the review reads the local commits. Never call - `mesh-delivery-checker.try` or `mesh-delivery-checker.checker_try`; one is run only when the operator asks for it. A reviewer + `mesh-controller.try`, `mesh-delivery-checker.try` or `mesh-delivery-checker.checker_try`; one is run only when the operator asks for it. A reviewer or a session that wants the code on the forge may push a branch that has no pull request: it runs nothing. Never land on a red check: read the result, then land in a separate step. - **The fixing agent's brief** (the lead gives it with the context file): name your issue in every step and @@ -310,7 +310,7 @@ issue whether it is being fixed in between, after the delivery, or waits, and on processing power"). The integration tests run once, in the checker's merge check on the merge with the trunk's head, at the unit and the integration level, through the build module of the repository's language and by that language's convention (ADR 0445, ADR 0529); the check waits on the language's check stream until a build node has a free slot - (ADR 0525 §1). **No try:** never call `mesh-delivery-checker.try` or `mesh-delivery-checker.checker_try`, except when the + (ADR 0525 §1). **No try:** never call `mesh-controller.try`, `mesh-delivery-checker.try` or `mesh-delivery-checker.checker_try`, except when the operator asks for one. While developing, no `go test -tags integration` run of a whole module or level, and no store or bus started by hand on the machine (the operator, 2026-10-18). **Before a group's single push, the integration tests that exercise the change are run locally against an embedded @@ -661,7 +661,7 @@ issues in `fixing` that nobody works on reads to the operator as stuck work. - **One release, one check** (ADR 0548): `gitea.gitea_get_pull_request` shows each pull request created after its review record's time, and `mesh-delivery.show` shows one check per head and, for a group, one head per member; a pull request that existed before its review approved it, a second head with no failed check before it, or a check of a - head asked more than once, is this rule skipped. A call of `mesh-delivery-checker.try` or `checker_try` that the operator + head asked more than once, is this rule skipped. A call of `mesh-controller.try`, `mesh-delivery-checker.try` or `checker_try` that the operator did not ask for shows in the checker's asks and is the same breach. - A milestone that adds or changes a module whose pull request has no integration test that starts the module whole is the failure of the check step's fourth item. diff --git a/00-META/process/08-small-fixes.md b/00-META/process/08-small-fixes.md index 4a08918e..c659f92b 100644 --- a/00-META/process/08-small-fixes.md +++ b/00-META/process/08-small-fixes.md @@ -52,7 +52,7 @@ processing power"). Everything before the push is local and fast, and no try is The tests are written from the acceptance criteria, at least one per criterion at its level, each citing the criterion it proves by its label (`/AC`, playbook 07 step 0 item 5). Commit, naming the issue. For a playbook or design edit, run the repository's own checks (in hq, `go test ./...` at the root). The integration tests are compiled (`go vet -tags integration ./...`) and not run: - nothing is pushed, no pull request is opened and no try (`mesh-delivery-checker.try`, `mesh-delivery-checker.checker_try`) is called, unless the operator asks for + nothing is pushed, no pull request is opened and no try (`mesh-controller.try`, `mesh-delivery-checker.try`, `mesh-delivery-checker.checker_try`) is called, unless the operator asks for one. A single integration test may be run locally against an embedded bus when it is the fastest way to find a cause; before the push, the integration tests that exercise the change are run that way, by name (playbook 07 step 3), and the pull request names them and their results. A test fixture writes state in the form its real @@ -141,7 +141,7 @@ reading itself and uses one subagent only for the review. - A pull request merged by hand in a temporary mode names the verdict of its one check in its description on the forge (`gitea.gitea_get_pull_request`); one without is the step skipped. - One fix, one check (ADR 0548): a pull request that existed before its review approved the head, or a head whose check was - asked more than once with no new reviewed head, is steps 4 and 5 skipped; so is a `mesh-delivery-checker.try` the operator did not ask for. + asked more than once with no new reviewed head, is steps 4 and 5 skipped; so is a `mesh-controller.try` or `mesh-delivery-checker.try` the operator did not ask for. - Its issue moves to `resolved` within the hour the view says its source revision `delivered`. - A pull request with no review record at its head (the Approve's ask says so first), a fix to a module's running pushed with no integration test of the module whole, or a review report -- 2.54.0 From f4fdbde5586d025abc1c20e5513750d4b12dcb70 Mon Sep 17 00:00:00 2001 From: jochen Date: Thu, 29 Oct 2026 00:42:23 +0100 Subject: [PATCH 3/4] Playbook 07: rules for a delivery group's mesh-sdk pins, learned on 2026-10-28, so the next group does not meet the same refusals --- 00-META/process/07-feature-branches.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index 998b2241..df7857fb 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -403,6 +403,21 @@ issue whether it is being fixed in between, after the delivery, or waits, and on moved to include it): one Approve, one delivery. The old Approve ask closes itself on the new head and the new head is asked once its checks pass. How it is checked: a follow-up that sits in a second pull request while the first still waits shows in `gitea.gitea_list_pull_requests` as two open pull requests of one lead. +6. **A member pins mesh-sdk only at a commit that is a pull request's head**, merged or open (2026-10-28: the check + refused a pin to a merge commit on main as "on no pull request", though its tree equalled the head's). How it is + checked: the check's pin step; a refusal "on no pull request" is this rule skipped. +7. **Two groups that pin the same module's mesh-sdk conflict in `go.mod` and `go.sum`.** The group that merges + second merges main in and re-pins once, to a pull request head that holds both changes, after the first group + is merged and not before (a re-pin before makes the first group conflict). How it is checked: the check's merge + step; a group that conflicts after the first one merged is this rule skipped. +8. **A group that adds a seat, a verb or a manifest field in mesh-sdk and uses it in a module's manifest in the + same group cannot pass its check** until the running assigner pins a mesh-sdk that defines it, because the + check composes with the running assigner's mesh-sdk (issue 1585). The assigner's pin ships first, as its own + release. How it is checked: the check's composition step; a composition refusing the new word in such a group + is this rule skipped. +9. **A new head on an open pull request needs its `Reviewed-by` line at that head before the Approve is asked, + even for a pin-only commit.** How it is checked: the Approve's ask names the review record + (item 5); an ask whose line names another commit is this rule skipped. **One exception: a catalog change that uses a new manifest word.** The catalog's merge check reads manifests with the controller the mesh runs, so the controller's pull request is merged and delivered first; -- 2.54.0 From 7fd89de7cb8136b00810798f6e502be89b13675e Mon Sep 17 00:00:00 2001 From: jochen Date: Thu, 29 Oct 2026 00:43:06 +0100 Subject: [PATCH 4/4] Playbook 07: item 9 names no wrong item --- 00-META/process/07-feature-branches.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index df7857fb..37530492 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -416,8 +416,8 @@ issue whether it is being fixed in between, after the delivery, or waits, and on release. How it is checked: the check's composition step; a composition refusing the new word in such a group is this rule skipped. 9. **A new head on an open pull request needs its `Reviewed-by` line at that head before the Approve is asked, - even for a pin-only commit.** How it is checked: the Approve's ask names the review record - (item 5); an ask whose line names another commit is this rule skipped. + even for a pin-only commit.** How it is checked: the Approve's ask names the review record; + an ask whose line names another commit is this rule skipped. **One exception: a catalog change that uses a new manifest word.** The catalog's merge check reads manifests with the controller the mesh runs, so the controller's pull request is merged and delivered first; -- 2.54.0