From 87c338da8ebae7e650f84b7263921b8bcf0ffb7a Mon Sep 17 00:00:00 2001 From: jochen Date: Fri, 23 Oct 2026 23:20:27 +0200 Subject: [PATCH 1/3] Playbooks 07 and 08: a failed try or check is run locally at once, so every failure shows in one run, not one per try (the operator, 2026-10-23) --- 00-META/process/07-feature-branches.md | 6 +++++- 00-META/process/08-small-fixes.md | 7 +++++-- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index 8c027a15..f275b46f 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -187,7 +187,11 @@ issue whether it is being fixed in between, after the delivery, or waits, and on move another issue; **never run an integration test on the machine** (no `go test -tags integration`, no store or bus started by hand): compile them with `go vet -tags integration ./...` and leave the running to the lead's try at the end of this step, where `mesh-controller.try` runs them on the pushed branch. On 2026-10-17 three fixing agents ran them anyway, one for minutes on end, because the - brief only said they wait for the check (the operator). Report back in under 150 words: commits, tests added and that they failed first, the + brief only said they wait for the check (the operator). **One exception: a failed try or check.** Then the whole + integration level of that repository is run locally at once (`go test -tags integration -count=1 ./...` in each module), + by the lead or by the fixing agent on the lead's word, before any further try: a verdict names only the first failed test + (issue 1921), and on 2026-10-23 R4g's faults surfaced one per try until a local run listed them all in a minute (the + operator: "if it fails, you should run it locally"). Report back in under 150 words: commits, tests added and that they failed first, the check results, anything you stopped on. - **An agent that finds the code differs from its context file stops and reports** (file:line); the lead settles it, updates the context file, and continues the agent. diff --git a/00-META/process/08-small-fixes.md b/00-META/process/08-small-fixes.md index d14b5e92..37d5ef54 100644 --- a/00-META/process/08-small-fixes.md +++ b/00-META/process/08-small-fixes.md @@ -61,8 +61,11 @@ one delivery**. Everything before the try is local and fast. 5. **Push the reviewed head, try it again if the review changed it, and open the pull request.** The trunk is what runs and nothing holds merged work back (ADR 0401), so a fix waits for no other change's delivery. `mesh-controller.try` on the pushed branch runs the integration tests, and the pull request is opened only when the head's last try passed; the checker's merge check runs - them again as the gate (playbook [07](07-feature-branches.md) step 3). They are never run on the machine. A - failed try or check goes back to the same agent with the failure, and the reviewer reads only the change it makes. + them again as the gate (playbook [07](07-feature-branches.md) step 3). **A failed try or check is run locally at once:** the + repository's whole integration level, `go test -tags integration -count=1 ./...` in each module, once, before anything + else, because a verdict names only the first failed test (issue 1921) and a try per fault costs a round each (the + operator, 2026-10-23: "if it fails, you should run it locally"). Every failure it shows goes back to the same agent + with the failure, fixed in one change, and the reviewer reads only the change it makes; then one try. 6. **The pull request's description carries the review record** (`Reviewed-by: at `, playbook [07](07-feature-branches.md) step 3) and the session that pushed it (`Pushed-by: `, ADR 0505 §5), and mesh-delivery asks the operator's Approve as soon as its checks pass and merges the approved head (ADR 0421); nobody marks, labels, comments or rechecks. A fix to a module that changes how it runs carries an From 2b53b6a5d24a8856e68559c224d1c5827c8256dd Mon Sep 17 00:00:00 2001 From: jochen Date: Fri, 23 Oct 2026 23:22:21 +0200 Subject: [PATCH 2/3] Playbooks 07 and 08: say the local run after a failed try as a guideline, not a rule (the operator) --- 00-META/process/07-feature-branches.md | 10 +++++----- 00-META/process/08-small-fixes.md | 10 +++++----- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index f275b46f..28900d47 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -187,11 +187,11 @@ issue whether it is being fixed in between, after the delivery, or waits, and on move another issue; **never run an integration test on the machine** (no `go test -tags integration`, no store or bus started by hand): compile them with `go vet -tags integration ./...` and leave the running to the lead's try at the end of this step, where `mesh-controller.try` runs them on the pushed branch. On 2026-10-17 three fixing agents ran them anyway, one for minutes on end, because the - brief only said they wait for the check (the operator). **One exception: a failed try or check.** Then the whole - integration level of that repository is run locally at once (`go test -tags integration -count=1 ./...` in each module), - by the lead or by the fixing agent on the lead's word, before any further try: a verdict names only the first failed test - (issue 1921), and on 2026-10-23 R4g's faults surfaced one per try until a local run listed them all in a minute (the - operator: "if it fails, you should run it locally"). Report back in under 150 words: commits, tests added and that they failed first, the + brief only said they wait for the check (the operator). After a failed try or check it + usually pays to run that repository's whole integration level locally (`go test -tags integration -count=1 ./...` in each + module), by the lead or by the fixing agent on the lead's word, before another try: a verdict names only the first failed + test (issue 1921), and on 2026-10-23 R4g's faults surfaced one per try until a local run listed them all in a minute (a + guideline, the operator). Report back in under 150 words: commits, tests added and that they failed first, the check results, anything you stopped on. - **An agent that finds the code differs from its context file stops and reports** (file:line); the lead settles it, updates the context file, and continues the agent. diff --git a/00-META/process/08-small-fixes.md b/00-META/process/08-small-fixes.md index 37d5ef54..74f4a601 100644 --- a/00-META/process/08-small-fixes.md +++ b/00-META/process/08-small-fixes.md @@ -61,11 +61,11 @@ one delivery**. Everything before the try is local and fast. 5. **Push the reviewed head, try it again if the review changed it, and open the pull request.** The trunk is what runs and nothing holds merged work back (ADR 0401), so a fix waits for no other change's delivery. `mesh-controller.try` on the pushed branch runs the integration tests, and the pull request is opened only when the head's last try passed; the checker's merge check runs - them again as the gate (playbook [07](07-feature-branches.md) step 3). **A failed try or check is run locally at once:** the - repository's whole integration level, `go test -tags integration -count=1 ./...` in each module, once, before anything - else, because a verdict names only the first failed test (issue 1921) and a try per fault costs a round each (the - operator, 2026-10-23: "if it fails, you should run it locally"). Every failure it shows goes back to the same agent - with the failure, fixed in one change, and the reviewer reads only the change it makes; then one try. + them again as the gate (playbook [07](07-feature-branches.md) step 3). A failed try or check is best run locally + first: the repository's whole integration level (`go test -tags integration -count=1 ./...` in each module) shows every + failure at once, where a verdict names only the first (issue 1921) and a try per fault costs a round each (a guideline, + the operator, 2026-10-23). The failures go back to the same agent, fixed in one change where they can be, and the + reviewer reads only the change it makes; then one try. 6. **The pull request's description carries the review record** (`Reviewed-by: at `, playbook [07](07-feature-branches.md) step 3) and the session that pushed it (`Pushed-by: `, ADR 0505 §5), and mesh-delivery asks the operator's Approve as soon as its checks pass and merges the approved head (ADR 0421); nobody marks, labels, comments or rechecks. A fix to a module that changes how it runs carries an From 8055006ba1f31ad92338d2ce9808e7686efb4928 Mon Sep 17 00:00:00 2001 From: jochen Date: Fri, 23 Oct 2026 23:24:15 +0200 Subject: [PATCH 3/3] Playbook 07: the two 'never run integration tests on the machine' lines say 'while developing', so the guideline after a failed try no longer contradicts them (review-471) --- 00-META/process/07-feature-branches.md | 7 ++++--- 00-META/process/08-small-fixes.md | 2 +- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index 28900d47..4c90fbb6 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -184,7 +184,7 @@ issue whether it is being fixed in between, after the delivery, or waits, and on message ("issue 805: landing in mesh-catalog"); reach the mesh only through the mesh MCP server, never ssh; never push, open, merge or close a pull request; never write to a store's database by hand, a schema change is a numbered migration and the consolidated schema; Go only unless the context file says otherwise; never - move another issue; **never run an integration test on the machine** (no `go test -tags integration`, + move another issue; **leave the integration tests to the try while developing** (no `go test -tags integration`, no store or bus started by hand): compile them with `go vet -tags integration ./...` and leave the running to the lead's try at the end of this step, where `mesh-controller.try` runs them on the pushed branch. On 2026-10-17 three fixing agents ran them anyway, one for minutes on end, because the brief only said they wait for the check (the operator). After a failed try or check it @@ -254,8 +254,9 @@ issue whether it is being fixed in between, after the delivery, or waits, and on stream (ADR 0525 §1), so it waits behind the asks before it until a build node has a free slot; no script of the repository decides it (ADR 0445, ADR 0529). A try that fails goes to step 3 item 3 as a failed check does; the pull requests are opened only when every head's last try passed (the operator, 2026-10-18: three pushes in a row failed their first merge check on - faults a try finds in minutes). Never `go test -tags integration` or a store or bus started - by hand on the machine (the operator, 2026-10-18). Pull requests in two or + faults a try finds in minutes). While developing, no `go test -tags integration` or store or bus started + by hand on the machine (the operator, 2026-10-18); after a failed try, a local run of the whole level is the guideline + in step 1's brief. Pull requests in two or more repositories that share the branch name are one delivery group (ADR 0239 §2). Where a session pushes through the forge tool `gitea_commit` (one commit on the forge's current base), the reviewer first confirms that commit's tree equals the reviewed one. **A large change is pushed by a pusher agent** on the smaller diff --git a/00-META/process/08-small-fixes.md b/00-META/process/08-small-fixes.md index 74f4a601..1327e19b 100644 --- a/00-META/process/08-small-fixes.md +++ b/00-META/process/08-small-fixes.md @@ -65,7 +65,7 @@ one delivery**. Everything before the try is local and fast. first: the repository's whole integration level (`go test -tags integration -count=1 ./...` in each module) shows every failure at once, where a verdict names only the first (issue 1921) and a try per fault costs a round each (a guideline, the operator, 2026-10-23). The failures go back to the same agent, fixed in one change where they can be, and the - reviewer reads only the change it makes; then one try. + reviewer reads only the change it makes, before the next try. 6. **The pull request's description carries the review record** (`Reviewed-by: at `, playbook [07](07-feature-branches.md) step 3) and the session that pushed it (`Pushed-by: `, ADR 0505 §5), and mesh-delivery asks the operator's Approve as soon as its checks pass and merges the approved head (ADR 0421); nobody marks, labels, comments or rechecks. A fix to a module that changes how it runs carries an