Merge pull request 'Playbook 07: every wait on the wait list has a watcher agent on the bus' (#406) from fix/pb07-read-the-whole-log into main

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

@@ -145,7 +145,7 @@ never into the running one, unless it blocks the running one.
 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. **The failure is read from the check's whole log**, never
    reasoned from its summary: `mesh-delivery.show` names the check's build id, and `mesh-controller.builds` with
-   `log` set to that id prints everything the build seat's holder said. A check's summary picks only some failing lines;
+   `log` set to that id prints everything the builder said. A check's summary picks only some failing lines;
    on 2026-10-17 it showed a store test's `FAIL` without its cause, and a fix was first guessed from the code.
    **A change to `merge-check.sh` is judged by main's version of it**, so a test the change adds must pass under
    either version: one that runs the new script's behaviour runs a file of its own, never `merge-check.sh` itself.
@@ -203,6 +203,16 @@ on, with when it started and its bound.
 | a merge after ready | 5 minutes after the checks pass | read `mesh-delivery.show` for the delivery |
 | a delivery plan | its class's budget (`mesh-delivery.times`), at most 30 minutes | read `mesh-controller.plans`, then `mesh-delivery.stalled` |
 
+**Every wait on the list has a watcher** (the operator, 2026-10-17). A session runs only when a message reaches
+it, so a check, a merge, a delivery plan, a record's review or the operator's Approve on a channel that lands
+while the lead's turn has ended wakes nobody: on 2026-10-17 an approved group sat half merged for 14 minutes
+unseen (issue 1032). For each wait the lead starts a watcher, an agent on the smallest model that changes nothing.
+It loops `mesh_wait` on the event families of what it watches (`mesh-delivery.transition` and
+`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.
+
 **Every five minutes, 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
 of the issues, often). Times are local and absolute, from the clock (`date`), never guessed; every number has its