Give design 57 its milestones and check every write-back moment (issue 1009, review round 1)

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

@@ -243,7 +243,7 @@ next action; then the prompt the operator pastes. The context files make the fea
 ## The design's state is written back
 
 Other sessions know what is built only from the design's frontmatter and the issue tracker; what the lead
-knows and does not write back, nobody else knows. A design merged as one release with three of its tasks
+knows and does not write back, nobody else knows. A design merged in one delivery with three of its tasks
 left, its frontmatter still saying `designed`, read to another session as not built, and a second design
 was started beside it (issue 1009, 2026-10-17). So the lead writes the design's state back at each of these
 moments, the same hour, an hq change going through [playbook 08](08-small-fixes.md):
@@ -276,6 +276,10 @@ 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.
+- 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
   of two designs in `fixing` at once is the failure of "one design is built at a time".
 - More than one open pull request in a repository that share no feature name, or a feature step whose issues