Playbook 07, features, in five phases with bounds: prepare (the lead settles the questions and writes one context file per repository, 15 min); develop (one fixing agent per repository kept for the whole feature, unit tests only, 1 to 2 hours); review (one reviewer, reports both ways to the same agents, at most 3 rounds, 15 min); check (push once, the merge checks run the integration tests, no second review; a failed check gets one more review cycle); deliver (the delivery plan). A larger feature is split into steps, each through every phase; the next step starts when the previous one's delivery plan is done. Scope is fixed at phase 0. Models per step (smaller for fixing and reading, larger for the lead, the review and decision records). A wait list with a bound per wait, said at once when one is passed; a report every ten minutes with the allowance used; a prepared clear at each phase end.
Kept from the old text: one branch name and one worktree per repository, sibling worktrees for the lab, landing by fast-forward under a lock when several agents share a repository, fetch by name, the catalogue's new-manifest-word exception, how it is checked.
Dropped: one fresh agent per five-to-ten-minute issue and the per-issue ready note (replaced by the per-repository context file), review rounds of up to five.
Playbook 08, small fixes: one issue in one repository, about an hour; local build with the failing test first, one review of the local commit (findings back to the same agent), push once, one delivery, resolved the same hour; bounds per wait.
The overview's table lists both. Neither uses the words walk or rollout: hq's glossary still keeps walk and retires rollout; flipping that is issue 646 (the operator: never use walk), its own change across the glossary, hq, the code's output and the knowledge base.
The two mesh-wide instructions that point here (prepare-before-clear with concrete moments, developing-a-feature) are proposed through the claude-code module for the operator's approval.
sh merge-check.sh passes. Review: the operator's own reading (it changes how every session works).
The operator's flow of 2026-10-15, written down.
**Playbook 07, features**, in five phases with bounds: prepare (the lead settles the questions and writes one context file per repository, 15 min); develop (one fixing agent per repository kept for the whole feature, unit tests only, 1 to 2 hours); review (one reviewer, reports both ways to the same agents, at most 3 rounds, 15 min); check (push once, the merge checks run the integration tests, no second review; a failed check gets one more review cycle); deliver (the delivery plan). A larger feature is split into steps, each through every phase; the next step starts when the previous one's delivery plan is done. Scope is fixed at phase 0. Models per step (smaller for fixing and reading, larger for the lead, the review and decision records). A wait list with a bound per wait, said at once when one is passed; a report every ten minutes with the allowance used; a prepared clear at each phase end.
Kept from the old text: one branch name and one worktree per repository, sibling worktrees for the lab, landing by fast-forward under a lock when several agents share a repository, fetch by name, the catalogue's new-manifest-word exception, how it is checked.
Dropped: one fresh agent per five-to-ten-minute issue and the per-issue ready note (replaced by the per-repository context file), review rounds of up to five.
**Playbook 08, small fixes**: one issue in one repository, about an hour; local build with the failing test first, one review of the local commit (findings back to the same agent), push once, one delivery, resolved the same hour; bounds per wait.
The overview's table lists both. Neither uses the words walk or rollout: hq's glossary still keeps walk and retires rollout; flipping that is issue 646 (the operator: never use walk), its own change across the glossary, hq, the code's output and the knowledge base.
The two mesh-wide instructions that point here (prepare-before-clear with concrete moments, developing-a-feature) are proposed through the claude-code module for the operator's approval.
`sh merge-check.sh` passes. Review: the operator's own reading (it changes how every session works).
A feature waited a day for its last issue, each small issue paid for its context again, and
waits nobody saw cost the most time. The operator set the flow on 2026-10-15: prepared context
per repository, one to two hours of local development on unit tests, one review of at most three
rounds back to the same agents, one push for the integration checks, then the delivery plan;
steps for a larger feature; a separate playbook for small fixes; models per step; a wait list
with bounds; a prepared clear at each phase end.
Deliverynovox/hq@db6430ccbf39 — delivered since 2026-10-15T17:54:23Z
Delivery plan — builds nothing: the change touches no module of the mesh's graph
Transitions
2026-10-15 17:53 (new) → proposed (announced): novox/hq#364's head announced
2026-10-15 17:54 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit
2026-10-15 17:54 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail
2026-10-15 17:54 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move
2026-10-15 17:54 published → delivered (done): nothing for a walk to move
The commit's note under refs/notes/mesh-plan keeps every transition: git log --notes=mesh-plan.
<!-- mesh-delivery:view -->
**Delivery** `novox/hq@db6430ccbf39` — **delivered** since 2026-10-15T17:54:23Z
**Delivery plan** — builds nothing: the change touches no module of the mesh's graph
**Transitions**
- 2026-10-15 17:53 (new) → proposed (announced): novox/hq#364's head announced
- 2026-10-15 17:54 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit
- 2026-10-15 17:54 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail
- 2026-10-15 17:54 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move
- 2026-10-15 17:54 published → delivered (done): nothing for a walk to move
The commit's note under `refs/notes/mesh-plan` keeps every transition: `git log --notes=mesh-plan`.
ready at db6430ccbf (the operator's word, 2026-10-15: okay to merge once reviewed; independent review APPROVE at this sha, round 2). Since the description: the ten-minute report's full and short layouts, the issues shown as a tree, and the agent's brief, the red-check rule and the forge-commit tree check restored.
ready at db6430ccbf391b6a3d0a4c5000f044df73f7c227 (the operator's word, 2026-10-15: okay to merge once reviewed; independent review APPROVE at this sha, round 2). Since the description: the ten-minute report's full and short layouts, the issues shown as a tree, and the agent's brief, the red-check rule and the forge-commit tree check restored.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The operator's flow of 2026-10-15, written down.
Playbook 07, features, in five phases with bounds: prepare (the lead settles the questions and writes one context file per repository, 15 min); develop (one fixing agent per repository kept for the whole feature, unit tests only, 1 to 2 hours); review (one reviewer, reports both ways to the same agents, at most 3 rounds, 15 min); check (push once, the merge checks run the integration tests, no second review; a failed check gets one more review cycle); deliver (the delivery plan). A larger feature is split into steps, each through every phase; the next step starts when the previous one's delivery plan is done. Scope is fixed at phase 0. Models per step (smaller for fixing and reading, larger for the lead, the review and decision records). A wait list with a bound per wait, said at once when one is passed; a report every ten minutes with the allowance used; a prepared clear at each phase end.
Kept from the old text: one branch name and one worktree per repository, sibling worktrees for the lab, landing by fast-forward under a lock when several agents share a repository, fetch by name, the catalogue's new-manifest-word exception, how it is checked.
Dropped: one fresh agent per five-to-ten-minute issue and the per-issue ready note (replaced by the per-repository context file), review rounds of up to five.
Playbook 08, small fixes: one issue in one repository, about an hour; local build with the failing test first, one review of the local commit (findings back to the same agent), push once, one delivery, resolved the same hour; bounds per wait.
The overview's table lists both. Neither uses the words walk or rollout: hq's glossary still keeps walk and retires rollout; flipping that is issue 646 (the operator: never use walk), its own change across the glossary, hq, the code's output and the knowledge base.
The two mesh-wide instructions that point here (prepare-before-clear with concrete moments, developing-a-feature) are proposed through the claude-code module for the operator's approval.
sh merge-check.shpasses. Review: the operator's own reading (it changes how every session works).Delivery
novox/hq@db6430ccbf39— delivered since 2026-10-15T17:54:23ZDelivery plan — builds nothing: the change touches no module of the mesh's graph
Transitions
The commit's note under
refs/notes/mesh-plankeeps every transition:git log --notes=mesh-plan.ready at
db6430ccbf(the operator's word, 2026-10-15: okay to merge once reviewed; independent review APPROVE at this sha, round 2). Since the description: the ten-minute report's full and short layouts, the issues shown as a tree, and the agent's brief, the red-check rule and the forge-commit tree check restored.