ce-work-integration

ce:work 集成 Overlay — Task Bundle + FSM

基础层：上游 ce:work 负责任务执行、质量检查、提交工作流。

本 Overlay 增量：Task Bundle 持久化（state.md 读写）+ Failure FSM 状态转换。

---

何时使用本 Overlay

当满足以下条件时，在运行 ce:work 前/后应用本 overlay：

1. 任务有对应的 Task Bundle：docs/tasks/<task-id>/ 目录存在
2. 或者任务预期超过 1 小时（值得持久化上下文）
3. 或者任务涉及多个子代理

---

Phase 0: 任务恢复（新增，在 ce:work Phase 1 之前）

当重新进入一个任务时，在执行 ce:work Phase 1 之前：

1. 检查 docs/tasks/<task-id>/state.md 是否存在
2. 如果存在，读取：
   - current_step / total_steps
   - status (active/blocked/debugging/replanned/resumed)
   - blocked_by（阻塞原因）
   - last_checkpoint 时间戳
3. 从 current_step 继续，不重新执行已完成步骤
4. 更新 state.md: status → active, updated_at → 当前时间

如果 state.md 不存在（新任务），从 plugins/compound-engineering/skills-custom/task-bundle/templates/state.md.tpl 创建：

cp plugins/compound-engineering/skills-custom/task-bundle/templates/state.md.tpl \
   docs/tasks/<task-id>/state.md
# 填写 task_id、total_steps、started_at

---

FSM 状态转换（替换 ce:work 的隐式 STOP 处理）

原 ce:work 行为（隐式）

ce:work 遇到阻塞时会停下来询问用户，没有状态记录。

本 Overlay 增强（显式状态机）

active → blocked: 遇到任何阻塞（依赖缺失、CI 失败、需求不清）
blocked → debugging: 开始排查阻塞原因
debugging → replanned: 需要修改原计划
debugging → active: 阻塞自行解除（如 CI 通过）
replanned → resumed: 新计划就绪，等待用户确认重启（⚠️ 必须等用户确认）
resumed → active: 用户确认后，按新计划重新开始（AI 执行）
active → reviewed: 实现完成，进入 ce:review
reviewed → compounded: 经验沉淀完成
任何状态 → cancelled: 任务被主动取消

replanned → resumed 用户确认门（强制）：

当状态进入 resumed 时，必须展示新计划摘要并等待用户确认，禁止自动进入 active：

📋 计划已更新，重启前需要你确认：

  原阻塞原因：[blocked_by 值]
  新计划摘要：[更新后的关键步骤]

  确认后将从步骤 [N] 重新开始。继续吗？(y/n)

用户确认后才将 state.md 的 status 更新为 active。

每次状态转换写入 state.md：

## 状态历史

| 时间 | 从 | 到 | 原因 |
|------|-----|-----|------|
| 2026-04-08 10:00 | created | active | 开始执行 |
| 2026-04-08 14:30 | active | blocked | 等待 upstream merge 完成 |

阻塞触发条件（替换隐式 STOP）

以下情况触发 active → blocked，写入 state.md 并告知用户：

触发条件	blocked_by 值
依赖任务未完成	depends_on: <task-id>
CI/测试持续失败（≥3 次）	ci_failure: <test-name>
需求不清无法继续	unclear_requirement: <描述>
Rate limit / 工具不可用	tool_unavailable: <tool-name>
需要人工决策	human_decision_required: <描述>