cc-devflow 4.5.11 → 4.5.13

package/.claude/skills/cc-do/PLAYBOOK.md

@@ -1,127 +1,33 @@
 # CC-Do Playbook
 
-## Visible State Machine
+## State Machine
 
 `cc-plan | cc-investigate -> cc-do -> cc-check`
 
-- Enter from: an approved `planning/design.md` or `planning/analysis.md` with frozen tasks.
-- Stay in: `cc-do` while there are ready tasks, current task state is clear, and the design contract still holds.
-- Exit to: `cc-check` once the current task set has red/green/review evidence and no hidden execution gaps remain.
-- Reroute to: `cc-investigate` if repeated failures prove the root-cause contract is wrong, or `cc-plan` if the requirement design itself is wrong.
-
-## Quick Triage
-
-开始前先把当前执行局面归到 4 类之一：
-
-- `implement`: 已有 ready task，可直接进入 TDD
-- `resume`: task 状态或 Git 工作区显示中断，需要续做
-- `repair-from-investigation`: `planning/analysis.md` 已冻结，可直接修
-- `reroute-cc-investigate`: bug 根因未明，回调查入口
-- `review-fix`: scope 不变，只修 review 指向的问题
-
-如果这一步归不清，说明当前上下文还没组装好，不准开始实现。
-
-## Execution Loop
-
-1. 读取 `task-manifest.json`，先用 `scripts/select-ready-tasks.sh` 找出当前 ready tasks 和当前 wave。
-2. 如果有多于一个 ready task，要先跑 `scripts/detect-file-conflicts.sh`；有共享触点、父子路径触点或依赖关系就退回串行。
-3. 对每个要执行的 task，先用 `workflow-context` 和完整 task block 组装上下文；只有恢复卡住时才运行 `scripts/build-task-context.sh`，且它只输出 stdout。
-4. 如果当前任务来自 `cc-investigate`，把 `planning/analysis.md` 当成上游合同，不准一边做一边重开调查。
-5. 进入 TDD 闭环：先红，再绿，再重构。
-6. 每个关键节点都留下客观证据：代码 diff、Git 状态、验证命令输出、review verdict；失败或 debug 才写 CLI event。
-7. 任务实现后，先过 `spec review`，再过 `code review`，review 不通过就回到实现。
-8. 两道 review 门都通过后，才能把任务标成完成，并把结果留给 `cc-check`。
-9. quick lane 只允许减少叙事，不允许减少 current task、verification、handoff 和 review gates。
-
-## Local Kit
-
-- 恢复时看 `references/execution-recovery.md`
-- 并行分配时看 `references/parallel-dispatch.md`
-- 需要判断当前任务时用 `scripts/check-task-status.sh`
-- 需要找 ready task 时用 `scripts/select-ready-tasks.sh`
-- 需要组装任务上下文时用 `scripts/build-task-context.sh`
-- 不要写 checkpoint；`scripts/write-task-checkpoint.sh` 只是旧兼容入口，默认不生成 checkpoint 文件
-- 需要写 review 门结果时用 `scripts/record-review-decision.sh`
-- 需要校验任务闭环时用 `scripts/verify-task-gates.sh`
-- 需要勾选任务时用 `scripts/mark-task-complete.sh`
-- 需要确认并行安全时用 `scripts/detect-file-conflicts.sh`
-- bug 根因没冻结时，退出当前执行并回 `cc-investigate`
-
-## TDD Standard
-
-1. 先写失败测试，再运行到红。
-2. 确认红灯是预期失败，不是测试写错、fixture 缺失或环境没接上。
-3. 确认红灯通过公共 seam 证明行为缺失，而不是测私有函数、内部调用次数或临时结构。
-4. 确认 mock 只发生在系统边界；内部协作者不 mock。
-5. 确认测试名像规格说明，一个 Red 只证明一个逻辑行为，结果从公共验证路径读回。
-6. 只写让当前测试转绿的最小实现，不提前实现未来测试尚未要求的分支、状态或 API。
-7. 绿后才允许重构。
-8. 重构后必须保持绿，并说明处理了重复、长方法、浅模块、feature envy、primitive obsession、命名、三层以上分支或其它具体坏味道。
-9. 测试没先红过，或红灯不是公共 seam 上的行为失败，就不能宣称这次变更受 TDD 保护。
-
-## TDD Exception Rule
-
-只有这些场景允许跳过 fail-first：
-
-- throwaway prototype
-- 纯生成文件
-- 纯配置变更
-- 上游明确禁止写测试的探索步骤
-
-每个例外都要写入当前 task block 或 manifest task context：
-
-- `tddException.reason`
-- `tddException.risk`
-- `tddException.alternativeEvidence`
-
-没有例外记录，就按违规处理，回到 Red。
+`cc-do` edits code. It does not create process files.
 
 ## Task Gates
 
-任务只有在下面顺序全部成立后，才算完成：
-
-1. `red_failed`: 已观察到预期失败
-2. `red_reason_verified`: 红灯原因与目标行为缺失一致
-3. `red_seam_verified`: 红灯通过公共接口、调用方流程、CLI/API/UI 或真实边界进入系统
-4. `red_behavior_verified`: 测试断言用户或调用方可观察行为，不断言内部实现细节
-5. `mock_boundary_verified`: mock 只在系统边界，内部协作者没有被 mock
-6. `green_passed`: 当前任务实现转绿，且实现只覆盖当前红灯要求的最小行为
-7. `refactor_done` 或 `refactor_not_needed`
-8. `refactor_green`: 重构后相关测试仍绿，且没有在 Red 状态做结构清理
-9. `spec_review_pass`
-10. `code_review_pass`
-
-任何一门失败，都回到实现，不准直接跨过去。
-
-## Parallel Dispatch Rule
-
-只有满足全部条件，才能并行：
-
-1. 任务处于当前 active phase
-2. `dependsOn` 已全部满足
-3. 任务显式允许并行，例如 `[P]`
-4. `touches` / `files` 不冲突，且父路径 / 子路径也不重叠
-5. submodule touches 已被标出；触达 submodule 的任务不能默认拿普通 worktree 隔离
-6. 每个 subagent 都拿到了自己的 task context
+1. Task selected from `task.md`
+2. Red observed or TDD exception recorded
+3. Green observed
+4. Refactor complete or unnecessary
+5. Verification run
+6. `mark-task-complete.sh` updates `task.md`
+7. Git commit created
 
-少一条，都按顺序执行。
+## Recovery
 
-## Root Cause Protocol
+Recover from Git and `task.md`:
 
-- 先复现，再猜原因
-- 先读 `planning/analysis.md`，再改代码
-- 先守住修复边界，再做最小实现
-- 两次失败后回看证据
-- 三次失败后先回 `cc-investigate`，再决定是否需要 `cc-plan`
+- current branch
+- latest commits
+- dirty files
+- completed checkboxes
+- next unchecked task
 
-## Recovery Standard
+Do not recover from process files. Only `task.md`, Git, and current repo truth count.
 
-至少留下这些恢复信息：
+## Commit Rule
 
-- 当前任务 ID
-- 当前 active phase / ready tasks
-- 已完成什么
-- 卡在哪里
-- 下一步唯一动作
-- 相关文件 / 命令 / 观察
-- 最近一次 Red/Green/Review 到了哪一站
+Every completed task or execution environment gets its own commit. Split by behavior or layer when needed, but do not leave completed work uncommitted between stages.

package/.claude/skills/cc-do/SKILL.md

@@ -1,67 +1,47 @@
 ---
 name: cc-do
-version: 1.6.8
-description: Use when implementing planned tasks, resuming interrupted work, applying a frozen investigation handoff, or landing review feedback after cc-plan or cc-investigate.
+version: 1.7.1
+description: Use when implementing frozen tasks, resuming interrupted work, applying an investigation handoff, or fixing review feedback inside the approved scope.
 triggers:
   - 开始做 T003
   - 继续上次做到一半的任务
-  - 按 planning/tasks.md 开始实现
+  - 按 task.md 开始实现
   - 修这个 review comment
   - implement this task
   - resume this requirement
-  - repair this investigated bug
 reads:
   - PLAYBOOK.md
-  - CHANGELOG.md
   - references/execution-recovery.md
   - references/parallel-dispatch.md
   - docs/guides/project-postmortem.md
+  - ../cc-dev/scripts/resolve-cc-devflow.sh
 writes:
-  - path: devflow/changes/<change-key>/execution/tasks/<task-id>/events.jsonl
+  - path: devflow/changes/<change-key>/task.md
     durability: durable
-    required: false
-    when: debug mode is enabled or the task execution fails
-  - path: devflow/changes/<change-key>/execution/team-state.json
-    durability: durable
-    required: false
-    when: execution mode uses delegated or team workers
-  - path: devflow/changes/<change-key>/meta/change-state.json
-    durability: durable
-    required: false
-    when: pause, resume, dispatch, or quick-lane state changes
+    required: true
+    when: task checkbox/status changes
 effects:
   - code changes
   - test changes
-  - task status updates in planning/tasks.md and planning/task-manifest.json
+  - Git commit after each completed execution environment or task slice
 entry_gate:
-  - Run `cc-devflow query workflow-context --change <changeId> --change-key <changeKey> --data-only --no-trace --compact` first and follow its context-index `packetOnly`, `mustNotForget`, `sourceHashes`, `defaultOpen`, `currentTask`, `commandsToTrust`, and `openWhen.conditions` fields before opening deep artifacts.
-  - Before editing, read the direct caller, exported surface, shared helper, and local convention for the touched path.
-  - Read `planning/tasks.md`, `planning/task-manifest.json`, `change-meta.json`, related specs, Git state, and CLI logs only when workflow-context says the deep section is needed; legacy `planning/design.md` / `planning/analysis.md` are fallback inputs only.
-  - Select only ready tasks whose dependencies, wave, touched paths, and file ownership are clear.
-  - Reject parallel execution when touched paths overlap by exact path or parent/child path; submodule touches must be isolated unless the task explicitly owns that submodule.
-  - If the current task cannot be restated from canonical artifacts, run a context reset before coding.
-  - Before each single-task execution, run a quick Project Postmortem search against `devflow/postmortems` using the task's touched files, capability, failure class, and model-risk terms; apply applicable reminders to the code path and mention only blocking/failure facts in CLI events.
-  - "Validate the current task's TDD shape before coding: spec-style test name, one logical behavior, public verification path, allowed boundary mocks, Green minimality guard, and refactor candidates."
+  - Resolve the CLI with `../cc-dev/scripts/resolve-cc-devflow.sh require query workflow-context config`.
+  - Run `query workflow-context --change <changeId> --change-key <changeKey> --data-only --no-trace --compact`.
+  - Read `task.md`, current Git status, and only the code/tests needed by the current task.
+  - Reject execution if the task cannot be restated from `task.md` and repo evidence.
 exit_criteria:
-  - The current task has red/green evidence, public-seam test quality evidence, review evidence, and synchronized task status.
-  - Red evidence proves one observable behavior through a public verification path; Green evidence shows only the minimal production change; Refactor evidence names the concrete smell removed or says why none was needed.
-  - The completed task was closed through `scripts/mark-task-complete.sh`; manual checkbox/status edits are not valid completion evidence.
-  - Execution leaves the next verifier enough code, Git, task-status, verification-command, and CLI-log truth to judge the task without chat memory.
-  - The honest next step is cc-check or an explicit reroute.
+  - Current task has Red/Green evidence or a recorded TDD exception in `task.md`.
+  - Verification commands have been run or explicitly blocked.
+  - Task status is updated through `scripts/mark-task-complete.sh`.
+  - The completed task/environment is committed to Git.
+  - No process file is created beyond `task.md` updates and Git commits.
 reroutes:
-  - when: Three failed repair attempts or new evidence show the investigation contract is wrong.
+  - when: New evidence disproves root cause.
     target: cc-investigate
-  - when: New evidence shows the requirement design or scope contract is wrong.
+  - when: New evidence breaks scope or design.
     target: cc-plan
-  - when: Implementation and reviews are complete for the current task set.
+  - when: Implementation and review feedback are complete.
     target: cc-check
-recovery_modes:
-  - name: resume-from-task-state
-    when: Work was interrupted but the current design contract is still valid.
-    action: Reload workflow-context, planning/tasks.md, task-manifest.json, current Git state, and CLI logs; continue from the first pending or failed task.
-  - name: context-reset
-    when: The conversation history is noisy, stale, or cannot reproduce the exact task state.
-    action: Discard chat memory, reread planning/tasks.md, planning/task-manifest.json, change-meta.json, current Git state, and CLI logs; use legacy design/analysis only as fallback.
 tool_budget:
   read_files: 9
   search_steps: 6
@@ -70,74 +50,15 @@ tool_budget:
 
 # CC-Do
 
-> [PROTOCOL]: 变更时同步更新 `version`、`CHANGELOG.md`、相关模板/脚本引用，然后检查 `CLAUDE.md`
-
-## Role
-
-`cc-do` 是 PDCA 里的 `Do`。
-
-同时它也是 IDCA / DDCA 里的 `Do`。
-
-它只做一件事：沿着已经冻结的任务，把代码真正做出来，并把执行证据留到足够让别人接手、复盘、复验。
-
-## Runtime Output Policy
-
-写入任何 durable Markdown 或 JSON metadata 前，先运行 `cc-devflow config resolve --format policy`。
-
-- `Output language` 是机器约束；如果失败或 debug CLI 日志需要人类可读摘要，必须记录并遵守它。
-- `agent_preferences` 是用户偏好建议，只影响表达方式和结构选择，不覆盖本 Skill 的工作流边界。
-- 如果配置解析失败，先修配置或向用户说明阻塞，不要用默认语言继续生成正式文档。
-
-上游冻结合同来自 `planning/tasks.md`：
-
-- `cc-plan` 产出的 `planning/tasks.md#Contract Summary`
-- `cc-investigate` 产出的 `planning/tasks.md#Root Cause Contract`
-
-## Read First
+`cc-do` 是 PDCA / IDCA 的 `Do`。它只执行 `task.md` 中已经冻结的任务。
 
-1. `PLAYBOOK.md`
-2. `CHANGELOG.md`
-3. `references/execution-recovery.md`
-4. `references/parallel-dispatch.md`
-5. `docs/guides/project-postmortem.md`
+默认只更新：
 
-## Use This Skill When
+- 代码和测试
+- `devflow/changes/<change-key>/task.md` 中的任务状态
+- Git commit
 
-- 要实现 `planning/tasks.md` / `planning/task-manifest.json`
-- 执行被中断，需要恢复
-- bug 根因已经在 `cc-investigate` 里冻结，准备开始修
-- review feedback 要落成代码
-
-如果方案还没冻结、任务边界还没定，停下并回 `cc-plan` 或 `cc-investigate`。
-
-## Quick Start
-
-先判断现在是哪一种执行局面，再开始编码：
-
-| 现实状态 | 先走什么路径 |
-| --- | --- |
-| 已有 ready task，直接实现 | `implement` |
-| 上次做到一半，需要继续 | `resume` |
-| bug 根因已冻结 | `repair-from-investigation` |
-| bug 还没搞清根因 | reroute 到 `cc-investigate` |
-| 收到 review comment，要在既定范围内修正 | `review-fix` |
-
-如果连“当前 task 是什么”都说不清，先别写代码，先跑 `cc-devflow query workflow-context`。只有它的 `openWhen` 指向 scheduling 或 recovery 时，才继续跑 `scripts/select-ready-tasks.sh`；`scripts/build-task-context.sh` 只能输出 stdout，不得生成 `context.md`。
-
-## Harness Contract
-
-- Allowed actions: implement ready tasks, debug inside frozen scope, update task status through the completion script, and apply review feedback that does not reopen design.
-- Forbidden actions: re-planning the requirement in place, blindly rerunning the whole requirement, or delegating tasks without full task context.
-- Required evidence: every task must leave objective code/Git/test evidence; blocked or failed work may leave compact CLI events, but must not create AI-written process files.
-- Reroute rule: after repeated failed repairs or root-cause drift, stop patching and go back to `cc-investigate`; if scope or design truth breaks, go back to `cc-plan`; after task closure, hand off to `cc-check`.
-
-## Execution Discipline
-
-- Make the smallest task-scoped diff; do not add features, abstractions, or adjacent cleanup outside the frozen task. Clean only traces introduced by this task.
-- Match existing style and conventions even when another pattern looks nicer; harmful conventions require reroute/discussion, not private divergence.
-- Deterministic state changes use scripts (`mark-task-complete.sh`, ready-task selectors); the model does not hand-edit status JSON.
-- Tests must prove the behavior's intent through a public seam; tests that would pass after the wrong business behavior changes are invalid.
-- Blockers, skipped tests, stale context, or unclear ownership are reported loudly before continuing.
+不要生成额外过程文件或 JSON 文档。失败和阻塞写在对用户的响应里；需要长期保留的失败教训交给 `cc-act` 写 incident postmortem。
 
 ## TDD Iron Law
 
@@ -145,150 +66,23 @@ tool_budget:
 NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 ```
 
-`cc-do` 默认采用测试先行的执行纪律：
-
-1. Red：先写一个最小失败测试，运行并确认它因为目标行为缺失而失败。
-2. Green：只写让当前失败测试通过的最小生产代码。
-3. Refactor：只有 Green 之后才能清理命名、重复、结构和坏味道。
-4. Record：任务状态只通过 `mark-task-complete.sh` 同步到 `planning/tasks.md` 与 `planning/task-manifest.json`；失败或 debug 时才写 `events.jsonl`。
-
-Red 不是形式上的红，而是公共 seam 上的行为缺失证明。测试必须通过公共接口、调用方流程、CLI/API/UI 路径或其它真实边界进入系统；只验证私有函数、内部调用次数、临时数据结构或 mock 自己控制的内部协作者，不算 TDD 证据。
-
-一个 Red 只证明一个逻辑行为。测试名要像规格说明，而不是实现步骤；结果要从同一类公共入口读回。直接查数据库、读内部状态、扫描临时文件或绕过 API 来证明行为，只在那个边界本身就是被测对象时成立。
-
-例外只能用于 throwaway prototype、纯生成文件、纯配置改动；例外必须写在当前 task block 或 manifest task context 中，包含原因、风险和替代验证命令。测试第一次就绿，说明测试没有证明新行为，必须修测试而不是继续写生产代码。
-
-禁止水平切片：不要先写一批测试，再写一批实现。每次只推进一个 tracer bullet：一个可观察行为的 Red -> 让它变绿的最小实现 -> 必要重构 -> 记录证据，然后再进入下一个行为。
-
-测试数据也必须诚实。fixture 只提供当前行为需要的最小输入；partial fixture、类型断言、mock payload 或 generated stub 必须写清哪些字段是真实 contract，哪些只是测试填充。不能用 `as`、`any`、双重 cast、缺字段 partial mock 或 test-only method 掩盖 seam 设计问题。
-
-Green 不是顺手把未来行为都做掉。只写当前红灯要求的最小生产代码；如果需要新接口，优先保持小接口深模块，依赖从调用方传入，外部 boundary adapter 拆成具体操作，而不是用一个 generic fetcher 把复杂条件推给 mock。
-
-Refactor 只能发生在 Green 之后。优先处理当前 slice 暴露出的重复、长方法、浅模块、feature envy、primitive obsession、命名混乱、三层以上分支和新代码揭开的旧代码坏味道；没被当前绿色测试保护的扩张性整理，回到 `cc-plan` 或后续任务。
-
-## Entry Gate
-
-1. 先运行 `cc-devflow query workflow-context --change <changeId> --change-key <changeKey> --data-only --no-trace --compact`，把 `nextAction.skill == "cc-do"` 和 `currentTask.id` 作为执行入口。
-2. 先只用 `workflow-context.progressiveDisclosure.packetOnly` 和 `mustNotForget` 做导航与护栏，必要时打开 `defaultOpen` 的 section / JSON refs；如果 `sourceHashes` 不匹配、命令缺失、scope/依赖/触点不确定，必须按 `openWhen.conditions` 打开 `deepOpen`，不能靠猜。
-3. 先用 `workflow-context.queues.readyTasks` 判断现在到底哪几个任务真的 ready；需要 shell 复核时再跑 `scripts/select-ready-tasks.sh`。
-4. 只锁定当前 ready task，或一组经依赖、wave、精确触点与父子路径触点校验后可并行的 ready tasks。
-5. 如果这次来自 `cc-investigate`，必须把 `planning/tasks.md#Root Cause Contract` 当成 canonical contract，而不是一边实现一边重新调查。
-6. 没有任务上下文，不准把任务扔给 subagent；先用 `workflow-context.currentTask`，不够时再用 `scripts/build-task-context.sh` 从 canonical artifacts 组装上下文。
-7. 如果 `task-manifest.json.metadata.lane == "quick"`，仍然必须有 current task、verification、task status 和唯一 next action；quick 只缩短文档密度，不跳过证据。
-8. 如果仓库含 `.gitmodules` 或 manifest 提供 `submodulePaths`，先用 `scripts/detect-file-conflicts.sh` 标出 `submoduleTouches`；只有触达该 submodule 的任务失去默认 worktree 隔离资格，未触达任务不能被无辜串行化。
-9. 每个单 task 开工前，用当前 task 的 touched files、capability、错误类型、模型风险词快速检索 `devflow/postmortems`；命中时把相关原则转成当前 task 的 guardrail。不要为 no-match 生成过程文件。
+允许例外：纯配置、纯生成文件、throwaway prototype、用户明确禁止测试。例外必须写进当前 task block。
 
 ## Loop
 
-1. 读取当前任务，而不是重新发明任务。
-2. 先执行当前 task 的 Project Postmortem quick search；如果命中同类 incident，先打开对应 incident 的 Prevention Summary 和 Git Evidence，再开始 Red。
-3. 依赖没满足前，不准提前做下游任务；不同 wave 之间不允许抢跑。
-4. 没有明确并行资格，不准把多个实现任务同时推进；`touches` 父子路径重叠也算同一执行表面。
-5. 先 `fail-first`：先写失败测试，先看见预期红，再写生产代码。
-6. 如果红灯不是预期失败（语法错、fixture 错、测试没连上），先修测试直到它正确失败。
-7. 如果红灯通过错误 seam 得到，比如私有方法、内部调用次数、mock 内部协作者，先修测试 seam，不准进入 Green。
-8. 如果红灯只断言实现形状、直接查内部状态或一次证明多个逻辑行为，先改测试，不准进入 Green。
-9. 按 `Red -> Green -> Refactor` 推进，Green 只允许最小实现，不预铺未来测试尚未要求的分支、状态或 API。
-10. 如果当前 Red 需要新的 fixture 或 mock，先证明它仍从公共 seam 触发真实行为；fixture 缺字段、类型强转或内部 mock 都要写入 `tdd.testQuality.fixtureRisk` 或先修 seam。
-11. Refactor 后必须重跑相关测试，保持 Green；Red 状态下不重构。
-12. 每次推进都以代码 diff、Git 状态、验证命令输出和 task 状态为真相源；只有失败、阻塞或 debug 需要机器日志时才写 `events.jsonl`。
-13. 任务实现后，先过 `spec review`，再过 `code review`，两道门都过才算任务收口；这里只验证 spec delta，不回写长期 spec。
-14. 当前任务完成后，把可验证证据留给 `cc-check`。
-
-## Output
-
-- 代码变更
-- 测试变更
-- `planning/tasks.md` 与 `planning/task-manifest.json` 的 task 状态
-- `devflow/changes/<change-key>/execution/tasks/<task-id>/events.jsonl`（仅 debug / failed 默认保留；CLI 自动日志，不写叙事 Markdown）
-- `planning/task-manifest.json` 里的 task review verdict
-
-## Good Output
-
-- 当前 task 一眼可见，执行者不用从聊天记录里猜目标
-- 当前 wave、ready tasks、parallel candidates、touch conflict verdict 和 submoduleTouches 一眼可见
-- 至少留下一次明确的 tracer bullet Red/Green/Refactor 证据，且 Red 是公共 seam 上的预期行为失败
-- Red 证据说明测试名、单一行为、公共验证路径和为何不是实现细节测试
-- Green 证据说明 minimality guard：本轮只满足当前红灯，没有提前实现未来分支
-- Refactor 证据说明清掉了哪个具体坏味道，或者为什么当前 slice 不需要 refactor
-- 测试 fixture 说明真实 contract 字段和测试填充字段，没有用类型欺骗或内部 mock 制造假绿
-- task status、Git diff、验证命令和必要 CLI 日志足够让下一位接手者恢复
-- quick lane 也有 mini manifest、verification 和唯一 next action，不靠聊天记录继续
-- reviewer 能顺着 review 记录和验证命令复盘这次实现
-
-## Bundled Resources
-
-- 变更记录：`CHANGELOG.md`
-- 执行 / 恢复规则：`references/execution-recovery.md`
-- 并行分配准则：`references/parallel-dispatch.md`
-- 恢复分析：`scripts/recover-workflow.sh`
-- 任务状态：`scripts/check-task-status.sh`
-- ready 任务选择：`scripts/select-ready-tasks.sh`
-- 任务上下文组装：`scripts/build-task-context.sh`（stdout only，不落盘）
-- 旧 checkpoint 兼容入口：`scripts/write-task-checkpoint.sh`（不写 checkpoint，只在失败 / debug 时写事件）
-- review 记录：`scripts/record-review-decision.sh`
-- 任务闭环校验：`scripts/verify-task-gates.sh`
-- 任务勾选：`scripts/mark-task-complete.sh`
-- 文件冲突：`scripts/detect-file-conflicts.sh`
-
-## Working Rules
-
-1. 没有根因，不准修 bug。
-2. 没有任务边界，不准无界发散。
-3. 没有失败测试，不准写生产代码。
-4. 测试如果第一次就绿，说明你没证明任何东西，先修测试。
-5. 红灯原因必须和目标行为缺失一致；红灯如果只是测试写错，不算 TDD 证据。
-6. 红灯必须验证公共接口上的行为；实现细节测试、私有方法测试、内部调用次数断言都要先退回 Red 修正。
-7. Mock 只能放在系统边界；如果必须 mock 内部协作者才能测试，说明 seam 或设计合同有问题。
-8. 一个 Red 只证明一个逻辑行为；bulk Red 或测试名描述实现步骤，都先退回测试设计。
-9. Green 只写当前红灯需要的最小实现；预铺未来功能、兼容分支或宽接口都算越界。
-10. Red 时不重构；Refactor 只在相关测试已绿后处理当前 slice 暴露的坏味道。
-11. 先过 `spec review`，再过 `code review`，顺序不能反。
-12. 不在 `cc-do` 里改 capability spec 正文；这里只产出实现证据和 spec 对齐证据。
-13. 失败和阻塞都要留下恢复证据。
-14. 给 subagent 的输入必须包含：当前进度、当前任务全文、依赖状态、必读文件、验收标准、可信命令。
-15. 三次失败修补后必须先质疑调查合同或设计合同，而不是继续堆补丁。
-16. 完成任务后必须调用 `scripts/mark-task-complete.sh` 同步 `planning/task-manifest.json` 和 `planning/tasks.md`；禁止手工改 checkbox、status、currentTaskId 来冒充完成。
-17. 如果 `mark-task-complete.sh` 失败，说明 review gate 或任务依赖还没闭合；先修证据，再重跑脚本，不准绕过。
-
-## Task Status Protocol
-
-ClaudeCode / Codex 执行 `cc-do` 时必须把任务状态当成状态机，不是普通 Markdown TODO。
-
-1. 开始前用 `planning/task-manifest.json.currentTaskId` 或 ready-task 脚本确认当前任务。
-2. 执行时读取完整 task block，包含 Goal、TDD phase、Files、Read first、Verification、Evidence、test seam、mock boundary、minimality / refactor 字段。
-3. 完成验证和 review gate 后运行完成脚本：
-
-```bash
-SCRIPT_ROOT=".claude/skills/cc-do/scripts"
-if [[ ! -d "$SCRIPT_ROOT" && -d ".codex/skills/cc-do/scripts" ]]; then
-  SCRIPT_ROOT=".codex/skills/cc-do/scripts"
-fi
-bash "$SCRIPT_ROOT/mark-task-complete.sh" --manifest devflow/changes/<change-key>/planning/task-manifest.json --tasks devflow/changes/<change-key>/planning/tasks.md --task <task-id>
-```
-
-4. 脚本会先跑任务 gate，再同步 manifest、checkbox、`currentTaskId` 和整体状态。不要手动改这些字段。
-5. 如果任务不能完成，只在失败 / debug 需要时写 CLI event；不要生成过程 Markdown，也不要把失败任务标成完成。
-
-## Exit Criteria
-
-- 当前任务有 Red/Green 证据
-- 当前任务有 `spec review` / `code review` 两道门证据
-- 恢复点可从 `planning/tasks.md`、`planning/task-manifest.json`、Git 状态和必要 CLI 日志判断
-- 阻塞原因已写清楚
-- 下一步应进入 `cc-check`，或明确退回 `cc-investigate` / `cc-plan`
+1. 从 `task.md` 选择第一个未完成且依赖满足的任务；必要时用 `scripts/select-ready-tasks.sh` 复核。
+2. 读取当前任务涉及的最小代码和测试。
+3. Red：写最小失败测试，确认失败原因就是目标行为缺失。
+4. Green：写最小实现，不预铺未来分支。
+5. Refactor：只清理当前 slice 暴露出的坏味道，保持测试绿。
+6. Review：自查 scope、公共 seam、mock 边界、错误路径和文档影响。
+7. Complete：运行 `scripts/mark-task-complete.sh --tasks devflow/changes/<change-key>/task.md --task <task-id>`。
+8. Commit：每个任务或执行环境完成后提交 Git commit。
 
-## Do Not
+## Parallel Rule
 
-- 不在这里重开方案讨论
-- 不把一次修复膨胀成重写整个模块
-- 不把依赖任务和被依赖任务同时并行
-- 不把没有当前进度的任务直接丢给 subagent
-- 三层以上判断说明上游合同该回炉
+只有任务显式允许并行、依赖已满足、触碰路径无重叠、且每个执行环境都能独立提交时，才并行。否则串行。
 
-## Companion Files
+## Exit
 
-- 深入剧本：`PLAYBOOK.md`
-- 变更记录：`CHANGELOG.md`
-- 执行规则：`references/execution-recovery.md`
-- 并行规则：`references/parallel-dispatch.md`
+退出时报告任务 ID、验证命令、commit hash、剩余任务或下一步 `cc-check`。不要写过程文件。

package/.claude/skills/cc-do/references/execution-recovery.md

@@ -1,114 +1,20 @@
-# Execution And Recovery
+# Execution Recovery
 
-## Minimum Runtime Truth
+Recover from:
 
-- 当前 requirement / change ID
-- 当前 task ID
-- 当前 task status
-- 当前 active phase
-- 当前 ready tasks
-- 当前 wave / parallel candidates / touch conflict verdict
-- submoduleTouches（如适用）
-- 当前 review gates（spec / code）
-- 已完成证据
-- 阻塞点
-- 下一步唯一动作
+- Git branch
+- Git status
+- recent commits
+- `task.md`
+- current test output
 
-## Recovery Rule
+Do not recover from process files. They are not part of the workflow.
 
-恢复时只回答 3 件事：
+## Resume Steps
 
-1. 现在停在哪
-2. 为什么停在这
-3. 下一步必须先做什么
-
-如果这三件事不能只靠规范产物、Git 状态和 CLI 日志回答，就先做 context reset，不准继续依赖聊天记忆。
-
-## Runtime Layout
-
-默认执行真相来自：
-
-- 代码和测试 diff
-- Git 状态
-- `planning/tasks.md` 的 checkbox
-- `planning/task-manifest.json` 的 task status / reviews / currentTaskId
-- `devflow/changes/<change-key>/execution/tasks/<task-id>/events.jsonl`（仅 debug / failed 默认保留；CLI 自动日志）
-- `planning/task-manifest.json` 里的 `tasks[*].reviews`
-
-不得生成 `context.md`、`checkpoint.json`、review markdown 或其它 AI 手写过程文件。需要复盘时重新读取代码、Git、task 状态和 CLI 自动日志。
-
-## Optional Event Spine
-
-`events.jsonl` 只在 debug 或 failed 时存在。存在时可以包含这些事件：
-
-1. `context_ready`
-2. `red_failed`
-3. `red_reason_verified`
-4. `red_seam_verified`
-5. `red_behavior_verified`
-6. `mock_boundary_verified`
-7. `green_passed`
-8. `refactor_done` 或 `refactor_not_needed`
-9. `refactor_green`
-10. `spec_review_pass`
-11. `code_review_pass`
-
-如果 `events.jsonl` 没开启，使用 manifest task status、`tasks.md` checkbox、review verdict 和验证命令输出恢复。
-
-## Task Evidence Fields
-
-当前 task block / manifest task / 验证输出至少能回答：
-
-- `red.command`
-- `red.exitStatus`
-- `red.expectedFailure`
-- `red.testSeam`
-- `red.behaviorAsserted`
-- `red.specStyleTestName`
-- `red.oneLogicalBehavior`
-- `red.publicVerificationPath`
-- `red.allowedMocks`
-- `red.implementationDetailRisk`
-- `green.command`
-- `green.exitStatus`
-- `green.minimalityGuard`
-- `refactor.status`
-- `refactor.candidates`
-- `refactor.greenCommand`
-- `testQuality.usesPublicInterface`
-- `testQuality.describesBehavior`
-- `testQuality.specStyleName`
-- `testQuality.verifiesThroughPublicPath`
-- `testQuality.noBulkRed`
-- `testQuality.survivesInternalRefactor`
-- `testQuality.mocksOnlySystemBoundaries`
-- `review.spec.status`
-- `review.code.status`
-
-如果跳过 TDD，必须有 `tddException` 或 task-level exception 说明，并写清替代验证。没有这些字段时，恢复执行先补证据，不准直接继续实现。
-
-## Bug Rule
-
-- 先复现
-- 再收证据
-- 再下根因判断
-- 最后改代码
-
-## Local Recovery Ladder
-
-1. 先重试当前命令或当前 task，而不是重跑整条 requirement
-2. 两次失败后回看证据链、task block、Git diff 和 CLI 日志
-3. 三次失败后默认怀疑上游合同：根因漂移回 `cc-investigate`，范围 / 设计漂移回 `cc-plan`
-
-## Subagent Rule
-
-给 subagent 的上下文至少包含：
-
-- 当前任务全文
-- 当前进度与 manifest task status
-- 已满足 / 未满足的依赖
-- 必读文件
-- 验收标准
-- 验证命令
-- 不做项 / 边界
-- quick lane 是否仍有 mini manifest、verification 和唯一 next action
+1. Read `task.md`.
+2. Run `git status --short`.
+3. Inspect recent commits.
+4. Select the first unchecked task.
+5. Re-run the task's verification command if previous output is stale.
+6. Continue or reroute.