Playbooks 07 and 08: the integration tests run once before every push, through mesh-controller.try or merge-check.sh (the operator, 2026-10-18)

00-META/process/07-feature-branches.md

@@ -125,18 +125,20 @@ 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 while you work and runs in the one merge check before the push.
 - **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
-  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
+  move another issue; **run the integration tests once before every push, not while developing** (the
+  operator, 2026-10-18): compile them with `go vet -tags integration ./...` while you work, and before the push
+  run the repository's whole merge check with `mesh-controller.try` on the pushed branch (the store and bus a
+  pull request's check gets) or `merge-check.sh` against a throwaway store, and push only on its pass. On
+  2026-10-18 three pushes in a row failed their first merge check on faults an integration run finds in a
+  minute (mesh-catalog #361, mesh-controller #380's stale keys, #381's 400 tests without the layout marker),
+  each costing a check, a fix and another check. 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.
@@ -175,8 +177,7 @@ 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
+   The integration tests ran once before the push (step 1); the merge check runs them again as the gate. 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
@@ -268,7 +269,10 @@ It loops `mesh_wait` on the event families of what it watches (`mesh-delivery.tr
 `mesh-delivery.group` for a delivery, for example) with a timeout under 60 seconds, since the call itself ends near
 a minute. After every answer or timeout it reads the state from the verb that owns it (`mesh-delivery.show`,
 `mesh-controller.plans`, `knowledge-base.get`), because an event only wakes it (ADR 0367). It finishes, and so wakes
-the lead, when the state changes or the wait passes its bound. The lead never sleeps or polls by hand to wait.
+the lead, when the state changes, when the wait passes its bound, **or when nothing changed for two minutes**
+(the operator, 2026-10-18): a wait that stopped moving is a stall, never a wait. On 2026-10-18 a delivery plan stopped
+at 12:46 because the bus refused the new controller's writes, its watcher waited for "done or failed", and the stall
+was found ten minutes later only because the operator asked what was happening (issue 1121). The lead never sleeps or polls by hand to wait.
 
 **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

00-META/process/08-small-fixes.md

@@ -35,7 +35,7 @@ one delivery**. Everything before the push is local and fast.
 3. **Build on a local branch** `fix/<issue>-<slug>`, in a worktree of its own branched from `main`, never in
    the repository's own clone, which stays on `main` (playbook [07](07-feature-branches.md), step 0, item 2). Write the
    test that fails today first; make the change; keep `gofmt`, `go vet` and the repository's whole unit suite green
-   before every commit (each test well under a second; never a merge check or a database locally: how-we-build §5, ADR 0391).
+   before every commit (each test well under a second; no database in the unit tests: how-we-build §5, ADR 0391); before the push the repository's merge check runs once, integration tests included, through `mesh-controller.try` or `merge-check.sh` against a throwaway store, as playbook 07 step 1 says.
    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 (`<issue>/AC<n>`, playbook 07 step 0 item 5). Commit, naming the issue. For a playbook or design edit, run the repository's own checks (in hq,
    `sh merge-check.sh`).
@@ -46,9 +46,8 @@ one delivery**. Everything before the push is local and fast.
    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
+   (ADR 0401), so a fix waits for no other change's delivery. The integration tests ran once
+   before the push (step 3); the forge's merge check runs them again as the gate. A failed 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