Merge pull request 'Design 47: one plan per group, no order lines, the Approve as the only gate (ADR 0418, 0419, 0421)' (#404) from fix/design-47-records-0418-0421 into main

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

@@ -4,6 +4,10 @@ status: in-progress
 code: [mesh-controller, mesh-catalog modules/mesh-delivery]
 updated: 2026-10-17
 decisions:
+  - "ADR 0421"
+  - "ADR 0420"
+  - "ADR 0419"
+  - "ADR 0418"
   - "ADR 0408"
   - "ADR 0407"
   - "ADR 0406"
@@ -30,7 +34,6 @@ decisions:
   - "ADR 0270"
   - "ADR 0267"
   - "ADR 0250"
-  - "ADR 0249"
   - "ADR 0239"
   - "ADR 0238"
   - "ADR 0233"
@@ -42,12 +45,13 @@ decisions:
 
 **A change reaches the machines in one of three ways, all owned by mesh-delivery: a hotfix (one pull request,
 delivered at its merge), a feature (one branch name across its repositories: in two or more, one delivery
-group merged together and delivered member by member in its order; in one, a lone delivery), or an epic (a run of milestones, each delivered as a feature). The trunk is what runs; there
+group merged in one pass on the operator's one Approve and delivered by one delivery plan; in one, a lone
-is no "release branch"** (ADR 0401).
+delivery), or an epic (a run of milestones, each delivered as a feature). The trunk is what runs; there is no
+"release branch"** (ADR 0401, ADR 0418 §1, ADR 0421 §2).
 
 **Every step starts on an event, and the state lives on the bus.** The forge's events, the controller's
 events and the nodes' reports move a delivery; the bus's own rules keep the queues, the merge window and the
-order; and one chain, from module to commit to build to rollout to assignment, is kept in the bus's
+order of a plan's tiers, which only the module graph gives (ADR 0419); and one chain, from module to commit to build to rollout to assignment, is kept in the bus's
 key-value store as its only source (ADR 0406, ADR 0407, ADR 0408). A running delivery never touches merging:
 every merge is recorded at once for the next delivery plan of what it touches.
 
@@ -68,7 +72,7 @@ controller's delivery tables and the timers that polled them.
                                                           (deliveries, groups, a key per                          │
                                                            pull request, the state table)                         ▼
                                                                                                          node-engine on every node
- builders (build seat) ◄── work queues: delivery builds, ready checks, other checks ─────────────────────────  (reports; backups first)
+ builders (build seat) ◄── work queues: delivery builds, approve-asked checks, other checks ─────────────────  (reports; backups first)
 ```
 
 - **mesh-delivery** (the seat `mesh-delivery`) owns hotfixes, features and milestones as deliveries and delivery
@@ -82,8 +86,8 @@ controller's delivery tables and the timers that polled them.
   the build seat's own account, and take their jobs from the bus's work queues, delivery builds first
   (ADR 0405, ADR 0406).
 - **The forge module** (`gitea`) publishes every forge event on the bus through the forge's system webhook
-  (issue 729): pull requests updated, synchronized, labeled, unlabeled, commented, merged and closed, and
+  (issue 729): pull requests updated, synchronized, merged and closed, and commit statuses; no label or comment
-  commit statuses. It sets statuses, keeps the delivery's view as one comment on the pull request, and appends
+  moves a delivery, and mesh-delivery subscribes to none (ADR 0421 §11). It sets statuses, keeps the delivery's view as one comment on the pull request, and appends
   to the commit's note under `refs/notes/mesh-plan`.
 - **Each node's backup seat** (`node-backup`) backs up the data a delivery plan moves there before the plan
   sends anything (ADR 0404).
@@ -95,7 +99,7 @@ controller's delivery tables and the timers that polled them.
 | Way | What it is | How it is delivered |
 |---|---|---|
 | **hotfix** | one pull request in one repository | at its merge, as a lone delivery; a lone merge is cut at once (ADR 0282 §2, as ADR 0304 §1 changed it) |
-| **feature** | one branch name across its repositories; in two or more, its pull requests are one delivery group; in one, a single pull request | a group is merged together once its composed check passes and every member is marked, reviewed and approved, then delivered member by member in its order (ADR 0239 §16); in one repository, as a lone delivery like a hotfix |
+| **feature** | one branch name across its repositories; in two or more, its pull requests are one delivery group; in one, a single pull request | a group is merged in one pass once its composed check passed at every member's head and the operator gave the group's one Approve (ADR 0418 §4, ADR 0421 §2); its merges are one batch and one delivery plan, each module built once and sent once (ADR 0418 §1); in one repository, as a lone delivery like a hotfix |
 | **epic** | a run of milestones in one design (playbook 04) | each milestone is a feature, delivered when its own group is ready; the next starts when the previous one's delivery plan is done |
 
 - **The trunk is what runs.** Every delivery is cut from a repository's trunk. A merge into any other branch
@@ -106,10 +110,12 @@ controller's delivery tables and the timers that polled them.
 - **A milestone is functional, its delivery shaped technically.** A milestone is named by what the operator or
   the mesh can do once it is delivered; how it ships is shaped by the delivery plan its changes would have, asked of
   the controller's planner through mesh-delivery's `what-if` (ADR 0239 §3): the modules it moves and their fan-out.
-- **What a merge waits for.** mesh-delivery merges a group's members once the group's composed check passed at
+- **What a merge waits for.** After its checks, a merge waits for one act of a person: the operator's Approve,
-  their heads, the independent reviewer marked each member ready (ADR 0364 §1, §2), each member carries the
+  asked as soon as both required checks passed at the head (ADR 0421 §1, §3). For a group the Approve is asked
-  review ADR 0382 §6 asks, and the operator approved each merge into main (ADR 0398 §3). The operator's Approve is
+  once, when every member's checks and the group's composed check passed, and covers every member's head
-  asked for every merge into main, a hotfix's too (the operator, 2026-10-16 23:40).
+  (ADR 0421 §2); it is the review ADR 0382 §6 asks (ADR 0421 §9). No ready mark, label, comment, forge review or
+  recheck stands before it. The operator's Approve is asked for every merge into main, a hotfix's too
+  (ADR 0398 §3; the operator, 2026-10-16 23:40).
 
 ## A delivery
 
@@ -121,8 +127,12 @@ Its id is `<owner>/<repository>@<twelve characters of its commit>`. It holds:
   its diffset (ADR 0238 §2, as ADR 0323 §1 changed it);
 - its **state**, its **transitions** (the last hundred, each with when, the event, from, to and why), and its
   **machine steps** while delivering;
+- its **Approve**: the ask, the operator's answer with its warrant, and the review record the pull request was
+  opened with (ADR 0421 §5, §8);
 - once merged, **the commit it landed on the trunk as**, and the delivery plan that delivers it: the plan of the
-  batch that answers its merge, which may carry a later commit of its repository that contains it.
+  batch that answers its merge, which may carry a later commit of its repository that contains it. Every member
+  of a delivery group is delivered by the same plan, and its delivery ends with that plan's result
+  (ADR 0418 §1).
 
 **One key per pull request.** Beside the delivery, mesh-delivery keeps one key per open pull request on the
 bus: its head, the trunk commit its current check is asked against, and its verdict, written by
@@ -141,7 +151,7 @@ allows.
 |---|---|---|---|
 | proposed | a head was announced and is being checked | 1 hour from when its check is asked; none while its verdict is out of date and no check is asked | nothing: the check's own watchdog (S6) speaks |
 | checked | a verdict arrived | 1 minute | nothing: it is decided at once |
-| ready | it passed; it waits to be merged | none | — |
+| ready | it passed; its Approve is asked (a group member's once the group is ready), and it waits for it and the merge | none | — |
 | rejected | it failed its check | none | — |
 | published | merged on its trunk, recorded in a batch; it waits for its plan to start | 30 minutes | `superseded` when a plan that does not answer its merge took over its plan; `go` when its plan started |
 | held | it waits for a person: a failed backup (ADR 0404 §4), a policy of record; it ends by itself when it moves nothing or a later merge covers it (ADR 0270) | 1 day | nothing: it is the operator's |
@@ -152,7 +162,8 @@ allows.
 when the builder clones it, and the verdict names both. When another merge moves the trunk, a `ready`
 delivery goes back to `proposed` on the event `trunk moved`, and mesh-delivery asks the check of every active,
 cleanly merging open pull request into that trunk at once (ADR 0395, *A move of the trunk asks every check
-again* below). The row from `proposed` to `checked` takes only a verdict that names the trunk's head.
+again* below). An Approve already asked stays; the merge waits for the fresh check, and the Approve is not asked
+again for a trunk move (ADR 0421 §1, §3). The row from `proposed` to `checked` takes only a verdict that names the trunk's head.
 
 **What needs no person ends by itself** (ADR 0270): a merge that moves nothing is `delivered` at its merge; a
 merge a later delivered merge contains is `covered`, by the forge's word that the later merge commit contains
@@ -170,23 +181,29 @@ nodes' reports, never inferred from time.
 
 ## Order without a person
 
-*ADR 0239 §11 and §12, ADR 0249, ADR 0402.*
+*ADR 0419, ADR 0418 §2.*
 
-A delivery group's order is a table of pairs, each with the rule that won (ADR 0249 §3). The controller's
+A delivery group has no order among its members, and nobody writes one (ADR 0419 §1). Inside a plan only the
-`delivery-order` infers it from the manifests and the module graph; a person writes an `after: <repository>`
+module graph orders: the planner orders the build and deploy tiers by edges between modules, never between
-line only where the rules cannot see the order.
+repositories or members (ADR 0418 §2, ADR 0419 §3). Modules with no edge between them share a tier.
 
-| Rank (highest first) | Rule | Read from |
+| Edge | A module goes before | Read from |
 |---|---|---|
-| 1 | *declared*: an `after:` line | the member's description |
+| *built by* and *stands on* | the modules built by it or standing on it | the module graph |
-| 2 | *built by* and *version skew* | the module graph and the change |
+| *SDK before its users* | every module built on the SDK, `mesh-sdk` | the module graph |
-| 2 | *verb before caller*: a member adding a verb to a seat's served verbs before a member adding that verb to an invoked verb | the manifests (ADR 0402) |
+| *verb before caller* | a module whose change adds to its invoked verbs a verb this module's change adds to a seat's served verbs | the manifests |
-| 2 | *SDK before its users*: a member changing `mesh-sdk` before every member whose modules are built on it | the module graph (ADR 0402) |
+| *version skew* | (the controller, when the plan moves it) every module whose manifest the plan changes | the change |
-| 3 | *engine before controller* | module names |
-| 4 | the repositories' names | — |
 
-Rules of one rank in opposite directions reject the group, naming both members, both rules and the line that
+- **Engine before controller is the one default.** When a plan moves both the node-engine and the controller and
-would settle it (ADR 0249 §4).
+  no edge orders them, the node-engine's tier comes first; an edge either way wins over it (ADR 0419 §4).
+- **Each tier says the edge that placed it.** The plan, `delivery-order`, `show` and the plan's note name, for
+  each module placed after another, the edge and its rule, and where the default was overruled, the edge that
+  overruled it (ADR 0419 §5).
+- **A cycle is refused before anything merges.** Edges that form a cycle fail the group's composed check, or a
+  lone pull request's check, naming every module and edge in it. The way out is in the change itself (a verb
+  promised optional before it is required, ADR 0246), never an order typed by a person (ADR 0419 §6).
+- **No `after:` line is read.** mesh-delivery reads no `after:` line, no refusal asks for one, and a description
+  that holds one is told once on its pull request that the line is not read (ADR 0419 §2).
 
 **The SDK by version.** A Go module names the SDK by its released version and fetches it from the mesh's forge,
 checked against its recorded checksum; vendored copies go. Inside a group, a member may name the SDK member's
@@ -201,10 +218,10 @@ commit on the SDK's trunk or the head of an SDK pull request the forge holds, op
 *ADR 0323, ADR 0350, ADR 0395, ADR 0406.*
 
 - **Three work queues, taken in order.** Delivery builds go on a work-queue stream of their own; checks of pull
-  requests marked ready on a second; every other check on a third. A builder takes from the first, then the
+  requests whose Approve is asked or given on a second (ADR 0421 §10); every other check on a third. A builder takes from the first, then the
   second, then the third. Each check stream has one subject per pull request and keeps only the newest request:
-  a newer request replaces one still waiting, by the stream's rule. A ready mark publishes its pull request's
+  a newer request replaces one still waiting, by the stream's rule. The fresh check of such a pull request, asked
-  check request on the ready stream; a request left behind on the third for a head and trunk commit already
+  on the merge path, is published on the second stream; a request left behind on the third for a head and trunk commit already
   judged or running is acknowledged and dropped when taken, by reading the pull request's key. Nothing pauses the
   worker or deletes and republishes a request (issue 558).
 - **A running check stops itself.** It watches its pull request's key and stops when the head or the trunk
@@ -222,15 +239,15 @@ commit on the SDK's trunk or the head of an SDK pull request the forge holds, op
 
 - A trunk move asks the check of every active open pull request into that trunk that merges cleanly, against the
   new head; a conflict is told once on the pull request, not checked.
-- A pull request with no push and no ready mark for 7 days is left out; a push, a ready mark or a recheck asks
+- A pull request with no push for 7 days and no Approve asked or given is left out; its statuses say out of date
-  its check.
+  and that a push or a recheck asks its check (ADR 0421 §10).
-- For a group, a move asks each member's own check, and the composed check runs again through those rechecks; a
+- For a group, a move asks each member's own check, and the composed check runs again through those checks; the
-  move made by a member merging in the group's order asks the other members nothing.
+  group's own merges, made in one pass on its Approve, ask its members nothing again (ADR 0418 §4).
 - Its cost is at most one check per active, cleanly merging pull request per trunk move; issue 944 measures it.
 
 ### A delivery group's checks
 
-*ADR 0239 §14, ADR 0323 §6, ADR 0382, ADR 0403.*
+*ADR 0239 §14, ADR 0323 §6, ADR 0382, ADR 0403, ADR 0418 §4, ADR 0421 §2, §9.*
 
 - **The composed check is each member's gate.** The group's composed check composes every machine with all
   members' heads, each merged into its own trunk's head first, judged by the controller built from the group's
@@ -242,20 +259,39 @@ commit on the SDK's trunk or the head of an SDK pull request the forge holds, op
   heads exists. A member's new head, close or base move puts the composed verdict out of date, and with it every
   member's gate. When mesh-delivery cannot say the groups, the pull request is checked alone and its verdict
   says so (ADR 0382 §1).
-- **A member merges only with its group passed and reviewed** (ADR 0382 §6), and in the group's order
+- **A group merges in one pass, with no order.** Once the composed check passed at every member's head and the
-  (ADR 0364 §8).
+  operator's one Approve covers those heads, mesh-delivery merges every member in one pass, no member waiting for
+  another's merge or delivery (ADR 0418 §4). The Approve is the review ADR 0382 §6 asks: the merge tool reads its
+  warrant for those heads in place of an approving forge review (ADR 0421 §9). A member the forge refuses is
+  merged again on its fresh check while the group's batch stays open for it.
 
-## Ready marks and the merge
+## The Approve and the merge
 
-*ADR 0364, ADR 0406 §1.*
+*ADR 0421, ADR 0398 §3, ADR 0406 §1.*
 
-The independent reviewer marks a pull request ready at the reviewed head with the label `mesh/ready` and a
+- **Asked as soon as the checks pass.** When a pull request's delivery reaches `ready` (both `mesh/merge-gate` and
-comment `ready at <full sha>`, through `mesh-delivery.mark-ready`. The forge's `labeled` and `commented` events
+  `mesh/repo-check` passed at its head against its trunk's head), mesh-delivery asks the operator's Approve of its
-reach mesh-delivery in seconds; once both required checks passed against the trunk's head, it asks the operator's
+  merge into main at once, on a channel that proves who answered (ADR 0274; Telegram today). The ask names the
-Approve for a merge into main, with the pull request, its issues, the reviewer's verdict and the delivery plan, and
+  pull request, its issues, the reviewer's verdict, the delivery plan and the trunk commit the checks judged. A
-merges the marked head through the forge's merge tool on that Approve (ADR 0398 §3). When the trunk moved, the merge tool asks the fresh check, and the event
+  verdict that names a trunk commit the trunk had already left raises no ask: mesh-delivery asks that head's check
-of its passing verdict asks the merge again; no timer asks it. A push clears the mark (the `synchronized`
+  against the trunk's head, and its passing verdict raises the ask (ADR 0421 §1).
-event), and a failed check is said once and listed by `stalled`.
+- **A group is asked once.** One ask names every member and its head, once every member is `ready` and the
+  composed check passed at those heads; one Approve covers them all (ADR 0421 §2).
+- **The reviewer's verdict is attached, not a gate.** The review finishes before the push (playbook 07), and the
+  session that opens a pull request gives its review record: who reviewed it, the commit the review approved and
+  the verdict. The ask carries it; with none, or one naming another commit, the ask says so in its first line and
+  the operator decides (ADR 0421 §5).
+- **The merge.** mesh-delivery merges through the forge's merge tool at the heads the Approve names, only while
+  they are still the heads and both checks passed against the trunk's head. When the trunk moved, the merge tool
+  asks the fresh check, and the event of its passing verdict asks the merge again; no timer asks it, and no person
+  rechecks (ADR 0421 §3, §12).
+- **A push or a Decline ends the Approve.** A new head ends its ask or its Approve, for a group every member's, and
+  is said once on the pull request; the new head is asked again once its checks pass. A Decline merges nothing and
+  is said once (ADR 0421 §6).
+- **A failure is said, never merged past.** An approved head whose check failed is said once on the pull request
+  and listed by `stalled`; so is a merge the merge tool kept refusing for an hour (ADR 0421 §7).
+- **Recorded.** The ask, the answer with its warrant and the review record are kept on the delivery, shown by
+  `show` and said in mesh-delivery's log; the merge's transition names the Approve (ADR 0421 §8).
 
 ## The merge window and the batch
 
@@ -269,12 +305,19 @@ event), and a failed check is said once and listed by `stalled`.
   refreshed by each merge into the batch, beside a key set once when the batch opens whose time to live is
   `merge-window-at-most` (10 minutes). The first to expire closes the batch, heard by a watcher; no cutter
   polls. A stop that records merges again into the open batch closes its window too (ADR 0299 §3).
+- **A group's merges are one batch.** A batch holding a merge of a delivery group with a member not yet merged
+  does not close when either key expires; once the group's last member merged, the window runs again from that
+  merge. A group whose last member has not merged ten minutes (`merge-window-at-most`) after its first raises a
+  condition naming the member and why, and nothing of the group is delivered while it waits (ADR 0418 §3).
 - **A lone merge is cut at once**: no batch it shares a repository, module, graph edge or delivery group member
   with is assembling (ADR 0282 §2, ADR 0304 §1, ADR 0306).
 - **The plan.** A closed batch becomes one delivery plan: every commit in it, tiered along the module graph
-  across repositories, at most one commit per repository, the latest of its trunk. It answers every merge in the
+  across repositories, at most one commit per repository, the latest of its trunk, each module it moves built once
-  batch, its own commits and the earlier merges a later commit contains (ADR 0276 §2, as ADR 0299 §7 changed it).
+  and sent once to each node that runs it. It answers every merge in the batch, its own commits and the earlier
-- **A plan fixes its commits when it starts.** A plan starts at its first send, after mesh-delivery's word, and
+  merges a later commit contains (ADR 0276 §2, as ADR 0299 §7 changed it; ADR 0418 §1). No member of a group has
+  a turn: only the module graph orders its tiers (ADR 0418 §2).
+- **A plan fixes its commits when it starts.** A plan starts at its first send, after mesh-delivery's word, given once for a
+  group's plan when every member is merged (ADR 0418 §2), and
   from then nothing that merges changes it. A plan still waiting for its word is folded into the next batch
   (ADR 0276 §4).
 - **Plans that share something run one after another.** A batch that shares a repository, a module or a graph
@@ -282,7 +325,9 @@ event), and a failed check is said once and listed by `stalled`.
   that shares none runs beside the open ones, so a hotfix is never held by an unrelated feature's delivery.
 - **The ends.** A plan done ends every delivery it answers: `delivered` for its own commits, `covered` for an
   earlier merge it carried by a later commit. A plan that failed fails its own commits' deliveries; each earlier
-  merge it answered is then delivered on its own commit, the newest first, until one is delivered (ADR 0276 §3).
+  merge it answered is then delivered on its own commit, the newest first, until one is delivered (ADR 0276 §3). A
+  group's plan fails as one: no member is stopped because another failed, what earlier tiers delivered stays, and
+  the fix is a new change (ADR 0418 §5).
 - **Shown.** `plans` lists the open batch first, with its window's time left and its merges, and a batch waiting
   behind an open plan names that plan; the controller says the batch as `plan-moved` in the state `assembling`.
 
@@ -325,9 +370,9 @@ nothing, and the plan says so for that node.
 
 One plan carries every merge of its batch, so a stop ends only the change it is for:
 
-- **A group's stop.** When a member after a failed one is stopped and its plan is open, mesh-delivery asks
+- **No stop by member.** A group's plan fails as one (ADR 0418 §5), so mesh-delivery asks no stop of a member
-  `delivery-stop` for that plan with the stopped members' merges to leave out. The controller ends the plan and
+  after a failed one. The mechanism stands for a person's stop with the way `again`: the controller ends the plan
-  records every other merge it answered again in the open batch of its kind, whose window the stop closes.
+  and records every other merge it answered again in the open batch of its kind, whose window the stop closes.
 - **What is left out with it.** A later merge of the stopped merge's repository, and a merge that moves a
   module a left-out merge moves, would deliver the stopped change; each is left out too, its delivery `stopped`,
   naming why.
@@ -426,27 +471,29 @@ forge module's files of what it announced (ADR 0406 §6).
 | Verb | Answers or does |
 |---|---|
 | `deliveries` | every delivery not final, the final ones of the last day, and every one `stalled` still lists |
-| `show` | one delivery or group whole: plan, transitions, machine steps, order, the chain's links |
+| `show` | one delivery or group whole: plan, the edge that placed each tier, the Approve, transitions, machine steps, the chain's links |
-| `groups` | every group with its members in order and its derived state |
+| `groups` | every group with its members and its derived state |
 | `what-if` | the delivery plan a diffset would have, asked of the controller's planner |
 | `table` | the state table and the machine-step table, with bounds and H2's repairs |
 | `stalled` | every delivery held past its bound, with the transition H2 may take |
-| `mark-ready` | a reviewer's mark at a head: the label and the `ready at` comment, by the mesh's own forge account |
+| `recheck` | an exception verb, no step of the flow: a check asked again for a proposed delivery nothing else asks again, an inactive one or a failed verdict gone out of date (ADR 0395 §6, ADR 0421 §12) |
-| `recheck` | a check asked again for a delivery whose verdict is out of date (ADR 0395 §6) |
 | `release` | a held delivery goes on, with why; for a failed backup it asks the backups again |
 | `stop` | a delivery to stopped, with why; on a shared plan it first answers what it would take down (ADR 0299) |
 | `close` | H2's only verb: the transition the table names for a stalled delivery |
 | `retire-history` | held history to retired (ADR 0250) |
 | `times` | each class's budget, the week's median and worst delivery time, and the deliveries over budget |
 
-**The controller's verbs for it**: `delivery-plan`, `delivery-order`, `delivery-check`, `deliver`,
+**The controller's verbs for it**: `delivery-plan`, `delivery-order` (the edges that order a plan's tiers,
+ADR 0419 §2), `delivery-check`, `deliver`,
 `delivery-stop`, `delivery-walks`, and `plans` (the open batch, the open plans, and a what-if for a repository
 and its files). A person has `plans go <plan> --why`.
 
 ## The bootstrap
 
 - A plan that moves the controller, the node-engine, the tool runner, the bus or mesh-delivery is the
-  controller's own, started by the merge; mesh-delivery records it (ADR 0239 §31).
+  controller's own, started by the merge; mesh-delivery records it (ADR 0239 §31). Such a merge shares one batch
+  and one plan with the other merges of its delivery group, and that plan is started by the controller when the
+  group's batch closes, not by its own merge (ADR 0418 §6).
 - Any other plan waits for `deliver` while the seat has a holder on record; with none, the controller starts it.
 - A replaced controller or mesh-delivery carries on from the bus: the keys, the queues and the durable
   consumers hold every step, so nothing is lost or repeated (ADR 0406 §6).
@@ -456,14 +503,17 @@ and its files). A person has `plans go <plan> --why`.
 What the build proves before this design is implemented (research 055's direction):
 
 1. A feature across the controller and the catalogue with a new seat verb is delivered as one group, with no
-   `after:` line, no two steps and one composed check.
+   `after:` line, one composed check, one Approve and one delivery plan: its merges are one batch, each module is
+   built once and sent once, its commits are carried by that one plan, and the plan names the edge that placed
+   each tier.
 2. An SDK change and a Go module using it are delivered as one group.
 3. A data module is backed up before a delivery moves it, and a failed backup holds the delivery.
 4. A build on any builder uses the installed toolchain with no container, and a toolchain update rebuilds only
    modules of that language when its version changes.
 5. Two merges into one repository within a minute leave each open pull request with one queued check, by the
    stream's rule.
-6. A ready mark is acted on within seconds of its event.
+6. The operator's Approve is asked within seconds of the event of a pull request's checks passing, with no ready
+   mark, label or comment written by anyone.
 7. A controller replaced in the middle of a rollout resumes it with no step lost or repeated.
 8. The merge window closes by its key's expiry.
 9. A hotfix to a module the running feature's delivery does not touch reaches the machines in minutes, beside it.
@@ -480,6 +530,13 @@ What the build proves before this design is implemented (research 055's directio
 - The window cutter, the merge catch-up timer, the rollout ticker, mesh-delivery's tick, reconcile and
   ready-mark poll, the forge's poll as a trigger, the queue reordering, the forge-asking cancel, and the forge
   module's announcement files (ADR 0406, ADR 0407).
+- The ready mark: the label `mesh/ready`, the `ready at` comment, `mark-ready`, the forge module's
+  `ready-authors` setting, and mesh-delivery's subscriptions to labeled, unlabeled and commented events
+  (ADR 0421 §4, §11); a recheck by hand as a step of the flow (ADR 0421 §12).
+- A group's order: `after:` lines, the ranked rules and the order of the repositories' names (ADR 0419, which
+  supersedes ADR 0249).
+- Delivery member by member, a stop of a member after a failed one, and the own path's separate batch for a
+  group's merges (ADR 0418 §1, §5, §6).
 - The controller's tables of builds, build requests, rollouts and their tiers, batches and merges, and
   assignments; the record mirrors, probe D17's audit and healer H6 for those kinds (ADR 0408).
 
@@ -492,12 +549,17 @@ when the previous one's delivery is done.
 |---|---|---|---|---|
 | 1 | A merge during a running delivery is never dropped and needs no person's release; the merge window lives on the bus; a rollout that shares nothing with an open one runs beside it | 8, 9, 11 | mesh-controller | 973 (with the rest of 525); delivered 2026-10-17 (mesh-controller #366, #367) |
 | 2 | A ready mark is acted on within seconds, and each pull request has at most one waiting check | 5, 6, 7 | mesh-controller, mesh-catalog (mesh-delivery, gitea) | 974, 975, 976; delivered 2026-10-17 in one plan (mesh-controller #368, mesh-catalog #345) |
-| 3 | A feature with a new seat verb across the controller and the catalogue is delivered as one group: no `after:` line, one composed check, no "release branches" | 1 | mesh-controller, mesh-catalog (mesh-delivery) | 977, 978 |
+| II | phase II: build-agent and route-proxy live whole in mesh-controller, in two releases under ADR 0420 (accepted 2026-10-17): release 1 has the controller accept a reviewed move and mesh-delivery announce each merge with its Approve; release 2 is the move | — | mesh-controller, mesh-catalog (mesh-delivery, build-agent, route-proxy) | release 1: 1025; release 2: 1019 |
+| 3 | A feature with a new seat verb across the controller and the catalogue is one group, one batch, one delivery plan and one Approve: no order lines, no ready mark, each module built and sent once | 1, 6 | mesh-controller, mesh-catalog (mesh-delivery, gitea) | 977, 978, 1022; 605 (1021 closed as its duplicate) is resolved by this build (ADR 0419 §7) |
 | 4 | A delivery backs up the data it moves first, and a failed backup holds it and is said | 3 | mesh-controller, mesh-catalog (mesh-delivery, the backup seat's holder) | 980 |
 | 5 | One read of a module on a node names the commit, build and rollout that put it there | 10, 12 | mesh-controller, mesh-catalog (mesh-config, nats) | 981 |
 | 6 | Builds use installed toolchains with no container, builders fetch over SSH with their own key, and an SDK change ships in one group with its users | 2, 4 | mesh-catalog (build modules, build-agent, ssh-client, gitea), mesh-controller, mesh-sdk | 979, 971 |
 
-The issues are linked `depends-on` in this order; 976 depends on 975, and 979 also on 971.
+The issues are linked `depends-on` in this order; 976 depends on 975, and 979 also on 971. Phase II is not a
+milestone of this design's own: it was put before milestone 3 by the operator on 2026-10-17, and its release 2
+is opened only once release 1's delivery plan is done. Milestone 3 builds ADR 0418, ADR 0419 and ADR 0421
+(issues 977, 978 and 1022). Acceptance test 6 spoke of a ready mark when milestone 2 was delivered; restated for
+the Approve, it is proved again by milestone 3.
 
 ## What is not decided here