Playbooks 07 and 08: integration tests run once through mesh-controller.try on the pushed branch before the pull request, never on the machine (the operator, 2026-10-18)

2026-10-18 15:02:56 +02:00
parent b98b93efc8
commit cec72d1dc9
2 changed files with 22 additions and 17 deletions
@@ -44,7 +44,7 @@ opened **once**, after the review. It runs in five steps, and its time is bounde
 | 0. Prepare | the lead settles the open questions and writes one context file per repository | 15 minutes |
 | 1. Develop | one fixing agent per repository builds every issue locally, the whole unit suite before every commit | the milestone's issues, 30 minutes each |
 | 2. Review | one reviewer reads all of it; reports go both ways; at most 3 rounds | 15 minutes |
-| 3. Check | push; the forge's merge checks run the integration tests; no further review | one check run |
+| 3. Check | push; `mesh-controller.try` runs the integration tests on each pushed branch, then the pull requests are opened and the forge's merge checks run them again; no further review | one try and one check run |
 | 4. Deliver | merge; the delivery plan builds, publishes and sends the whole feature | its delivery plan |

 **One milestone is one release** (the operator, 2026-10-17). A milestone is developed whole, reviewed once,
@@ -87,7 +87,7 @@ never into the running one, unless it blocks the running one.
   - what not to touch, and what lands beside it in other repositories;
   - the local facts: the worktree, the branch, the check commands, a temporary directory for tests outside
     the home (`TMPDIR`), and the unit tests to run (never a database server: tests that need one are
-     integration tests, which the forge's checks run).
+     integration tests, which `mesh-controller.try` and the forge's checks run).
   When the reading is large, a read-only agent on the smaller model answers the lead's exact questions with
   file:line, and the lead writes the file from its answers.
 5. **Write the findings into the issues** (the operator, 2026-10-17: the better the content of the issues, the
@@ -125,17 +125,17 @@ never into the running one, unless it blocks the running one.
  after; `gofmt`, `go vet` and the whole unit suite stay green. **The tests are written from the issue's
  acceptance criteria**: one test or more per criterion at the level it names, each test's comment citing
  the criterion it proves by its label (`// 1118/AC2`), and no criterion left without its test; an integration criterion is a test
-  that compiles and waits for the check step. The integration tests (`merge-check.sh` with the store and the
-  bus) wait for the check step.
+  that compiles and waits for the check step. The integration tests (those that start a store, a bus or a
+  process) wait for the check step, where `mesh-controller.try` runs them first.
 - **Nothing is pushed** and no pull request is opened in this step. Never land on a red check: run the
  checks, 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
  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 locally** (no `go test -tags integration`, no `merge-check.sh`,
-  no bus or store test run): compile them with `go vet -tags integration ./...` and leave the running to the
-  forge's merge check. On 2026-10-17 three fixing agents ran them anyway, one for minutes on end, because the
+  move another issue; **never run an integration test on the machine** (no `go test -tags integration`, no `merge-check.sh`,
+  no store or bus started by hand): compile them with `go vet -tags integration ./...` and leave the running to
+  the check 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
  check results, anything you stopped on.
 - **An agent that finds the code differs from its context file stops and reports** (file:line); the lead
@@ -174,9 +174,14 @@ never into the running one, unless it blocks the running one.

 ## Step 3 — Check (no review)

-1. **Push every feature branch and open one pull request per repository, together.**
-   The integration tests
-   run only in the merge check (the operator, 2026-10-16), never before. Pull requests in two or
+1. **Push every feature branch, try it, then open one pull request per repository, together.**
+   **The integration tests run once before the pull requests are opened**: `mesh-controller.try` with the
+   repository and the pushed branch runs the repository's `merge-check.sh` (main's version) on the merge, in the
+   toolchain containers and against the throwaway store and bus a merge check gets, and answers with an id to
+   read back. A try that fails goes to step 3 item 3 as a failed check does; the pull requests are opened only
+   when every 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 `merge-check.sh`, `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
   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. **Each pull request's description carries
@@ -184,7 +189,7 @@ never into the running one, unless it blocks the running one.
   `Reviewed-by: <who@node> at <full sha>` (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.
-2. **The forge's merge checks run the integration tests once** (`mesh/merge-gate`, `mesh/repo-check`). No
+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
   the same fixing agents; then push once again. **The failure is read from the check's whole log**, never
@@ -45,15 +45,15 @@ one delivery**. Everything before the push is local and fast.
   criteria is opened as an issue of its own, never asked as a change). The reviewer's findings go back to the same agent that wrote the fix, continued by
   its id, so the fix keeps its context. A playbook or design edit of a few lines may skip the reviewer: the
   operator's Approve of its merge is its review, and the review record says so.
-5. **Push once 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. The forge's merge
-   check runs the integration tests, the only
-   place they run (the operator, 2026-10-16). A failed check
-   goes back to the same agent with the failure, and the reviewer reads only the change it makes.
+5. **Push once, try 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 once, and the pull request is opened only on a pass; the forge'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.
 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 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
-   integration test starting the module whole against the real bus and store, run by the forge's checks
+   integration test starting the module whole against the real bus and store, run by `mesh-controller.try` and the forge's checks
   (ADR 0391 §1, §6); unit tests alone are not that proof, and the lab is not used. The operator's word is waited for only when the fix changes what the operator sees, removes data,
   or needs the operator's terminal.
 7. **Follow its delivery plan to done** (`mesh-controller.plans` with `wait` and `until: done`), prove the fix on