Playbooks 04 and 07 after research 055: a milestone's shape from what-if; the Approve on every merge into main; when the two-step exception ends (issue 922)

2026-10-17 00:04:48 +02:00
parent b6a191d0a6
commit 75d3ac0f82
2 changed files with 6 additions and 2 deletions
@@ -30,7 +30,8 @@ A design becomes **milestones**, and each milestone becomes **issues**:
 4. **Break it into milestones.** Write them into the design, in a section *Milestones*: for each, its number,
   its one-sentence outcome, the acceptance tests of the design it proves, the repositories it touches, and
   what it depends on. Order them so each is usable as soon as it is delivered, the smallest useful one
-   first.
+   first. A milestone is named by what it lets someone do; how it ships is shaped by the plan its changes would
+   have, asked through `mesh-delivery.what-if`: the modules it moves and their fan-out (ADR 0401 §6).
 5. **Ask the operator to confirm the milestones**, in a short table: number, outcome, the acceptance tests it
   proves, repositories, the parts each repository builds. Change what they change.
 6. **Open the issues.** For each confirmed milestone, `issue-tracker.open` one issue per repository part, its
@@ -140,12 +140,15 @@ never into the running one, unless it blocks the running one.
 5. **The reviewer marks each pull request ready as soon as the acceptance is shown** 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
-   (ADR 0364). The operator's word is waited for only when the step changes what the operator sees, removes
+   and the operator approved the merge into main on Telegram or at the terminal (ADR 0364, ADR 0398 §3). Beyond that
+   Approve, the operator's word is waited for only when the step changes what the operator sees, removes
   data, or needs a step only the operator's terminal can take; the lead says which before the step starts.

 **One exception: a catalogue change that uses a new manifest word.** The catalogue's merge check reads
 manifests with the controller the mesh runs, so the controller's pull request is merged and delivered first;
 then `mesh-delivery.recheck` the catalogue's and merge it on the new verdict. Plan such a feature as two steps.
+The exception ends when milestone 3 of design 47 is delivered (issue 977, ADR 0402, ADR 0403): the group's composed
+check, judged by the group's controller, is then each member's gate, and the feature is one group.

 ## Phase 4 — Deliver