cc-devflow 4.5.9 → 4.5.11

package/.claude/skills/cc-plan/assets/TASKS_TEMPLATE.md

@@ -5,6 +5,7 @@
 - Requirement version:
 - Design version:
 - CC-Plan skill version:
+- Work branch:
 - Output language:
 - Source roadmap item:
 - Source roadmap version:
@@ -13,14 +14,46 @@
 
 ## Progressive Disclosure Index
 
-- Default read: Plan Meta, Execution Handoff, Execution Protocol, current task block.
+- Default read: Plan Meta, Contract Summary, Execution Handoff, Execution Protocol, current task block.
 - Open for scheduling: `planning/task-manifest.json`, ready-task selector output, dependencies, touched files.
 - Open for parallel or ownership questions: Implementation Surface Map, Tracer Bullet Map.
-- Open for audit/recovery: Task Quality Bar, checkpoint files, review/report-card.json.
+- Open for audit/recovery: Task Quality Bar, Git state, CLI logs, review/report-card.json.
+- Machine JSON rule: after editing this file, run `cc-devflow task-contract compile --change <changeId> --change-key <changeKey>` and `cc-devflow task-contract validate --change <changeId> --change-key <changeKey>`; do not handwrite `task-manifest.json` or `change-meta.json`.
+
+## Contract Summary
+
+Change:
+Mode: plan
+Profile: tiny-design | full-design
+Approval:
+
+Goal:
+-
+
+Do Not Do:
+-
+
+Approved Direction:
+-
+
+Acceptance:
+-
+
+Verification:
+-
+
+Risk / Escalate If:
+-
+
+> This is the default human-authored planning contract. Do not create
+> `planning/design.md` for new changes unless the user explicitly requests a
+> legacy artifact or a migration requires preserving one.
+> `task-manifest.json` and `change-meta.json` are generated by
+> `cc-devflow task-contract compile`, not by manual AI JSON authoring.
 
 ## Execution Handoff
 
-- Canonical design: `planning/design.md`
+- Canonical contract: `planning/tasks.md#Contract Summary`
 - Canonical change meta: `change-meta.json`
 - Execution mode: `single-path` | `parallel-ready`
 - Frozen decisions:
@@ -70,14 +103,17 @@
 ClaudeCode / Codex 执行本计划时，必须把本文件当成任务模板合同，而不是普通 TODO 列表。
 
 - Template source: `assets/TASKS_TEMPLATE.md`
+- Context index first: run `cc-devflow query workflow-context --change <changeId> --change-key <changeKey> --cwd <repo-root> --data-only --no-trace --compact` before opening deep sections; use `packetOnly` plus `mustNotForget` first, verify `sourceHashes`, open `defaultOpen` refs only when needed, and reserve `deepOpen` for matching `openWhen.conditions`.
 - Task selection: read `planning/task-manifest.json.currentTaskId`; if empty, run the ready-task selector before choosing work.
 - Task block rule: read the full task block before coding; title-only execution is invalid.
-- Contract sync rule: every task must inherit one row from Task Contract Matrix; if the matrix lacks source funnel rounds, interface/data contract, do-not-re-decide items, or artifact updates, return to `planning/design.md` before coding.
+- Contract sync rule: every task must inherit one row from Task Contract Matrix; if the matrix lacks source funnel rounds, interface/data contract, do-not-re-decide items, or artifact updates, return to `planning/tasks.md#Contract Summary` before coding.
 - Completion rule: after verification and review gates pass, run the completion script; do not manually edit checkbox, status, or `currentTaskId`.
-- Completion failure: if the script fails, fix the missing checkpoint / review / dependency evidence and rerun it. Do not bypass it by editing JSON or Markdown.
-- Postmortem recall rule: before each task, search `devflow/postmortems` with the task's touched files, capability, failure class, and model-risk terms; record relevant reminders or an explicit no-match in checkpoint/events.
+- Completion failure: if the script fails, fix the missing review / dependency evidence and rerun it. Do not bypass it by editing JSON or Markdown.
+- Postmortem recall rule: before each task, search `devflow/postmortems` with the task's touched files, capability, failure class, and model-risk terms; apply relevant reminders to the work. Do not generate no-match process files.
+- Runtime file ban: do not generate `execution/tasks/<task-id>/context.md`, `checkpoint.json`, review markdown, or any AI-written process file. Recovery reads code, Git, `planning/tasks.md`, `planning/task-manifest.json`, and CLI logs only.
 
 ```bash
+cc-devflow query workflow-context --change <changeId> --change-key <changeKey> --cwd <repo-root> --data-only --no-trace --compact
 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"
@@ -124,7 +160,7 @@ bash "$SCRIPT_ROOT/mark-task-complete.sh" --manifest devflow/changes/<change-key
   Project postmortem search: `rg -n "<test seam|capability|module|model-risk>" devflow/postmortems` or record `no-project-postmortems-yet`
   Verification: `npm test -- path/to/test`
   Evidence: failing output
-  Completion: after failing evidence and required checkpoint/review records exist, run `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 T001`; do not hand-edit status.
+  Completion: after failing evidence and required review records exist, run `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 T001`; do not hand-edit status.
   Coverage: unit / integration / e2e / eval; regression: yes / no
   Spec-style test name: 测试名像规格说明，描述可观察行为
   One logical behavior: yes / no
@@ -147,8 +183,8 @@ bash "$SCRIPT_ROOT/mark-task-complete.sh" --manifest devflow/changes/<change-key
   Read first: `design.md`, `path/to/test`
   Project postmortem search: `rg -n "<implementation surface|module|failure-class|model-risk>" devflow/postmortems` or record `no-project-postmortems-yet`
   Verification: `npm test -- path/to/test`
-  Evidence: passing output + checkpoint
-  Completion: after green evidence and required checkpoint/review records exist, run `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 T002`; do not hand-edit status.
+  Evidence: passing output + Git diff
+  Completion: after green evidence and required review records exist, run `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 T002`; do not hand-edit status.
   Green minimality guard: 只写当前红灯要求的最小实现，不预铺未来行为、分支或 API
   Vertical slice: Slice 1
   Ready when: T001 已经见红，且当前 touched files 不和其他并行任务冲突
@@ -167,7 +203,7 @@ bash "$SCRIPT_ROOT/mark-task-complete.sh" --manifest devflow/changes/<change-key
   Project postmortem search: `rg -n "<test seam|capability|module|model-risk>" devflow/postmortems` or record `no-project-postmortems-yet`
   Verification: `npm test -- path/to/other.test`
   Evidence: failing output
-  Completion: after failing evidence and required checkpoint/review records exist, run `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 T003`; do not hand-edit status.
+  Completion: after failing evidence and required review records exist, run `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 T003`; do not hand-edit status.
   Coverage: unit / integration / e2e / eval; regression: yes / no
   Spec-style test name: 测试名像规格说明，描述可观察行为
   One logical behavior: yes / no
@@ -191,7 +227,7 @@ bash "$SCRIPT_ROOT/mark-task-complete.sh" --manifest devflow/changes/<change-key
   Project postmortem search: `rg -n "<implementation surface|module|failure-class|model-risk>" devflow/postmortems` or record `no-project-postmortems-yet`
   Verification: `npm test -- path/to/other.test`
   Evidence: passing output + review notes
-  Completion: after green evidence and required checkpoint/review records exist, run `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 T004`; do not hand-edit status.
+  Completion: after green evidence and required review records exist, run `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 T004`; do not hand-edit status.
   Green minimality guard: 只写当前红灯要求的最小实现，不预铺未来行为、分支或 API
   Vertical slice: Slice 2
   Ready when: T003 已经见红，且文件触点与其他 `[P]` 任务不冲突
@@ -210,7 +246,7 @@ bash "$SCRIPT_ROOT/mark-task-complete.sh" --manifest devflow/changes/<change-key
   Project postmortem search: `rg -n "<refactor candidate|code smell|module|model-risk>" devflow/postmortems` or record `no-project-postmortems-yet`
   Verification: `npm test -- path/to/test path/to/other.test`
   Evidence: refactor diff + repeated green output
-  Completion: after refactor evidence and required checkpoint/review records exist, run `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 T005`; do not hand-edit status.
+  Completion: after refactor evidence and required review records exist, run `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 T005`; do not hand-edit status.
   Refactor candidates: duplication / long method / shallow module / feature envy / primitive obsession / naming / >3 nesting / newly exposed old code smell
   Ready when: 对应 Red/Green 任务都已完成，且清理不会扩大 scope
 
@@ -219,14 +255,14 @@ bash "$SCRIPT_ROOT/mark-task-complete.sh" --manifest devflow/changes/<change-key
   Source funnel rounds: Execution Architecture; Task Contract; Final Approval.
   Contract: user story `all planned stories`; file responsibility `verification evidence`; method/interface `all changed public seams`; key fields `all contract fields`; input/output `not applicable`; failure path `gate failure blocks completion`; AFK/HITL `AFK`.
   Do not re-decide: scope, test framework, gate set, completion protocol.
-  Artifact updates: review evidence / checkpoint only; no behavior changes.
+  Artifact updates: review evidence only; no behavior changes and no execution process files.
   TDD phase: evidence
   Files: `command or file`
   Read first: `tasks.md`, `task-manifest.json`
   Project postmortem search: `rg -n "<verification|release|tooling|model-risk>" devflow/postmortems` or record `no-project-postmortems-yet`
   Verification: `npm test && npm run lint`
   Evidence: gate output
-  Completion: after gate evidence and required checkpoint/review records exist, run `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 T006`; do not hand-edit status.
+  Completion: after gate evidence and required review records exist, run `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 T006`; do not hand-edit status.
   Ready when: 当前 requirement 的实现任务都已收口
 
 > `[P]` 只表示“依赖满足后有资格并行”，不表示可以无脑同时开发。

package/.claude/skills/cc-plan/assets/TASK_MANIFEST_TEMPLATE.json

@@ -9,8 +9,9 @@
     "documentLanguage": ""
   },
   "planningMeta": {
-    "reqPlanSkillVersion": "3.8.5",
+    "reqPlanSkillVersion": "3.9.2",
     "designVersion": "design.v1",
+    "workBranch": "REQ/XXX-short-feature-name",
     "approvedAt": "2026-04-15T12:00:00.000Z",
     "basedOnOption": "Option A",
     "aiLeverageDecisionLens": {
@@ -132,7 +133,6 @@
       ],
       "context": {
         "readFiles": [
-          "design.md",
           "tasks.md",
           "change-meta.json"
         ],
@@ -141,7 +141,8 @@
         ],
         "notes": [
           "Write the failing test first",
-          "Do not change unrelated contracts in this task"
+          "Do not change unrelated contracts in this task",
+          "Do not generate execution context.md, checkpoint.json, review markdown, or AI-written process files"
         ]
       },
       "reviews": {
@@ -171,7 +172,7 @@
   ],
   "metadata": {
     "source": "tasks.md",
-    "generatedBy": "skill:cc-plan",
+    "generatedBy": "cc-devflow task-contract",
     "planVersion": 1
   }
 }

package/.claude/skills/cc-plan/assets/{DESIGN_TEMPLATE.md → legacy/DESIGN_TEMPLATE.md}

@@ -5,6 +5,7 @@
 - Requirement version:
 - Design version:
 - CC-Plan skill version:
+- Work branch:
 - Output language:
 - Requirement ID:
 - Design mode: `full-design`

package/.claude/skills/cc-plan/assets/{TINY_DESIGN_TEMPLATE.md → legacy/TINY_DESIGN_TEMPLATE.md}

@@ -194,7 +194,7 @@
 - Tracer bullet order:
 - Green implementation check:
 - Green minimality guard:
-- Refactor checkpoint:
+- Refactor gate:
 - Refactor candidates:
 - TDD exceptions:
 - Regression test required:

package/.claude/skills/cc-plan/references/planning-contract.md

@@ -2,23 +2,24 @@
 
 ## Hard Rules
 
-1. `cc-plan` 默认只产出 4 个文件：`planning/design.md`、`planning/tasks.md`、`planning/task-manifest.json`、`change-meta.json`。
-2. clarification / brainstorm / review 结论必须并入 `planning/design.md`，不能再默认拆独立文档。
+1. `cc-plan` 默认只产出 3 个文件：`planning/tasks.md`、CLI 生成的 `planning/task-manifest.json`、CLI 生成的 `change-meta.json`。
+2. clarification / brainstorm / review 结论必须并入 `planning/tasks.md#Contract Summary`，不能再默认拆 `planning/design.md` 或独立文档。
 3. 执行 handoff 必须写进 `planning/tasks.md` 顶部，不能依赖单独的 `context-package.md`。
 4. `planning/task-manifest.json` 必须和 `planning/tasks.md` 同步，且能告诉 `cc-do` 当前任务是谁。
-5. `planning/design.md`、`planning/tasks.md`、`planning/task-manifest.json` 必须记录来源版本链。
+5. `planning/tasks.md`、`planning/task-manifest.json` 必须记录来源版本链。
+6. 机器态 JSON 必须由 `cc-devflow task-contract compile` / 模板 / validator 生成或更新；AI 不手写 `task-manifest.json` 或 `change-meta.json`。
 6. 所有 SKILL 输出必须遵守 `docs/guides/artifact-contract.md`：状态只能有一个 owner，其它文件只能引用、投影或派生。
 7. 计划里出现 placeholder 词，就说明还没想清楚。
 8. 一次只推进一个澄清问题，不允许问题轰炸。
 9. 推荐方案没获批前，不允许继续拆执行任务。
-10. `planning/design.md` 通过 review gate 前，不允许宣称计划完成。
+10. `planning/tasks.md#Contract Summary` 通过 review gate 前，不允许宣称计划完成。
 11. 如果来自 `roadmap`，planning 不得悄悄丢掉 source constraints / non-goals / success signal。
 12. 每个计划必须先找 existing leverage，再决定新增实现；重复已有能力属于 planning 失败。
 13. 同 blast radius 内的完整边界默认纳入，defer 必须写入 `NOT in scope` 和原因。
 14. 如果推荐方案挑战用户原始方向，必须标成 `user challenge`，不能自动改写用户意图。
 15. 行为变更的具体任务默认采用测试先行；没有 Red/Green/Refactor 链、spec-style test name、公共测试 seam、行为断言、mock 边界或 TDD exception，不允许交给 `cc-do`。
 16. 新 change 目录必须通过 `cc-devflow next-change-key` 生成（不能手动心算编号），格式是 `REQ-<number>-<description>` 或 `FIX-<number>-<description>`；`REQ` 和 `FIX` 各自递增，跨前缀同号不是冲突；并行工作树造成同前缀同号时，完整 change key 靠描述区分业务内容。
-17. 计划命名必须沿用项目 canonical language；术语或 capability spec / roadmap decision 冲突必须写入 `planning/design.md`，不能在任务里发明第二套语言。
+17. 计划命名必须沿用项目 canonical language；术语或 capability spec / roadmap decision 冲突必须写入 `planning/tasks.md#Contract Summary`，不能在任务里发明第二套语言。
 18. 行为变更任务必须按 tracer bullet 垂直切片组织：一个可观察行为对应一组 Red/Green/Refactor 任务。
 19. Red 任务必须通过公共接口、调用方流程、CLI/API/UI 路径或其它真实 seam 证明行为缺失。
 20. Mock 只能发生在系统边界；mock 内部协作者、私有方法或调用次数属于测试设计失败。
@@ -31,9 +32,9 @@
 27. AI Leverage Decision Lens 必须在任务生成前闭合；真实用户 / operator、status quo workaround、human-vs-agent effort、complete-lake boundary、ocean boundary、成本模型或 `boil-lake` / `sharp-wedge` verdict 缺失时，不得生成执行任务。`boil-lake` verdict 下不得退缩成 happy-path MVP。
 28. review loop 必须有 attempt 上限和 stall reroute；不能靠无限 review 掩盖需求仍不清楚。
 29. Roadmap Sync Gate 必须在退出前闭合：source RM 存在就回写 `devflow/roadmap.json` 并重新生成 `devflow/ROADMAP.md` / `devflow/BACKLOG.md`；不存在就记录 no-op reason。
-30. PRD-grade requirement brief 必须并入 `planning/design.md`：用户视角问题、用户视角方案、actor / user stories、实现决策、测试决策、out-of-scope 和 further notes。默认不得额外产出 `PRD.md`。
+30. PRD-grade requirement brief 必须并入 `planning/tasks.md#Contract Summary`：用户视角问题、用户视角方案、actor / user stories、实现决策、测试决策、out-of-scope 和 further notes。默认不得额外产出 `PRD.md`。
 31. 需要用户判断时必须使用固定 Decision Question：`D<N>`、证据、推荐、2-3 个互斥的 `A/B/C` 字母选项、影响和 STOP 都必须出现；禁止用自由问句或 `1/2/3` 数字选项代替审批 gate。
-32. 所有用户决策必须写入 `planning/design.md` 的 `Decision Questions`，并同步到 `task-manifest.json.planningMeta.decisionQuestions`，不能只留在聊天里。
+32. 所有用户决策必须写入 `planning/tasks.md#Contract Summary` 的 `Decision Questions`，并同步到 `task-manifest.json.planningMeta.decisionQuestions`，不能只留在聊天里。
 33. Deep Planning Funnel 必须在任务生成前闭合：requirement reality、system shape、interface/data contract、abstraction/encapsulation、execution architecture、task contract、final approval 都要记录状态、证据和 artifact impact。
 34. 每个任务必须继承 funnel 结论形成 task contract：user story / edge story、文件职责、方法或接口、关键字段、输入输出、失败路径、验证方式和 AFK/HITL。没有 task contract 的任务不允许交给 `cc-do`。
 
@@ -88,7 +89,7 @@
 - Completion command：调用 `mark-task-complete.sh`，同步 `planning/task-manifest.json` 与 `planning/tasks.md`
 - Forbidden shortcuts：禁止手工改 checkbox、manifest status 或 `currentTaskId`
 
-行为变更任务必须先有 `[TEST]` 红灯任务，再有 `[IMPL]` 绿灯任务，最后有 `[REFACTOR]` 或明确 refactor checkpoint。纯文档、纯配置、纯生成文件、throwaway prototype 可以例外，但必须写明原因、风险和替代验证。
+行为变更任务必须先有 `[TEST]` 红灯任务，再有 `[IMPL]` 绿灯任务，最后有 `[REFACTOR]` 或明确 refactor gate。纯文档、纯配置、纯生成文件、throwaway prototype 可以例外，但必须写明原因、风险和替代验证。
 不要把计划拆成水平层：一批测试、一批服务、一批 UI。每个切片完成后都应该能证明一个真实行为。
 也不要把一批 Red 一次性写完再批量实现。每条 tracer bullet 只证明一个可观察行为，Green 只做当前红灯要求的最小实现；下一条 Red 可以吸收上一轮学到的事实，但不能越过冻结边界。
 
@@ -99,7 +100,8 @@
 - task 选择来自 `currentTaskId` 或 `select-ready-tasks.sh`
 - 每个 task 必须按模板字段完整展开，不能退化成标题清单
 - 完成 task 必须调用 `mark-task-complete.sh`
-- 脚本失败时修 evidence / checkpoint / review gate 后重跑，禁止手工绕过
+- 脚本失败时修 evidence / review gate / dependency state 后重跑，禁止手工绕过
+- 禁止规划或要求生成执行过程文件：`execution/tasks/<task-id>/context.md`、`checkpoint.json`、review markdown 或其它 AI 手写过程文件都不是默认真相源；恢复只看代码、Git、`planning/tasks.md`、`task-manifest.json` 和 CLI 自动日志。
 - completion command、required-before-completion 和 forbidden-shortcuts 写在 `planning/tasks.md` 的 task block；不得再写入 `task-manifest.json.executionProtocol` 或 `tasks[].completion`
 - `task-manifest.json` 不写顶层 `status`、`activePhase`、`sourceRoadmap` 或 `spec`；整体完成度从 `tasks[].status` 派生，phase 从任务图派生，roadmap/spec 状态从 `change-meta.json` 和 `devflow/roadmap.json` 读取。
 
@@ -120,7 +122,7 @@
 
 ## Review Gate
 
-`planning/design.md` 至少完成：
+`planning/tasks.md#Contract Summary` 至少完成：
 
 1. Placeholder scan
 2. Consistency scan

package/.claude/skills/cc-review/CHANGELOG.md

@@ -1,5 +1,11 @@
 # CC-Review Changelog
 
+## 2.0.0 - 2026-05-13
+
+- break default review output away from Markdown plan/report files and make `review-ledger.jsonl` the required durable record
+- add CLI-first lifecycle guidance for `review start`, `record-node`, `add-finding`, `close`, and on-demand `render`
+- rename optional machine outputs to `review-findings.json` and `review-agent-results.jsonl`, with legacy `cc-review-*` files retained only as fallback inputs
+
 ## 1.3.0
 
 - Added a risk-lane review swarm profile for broad implementation and PR-landing reviews.

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

@@ -14,8 +14,8 @@
 ## Core Rules
 
 1. 先判断 review 对象是计划、实现，还是混合。
-2. 先读上一次 `cc-review` 的 plan / report / ledger / findings，再看当前 git 或 artifact delta。
-3. 先写 `cc-review-plan.md`，列出要用哪些 Review 工具和哪些节点需要遍历。
+2. 先读上一次 `cc-review` 的 `review-ledger.jsonl` / `review-findings.json` / `review-agent-results.jsonl`，再看当前 git 或 artifact delta；旧 `cc-review-*` 文件只作 fallback。
+3. 先用 `cc-devflow review start` 写入 `review-started` 事件，列出 Review 工具、节点、跳过理由和风险 lane。
 4. 对适合独立审查的节点，优先派发只读 reviewer subAgent；没有工具时如实降级。
 5. 复杂实现 diff 优先使用 intent/regression、security/privacy、performance/reliability、contracts/coverage 四类风险 lane；小 diff 可以合并但必须说明。
 6. 按节点逐个 Review：review 一个、check 一个、ledger 记录一个。
@@ -30,15 +30,13 @@
 15. 不允许固定只列 3 个问题；finding 数量由节点遍历和证据决定。
 16. 输出前必须聚合 raw findings：合并重复，降级弱证据，拒收 speculative / out-of-scope / stale findings。
 17. 发现计划合同错误，回 `cc-plan`；发现代码错误，回 `cc-do`；只差验收，进 `cc-check`。
-18. 输出必须落到 `review/cc-review-plan.md`、`review/cc-review-ledger.jsonl` 和 `review/cc-review-report.md`，不能只留在聊天里。
+18. 输出必须落到 `review/review-ledger.jsonl`，必要时补 `review/review-findings.json` / `review/review-agent-results.jsonl`；Markdown 报告只通过 `cc-devflow review render` 按需生成。
 
 ## Required Outputs
 
-- `review/cc-review-plan.md`
-- `review/cc-review-ledger.jsonl`
-- `review/cc-review-report.md`
-- `review/cc-review-agent-results.jsonl` when subagent reviewers are used
-- `review/cc-review-findings.json` when later agents need structured findings
+- `review/review-ledger.jsonl`
+- `review/review-agent-results.jsonl` when subagent reviewers are used
+- `review/review-findings.json` when later agents need structured findings
 
 ## Local Kit
 
@@ -50,7 +48,7 @@
 
 ## Stateful Review Plan
 
-`cc-review-plan.md` 必须至少包含：
+`review-started` ledger event 必须至少包含：
 
 - review mode：plan / implementation / mixed
 - previous review state：上次 report、ledger、findings 是否存在
@@ -61,7 +59,7 @@
 - risk lanes：implementation / mixed review 是否覆盖 intent-regression、security-privacy、performance-reliability、contracts-coverage
 - node list：`R001`、`R002` ...，每个节点有 target、method、owner、evidence source、status
 
-Review 过程中每完成一个节点，就追加一条 ledger；不要等最后一次性补记。
+Review 过程中每完成一个节点，就用 `cc-devflow review record-node` 追加一条 ledger；不要等最后一次性补记。
 
 ## SubAgent Review
 
@@ -70,7 +68,7 @@ Review 过程中每完成一个节点，就追加一条 ledger；不要等最后
 调度规则：
 
 - 大范围 / 多文件 / 多 facet review：至少尝试两个独立 reviewer。
-- 小范围 review：至少尝试一个 combined reviewer，除非 `cc-review-plan.md` 写明不需要。
+- 小范围 review：至少尝试一个 combined reviewer，除非 `review-ledger.jsonl` 写明不需要。
 - Plan 节点可分配 strategy、engineering、design、DX、TOC reviewer。
 - Implementation 节点可分配 contract、smell、test、runtime reviewer。
 - 复杂 implementation 节点优先按四类风险 lane 派发 reviewer：intent/regression、security/privacy、performance/reliability、contracts/coverage。

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

@@ -1,6 +1,6 @@
 ---
 name: cc-review
-version: 1.3.0
+version: 2.0.0
 description: Use when a complex requirement, bug fix, plan, or implementation diff needs optional deep multi-round review beyond cc-check. Builds a review plan from prior records and current git/artifact delta, dispatches independent read-only reviewer agents when available, applies a risk-lane review swarm profile for broad implementation diffs, records node results, identifies in-scope code smells, queues user decisions, and reroutes to cc-plan, cc-do, or cc-check.
 triggers:
   - 深度 review 这个方案
@@ -20,22 +20,17 @@ reads:
   - references/e2e-and-plugin-verification.md
   - scripts/collect-review-context.sh
 writes:
-  - path: devflow/changes/<change-key>/review/cc-review-plan.md
+  - path: devflow/changes/<change-key>/review/review-ledger.jsonl
     durability: durable
     required: true
-  - path: devflow/changes/<change-key>/review/cc-review-report.md
-    durability: durable
-    required: true
-  - path: devflow/changes/<change-key>/review/cc-review-ledger.jsonl
-    durability: durable
-    required: true
-  - path: devflow/changes/<change-key>/review/cc-review-agent-results.jsonl
+  - path: devflow/changes/<change-key>/review/review-findings.json
     durability: durable
     required: false
-    when: subagent reviewers are used
-  - path: devflow/changes/<change-key>/review/cc-review-findings.json
+    when: actionable findings need machine consumption
+  - path: devflow/changes/<change-key>/review/review-agent-results.jsonl
     durability: durable
     required: false
+    when: subagent reviewers are used
 effects:
   - optional deep review
   - read-only reviewer agent dispatch
@@ -45,18 +40,18 @@ effects:
 entry_gate:
   - Read planning/design.md or planning/analysis.md when the work is still plan-stage.
   - Read the current diff, task manifest, change metadata, and latest verification evidence when the work is execution-stage.
-  - Read prior cc-review-plan.md, cc-review-report.md, cc-review-ledger.jsonl, and cc-review-findings.json when present.
+  - Read prior `review-ledger.jsonl`, optional `review-findings.json`, optional `review-agent-results.jsonl`, and legacy `cc-review-*` files when present.
   - Use git diff or scripts/collect-review-context.sh to identify content changed since the last review before deciding what to re-review.
   - Classify the review branch as plan, implementation, or mixed before loading detailed references.
-  - Write or refresh cc-review-plan.md before producing findings.
-  - Decide whether nodes need independent reviewer agents before starting node execution; record the decision in cc-review-plan.md.
-  - For broad implementation or mixed reviews, decide whether the risk-lane review swarm profile is required; record used, skipped, or unavailable lanes in cc-review-plan.md.
+  - Start the durable review with `cc-devflow review start` before producing findings; encode selected nodes, skipped nodes, risk lanes, scope, base SHA, and head SHA in the first ledger event.
+  - Decide whether nodes need independent reviewer agents before starting node execution; record the decision in the `review-started` event and optional `review-agent-results.jsonl`.
+  - For broad implementation or mixed reviews, decide whether the risk-lane review swarm profile is required; record used, skipped, or unavailable lanes in `review-ledger.jsonl`.
   - Freeze the requested scope before finding smells; only report smells inside the requirement blast radius or clearly amplified by the current work.
 exit_criteria:
-  - cc-review-plan.md records selected tools, review nodes, skipped nodes with reasons, and checkpoint order.
-  - cc-review-ledger.jsonl appends one record per reviewed node with status, evidence, findings, and follow-up route.
-  - cc-review-agent-results.jsonl records read-only reviewer outputs when subagents are used, or cc-review-report.md records why agents were unavailable or unnecessary.
-  - cc-review-report.md records branch classification, scope, prior-review delta, methods used, node coverage, reviewer-lane coverage, findings triage, user decisions needed, quick fixes, and next route.
+  - review-ledger.jsonl records selected tools, review nodes, skipped nodes with reasons, review order, and final route through CLI events.
+  - review-ledger.jsonl appends one record per reviewed node with status, evidence refs, findings, and follow-up route.
+  - review-agent-results.jsonl records read-only reviewer outputs when subagents are used, or the review ledger records why agents were unavailable or unnecessary.
+  - review-findings.json exists only when later agents need structured findings; human Markdown is rendered on demand with `cc-devflow review render`.
   - Plan-stage reviews record every selected strategy/design/engineering/DX facet as checked, skipped, or blocked.
   - Implementation-stage reviews include diff evidence, code-smell evidence, test and E2E/plugin verification evidence for every selected changed surface.
   - Every in-scope code smell has a concrete recommendation or an explicit skip/defer rationale.
@@ -76,7 +71,7 @@ recovery_modes:
     action: Stop the current pass, restate the correct branch classification, load the matching reference, and restart from the scope freeze.
   - name: progressive-disclosure-reset
     when: The review is drowning in unrelated methods or external review templates.
-    action: Return to cc-review-plan.md, keep only review nodes that are in scope, and continue node-by-node instead of collapsing to a short finding list.
+    action: Return to the latest `review-started` event, keep only review nodes that are in scope, and continue node-by-node instead of collapsing to a short finding list.
 tool_budget:
   read_files: 24
   search_steps: 16
@@ -97,7 +92,7 @@ tool_budget:
 
 写入任何 durable Markdown 或 JSON metadata 前，先运行 `cc-devflow config resolve --format policy`。
 
-- `Output language` 是机器约束，`review/cc-review-report.md` 和 `review/cc-review-findings.json` 中新增的人类可读摘要必须记录并遵守它。
+- `Output language` 是机器约束，`review/review-ledger.jsonl`、`review/review-findings.json` 和 on-demand rendered Markdown 中新增的人类可读摘要必须记录并遵守它。
 - `agent_preferences` 是用户偏好建议，只影响表达方式和结构选择，不覆盖本 Skill 的 Review 边界。
 - 如果配置解析失败，先修配置或向用户说明阻塞，不要用默认语言继续生成正式文档。
 
@@ -223,10 +218,10 @@ Low-confidence notes below `5` stay out of final findings unless they point to c
 Every run follows this loop:
 
 1. Collect prior review state:
-   - previous `cc-review-plan.md`
-   - previous `cc-review-report.md`
-   - previous `cc-review-ledger.jsonl`
-   - previous `cc-review-findings.json`
+   - previous `review-ledger.jsonl`
+   - previous `review-findings.json`
+   - previous `review-agent-results.jsonl`
+   - legacy `cc-review-plan.md` / `cc-review-report.md` / `cc-review-ledger.jsonl` / `cc-review-findings.json` only as fallback
 2. Collect current delta:
    - `git diff <last-reviewed-sha>...HEAD` when a reviewed SHA exists
    - otherwise `git diff <base>...HEAD`
@@ -243,14 +238,12 @@ Every run follows this loop:
    - which nodes need independent subagent review
    - which nodes stay in main thread
    - why any eligible reviewer was skipped
-5. Write `cc-review-plan.md` before findings:
-   - node id
-   - target artifact or code surface
-   - tool/reference to load
-   - reason selected
-   - owner: `main` or reviewer name
-   - check command or evidence source
-   - status: `pending`
+5. Run `cc-devflow review start` before findings:
+   - selected node ids
+   - skipped nodes and reasons
+   - review mode and scope
+   - risk lanes
+   - base/head SHA
 6. Traverse nodes one by one:
    - review the node
    - run the smallest useful check for that node
@@ -268,40 +261,23 @@ When re-reviewing the same file or plan, do not restart from zero. Compare curre
 
 ## Output Contract
 
-Write `review/cc-review-plan.md` before the review pass with:
-
-1. Branch classification and review scope.
-2. Prior review records found.
-3. Current git/artifact delta.
-4. Selected tools and skipped tools with reasons.
-5. Reviewer dispatch plan: agents used, unavailable, skipped, or unnecessary.
-6. Risk-lane coverage for implementation or mixed reviews.
-7. Ordered review nodes and per-node check plan.
-
-Write `review/cc-review-report.md` with:
-
-1. Review branch classification and scope.
-2. Source artifacts read and prior review records used.
-3. Current delta against previous review or base.
-4. Review methods used and methods intentionally skipped.
-5. Node coverage table.
-6. Reviewer dispatch summary, risk-lane coverage, and agent result paths.
-7. Raw finding triage: accepted, merged, downgraded, rejected.
-8. Findings by severity, each with evidence, smell category when relevant, recommendation, and route.
-9. Quick mechanical fixes that can be handled by `cc-do`.
-10. Decision questions still needing user input.
-11. E2E / Browser / Computer Use evidence when applicable.
-12. Final next action.
-
-Append one JSON line to `review/cc-review-ledger.jsonl` per reviewed node:
+Use CLI records as the default durable output:
+
+1. `cc-devflow review start --change <id> --change-key <key> --mode <plan|implementation|mixed> --scope <scope> --base-sha <sha> --head-sha <sha> --selected-node <node> --skipped-node <node:reason> --risk-lane <lane>`
+2. `cc-devflow review record-node --review-id <id> --node-id <node> --target <artifact> --status checked|skipped|blocked --evidence-ref <ref> --finding <id> --next <skill>`
+3. `cc-devflow review add-finding --review-id <id> --finding-id <id> --severity <level> --confidence <1-10> --display-tier <blocking|warning> --path <path> --evidence <evidence> --recommendation <text> --route <skill>`
+4. `cc-devflow review close --review-id <id> --status clean|findings|blocked --blocking-count <n> --warning-count <n> --next <skill>`
+5. `cc-devflow review render --review-id <id> --output <path>` only when a human Markdown report is explicitly needed.
+
+Append one JSON line to `review/review-ledger.jsonl` per review event. A reviewed node event looks like:
 
 ```json
 {"nodeId":"R001","status":"checked","target":"planning/design.md","tool":"engineering","headSha":"...","evidence":["..."],"findings":["F001"],"next":"cc-plan"}
 ```
 
-Write `review/cc-review-findings.json` when findings need machine consumption by later agents.
+Write `review/review-findings.json` only when findings need machine consumption by later agents.
 
-Write `review/cc-review-agent-results.jsonl` when subagents are used. It contains raw reviewer findings plus reviewer identity. The report must say which raw findings were accepted, merged, downgraded, or rejected.
+Write `review/review-agent-results.jsonl` when subagents are used. It contains raw reviewer findings plus reviewer identity. The ledger or rendered report must say which raw findings were accepted, merged, downgraded, or rejected.
 
 ## Finding Rules
 

package/.claude/skills/cc-review/references/e2e-and-plugin-verification.md

@@ -64,7 +64,7 @@ When Codex plugins are part of the expected path:
 
 ## Report Format
 
-Add an E2E section to `cc-review-report.md`:
+Record E2E evidence in `review-ledger.jsonl` and render it into Markdown on demand:
 
 ```markdown
 ## E2E / Plugin Evidence

package/.claude/skills/cc-review/references/implementation-review-branch.md

@@ -41,7 +41,7 @@ For broad or PR-landing diffs, prefer the risk-lane review swarm profile from `r
 3. Performance and reliability
 4. Contracts and coverage
 
-The lanes may map onto the passes below, but they should stay separate in `cc-review-plan.md` and raw reviewer output when separate reviewers are used.
+The lanes may map onto the passes below, but they should stay separate in `review-ledger.jsonl` and raw reviewer output when separate reviewers are used.
 
 ### 1. Contract Fidelity
 
@@ -57,7 +57,7 @@ Check whether implementation matches the frozen plan or investigation:
 
 Use `review-methods.md` smell taxonomy.
 
-If this pass finds duplication, over-complexity, awkward abstraction, branch forests, unclear ownership, or broad architecture cleanup risk, load `cc-simplify` and record it as a selected tool in `cc-review-plan.md`.
+If this pass finds duplication, over-complexity, awkward abstraction, branch forests, unclear ownership, or broad architecture cleanup risk, load `cc-simplify` and record it as a selected tool in `review-ledger.jsonl`.
 
 Look for:
 
@@ -110,7 +110,7 @@ If changed behavior affects README, guides, CLI help, package install, public AP
 Use git and prior review records:
 
 1. Find changed files with `git diff <base>...HEAD --name-only`.
-2. If prior `cc-review-ledger.jsonl` records a reviewed SHA, narrow to `git diff <reviewedSha>...HEAD`.
+2. If prior `review-ledger.jsonl` records a reviewed SHA, narrow to `git diff <reviewedSha>...HEAD`; fall back to legacy `cc-review-ledger.jsonl` only when needed.
 3. Group changed files by behavior surface, not just extension.
 4. Add dependent nodes for direct importers/callers when a shared helper, enum, state shape, API contract, or skill contract changes.
 5. Preserve prior clean nodes only when the target file and dependent contract did not change.
@@ -136,7 +136,7 @@ If the user explicitly asks to fix findings in the same turn, switch to `cc-do`
 
 ## Output Requirements
 
-Add to `cc-review-report.md`:
+Record in `review-ledger.jsonl` and render on-demand Markdown when a human report is needed:
 
 - base branch and diff summary
 - scope check
@@ -149,4 +149,4 @@ Add to `cc-review-report.md`:
 - docs/DX notes
 - final route
 
-Write `cc-review-findings.json` when there are actionable findings.
+Write `review-findings.json` when there are actionable findings that later agents need to consume.

package/.claude/skills/cc-review/references/plan-review-branch.md

@@ -137,7 +137,7 @@ Each planning smell must become a plan finding and route to `cc-plan`.
 
 ## Output Requirements
 
-Add to `cc-review-report.md`:
+Record in `review-ledger.jsonl` and render on-demand Markdown when a human report is needed:
 
 - plan review nodes checked, skipped, or blocked
 - plan reviewer agents used or fallback reason

package/.claude/skills/cc-review/references/review-methods.md

@@ -4,7 +4,7 @@ Use this reference for every `cc-review` run. It defines the shared method libra
 
 ## Method Selection
 
-Select every method needed by the current risk and write the selected methods into `cc-review-plan.md`. This table is a routing map, not a cap.
+Select every method needed by the current risk and write the selected methods into the `review-started` event in `review-ledger.jsonl`. This table is a routing map, not a cap.
 
 | Risk | Method |
 | --- | --- |
@@ -53,7 +53,7 @@ Assignment rules:
 
 - Assign independent reviewers by facet, not by random file chunks.
 - Keep each reviewer packet self-contained: scope, delta, node ids, required artifacts, reference to use, and output schema.
-- Do not ask one reviewer to wait for another reviewer result unless the dependency is explicit in `cc-review-plan.md`.
+- Do not ask one reviewer to wait for another reviewer result unless the dependency is explicit in `review-ledger.jsonl`.
 - Do not assign two reviewers to the same node unless a critical finding needs a second opinion.
 - Main thread validates reviewer evidence before final findings.
 
@@ -66,7 +66,7 @@ downgraded -> real note but not blocking or confidence too low
 rejected   -> out-of-scope, stale, speculative, or contradicted by evidence
 ```
 
-Record these states in `cc-review-report.md` and preserve raw reviewer output in `cc-review-agent-results.jsonl`.
+Record these states in `review-ledger.jsonl` or on-demand rendered Markdown and preserve raw reviewer output in `review-agent-results.jsonl`.
 
 ## Risk-Lane Review Swarm Profile
 
@@ -93,7 +93,7 @@ The main thread owns aggregation:
 
 Use git and prior records to avoid repeating stale work:
 
-1. Find the previous reviewed SHA from `cc-review-ledger.jsonl` or `cc-review-report.md`.
+1. Find the previous reviewed SHA from `review-ledger.jsonl`, falling back to legacy `cc-review-ledger.jsonl` or `cc-review-report.md`.
 2. Compare `git diff <previous-sha>...HEAD` when possible.
 3. If no previous SHA exists, compare against the base branch or reviewed artifact timestamps.
 4. Re-review changed nodes and dependent nodes.