Playbook 07: the reviewer is kept for the whole release, and a watcher waits for its checks (issue 1042)

The operator asked why review takes so long: a fresh reviewer per round or per mark reads
everything again, and a reviewer waiting on the forge's checks spends its run waiting.

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

@@ -121,7 +121,10 @@ never into the running one, unless it blocks the running one.
 1. **Bring every feature branch up to the current trunk** (fetch by name, then merge), so the reviewed tree is
    the tree that is pushed.
 2. **One reviewer reads every repository's local commits** together, against the context files and the
-   decisions. Its report is per repository: each finding as file:line, the failure it causes, and the fix.
+   decisions. **It is one agent, kept for the whole release** like the fixing agents: the lead continues it by
+   its id for every later round, for the extra cycle after a failed check (phase 3) and for the ready mark, so it
+   reads the decisions, the issues, the context files and the commits once (issue 1042). A fresh reviewer per
+   round or per mark pays for all of that again. Its report is per repository: each finding as file:line, the failure it causes, and the fix.
    It says which round it is in ("round 1 of at most 3").
 3. **The report goes to the same fixing agents** that wrote the code, continued by their ids, so they fix
    with the context they already hold. Each answers the reviewer: what it changed, per finding, or why not.
@@ -142,7 +145,7 @@ never into the running one, unless it blocks the running one.
    reviewer first confirms that commit's tree equals the reviewed one.
 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.
-3. **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 same reviewer, continued by its id, 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 builder said. A check's summary picks only some failing lines;
@@ -153,7 +156,9 @@ never into the running one, unless it blocks the running one.
    carries an integration test that starts the module whole, its process against the real bus and store, and
    shows the milestone's acceptance sentence; the forge's checks run it (ADR 0391 §1, §6). Unit tests alone are not
    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** with
+5. **The reviewer marks each pull request ready as soon as the acceptance is shown.** It does not wait for the
+   checks itself: a watcher waits for them and wakes the lead, who continues the reviewer by its id to mark
+   (issue 1042). It marks with
    `mesh-delivery.mark-ready` (the delivery of the head it approved, who reviewed it and why), which writes the
    label `mesh/ready` and then `ready at <full sha>`, the order the forge counts (issue 913); mesh-delivery merges it when its checks pass
    and the operator approved the merge into main on Telegram, the channel that proves who answered today (ADR 0364,
@@ -182,7 +187,7 @@ survive.
 | The lead (phase 0 decisions, the context files, following and reporting) | larger | judgement |
 | Read-only questions about the code for the context files | smaller | reading, answered with file:line |
 | Fixing agents (phase 1, and the fixing in phases 2 and 3) | smaller | building to a written context |
-| The reviewer (phase 2, and the extra cycle in phase 3) | larger | judgement, once per round |
+| The reviewer (phase 2, the extra cycle in phase 3 and the ready mark; one agent, continued by its id) | larger | judgement, once per round |
 | Decision records | larger | judgement |
 
 Every agent the mesh runs draws on one weekly allowance shared by every session, and the larger model
@@ -315,6 +320,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.
+- Every ready mark of a release names one reviewer (`mesh-delivery.show`, `ready.by`), and the lead's save point
+  names one reviewer id per release; a second reviewer within one release is a reviewer not kept (issue 1042).
 - A milestone 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