Playbook 07: the lead writes a design's state back (issue 1009)

Design 57 was merged as a release with three tasks left and still said
designed, so another session took it for unbuilt. Say it in-progress, with
what is left and when it is built.
This commit is contained in:
jochen
2026-10-17 13:33:37 +02:00
parent 84b464d109
commit b83a1e748e
2 changed files with 29 additions and 2 deletions
+22
View File
@@ -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 as one release 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,9 @@ 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.
- 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,11 @@ 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 release is merged into main of mesh-controller, the node-engine
(`mesh-host`) and mesh-catalog, and delivered. Every package but B3, R1 and R2 is resolved. Those three
(issues 680, 682 and 683) are built after design 47's milestones are delivered and before design 58 starts,
the operator's decision of 2026-10-17 (one design is built at a time, playbook 07).
## What exists already, measured
Counted 2026-10-14 at mesh-controller `1601cb1`, the node-engine (`mesh-host`) `1a26778`, mesh-sdk `a2d2af0`, mesh-catalog