Playbook 07: every wait on the wait list has a watcher agent on the bus (the operator, 2026-10-17)

2026-10-17 18:00:35 +02:00
parent 06440c1522
commit 9a39785116
1 changed files with 10 additions and 0 deletions
@@ -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