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/<slug> 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

@@ -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/<slug>` branch and no `.work/<slug>` worktree
 survive.
 
+**Removing what is left means everything the feature made, wherever it lives**: every worktree the lead or its
+agents made (under `.work/<slug>`, 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 <branch> -- <the files it changed>` 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/<slug>/` while the feature runs.
-- After a feature's delivery, `git branch -r | grep feat/<slug>` and `git worktree list` return nothing for it.
+- After a feature's delivery, `git branch -r | grep feat/<slug>` 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

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/<issue>-…` 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.