Merge pull request 'Playbook 07: the lead writes a design's state back (issue 1009)' (#398) from fix/design-status-written-back into main

2026-10-17 11:38:12 +00:00
parent 84b464d109 2cea6c9b0c
commit d901156614
2 changed files with 43 additions and 2 deletions
@@ -240,6 +240,25 @@ lead prepares a `/clear` as the mesh's instruction "prepare before clear" says:
 feature's phase, its branches and heads, the context files' paths, the agents' ids, the wait list and the
 next action; then the prompt the operator pastes. The context files make the feature resumable after a clear.
 ## 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 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):
 - **The first step starts:** the design's `status: in-progress` ([playbook 04](04-build-handoff.md) step 7),
  if it is not already.
 - **A step's delivery plan is done:** its issues are resolved (phase 4), and the design's milestone entry says
  it is delivered, with the date.
 - **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
  a design that waits its turn gets the same note.
 - **The last milestone is delivered:** [playbook 02](02-graduation.md), "When something ships": the as-is is
  written and the design says `implemented`.
 ## Issues that stop
 An issue stays in `fixing` only while an agent works on it. A step that stops, for a wait past its bound, a
@@ -254,6 +273,13 @@ issues in `fixing` that nobody works on reads to the operator as stuck work.
  phase 1, is the failure this playbook prevents.
 - A context file exists per touched repository under `.work/<slug>/` while the feature runs.
 - After a feature's delivery, `git branch -r | grep feat/<slug>` and `git worktree list` return nothing for it.
 - 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
@@ -1,8 +1,8 @@
 ---
 layer: to-be
-status: designed
+status: in-progress
 code: [mesh-controller, mesh-host, mesh-sdk, mesh-catalog]
-updated: 2026-10-14
+updated: 2026-10-17
 decisions:
  - "ADR 0348"
  - "ADR 0349"
@@ -61,6 +61,10 @@ both, by the form of its manifest, and the old forms stay accepted until the las
 Inside the release this still holds: the media catalogue and the applications kept in their own
 repositories move after it, so the old forms stay accepted until they have (R1).
 **Where it stands, 2026-10-17** (the Milestones section below). The packages' branches were merged into
 main of mesh-controller, the node-engine (`mesh-host`) and mesh-catalog on 2026-10-16. T6 moved after them, as
 planned above, and is resolved. B3 was left out as well, so B3, R1 and R2 are what is left.
 ## What exists already, measured
 Counted 2026-10-14 at mesh-controller `1601cb1`, the node-engine (`mesh-host`) `1a26778`, mesh-sdk `a2d2af0`, mesh-catalog
@@ -333,6 +337,17 @@ removed code.
 amended, the 67 documents that still say "setting" in running prose are reworded so the glossary can
 retire the word (F4 left it off the *Not:* line for them), design 49 lists the Config domain, ADR 0348's and 0349's built status is said, and this document's status becomes `implemented`.
 ## Milestones
 Written back on 2026-10-17 (playbook 07, "The design's state is written back"): the packages above were built
 as one delivery, not milestone by milestone, so the milestones are what was delivered and what is left.
 | # | Outcome | Packages | Issues | State |
 |---|---|---|---|---|
 | 1 | Config, provisioning, secrets, bindings, collections and runtime asks run the new way; the old forms are still accepted | every package but T6, B3, R1, R2 | 647, 650 to 679 but 659, 681, 684, 685 | merged into main and delivered on 2026-10-16; issues resolved |
 | 2 | The media catalogue and the applications carry their file text as templates | T6 | 659 | resolved; delivered on 2026-10-16 |
 | 3 | The other providers answer their consumers; the old forms are refused; the record says what runs | B3, R1, R2 | 680, 682, 683 | open: built after design 47's milestones are delivered and before design 58 starts (the operator, 2026-10-17; one design is built at a time, playbook 07) |
 ## What is deliberately not here
 - **Secrets in a module's own code** wait on issue 569 (a module's tools run as the tool runner's