From 1552b0e0a3eccca220177ba5a69517fd3da3c978 Mon Sep 17 00:00:00 2001 From: mesh-tools Date: Fri, 16 Oct 2026 15:37:55 +0000 Subject: [PATCH] Playbooks 07 and 08: remove everything a feature or fix made after its delivery Feature 57 left over a hundred worktrees and per-issue branches in a session scratchpad, outside the .work/ the playbook named; a small fix had no clean-up step at all. Content is checked on main, not hashes, because gitea_commit lands commits with new hashes. --- 00-META/process/07-feature-branches.md | 11 ++++++++++- 00-META/process/08-small-fixes.md | 3 +++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index 663edd29..05d19985 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -177,6 +177,14 @@ delivery: no machine receives it (issue 889 while it still starts one). The lead naming its pull requests, and removes what is left: no `feat/` branch and no `.work/` worktree survive. +**Removing what is left means everything the feature made, wherever it lives**: every worktree the lead or its +agents made (under `.work/`, in a session's scratchpad, a reviewer's copy), every per-issue or per-package +branch, and every branch the feature pushed to the forge. Before one goes, check it holds nothing that is not on +`main`. Compare content, not hashes: a commit put on the forge with `gitea_commit` lands with a new hash, so a +merged branch still shows commits "not on main" (`git diff origin/main -- ` is +empty when its content is there). What is not on `main` is delivered in the next step or written on its issue +before it goes. Feature 57 left over a hundred worktrees and per-issue branches in one scratchpad (2026-10-16). + ## Models | Who | Model | Why | @@ -260,7 +268,8 @@ issues in `fixing` that nobody works on reads to the operator as stuck work. request into a feature branch exists. A pull request per issue, or an agent waiting on a merge check in phase 1, is the failure this playbook prevents. - A context file exists per touched repository under `.work//` while the feature runs. -- After a feature's delivery, `git branch -r | grep feat/` and `git worktree list` return nothing for it. +- After a feature's delivery, `git branch -r | grep feat/` and `git worktree list` return nothing for it, in every clone the + feature used, its session scratchpads included. - 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 diff --git a/00-META/process/08-small-fixes.md b/00-META/process/08-small-fixes.md index 3ae0b95d..2a6dbddb 100644 --- a/00-META/process/08-small-fixes.md +++ b/00-META/process/08-small-fixes.md @@ -49,6 +49,8 @@ one delivery**. Everything before the push is local and fast. or needs the operator's terminal. 7. **Follow its delivery plan to done** (`mesh-controller.plans` with `wait` and `until: done`), prove the fix on the mesh (the symptom gone, measured), and resolve the issue with `located-in` and `fixed-by` the same hour. +8. **Remove the fix's worktree and its branch**, local and on the forge, as playbook [07](07-feature-branches.md) + phase 4 says: content checked on `main` first, not hashes. A fix that stops before its delivery moves its issue back to `open` with a note saying how far it got (branch, last commit, what is left), as playbook [07](07-feature-branches.md) says. @@ -76,6 +78,7 @@ reading itself and uses one subagent only for the review. - A small fix has one pull request with one or few commits naming its issue, opened after its review: a pull request with many heads is a fix reviewed after its push. - Its issue moves to `resolved` within the hour its delivery plan ends. +- After its delivery, no worktree and no branch named `fix/-…` is left, locally or on the forge. - A pull request reviewed and green but unmarked for more than 15 minutes, a fix to a module's running marked ready with no integration test of the module whole, or a review report asking a change outside the issue's done-when, is the failure of steps 4 to 6.