66 lines
4.3 KiB
Markdown
66 lines
4.3 KiB
Markdown
# Playbook 04 — Work breakdown and handoff
|
|
|
|
**Trigger.** A to-be design is settled (playbook [02](02-graduation.md)) and its building is about to start.
|
|
|
|
**Who runs it.** The lead who will run the feature, on the larger model. It is one sitting, bounded at about
|
|
an hour, and said to the operator if it runs past.
|
|
|
|
## What it produces
|
|
|
|
A design becomes **milestones**, and each milestone becomes **issues**:
|
|
|
|
- **A milestone is usable on its own.** Once its delivery plan is done, the operator or the mesh can do
|
|
something new, said in one sentence ("a Claude Code session is mirrored into a thread on the bus").
|
|
A milestone that changes nothing anyone can use is not a milestone; fold it into the next.
|
|
- **A milestone is one feature step** of playbook [07](07-feature-branches.md): prepared, developed in one to
|
|
two hours, reviewed, checked and delivered as one. A milestone larger than that is split.
|
|
- **An issue is one repository's part of a milestone,** sized so a fixing agent finishes it inside the
|
|
milestone's development time. Issues that must land in order are linked `depends-on`.
|
|
|
|
## Steps
|
|
|
|
1. **Confirm the design is settled.** Its frontmatter reads `status: designed`, and every claim in it traces
|
|
to a decision record in the knowledge base (`knowledge-base.get` for each entry of its `decisions:`). An
|
|
open question in the text is a reason to go back to playbook [01](01-research.md), not to build around it.
|
|
2. **Name the owners.** Set `code:` in the design's frontmatter to the repositories from
|
|
[`repos.md`](../repos.md). A repository that does not exist yet is added to `repos.md` in the same change.
|
|
3. **Check the as-is.** Read the matching `03-DESIGN/00-as-is/` document. What is being replaced is stated
|
|
there; if it is not, write it before changing it. Building against an undocumented as-is is how a shipped
|
|
behaviour gets lost.
|
|
4. **Break it into milestones.** Write them into the design, in a section *Milestones*: for each, its number,
|
|
its one-sentence outcome, the repositories it touches, and what it depends on. Order them so each is
|
|
usable as soon as it is delivered, the smallest useful one first.
|
|
5. **Ask the operator to confirm the milestones**, in a short table: number, outcome, repositories, the
|
|
parts each repository builds. Change what they change.
|
|
6. **Open the issues.** For each confirmed milestone, `issue-tracker.open` one issue per repository part, its
|
|
title the symptom or capability in plain words, its report naming the design, the milestone and the
|
|
decisions it builds with; link the order with `depends-on`. Write the issue numbers into the milestone's
|
|
entry in the design.
|
|
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.
|
|
9. **On completion of the last milestone**, run the "when something ships" section of playbook
|
|
[02](02-graduation.md).
|
|
|
|
## Rules
|
|
|
|
- What the handoff leaves for later is an issue with an owner, named in the design or the decision that leaves
|
|
it — never a sentence saying "later". The design's `code:` names who owns what is built; the issue names who
|
|
owns what is not. The knowledge base's rule `deferral` checks the decision record when it is proposed
|
|
([issue 354](../../04-ISSUES/354-a-decided-rename-was-never-scheduled-and-the-operator-believed-it-live/00-report.md)).
|
|
- HQ is not a code repository and never carries implementation.
|
|
- How the building is done — worktrees, agents, review, checks, the ready mark and the delivery — is playbook
|
|
07's, not this one's.
|
|
|
|
## How it is checked
|
|
|
|
Read by the lead and the reviewer today; a check in hq's merge-check is tracked by issue 845.
|
|
|
|
- A design in `status: in-progress` has a *Milestones* section, each milestone with its outcome and its
|
|
issues; an in-progress design without one is the smell of building without a breakdown.
|
|
- Every issue a milestone names exists in the tracker (`issue-tracker.get`), and an issue in `fixing` names
|
|
its milestone in its report.
|
|
- A milestone whose issues are all `resolved` has had its delivery plan done; its outcome sentence is proven on
|
|
the mesh before the next milestone starts.
|