Playbooks 07 and 08: a module's acceptance is an integration test the forge runs, and try runs on the builder (ADR 0391)

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

@@ -124,7 +124,8 @@ 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 in the check's own toolchain; a branch that fails goes back
+   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
@@ -135,11 +136,10 @@ never into the running one, unless it blocks the running one.
    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
    the same fixing agents; then push once again.
-5. **Prove the step's acceptance before it is marked ready.** A step that adds or changes a module runs that
-   module whole (its process against a real bus and store) on the cheapest bed that can show the step's
-   acceptance sentence, as playbook [01](01-research.md) says for research: a test that starts the built module
-   against a throwaway bus and store. Unit tests alone are not that proof. The lab is not used for this while
-   its runs are too slow (the operator, 2026-10-16).
+5. **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
    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
@@ -247,7 +247,7 @@ issues in `fixing` that nobody works on reads to the operator as stuck work.
 - 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 run of the module whole named in the lead's report, is
+  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 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

@@ -43,9 +43,9 @@ one delivery**. Everything before the push is local and fast.
    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 proves the issue's done-when with the
-   module running whole (its process against a throwaway bus and store, never the lab for now) before it is marked, not with unit tests
-   alone. The operator's word is waited for only when the fix changes what the operator sees, removes data,
+   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,
    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.
@@ -77,7 +77,7 @@ reading itself and uses one subagent only for the review.
   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
-  for more than 15 minutes, a fix to a module marked ready with no run of the module whole, or a review report
+  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
   moves it back to `open` with its note.