Merge pull request 'Name ADR 0457 and ADR 0463 in design 47, and write the day's delivery lessons into playbook 07' (#444) from design/47-adr-0457-0463-and-lessons into main

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

@@ -225,6 +225,14 @@ never into the running one, unless it blocks the running one.
    `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.
    It is never a gate.
+   **A catalogue pull request that removes a module, or a subject a module names, is also judged by the
+   controller's unit tests against the catalogue's branch**, because those tests read the catalogue and no check
+   of the catalogue runs them: on 2026-10-20 mesh-catalog #381 removed the old delivery module, and every
+   controller check failed afterwards on a test of the catalogue's subjects until issue 1406 removed the name
+   mesh-issues still listened to. A controller try does not find it, since a check reads the catalogue's main
+   (also in a delivery group that holds the catalogue's pull request); the lead runs mesh-controller's unit
+   suite with `MESH_CHECK_BESIDE` naming a directory that holds the catalogue's branch, as mesh-controller's
+   `internal/beside` says.
 2. **The forge's merge checks run the integration tests again, as the gate** (`mesh/merge-gate`, `mesh/repo-check`). No
    second review: step 2 reviewed this tree.
 3. **A check that fails** goes back to the same reviewer, continued by its id, with the failure, for **one more cycle** of step 2 with
@@ -277,6 +285,12 @@ 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.
 
+**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
+never tells the operator to answer a Retry while an Approve is open, and reads the failed plan again after the
+answer: a Retry refused is asked again once the other plan ends.
+
 ## Models
 
 | Who | Model | Why |
@@ -300,7 +314,7 @@ on, with when it started and its bound.
 |---|---|---|
 | a fixing agent's issue | 30 minutes | ask it where it stands; split or take over |
 | the review | 15 minutes a round | ask the reviewer; stop at round 3 |
-| a merge check | 15 minutes | read the build queue (`mesh-controller.queue`) and the check's log |
+| a merge check | 15 minutes | read `mesh-delivery.show` (its state and verdict), then the check's log; the build queue (`mesh-controller.queue`) never lists a running check |
 | the Approve's ask | 5 minutes after both checks pass | read `mesh-delivery.show`: an ask not raised is a fault, said to the operator |
 | a merge after the Approve | 5 minutes | 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` |
@@ -319,6 +333,10 @@ the lead, when the state changes or the wait passes its bound. The lead never sl
 2026-10-19 one watcher sent on to three pull requests in turn missed that the third's checks had passed at 04:58,
 and the lead told the operator for 15 minutes that they were still running. The next wait gets a fresh watcher,
 and before a report the watcher reads the owning verb once more and says only what it says now.
+**An ask is said to exist only after it is read on the router.** Before the lead tells the operator that an
+Approve, a Retry or a Release waits for them, it reads `operator-channel.asks` and finds that ask open by its key;
+on 2026-10-20 an ask was named to the operator that the router did not hold. A merge the gate passed but whose
+ask is not on the router is the fault of the Approve's wait in the table above.
 
 **Every ten minutes (the operator, 2026-10-17), 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

03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md

@@ -4,6 +4,8 @@ status: in-progress
 code: [mesh-controller, mesh-catalog modules/mesh-delivery, mesh-delivery, mesh-host, mesh-sdk]
 updated: 2026-10-20
 decisions:
+  - "ADR 0463"
+  - "ADR 0457"
   - "ADR 0453"
   - "ADR 0452"
   - "ADR 0450"