القائمة
Fork Overlay：Task Bundle 持久化 + Failure FSM 集成。在 ce:work 基础上增加 state.md 读写和状态机转换。使用时机：执行 ce:work 时，如果任务有对应的 Task Bundle（docs/tasks/<id>/），加载此 skill 以启用持久化和状态追踪。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Fork Overlay：Codex-first 外部执行器策略。按任务特征路由到 Claude 或 Codex，Codex-first（非品牌路由）。使用时机：需要决定是否将当前任务派发给 Codex 时加载此 skill。
Fork Overlay：经验分层沉淀升级阶梯。检测是否值得将 solution 升级为 pattern 或 skill。使用时机：ce:compound 完成后手动调用，分析 docs/solutions/ 中的重复模式。（不会自动触发，需主动加载此 skill）
Fork Overlay：外部模型调用前置检查门控。调用 Codex/Gemini 之前运行五项检查，防止调用失败浪费时间。使用时机：任何调用外部模型（Codex [C]、Gemini [G]）之前自动运行。
Fork Overlay：ce:work 意图分类门控。在执行前识别任务意图（实现/修复/重构/探索），设定对应的执行策略。使用时机：ce:work Phase 0（环境扫描）之后、Phase 1（Quick Start）之前。
Fork Overlay：Codex Patch Approval 咨询版。当 Codex 返回 patch 时，Claude 审批后才写入文件。使用时机：Codex 以 patch/diff 格式返回代码变更时，由 Claude 作为审批层。
Fork Overlay：Review Contract 三档 Tier 分类 + Anti-Leniency 注入。在 ce:review 基础上增加 Blocking/Analytical/Advisory 分层和结论类型系统。使用时机：运行 ce:review 前阅读此协议以理解审查标准。
| name | ce-work-integration |
| description | Fork Overlay：Task Bundle 持久化 + Failure FSM 集成。在 ce:work 基础上增加 state.md 读写和状态机转换。使用时机：执行 ce:work 时，如果任务有对应的 Task Bundle（docs/tasks/<id>/），加载此 skill 以启用持久化和状态追踪。 |
基础层：上游
ce:work负责任务执行、质量检查、提交工作流。本 Overlay 增量：Task Bundle 持久化（state.md 读写）+ Failure FSM 状态转换。
当满足以下条件时，在运行 ce:work 前/后应用本 overlay：
docs/tasks/<task-id>/ 目录存在当重新进入一个任务时，在执行 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
ce:work 遇到阻塞时会停下来询问用户，没有状态记录。
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 完成 |
以下情况触发 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: <描述> |
在 ce:work 原有 Phase 1-3 的基础上，在以下时机写入/更新 state.md：
| 时机 | state.md 更新内容 |
|---|---|
| 开始执行 | status: active, current_step: 1 |
| 每个任务完成 | current_step +1, last_checkpoint |
| 遇到阻塞 | status: blocked, blocked_by |
| 开始排查 | status: debugging |
| 提交代码 | 记录 commit hash（可选） |
| 完成实现 | status: reviewed（等待 ce:review） |
ce:work Phase 4（完成阶段）后，如果运行了 ce:compound：
compoundeddocs/tasks/archive/当任务有明确 verifier（测试/lint/build）且遇到小错误时，在触发 STOP FSM 之前：
Execute → Verify → Fail → Ralph-lite(≤2次) → Verify →
├── 通过 → 继续
└── 仍失败 → 触发 active → blocked
Ralph-lite 规则：
docs/tasks/<YYYY-MM-DD-seq-description>/
├── plan.md # 目标、约束、验收标准（链接到 docs/plans/）
├── state.md # 当前步骤、阻塞点、状态历史（本 overlay 写入）
└── review.md # findings、证据、结论（ce:review 写入）
模板位置：plugins/compound-engineering/skills-custom/task-bundle/templates/