Playbook 07: a design names its milestones' issues, never their delivery state (issue 1038)

The tracker and the delivery records hold whether a milestone is delivered, when and by what;
a copy in the design's table is a central status kept by hand (AGENTS.md). Design 47 loses its
copied cells.

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

@@ -272,8 +272,10 @@ moments, the same hour, an hq change going through [playbook 08](08-small-fixes.
 
 - **The first milestone starts:** the design's `status: in-progress` ([playbook 04](04-build-handoff.md) step 7),
   if it is not already.
-- **A milestone's delivery plan is done:** its issues are resolved (phase 4), and the design's milestone entry says
-  it is delivered, with the date.
+- **A milestone's delivery plan is done:** its issues are resolved (phase 4), with `fixed-by` naming its pull
+  requests. The design's milestone entry is not changed: it names the milestone's issues, and whether they are
+  delivered, when and by what is read from the issue tracker when it is asked, never copied into the design
+  (issue 1038; AGENTS.md: cross-cutting views are generated when they are read).
 - **The building pauses with work left** (another design takes its turn, a hand-over, the session's end): the
   design stays `in-progress`, and each issue left gets a note with `issue-tracker.note` saying what it waits
   for and what comes after it ("built after design N is delivered, before design M"). The first issue of
@@ -300,8 +302,9 @@ issues in `fixing` that nobody works on reads to the operator as stuck work.
 - A design whose milestone issues are partly resolved says `in-progress`, and one whose issues are all
   resolved and delivered says `implemented`: read its Milestones section against `issue-tracker.get` for each
   issue. A design that says `designed` with a resolved milestone issue is a state not written back.
-- A milestone whose issues are all resolved and delivered has the date in its entry in the design's Milestones
-  section; an entry without it is a delivery not written back.
+- A design's Milestones section names each milestone's issues and nothing of their state: a "delivered", a date
+  or a pull request in an entry is a copy of the tracker's state (issue 1038), read with
+  `grep -n 'delivered' <design>` over its Milestones section.
 - Every open issue of a design that says `in-progress` and has no agent on it shows, in `issue-tracker.get`, a
   note saying what it waits for; one without such a note is a pause not written back.
 - The milestone issues in `fixing` (`issue-tracker.list`) belong to one design at most: milestone issues

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

@@ -547,9 +547,9 @@ when the previous one's delivery is done.
 
 | # | Outcome | Acceptance tests | Repositories | Issues |
 |---|---|---|---|---|
-| 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) |
-| 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, delivered 2026-10-17 (mesh-controller #369, mesh-catalog #348); release 2: 1019 |
+| 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) |
+| 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 |
+| 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 |