Name ADR 0465, 0466 and 0469 in design 47, and write the day's lessons on watchers, pushes and what a merge moves into playbook 07

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

@@ -220,7 +220,10 @@ never into the running one, unless it blocks the running one.
    by hand on the machine (the operator, 2026-10-18). 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
+   reviewer first confirms that commit's tree equals the reviewed one. **A large change is pushed by a pusher agent** on the smaller
+   model: `gitea_commit` patches of about 30 KB each, a file copied from another path sent as a copy (`copy_from`)
+   and not as its bytes, and the forge's tree compared with the local one after the last part (2026-10-20: R4c-2's
+   two repositories went up in parts this way, and the lead's own context stayed free for the review). **Each pull request's description carries
    the review record** (ADR 0421 §5), one line the lead writes from the reviewer's approval:
    `Reviewed-by: <who@node> at <full sha>` (the issue 1022 note gives its form). mesh-delivery reads it at every new
    head and puts it in the Approve's ask; a missing line, or one naming another commit, is said first in the ask.
@@ -285,6 +288,11 @@ delivery: no machine receives it (issue 889 while it still starts one). The lead
 naming its pull requests, and removes what is left: no `feat/<slug>` branch and no `.work/<slug>` worktree
 survive.
 
+**What a merge moves is read from its plan before the operator is told.** A change to mesh-sdk rebuilds every
+module that takes the SDK, with their backups and their asks for a person (issue 721): on 2026-10-20 the lead
+said an SDK merge moved nothing, and its delivery plan moved mesh-sdk with 41 dependents to all four machines.
+The lead reads the merge gate's plan in `mesh-delivery.show` and names what it moves before asking an Approve.
+
 **A failed plan's Retry is asked of the operator alone, never beside an Approve.** An Approve's merge starts a
 plan, and the controller refuses a Retry while another plan runs; on 2026-10-20 the operator chose both at once,
 the merge's plan started first, the chosen Retry was refused and nobody asked it again (issue 1408). So the lead
@@ -324,8 +332,9 @@ it, so a check, a merge, a delivery plan, a record's review or the operator's Ap
 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 smaller model that changes nothing,
 never the smallest (the operator, 2026-10-17).
-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
+It loops `mesh_wait` on the event families of what it watches (`mesh-delivery-gate.transition` and
+`mesh-delivery-gate.group` for a delivery, for example; the families a watcher may wait on are those the mesh granted
+the tool runner, and a refusal names them) 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.