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)

2026-10-23 23:24:15 +02:00
parent 2b53b6a5d2
commit 8055006ba1
2 changed files with 5 additions and 4 deletions
@@ -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
@@ -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: <who@node> at <full sha>`,
   playbook [07](07-feature-branches.md) step 3) and the session that pushed it (`Pushed-by: <who@node>`, 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