Playbook 07: one design is built at a time (issue 1007)

The operator decided on 2026-10-17 that a second design's milestones wait until the design being built is delivered; nothing in the playbooks said so.
2026-10-17 13:22:41 +02:00
parent c61f01d63e
commit 974b3e7d42
2 changed files with 11 additions and 1 deletions
@@ -41,7 +41,9 @@ A design becomes **milestones**, and each milestone becomes **issues**:
 7. **Flip the status.** `status: in-progress`, `updated:` today; the design change goes through playbook
   [08](08-small-fixes.md) (one hq pull request).
 8. **Hand each milestone to playbook 07, one at a time.** The milestone is the feature step; its issues are the
-   step's issues; the next milestone starts when the previous one's delivery plan is done.
+   step's issues; the next milestone starts when the previous one's delivery plan is done. A design waits while
+   another design's milestones are being built: one design is built at a time (playbook
+   [07](07-feature-branches.md)), so this step starts only when the design before it is delivered.
 9. **On completion of the last milestone**, run the "when something ships" section of playbook
   [02](02-graduation.md).

@@ -49,6 +49,12 @@ A feature that cannot be developed in about two hours is split into **steps**. E
 phases on its own; the next step starts only when the previous step's delivery plan is done. A step is the
 unit that ships, so nothing finished waits for work that is not.

+**One design is built at a time** (the operator, 2026-10-17). While the milestones of one design are being
+built, no milestone of another design starts: its issues stay `open`, and nobody moves them to `diagnosing` or
+`fixing`. The next design starts when the last milestone of the one being built has its delivery plan done. A
+lead who finds another design's milestone already in `fixing` asks its owner before starting its own. A small
+fix ([playbook 08](08-small-fixes.md)) and an issue that is in no design's milestones are not held by this rule.
+
 **Scope is fixed at phase 0.** An issue found during a feature goes to the next step or the next feature,
 never into the running one, unless it blocks the running one.

@@ -248,6 +254,8 @@ 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.
+- The issues in `fixing` (`issue-tracker.list`) belong to the milestones of 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
  stay in `fixing` for more than a working day, is the smell: stop and bring it to the operator.
 - A review report that asks a change outside the issues' done-when, or a fourth round, is the failure of the