🐛 fix(main_loop): enforce plan lifecycle ordering

Claim the first executable plan in plan-file order after resuming any in-progress plan, preserve skipped as its own workflow phase, and document the required post-done commit gate in the agent rules.

templates/AGENT_RULES.template.md

@@ -83,7 +83,7 @@
 - `$subagent-driven-development` 仅在 Plan 或平台明确要求时使用，
   不是默认执行器
 - 执行完成后，必须先运行 `main_loop.py finish` 写回状态，
-  再更新 `progress.md` 上半部分摘要
+  再更新 `progress.md` 上半部分摘要，并按主循环收尾要求提交
 
 ### Plan 要求
 
@@ -116,7 +116,8 @@
 - `in-progress`：执行中，用于恢复中断任务
 - `done`：已完成
 - `blocked`：阻塞，需人工介入或切换环境
-- `skipped`：永久跳过，不再执行
+- `skipped`：永久跳过，不再执行，`workflow-state.phase` 也写为
+  `skipped`
 
 `skipped` 如需恢复，必须手动改回 `pending`。
 
@@ -139,8 +140,9 @@ python {{PLAYBOOK_SCRIPTS}}/main_loop.py claim \
 该命令会在锁保护下串行完成三件事：
 
 - 自动识别当前环境：`windows`、`linux`、`darwin`
-- 按顺序选择可执行 Plan：
-  `in-progress` > `pending` > `blocked: env:<当前环境>:...`
+- 已有 `in-progress` 优先恢复
+- 如无 `in-progress`，按 Plan 文件顺序选择第一个可执行 Plan：
+  `pending` 或 `blocked: env:<当前环境>:...`
 - 将选中的 Plan 写成 `in-progress`
 
 这里的锁保护的是 `progress.md` 状态块更新，避免多个 session
@@ -218,10 +220,27 @@ python {{PLAYBOOK_SCRIPTS}}/main_loop.py finish \
 8. 触碰安全红线时立即停止，不继续后续 Plan
 9. 常规模式下可对高风险事项向用户确认；无交互模式按本文件
    的“需要确认的场景”自动处理
-10. 每次 `claim` 只领取一个 Plan；写回后再领取下一个
+10. 每次 `claim` 只领取一个 Plan；写回并完成必要提交后再领取下一个
 11. 全部 Plan 处理完后，统一汇总完成项、阻塞项、跳过项、
     环境需求与待确认事项
 
+### Plan 完成提交契约
+
+- Plan `done` 后必须完成一次 commit，然后才能继续领取下一个 Plan
+- 提交顺序：
+  1. 完成 Plan 约定验证
+  2. 运行 `main_loop.py finish -status done` 写回状态
+  3. 必要时更新 `progress.md` 上半部分摘要和相关 memory
+  4. 检查 `git status --short` 与 diff
+  5. 只提交当前 Plan 相关改动
+- 不得由 `main_loop.py finish` 自动执行 `git commit`
+- 不得把用户已有改动或其他 Plan 的改动混入当前 Plan commit
+- 如 Plan `done` 后没有 diff，必须在回复中说明无提交原因
+- `blocked` / `skipped` 不默认提交代码改动；只有状态留痕或已验证的
+  局部成果需要保留时才提交
+- 工作区保持干净后再领取下一个 Plan；如存在不属于当前 Plan 的脏改动，
+  常规模式先向用户确认，无交互模式写入风险并停止继续领取
+
 ## 通用执行约束
 
 ### 代码与配置修改
@@ -297,6 +316,7 @@ python {{PLAYBOOK_SCRIPTS}}/main_loop.py finish \
 - [ ] 换行符与文件格式正确
 - [ ] 无语法错误或明显运行时错误
 - [ ] 已通过 `main_loop.py finish` 写回 Plan 状态
+- [ ] Plan `done` 后已完成对应 commit，或已说明无 diff 无需提交
 
 ---
 

templates/prompts/coding/close-task.template.md

@@ -17,7 +17,8 @@
 
 ## 规则
 
-- 如果任务状态变更，优先通过 `main_loop.py finish` 留痕
+- 如本轮来自 `main_loop.py claim` 且任务状态变更，优先通过
+  `main_loop.py finish` 留痕
 - 未验证内容必须显式说明
 - 只写对下一轮仍重要的信息
 - 不手工改写 `workflow-state` 或 `plan-status` 状态块
@@ -26,15 +27,18 @@
 
 1. 核对已完成项与未完成项
 2. 核对已运行验证与未运行验证
-3. 核对 `main_loop.py finish` 是否已经写回 `plan-status`
-4. 核对 `workflow-state.phase` 是否与当前结果一致
+3. 如本轮来自 `main_loop.py claim`，核对 `main_loop.py finish`
+   是否已经写回 `plan-status`
+4. 如本轮来自 `main_loop.py claim`，核对 `workflow-state.phase`
+   是否与当前结果一致
 5. 如需回写上下文，更新 `active-context`、`progress` 上半部分和 `decisions`
 6. 输出本轮摘要与下一步
 
 ## 状态留痕复核
 
-- `main_loop.py finish` 是否已经写回 `plan-status`
-- `workflow-state.phase` 是否与当前结果一致
+- 如本轮来自 `main_loop.py claim`，`main_loop.py finish` 是否已经写回
+  `plan-status`
+- 如本轮来自 `main_loop.py claim`，`workflow-state.phase` 是否与当前结果一致
 - 如为代码类执行，`workflow-state` 中是否保留了
   `executor=executing-plans` 与既定 `constraints`
 
@@ -59,7 +63,7 @@
 
 ## 停止条件
 
-- 如状态未写回，先完成留痕再收尾
+- 如已领取 Plan 但状态未写回，先完成留痕再收尾
 - 如验证不足以支持交付，停止并标记风险
 
 ---

templates/prompts/coding/verify-change.template.md

@@ -31,7 +31,8 @@
 2. 运行与本次改动直接相关的验证命令
 3. 记录命令、结果和关键输出
 4. 复核 diff 是否只包含预期修改
-5. 复核 `workflow-state.phase`、`plan-status` 与当前声明一致
+5. 如本轮来自 `main_loop.py claim`，复核 `workflow-state.phase`、
+   `plan-status` 与当前声明一致
 6. 汇总未覆盖项和剩余风险
 
 ## 输出协议
@@ -52,8 +53,9 @@
 
 ## 状态留痕复核
 
-- `workflow-state.phase` 是否与当前声明一致
-- `plan-status` 是否已经通过 `main_loop.py finish` 写回
+- 如本轮来自 `main_loop.py claim`，`workflow-state.phase` 是否与当前声明一致
+- 如本轮来自 `main_loop.py claim`，`plan-status` 是否已经通过
+  `main_loop.py finish` 写回
 - 如为代码类任务，`workflow-state` 中是否保留：
   `executor=executing-plans`
   `constraints=karpathy-guidelines,.agents,AGENT_RULES`