Playbooks 07 and 08: integration tests only in the merge check, no try before it, no lab and no end-to-end tests yet (the operator, 2026-10-16)

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

@@ -26,7 +26,7 @@ A small fix (one repository, one issue, about an hour of work) follows
   change wrong; everything else is an issue of its own.
 - **The first check after the whole branch is written.** A feature's catalogue branch, pushed once after
   hours of local work, met its first check on 2026-10-16 and failed on 29 problems, TypeScript errors among
-  them, that its own check finds in minutes.
+  them, that a unit suite run continuously while working finds at once.
 - **A green pull request nobody marks.** An approved, green pull request that was not marked ready waited
   12 h 17 min for someone to merge it (mesh-catalog #300, 2026-10-14).
 - **A module proven only after it reached the machines.** The mail modules were delivered with unit tests
@@ -123,24 +123,20 @@ never into the running one, unless it blocks the running one.
 
 ## Phase 3 — Check (no review)
 
-1. **Push every feature branch and try it before any pull request.** `mesh-controller.try` with the
-   repository and the branch runs the merge check on the builder, in the check's own toolchain, never
-   locally (ADR 0391 §4); a branch that fails goes back
-   to its fixing agent, and nothing is opened until every branch passes. A local run never stands in for it:
-   the check's containers carry other tools than the nodes.
-2. **Open one pull request per repository, together.** Pull requests in two or
+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
    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.
-3. **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 once** (`mesh/merge-gate`, `mesh/repo-check`). No
    second review: phase 2 reviewed this tree.
-4. **A check that fails** goes back to the reviewer with the failure, for **one more cycle** of phase 2 with
+3. **A check that fails** goes back to the reviewer with the failure, for **one more cycle** of phase 2 with
    the same fixing agents; then push once again.
-5. **The step's acceptance is proven before it is marked ready.** A step that adds or changes a module
+4. **The step's acceptance is proven before it is marked ready.** A step that adds or changes a module
    carries an integration test that starts the module whole, its process against the real bus and store, and
    shows the step's acceptance sentence; the forge's checks run it (ADR 0391 §1, §6). Unit tests alone are not
-   that proof, and no lab run is (ADR 0391 §5: end to end only on the operator's ask).
-6. **The reviewer marks each pull request ready as soon as the acceptance is shown** (`mesh/ready` and a
+   that proof; the mesh has no end-to-end tests yet, and the lab is not used (the operator, 2026-10-16).
+5. **The reviewer marks each pull request ready as soon as the acceptance is shown** (`mesh/ready` and a
    comment `ready at <full sha>`, the head it approved); mesh-delivery merges it when its checks pass
    (ADR 0364). The operator's word is waited for only when the step changes what the operator sees, removes
    data, or needs a step only the operator's terminal can take; the lead says which before the step starts.
@@ -246,9 +242,8 @@ issues in `fixing` that nobody works on reads to the operator as stuck work.
   review rules; `issue-tracker.list` with `flag: abandoned` lists issues left in `fixing` with nobody on them.
 - A pull request reviewed and green but not marked ready for more than 15 minutes is a lead that did not
   mark it.
-- A pull request whose head has no passing `mesh-controller.try` before it was opened, or a step that adds or
-  changes a module marked ready with no integration test that starts the module whole, is
-  the failure of phase 3's first and fifth steps.
+- A step that adds or changes a module marked ready with no integration test that starts the module whole is
+  the failure of phase 3's fourth step.
 - A bed run from `.work/<slug>/mesh-lab` that fails naming a `.work/<slug>/<repo>/…` path it cannot find is a
   missing sibling worktree, not a mesh fault.
 

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

@@ -35,17 +35,14 @@ one delivery**. Everything before the push is local and fast.
    done-when 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 word on the pull request is its review, and the lead marks it ready on that word.
-5. **Push the branch, try it, then open the pull request.** `mesh-controller.try` with the repository and the
-   branch runs the merge check in the check's own toolchain before any status is set; open the pull request
-   only once it passes. A local run never stands in for it: the check's containers carry other tools than the
-   nodes (a test that called util-linux `flock -E` passed on a node and failed on BusyBox's in the check). The
-   forge's merge checks run the integration tests. A failed check
+5. **Push once and open the pull request.** 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.
 6. **The reviewer marks it ready at once** (for an edit that skipped the reviewer, the lead, on the
    operator's word) (`mesh/ready` and `ready at <full sha>`, the head it approved);
    mesh-delivery merges it when its checks pass. 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
-   (ADR 0391 §1, §6); unit tests alone, or a lab run, are not that proof. The operator's word is waited for only when the fix changes what the operator sees, removes data,
+   (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
    the mesh (the symptom gone, measured), and resolve the issue with `located-in` and `fixed-by` the same hour.
@@ -76,7 +73,7 @@ reading itself and uses one subagent only for the review.
 - A small fix has one pull request with one or few commits naming its issue, opened after its review: a pull
   request with many heads is a fix reviewed after its push.
 - Its issue moves to `resolved` within the hour its delivery plan ends.
-- A pull request opened with no passing `mesh-controller.try` on its head, one reviewed and green but unmarked
+- A pull request reviewed and green but unmarked
   for more than 15 minutes, a fix to a module's running marked ready with no integration test of the module whole, or a review report
   asking a change outside the issue's done-when, is the failure of steps 4 to 6.
 - An issue in `fixing` with nobody on it shows in `issue-tracker.list` with `flag: abandoned`; a stopped fix