docs: 补充 worktree 生命周期约定(治理文档)

记录本次会话的教训:worktree 曾累积到16个、占用两位数GB磁盘,
因为清理被推迟。补充判断"何时该删"的具体方法
(git worktree list + merge-base --is-ancestor),供后续开发/agent参考。
这个提交包含在:
2026-09-26 08:48:46 +08:00
父节点 ed3814fccd
当前提交 e92596a2ac
@@ -72,6 +72,14 @@ tasks after TRELLIS2.
Do not treat that inferred task as new execution approval. Activate Do not treat that inferred task as new execution approval. Activate
the next approved task explicitly when work actually resumes. Commit, push, the next approved task explicitly when work actually resumes. Commit, push,
archive and production operations retain their separate approval boundaries. archive and production operations retain their separate approval boundaries.
- Worktrees are for genuine isolation (risky merges, DB-touching regression
runs, parallel tasks across sessions/agents), not a default habit. Once the
isolated work is merged or its branch's HEAD is an ancestor of the target
branch, remove the worktree (`git worktree remove`) instead of leaving it
"for later" — this project has previously accumulated over a dozen stale
worktrees consuming double-digit GB of disk because cleanup was deferred.
A quick `git worktree list` + `git merge-base --is-ancestor <head> main`
check identifies safe-to-remove ones during any disk or repo-hygiene pass.
## Risk-Scoped Execution ## Risk-Scoped Execution