feat(git): 完善 Worktree 生命周期与发布约定

WORKFLOW.md

@@ -88,7 +88,7 @@
 | S6 验证与自修复 | `test-backend`、`test-ui` | 分层验证记录、失败分类、修复结果 | 自动进入 S7 |
 | S7 代码审核 | `review-code`，按需叠加 `review-java`、`review-mybatis`、`review-frontend` | 审核报告、问题清单、未验证边界 | 自动修复明确问题后复审，进入 G4 |
 | S8 提交准备 | `commit-msg` | 精确文件范围、提交拆分与提交信息 | 进入审批门 G5 |
-| S9 本地提交 | Git 原生命令 | 一个或多个本地提交、提交后状态 | 输出最终交付报告并结束 |
+| S9 本地提交与收尾 | Git 原生命令、`branch close` | 一个或多个本地提交、提交后状态、Worktree 清理结果 | 释放额外 Worktree 后输出最终交付报告 |
 
 阶段不得仅凭名称跳过。确实不适用时，应记录“不适用”的证据和原因，再继续推进。
 
@@ -126,10 +126,11 @@
 - 当前分支和工作区状态；
 - 目标分支名；
 - 基准引用及提交短哈希；
-- 是否携带未提交修改；
+- 在当前工作区还是独立 Worktree 创建，以及是否影响未提交修改；
+- 使用独立 Worktree 时的准确绝对路径；
 - 唯一的分支创建命令。
 
-只有用户明确批准这组最终信息后才能创建并切换本地分支。`fetch`、创建分支、推送分支是彼此独立的授权；本流程默认不执行 fetch 和 push。
+只有用户明确批准这组最终信息后才能创建本地分支。`fetch`、创建分支、移除 Worktree 和推送分支是彼此独立的授权；本流程默认不执行 fetch 和 push。
 
 ### G4 代码效果审批
 
@@ -237,9 +238,9 @@
 3. 不默认基准分支，不默认远端为最新；
 4. 验证分支名、基准提交和同名引用；
 5. 到达 G3，等待用户对最终命令的明确批准；
-6. 创建后验证当前分支、起点和工作区状态。
+6. 创建后验证实际工作目录中的分支、起点和状态；使用独立 Worktree 时，还要确认主工作区未变化并记录分支占用路径。
 
-若工作区不干净，不能自动 stash、提交、还原或清理。必须说明现有修改是否会随分支切换携带，并等待用户决定。
+若工作区不干净，不能自动 stash、提交、还原或清理。必须说明直接切换会携带哪些修改，并优先建议在经 G3 批准的独立 Worktree 中创建分支。独立 Worktree 在开发期间保持使用，任务完成后必须通过 `branch close` 清理门禁释放分支占用。
 
 ### S5：代码实现
 
@@ -312,7 +313,10 @@ G5 批准后：
 4. 确认无敏感文件、缓存、本地配置和无关改动；
 5. 使用批准的提交信息创建本地提交；
 6. 验证提交哈希、提交内容、当前分支和提交后工作区状态；
-7. 输出最终交付报告。
+7. 如果本次使用独立 Worktree，确认开发、验证和本地交付已完成，检查 Worktree 干净、无进行中的 Git 操作且 HEAD 已被本地分支引用；
+8. 展示准确清理路径、分支、HEAD 和 `git worktree remove` 命令，取得独立确认后使用 `branch close` 移除额外 Worktree；
+9. 验证 Worktree 目录和占用记录已移除、分支与提交仍存在、主工作区未变化；
+10. 输出最终交付报告。
 
 最终报告至少包含：需求与设计产物路径、分支、提交哈希、实现摘要、验证结果、审核结论、未提交文件、未验证边界和后续建议。
 
@@ -381,7 +385,7 @@ G5 批准后：
 3. 到达 G1 时一次性展示需求基线、疑问、建议决策和拟落盘路径，等待我批准。批准后自动执行到下一审批门，不再要求我发送“继续”。
 4. 使用 plan-change 和实际适用的设计 Skill 完成设计。只调用与需求有关的 design-db、design-api、design-backend、design-frontend、design-frontend-data、design-workflow、prepare-api、component、form、style，不为不适用领域制造空文档。
 5. 到达 G2 时展示设计、影响范围、风险、实施步骤、验证矩阵和文档路径，等待批准。
-6. 设计批准后使用 branch 检查并规划本地开发分支。严格按照该 Skill 展示当前状态、分支名、基准提交、工作区影响和唯一创建命令，在 G3 等待明确批准。不要自动 fetch、stash、清理、提交或 push。
+6. 设计批准后使用 branch 检查并规划本地开发分支。严格按照该 Skill 展示当前状态、分支名、基准提交、创建位置、工作区影响和唯一创建命令，在 G3 等待明确批准。工作区不干净或要求不影响当前 checkout 时使用独立 Worktree。不要自动 fetch、stash、清理、提交或 push。
 7. 分支创建后，使用 implement-backend 和/或 implement-frontend 在批准范围内完成最小完整实现。保持项目现有语言、框架版本、目录、注释和测试风格，不虚构接口、组件、业务规则或内部依赖。
 8. 自动运行格式化、静态检查、编译、聚焦测试和具备条件的真实验证。本次实现缺陷可自动修复并重跑；需求或设计变化必须回到对应审批门。
 9. 使用 review-code 审查最终差异，并按需叠加 review-java、review-mybatis、review-frontend。已批准范围内、低风险且修复方式明确的问题自动修复、复测和复审；范围外或改变契约的问题只报告并等待决策。
@@ -390,7 +394,8 @@ G5 批准后：
 12. G5 批准后只暂存已展示的精确路径，执行暂存检查并创建本地提交。禁止 git add .、git add -A、push、合并、打标签、发布和历史改写。
 13. 每阶段满足质量门后自动进入下一阶段。只有审批门、证据不足、权限缺失、脏工作区冲突、敏感信息或高风险外部操作可以暂停。
 14. 每次等待审批时，给出：已完成事项、产物、关键证据、需要批准的明确内容、批准后的自动动作。不要只问“是否继续”。
-15. 最终报告必须包含文档路径、分支、提交哈希、变更文件、验证结果、审核结论、未提交内容、未验证边界和后续建议。
+15. 本地提交核对完成后，如果使用了独立 Worktree，确认生命周期已经结束并进入 branch close：展示准确路径、分支、HEAD、干净状态和唯一移除命令，取得确认后移除，验证分支与提交仍存在且主工作区未变化。
+16. 最终报告必须包含文档路径、分支、提交哈希、变更文件、验证结果、审核结论、未提交内容、未验证边界、Worktree 清理结果和后续建议。
 
 现在从 S0 开始执行，并自动推进到 G1。
 ```
@@ -434,6 +439,7 @@ G5 批准后：
 - 代码效果已通过 G4；
 - 提交范围与信息已通过 G5；
 - 本地提交已创建并核对内容；
+- 使用独立 Worktree 时，其生命周期已经结束并安全移除；若用户明确要求保留现场，则任务状态应说明生命周期尚未结束及分支占用路径；
 - 未发生未经授权的 push、合并、发布、生产操作或历史改写。
 
 如果由于环境或外部依赖无法完成某项验证，任务只能标记为“本地实现完成，等待外部验证”，不能声称全流程验收通过。