🗑️ remove(progress): drop workflow state tracking

Use plan-status as the only machine state source for plan queueing, claiming, and finishing.

Route record-plan through queue insertion and update templates/prompts to match the single-state model.

BREAKING CHANGE: playbook.py -record-spec and main_loop.py record are removed.

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

@@ -23,7 +23,7 @@
   完成当前 Plan 变更归档/提交；未归档不得声明 Plan 完成
 - 未验证内容必须显式说明
 - 只写对下一轮仍重要的信息
-- 不手工改写 `workflow-state` 或 `plan-status` 状态块
+- 不手工改写 `plan-status` 状态块
 
 ## 执行步骤
 
@@ -31,23 +31,18 @@
 2. 核对已运行验证与未运行验证
 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 claim` 且结果为 `done`，按项目归档机制只归档
+4. 如需回写上下文，更新 `active-context`、`progress` 上半部分和 `decisions`
+5. 如本轮来自 `main_loop.py claim` 且结果为 `done`，按项目归档机制只归档
    当前 Plan 相关差异
-7. 复核剩余差异是否属于其他 session / 其他 Plan，且未混入本轮交付单元
-8. 输出本轮摘要与下一步
+6. 复核剩余差异是否属于其他 session / 其他 Plan，且未混入本轮交付单元
+7. 输出本轮摘要与下一步
 
 ## 状态留痕复核
 
 - 如本轮来自 `main_loop.py claim`，`main_loop.py finish` 是否已经写回
   `plan-status`
-- 如本轮来自 `main_loop.py claim`，`workflow-state.phase` 是否与当前结果一致
 - 如本轮来自 `main_loop.py claim` 且结果为 `done`，当前 Plan 相关差异
   是否已经归档/提交，或是否已说明无当前 Plan 差异
-- 如为代码类执行，`workflow-state` 中是否保留了
-  `executor=executing-plans` 与既定 `constraints`
 
 ## 输出协议
 

templates/prompts/coding/update-memory.template.md

@@ -35,8 +35,7 @@
 
 ### `memory-bank/progress.md`
 
-- 先读取 `workflow-state`：当前阶段、spec、plan、executor、constraints
-- 再读取 `plan-status`：当前 Plan 的机器状态
+- 读取 `plan-status`：Plan 队列与机器状态
 - 只更新上半部分的人类摘要，不修改状态块
 - 上半部分是短期状态快照，不是长期日志
 - `Recent Changes` 只保留最近 3-5 条对恢复上下文有价值的变化
@@ -61,14 +60,14 @@
 - 临时聊天内容不要写进去
 - 高变化信息放 `active-context`，稳定技术模式放 `system-patterns`
 - 流程规则或项目私有约束变更写入 `AGENT_RULES.local.md`
-- `progress.md` 的状态块只由 `main_loop.py` 维护
-- 摘要应与 `workflow-state` / `plan-status` 保持一致
+- `progress.md` 的 `plan-status` 状态块只由 `main_loop.py` 或
+  `playbook.py -record-plan` 维护
+- 摘要应与 `plan-status` 保持一致
 - 摘要区保持短期状态快照；长期历史依赖项目归档记录、Plan 文件和
   `decisions.md`
 
 ## 禁止事项
 
-- 手工改写 `<!-- workflow-state:start/end -->`
 - 手工改写 `<!-- plan-status:start/end -->`
 - 把临时聊天内容、未验证猜测写进摘要
 

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

@@ -23,7 +23,7 @@
 - 验证命令必须 fresh run
 - 局部修改优先局部验证
 - 不能运行的验证必须写明原因
-- 不手工改写 `workflow-state` 或 `plan-status` 状态块
+- 不手工改写 `plan-status` 状态块
 - 如本轮来自 `main_loop.py claim`，验证通过不等于 Plan 完成；Plan
   `done` 还必须完成当前 Plan 变更归档/提交
 
@@ -33,8 +33,7 @@
 2. 运行与本次改动直接相关的验证命令
 3. 记录命令、结果和关键输出
 4. 复核 diff 是否只包含预期修改
-5. 如本轮来自 `main_loop.py claim`，复核 `workflow-state.phase`、
-   `plan-status` 与当前声明一致
+5. 如本轮来自 `main_loop.py claim`，复核 `plan-status` 与当前声明一致
 6. 如本轮来自 `main_loop.py claim` 且结果为 `done`，复核当前 Plan
    相关差异是否已经归档/提交；未归档时只能声明“验证完成”，
    不能声明“Plan 完成”
@@ -58,14 +57,10 @@
 
 ## 状态留痕复核
 
-- 如本轮来自 `main_loop.py claim`，`workflow-state.phase` 是否与当前声明一致
 - 如本轮来自 `main_loop.py claim`，`plan-status` 是否已经通过
   `main_loop.py finish` 写回
 - 如本轮来自 `main_loop.py claim` 且结果为 `done`，当前 Plan 相关差异
   是否已经归档/提交，或是否已说明无当前 Plan 差异
-- 如为代码类任务，`workflow-state` 中是否保留：
-  `executor=executing-plans`
-  `constraints=karpathy-guidelines,.agents,AGENT_RULES`
 
 ## 停止条件