cc-devflow 4.5.13 → 4.5.15

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

@@ -13,6 +13,9 @@ Mode: investigation
 Profile: tiny | standard | deep
 Diagnosis:
 
+Investigation Mode:
+-
+
 Symptom:
 -
 
@@ -31,15 +34,79 @@ Root Cause:
 Evidence Chain:
 -
 
+Feedback Loop Contract:
+- Type:
+- Command / driver:
+- Expected failing signal:
+- Actual failing signal:
+- Symptom match:
+- Runtime / determinism / failure rate:
+- Sharpening plan:
+
+Root Cause Proof Ladder:
+| Level | Evidence | Verdict |
+|-------|----------|---------|
+| L1 Symptom Site |  |  |
+| L2 First Bad State |  |  |
+| L3 Violated Contract |  |  |
+| L4 Original Trigger |  |  |
+| L5 Counterfactual Proof |  |  |
+| L6 Escape Reason |  |  |
+
+Hypothesis Table:
+| Hypothesis | Support | Counter-evidence | Falsification method | Observation | Status |
+|------------|---------|------------------|----------------------|-------------|--------|
+| H1 |  |  |  |  | active |
+
+Boundary Probe Matrix:
+| Boundary | Input | Output | Config / env | State | Verdict |
+|----------|-------|--------|--------------|-------|---------|
+| N/A |  |  |  |  | not-applicable |
+
+Backward Trace Chain:
+- Immediate failure site:
+- Direct caller:
+- Caller chain:
+- Bad value origin:
+- Original trigger:
+- Why symptom-site fix is rejected:
+
+Reference Comparison:
+- Similar working example:
+- Broken path:
+- Differences found:
+- Accepted hypothesis:
+- Ruled-out differences:
+
+Diagnostic Instrumentation:
+- Probe tag:
+- Location:
+- Question answered:
+- Command:
+- Expected signal:
+- Actual signal:
+- Cleanup requirement:
+
 Repair Boundary:
 -
 
+Correct Test Seam:
+- Public seam:
+- Real trigger chain covered:
+- Mock boundary:
+- Private implementation assertions avoided:
+
 Verification:
 -
 
 Prevention:
 -
 
+Diagnose-Only / Reroute:
+- Applies: yes | no
+- Next action:
+- Why no repair task:
+
 Risk / Escalate If:
 -
 
@@ -47,7 +114,7 @@ Risk / Escalate If:
 
 Codex / ClaudeCode must treat this `task.md` as the only repair contract.
 
-- CLI resolver: all workflow commands must run through `.claude/skills/cc-dev/scripts/resolve-cc-devflow.sh` or `.codex/skills/cc-dev/scripts/resolve-cc-devflow.sh`; if it cannot prove `query workflow-context` and `next-change-key`, stop blocked.
+- CLI resolver: all workflow commands must run through `.claude/skills/cc-dev/scripts/resolve-cc-devflow.sh` or `.codex/skills/cc-dev/scripts/resolve-cc-devflow.sh`; if it cannot prove `next-change-key`, stop blocked.
 - Do not generate process files beyond this `task.md`.
 - Complete tasks with `scripts/mark-task-complete.sh --tasks devflow/changes/<change-key>/task.md --task <task-id>`.
 - Stage commit rule: when PDCA or IDCA finishes in the current environment, commit the completed stage to Git.

package/.claude/skills/cc-investigate/references/investigation-contract.md

@@ -7,20 +7,52 @@
 
 ## Minimum Evidence
 
+- investigation mode
 - symptom
 - reproduction path
 - expected vs actual
+- feedback loop contract
 - code path
 - recent change signal
 - prior postmortem signal
+- evidence chain
+- tested hypotheses and falsification results
 - first bad state
 - violated contract
 - original trigger
 - counterfactual proof
 - escape reason
+- boundary probe, backward trace, or reference comparison when applicable
 - repair boundary
+- correct test seam
 - verification command
 
+## Investigation Modes
+
+- `reproduce-first`: stabilize the reported failure before naming root cause.
+- `feedback-loop`: sharpen a slow, broad, or flaky signal before proof.
+- `diff-trace`: inspect recent changes and behavioral breakpoints.
+- `boundary-probe`: inspect every component boundary before localizing repair.
+- `backward-trace`: trace from symptom site to bad value origin and original trigger.
+- `reference-compare`: compare working and broken paths before guessing.
+- `condition-wait`: replace sleeps/timeouts with real completion conditions.
+- `workflow-forensics`: classify artifact, Git, state, tool, permission, or process failure.
+- `performance`: collect baseline/profile/query/bisect evidence.
+- `diagnose-only`: produce evidence handoff, monitoring, human action, or reroute; do not invent repair tasks.
+
+## Root Cause Proof
+
+The contract must climb the ladder:
+
+1. Symptom Site
+2. First Bad State
+3. Violated Contract
+4. Original Trigger
+5. Counterfactual Proof
+6. Escape Reason
+
+Missing first bad state, original trigger, or counterfactual proof means no confirmed repair task. Return an Evidence Request, diagnose-only handoff, or reroute.
+
 ## Output Shape
 
 - `task.md#Root Cause Contract` is the human truth.

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

@@ -1,5 +1,19 @@
 # CC-Plan Skill Changelog
 
+## v3.10.4 - 2026-05-14
+
+- require product discovery before engineering planning
+
+## v3.10.3 - 2026-05-14
+
+- add Second-Move Review before plan approval
+
+## v3.10.2 - 2026-05-14
+
+- restore the planning flow that was over-pruned during artifact minimization: requirement reality, system shape, interface/data contract, abstraction boundary, execution architecture, task contract, and final approval
+- keep decision questions, option comparison, PRD/user-story thinking, and engineering review inside `task.md#Contract Summary` instead of reviving separate process files
+- update the task template and planning contract so `cc-plan` remains artifact-light but still guides multi-round planning
+
 ## v3.10.1 - 2026-05-13
 
 - simplify the planning artifact contract to `task.md` plus Git history

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

@@ -14,7 +14,12 @@
 2. Git commits record Plan completion; do not create process files beyond `task.md`.
 3. Current branch must bind to the full change key before writing durable output.
 4. The task list must let `cc-do` continue without chat memory.
-5. Ask only blocking questions; otherwise choose from repo evidence.
+5. Ask only decisions that change product value, product shape, scope, design, task split, interface, or verification; otherwise choose from repo evidence.
+6. Product/creative questions come before engineering questions when worth or shape is unclear.
+7. Preserve planning thought inside `task.md#Contract Summary`: product/creative discovery, requirement reality, system shape, interface/data contract, abstraction boundary, execution architecture, task contract, Second-Move Review, and final approval.
+8. Non-trivial plans complete Second-Move Review: first good move, simpler move, better architecture, selected move, and rejected tradeoff. Tiny plans still record why the short path is enough.
+9. Non-trivial plans use at least two confirmation rounds unless source evidence already answers one: product/creative confirmation, then engineering/task confirmation.
+10. User-facing decisions use `D<N>` questions with recommendation, options, impact, and STOP.
 
 ## Required Task Fields
 
@@ -29,6 +34,21 @@ Each task block includes:
 - completion evidence
 - commit point if the task closes an execution environment
 
+## Contract Summary Fields
+
+`task.md#Contract Summary` includes:
+
+- Source handoff and repo evidence
+- Product/creative discovery: worth doing, desired product shape, narrowest wedge, 10x/better version, do-nothing consequence
+- Requirement reality
+- Decision questions and answers
+- Planning flow table
+- Second-Move Review when non-trivial
+- Approved direction and non-goals
+- User stories and edge stories
+- Engineering review gate
+- Verification and escalation triggers
+
 ## Exit
 
 Run the smallest relevant validation for the plan artifacts, stage only owned changes, and commit the Plan stage. Then hand off to `cc-do`.

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

@@ -1,6 +1,6 @@
 ---
 name: cc-plan
-version: 3.10.1
+version: 3.10.4
 description: Use when a requirement, roadmap item, or bug needs scope clarification, design decisions, and executable task breakdown before coding starts.
 triggers:
   - 帮我规划这个需求
@@ -25,14 +25,18 @@ effects:
   - roadmap progress sync when a source item exists
   - Git commit after the Plan stage is complete
 entry_gate:
-  - Resolve the CLI with `../cc-dev/scripts/resolve-cc-devflow.sh require query workflow-context next-change-key config` before workflow commands.
+  - Resolve the CLI with `../cc-dev/scripts/resolve-cc-devflow.sh require next-change-key config` before workflow commands.
   - Assign a canonical REQ/FIX change key through `next-change-key` before writing `task.md`.
   - Enforce the Worktree Branch Contract immediately after the change key exists.
-  - Read only the repo evidence needed to decide scope, existing leverage, task boundaries, and verification.
-  - Ask only when the answer changes scope, design, implementation boundary, or verification.
+  - Read repo evidence before asking the user: roadmap handoff, specs, relevant code/tests/docs, recent commits, and existing task truth when present.
+  - Run the planning flow before task generation: product/creative discovery, requirement reality, system shape, interface/data contract, abstraction boundary, execution architecture, task contract, Second-Move Review, and final approval.
+  - Ask with the Decision Question Protocol when the answer changes scope, design, implementation boundary, or verification.
 exit_criteria:
-  - "`task.md#Contract Summary` states the approved solution, non-goals, frozen decisions, work branch, verification expectations, and open assumptions."
+  - "`task.md#Contract Summary` states the approved solution, non-goals, frozen decisions, work branch, user stories, decision questions, planning-flow results, review gate, verification expectations, and open assumptions."
   - "`task.md` contains executable task blocks generated from `assets/TASKS_TEMPLATE.md`."
+  - "Non-trivial plans complete product/creative discovery before engineering design: worth doing, desired product shape, narrowest wedge, 10x/better version, and do-nothing consequence."
+  - "Non-trivial plans complete Second-Move Review before approval: first good move, simpler move, better architecture, selected move, and rejected tradeoff."
+  - "User decisions that changed the plan were asked as D<N> questions and recorded in `task.md`."
   - "No process file is created beyond `task.md`."
   - "Source roadmap progress is synced or explicitly skipped in the final response."
   - "Plan-stage changes are committed to Git before handing off to `cc-do`."
@@ -53,15 +57,15 @@ tool_budget:
 
 - `devflow/changes/<change-key>/task.md`
 
-不要生成额外过程文件或 JSON 文档。Git commit 是阶段历史，`task.md` 是任务真相。
+不要生成额外过程文件。Git commit 是阶段历史，`task.md` 是任务真相。
 
 ## Operating Contract
 
-1. 先用 resolver 找到当前仓库的 `cc-devflow`，并确认支持 `query workflow-context`、`next-change-key`、`config`。
+1. 先用 resolver 找到当前仓库的 `cc-devflow`，并确认支持 `next-change-key`、`config`。
 2. 用 `next-change-key --prefix REQ|FIX --description "..."` 生成 `changeId` 和完整 `changeKey`，不要手动扫描编号。
 3. 分配 change key 后立刻锚定分支：`REQ-003-copy-link` 对应 `REQ/003-copy-link`，`FIX-014-auth-race` 对应 `FIX/014-auth-race`。当前在 default branch 时停止并报告 setup blocker。
-4. 写 `task.md` 前先确认方案。tiny 计划仍要被批准，只是更短。
-5. `task.md` 必须包含 `Contract Summary`、任务列表、验证命令、完成证据、禁止重决策事项和阶段 commit 要求。
+4. 写 task blocks 前先确认方案。tiny 计划仍要过 planning flow，只是更短。
+5. `task.md` 必须包含 `Contract Summary`、决策问题、planning flow、review gate、任务列表、验证命令、完成证据、禁止重决策事项和阶段 commit 要求。
 6. 完成 Plan 后提交 Git commit。下一阶段从 Git history 和 `task.md` 恢复，不靠过程文件。
 
 ```bash
@@ -73,11 +77,74 @@ bash "$DEVFLOW" config resolve --format policy
 
 - 用最小可逆方案解决真实需求，不扩张到假想未来。
 - 缺证据就写 assumption，不伪装成事实。
-- 非 trivial 方案比较 `minimal viable` 和 `ideal architecture`，但推荐必须落到当前仓库可执行边界。
+- 工程计划前先做产品/创意确认：这个问题值不值得做，用户想得到什么体验，最窄可交付楔子是什么，10x / better version 是什么，不做会损失什么。
+- 非 trivial 计划至少经过两轮用户确认：先确认产品价值和形态，再确认工程方案和任务合同；只有 roadmap / spec 已经给出等价证据时才能记录 skip reason。
+- 第一手好方案不能直接冻结；非 trivial 计划必须过 Second-Move Review：先写 first good move，再找 simpler move 和 better architecture，最后选择一个当前可执行的 move。
+- 计划先做上下文和设计判断，再拆 task；不能把架构、接口、字段、测试缝隙留给 `cc-do` 猜。
+- 用户视角必须清楚：真实用户 / operator、status quo、最痛失败场景、最小成功信号和非目标。
 - 行为变更任务按 tracer bullet 写：`[TEST] -> [IMPL] -> [REFACTOR]`，不要水平切层。
 - 每个任务写清目标、文件、依赖、TDD phase、读什么、怎么验证、完成证据。
 - 回归测试不能 defer；缺 seam 时先计划 spike 或设计修正。
 
+## Planning Flow
+
+先把调查和引导结果写进 `task.md#Contract Summary`，再生成任务。不要把这些内容拆成其它过程文件。
+
+1. Product / Creative Discovery：确认这个问题值不值得做、目标体验、最窄楔子、10x / better version、do-nothing consequence；证据不足时先问用户，不先谈实现。
+2. Requirement Reality：确认真实用户 / operator、当前 workaround、最痛失败场景、最小成功信号、非目标。
+3. System Shape：确认现有代码链路、模块归属、状态 / 数据流、复用点、边界外系统和必须保留的不变量。
+4. Interface / Data Contract：确认 public interface、调用方、输入输出、关键字段、错误形态、权限 / 边界和命名来源。
+5. Abstraction Boundary：确认复杂度藏在哪个模块，哪些抽象被拒绝，哪些公共方法必须保持小而深。
+6. Execution Architecture：确认 foundation、core logic、integration、polish/tests 阶段的冻结决策、文件职责、耦合风险和失败恢复。
+7. Task Contract：确认每条 tracer bullet 的 user / edge story、Red test name、public seam、Green minimality guard、refactor candidates 和 2-5 分钟任务粒度。
+8. Second-Move Review：记录 first good move、simpler move、better architecture、selected move 和 rejected tradeoff；tiny 计划可压成一句，非 trivial 计划必须说明为什么没有选择另一个好走法。
+9. Final Approval：展示冻结方案和任务合同摘要；用户批准前不生成执行 task blocks。
+
+`tiny-design` 可以把每轮压成一句话；`full-design` 必须保留足够证据让执行者不二次设计。任一轮 `blocked` 时，只能问一个 blocking question、拆回 roadmap / 多个 REQ/FIX，或记录用户明确接受的人工边界。非 trivial 计划的产品/创意确认和工程方案确认必须分成至少两次确认，不能一次性把所有问题塞给用户。
+
+## Decision Question Protocol
+
+只在答案会改变范围、方案、接口、任务切分或验证口径时提问。能从 repo evidence、roadmap、spec、测试或 git history 确认的，不问用户。
+提问前先做一次 Second-Move Review：这个问题是否能由 repo evidence 回答，是否把用户拉进实现细节，是否有更高质量的问题能一次冻结更多下游决策。
+产品/创意问题优先于工程问题。若“值不值得做”或“做成什么样”仍不清楚，只问产品/创意层 D<N>；不要提前问文件、接口、字段、测试实现。
+
+固定格式：
+
+```text
+D<N> - <decision title>
+Planning object: <REQ/FIX/RM/change key>
+Known evidence: <repo / roadmap / code / test facts>
+Decision needed: <what changes downstream>
+Recommendation: <A/B/C> because <reason>
+Options:
+A) <label> (recommended)
+  Good: <upside>
+  Cost/Risk: <cost or risk>
+B) <label>
+  Good: <upside>
+  Cost/Risk: <cost or risk>
+C) <label, optional>
+  Good: <upside>
+  Cost/Risk: <cost or risk>
+Impact: <what cc-do will do differently>
+STOP: wait for the user answer before continuing.
+```
+
+用户回答后，把决定写入 `task.md#Contract Summary` 的 `Decision Questions`。聊天不是长期真相源。
+
+## Engineering Review Gate
+
+冻结 task blocks 前，在 `task.md#Contract Summary` 里完成轻量 review：
+
+1. Existing leverage map：每个子问题先映射到现有代码、脚本、spec、模板或测试。
+2. Scope challenge：超过 8 个文件、2 个新 service/class、或跨模块连锁时，说明为什么不是过度设计。
+3. Second-Move Review：非 trivial 方案必须比较 first good move、simpler move、better architecture，并说明 selected move 与 rejected tradeoff。
+4. Domain language check：核心名词、文件名、测试名、任务标题对齐项目真相；没有来源就写 assumption。
+5. Interface depth check：公共面小而深，复杂度藏进模块内部，边界 adapter 是具体操作而不是 generic catch-all。
+6. Test seam check：Red 任务从公共接口、调用方流程或用户可见路径证明行为；不要测私有实现细节。
+7. Mock boundary check：只 mock 外部 API、时间、随机性、文件系统或必要数据库边界。
+8. Feedback loop check：为每个行为选定最短可信反馈循环。
+
 ## Required Output
 
 `task.md` 的结构由 `assets/TASKS_TEMPLATE.md` 提供。模板外只允许补充对当前需求必要的事实，不允许新建额外过程文件。

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

@@ -20,9 +20,68 @@ Goal:
 Do Not Do:
 -
 
+Source Handoff:
+- Roadmap / issue / user source:
+- Repo evidence read:
+- Existing leverage:
+- Canonical language:
+
+Product / Creative Discovery:
+- Worth doing because:
+- Desired product shape:
+- Narrowest wedge:
+- 10x / better version:
+- Do-nothing consequence:
+- Product confirmation rounds:
+
+Requirement Reality:
+- User / operator:
+- Status quo workaround:
+- Most painful failure:
+- Smallest success signal:
+- Non-goals:
+
+Decision Questions:
+| ID | Decision | Evidence | Choice | Impact |
+|----|----------|----------|--------|--------|
+| D1 |  |  |  |  |
+
+Planning Flow:
+| Round | Status | Evidence / decision | Opens task? |
+|-------|--------|---------------------|-------------|
+| Product / Creative Discovery | confirmed |  |  |
+| Requirement Reality | confirmed |  |  |
+| System Shape | confirmed |  |  |
+| Interface / Data Contract | confirmed |  |  |
+| Abstraction Boundary | confirmed |  |  |
+| Execution Architecture | confirmed |  |  |
+| Task Contract | confirmed |  |  |
+| Second-Move Review | confirmed |  |  |
+| Final Approval | confirmed |  | yes |
+
+Second-Move Review:
+- First good move:
+- Simpler move:
+- Better architecture:
+- Selected move:
+- Rejected tradeoff:
+
 Approved Direction:
 -
 
+User Stories:
+| ID | Actor | Story | Acceptance | Edge / recovery |
+|----|-------|-------|------------|-----------------|
+| US-001 |  |  |  |  |
+
+Engineering Review Gate:
+- Existing leverage map:
+- Scope challenge:
+- Interface depth:
+- Test seam:
+- Mock boundary:
+- Feedback loop:
+
 Acceptance:
 -
 
@@ -36,7 +95,7 @@ Risk / Escalate If:
 
 ClaudeCode / Codex 执行本计划时，必须把 `task.md` 当成唯一任务合同。
 
-- CLI resolver: all workflow commands must run through `.claude/skills/cc-dev/scripts/resolve-cc-devflow.sh` or `.codex/skills/cc-dev/scripts/resolve-cc-devflow.sh`; if it cannot prove `query workflow-context` and `next-change-key`, stop blocked.
+- CLI resolver: all workflow commands must run through `.claude/skills/cc-dev/scripts/resolve-cc-devflow.sh` or `.codex/skills/cc-dev/scripts/resolve-cc-devflow.sh`; if it cannot prove `next-change-key`, stop blocked.
 - Task selection: use `scripts/select-ready-tasks.sh --tasks devflow/changes/<change-key>/task.md`.
 - Completion: after Red/Green/Refactor evidence and review pass, run `scripts/mark-task-complete.sh --tasks devflow/changes/<change-key>/task.md --task <task-id>`.
 - Stage commit rule: when PDCA or IDCA finishes in the current environment, commit the completed stage to Git.
@@ -47,8 +106,7 @@ DEVFLOW=".claude/skills/cc-dev/scripts/resolve-cc-devflow.sh"
 if [[ ! -f "$DEVFLOW" && -f ".codex/skills/cc-dev/scripts/resolve-cc-devflow.sh" ]]; then
   DEVFLOW=".codex/skills/cc-dev/scripts/resolve-cc-devflow.sh"
 fi
-bash "$DEVFLOW" require query workflow-context next-change-key
-bash "$DEVFLOW" query workflow-context --change <changeId> --change-key <changeKey> --cwd <repo-root> --data-only --no-trace --compact
+bash "$DEVFLOW" require next-change-key
 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"

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

@@ -9,9 +9,33 @@
 5. New change keys come from `cc-devflow next-change-key`.
 6. Branch binds to the full change key before durable output.
 7. User decisions that affect scope, design, or verification are written into `task.md#Contract Summary`.
-8. Placeholder tasks are invalid.
-9. Behavior work uses tracer bullets and TDD unless an exception is recorded.
-10. Roadmap sync, when needed, happens through roadmap files and Git commit, not change metadata.
+8. Planning flow results are written into `task.md#Contract Summary`; removing old process files must not remove planning thought.
+9. Placeholder tasks are invalid.
+10. Behavior work uses tracer bullets and TDD unless an exception is recorded.
+11. Roadmap sync, when needed, happens through roadmap files and Git commit, not change metadata.
+12. Non-trivial plans complete Second-Move Review before approval; the first workable plan is not frozen until a simpler move and a better-architecture move have both been considered.
+13. Non-trivial plans complete product/creative discovery before engineering design; if worth, shape, wedge, or 10x/better version is unclear, ask product questions before implementation questions.
+14. Product/creative confirmation and engineering confirmation are separate rounds unless roadmap/spec evidence already answers one of them and `task.md` records the skip reason.
+
+## Planning Flow
+
+Every non-trivial plan confirms these rounds before task generation:
+
+1. Product/Creative Discovery: worth doing, desired product shape, narrowest wedge, 10x/better version, do-nothing consequence.
+2. Requirement Reality: real user/operator, workaround, painful failure, smallest success signal, non-goals.
+3. System Shape: existing code path, module owner, state/data flow, reuse point, boundary systems.
+4. Interface/Data Contract: public seam, caller, input/output, fields, error shape, permission/boundary.
+5. Abstraction Boundary: where complexity lives, rejected abstractions, public/private method split.
+6. Execution Architecture: foundation/core/integration/polish decisions, file responsibility, failure recovery.
+7. Task Contract: tracer bullets, Red test names, public seams, Green minimality, refactor candidates.
+8. Second-Move Review: first good move, simpler move, better architecture, selected move, and rejected tradeoff.
+9. Final Approval: approved option and task contract summary.
+
+Tiny plans may compress a round to one evidence-backed line. Full designs must preserve enough detail that `cc-do` does not invent architecture, fields, interfaces, or tests.
+
+## Decision Questions
+
+Ask only when the answer changes product value, product shape, scope, design, task split, interface, or verification. Before asking, run Second-Move Review on the question itself: can repo evidence answer it, is it too implementation-shaped for the user, and would a better question freeze more downstream decisions? Product/creative questions come before engineering questions when worth or shape is unclear. Use `D<N>` with known evidence, recommendation, 2-3 mutually exclusive options, impact, and a stop point. Record the answer in `task.md#Contract Summary`.
 
 ## Required Task Fields
 
@@ -28,4 +52,4 @@
 
 ## Review Gate
 
-Before exit, check scope, existing leverage, non-goals, ambiguity, test seam, mock boundary, and failure modes. If the plan is not executable from `task.md`, it is not done.
+Before exit, check product/creative discovery, scope, existing leverage, Second-Move Review, domain language, interface depth, test seam, mock boundary, feedback loop, and failure modes. If the plan is not executable from `task.md`, it is not done.

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

@@ -1,5 +1,11 @@
 # CC-Review Changelog
 
+## 2.2.1 - 2026-05-14
+
+- restore deep review method flow without restoring review process files
+- add node-by-node review, risk-lane coverage, finding aggregation, decision question, plan facet, implementation diff, and test-quality guidance
+- keep plan review output in `task.md` and implementation review output in the response/user-choice loop
+
 ## 2.2.0 - 2026-05-13
 
 - split review exits by branch: plan and investigation reviews write findings directly into `task.md`

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

@@ -11,9 +11,12 @@
 3. 不读取、不生成、不维护过程文件。
 4. Git history 是唯一持久 review 记忆；重复 review 时用 `git diff <old>...HEAD` 缩小范围。
 5. 可用 subagent 时可以派发只读 reviewer；raw output 留在会话里，主线程验证后再进入最终 findings。
-6. 不固定 finding 数量。证据决定输出。
-7. 每条 finding 必须有 evidence、impact、recommendation 和 route。
-8. 计划 review 的结果直接写回 `task.md`；执行 review 的结果先询问用户选择修复方案；只差验收，进 `cc-check`。
+6. 复杂实现或 mixed review 考虑 intent/regression、security/privacy、performance/reliability、contracts/coverage 四类风险 lane。
+7. 按 selected facet 或 changed surface 逐节点检查；每个节点 checked、skipped 或 blocked。
+8. 不固定 finding 数量。证据决定输出。
+9. 每条 finding 必须有 evidence、impact、recommendation 和 route。
+10. 输出前聚合 raw findings：合并重复，降级弱证据，拒收 speculative / out-of-scope / stale findings。
+11. 计划 review 的结果直接写回 `task.md`；执行 review 的结果先询问用户选择修复方案；只差验收，进 `cc-check`。
 
 ## Review Standard
 
@@ -26,6 +29,9 @@
 - 哪些代码坏味道在当前 blast radius 内？
 - 哪些测试、日志、UI 操作或端到端证据缺失？
 - 哪些 finding 必须修，哪些可以 defer，哪些只是 advisory？
+- 哪些节点已经审过，哪些 skipped / blocked，原因是什么？
+- 四类风险 lane 哪些覆盖了，哪些因为 scope 小或工具不可用跳过？
+- subagent findings 哪些被接受、合并、降级或拒收？
 - 下一步为什么是 `cc-plan` / `cc-do` / `cc-check` / `cc-act` / `stop`？
 
 ## Decision Rule

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

@@ -1,6 +1,6 @@
 ---
 name: cc-review
-version: 2.2.0
+version: 2.2.1
 description: Use when a plan, bug fix, PR, or implementation diff needs review findings. Plan reviews write findings into task.md; implementation reviews ask the user to choose a repair option before fixing.
 triggers:
   - 深度 review 这个方案
@@ -17,6 +17,7 @@ reads:
   - references/plan-review-branch.md
   - references/implementation-review-branch.md
   - references/e2e-and-plugin-verification.md
+  - scripts/collect-review-context.sh
 writes:
   - path: current response
     durability: ephemeral
@@ -34,6 +35,7 @@ entry_gate:
   - Classify the review target as plan, implementation, PR, or mixed.
   - Read only the task, PR, diff, code, tests, logs, screenshots, and docs needed to review the requested scope.
   - Use Git history and current diff as the only durable review memory; do not load or create process files.
+  - For repeat reviews, use `git diff <old>...HEAD` or `scripts/collect-review-context.sh` to narrow the delta before re-reviewing.
   - Freeze the requested scope before finding smells; report only issues inside the change blast radius or clearly amplified by it.
   - Subagents are optional read-only reviewers; their raw output stays in the conversation and is not saved to files.
 exit_criteria:
@@ -42,6 +44,8 @@ exit_criteria:
   - Plan or investigation review findings are written into the relevant `task.md` section before exit.
   - Implementation review findings are returned with concrete repair options and a blocking user choice; no repair happens until the user selects an option.
   - In-scope code smells are either findings, explicit defers, or clean with reason.
+  - Selected review facets or changed surfaces are checked, skipped with reason, or blocked; no artificial finding cap was applied.
+  - Subagent findings, when used, are accepted, merged, downgraded, or rejected by the main thread before final output.
   - If no issues are found, the answer says so and names residual test or evidence risk.
   - No process file was created.
 reroutes:
@@ -97,6 +101,21 @@ Review 的价值在于问题质量，不在于过程记录数量。没有证据
 | `PR` | 用户要求 review PR | PR diff, body accuracy, CI/test proof, merge risk |
 | `mixed` | 方案和实现都变了 | plan contract first, then implementation conformance |
 
+## Review Loop
+
+每次 review 都保留深度流程，但不保留过程文件：
+
+1. Classify：判断 plan / implementation / PR / mixed。
+2. Scope Freeze：写清本次 review 的意图、blast radius、明确不审的历史债。
+3. Delta：用 Git、PR diff、`task.md` 和当前命令输出确定相对上次或 base 的真实变化。
+4. Facets：按风险选择 strategy / engineering / design / DX / TOC / contract / smell / test / runtime / docs。
+5. Nodes：把每个 selected facet 或 changed surface 当成一个 review node，在 scratch reasoning 中逐个检查；每个 node 只能 checked、skipped、blocked。
+6. Findings：每个 finding 必须有 evidence、impact、recommendation、route；没有证据的怀疑只能是 residual risk 或 blocked evidence。
+7. Aggregate：合并重复 finding，降级弱证据，拒收 out-of-scope、stale、speculative finding。
+8. Exit：计划问题写 `task.md`；实现问题回对话给修复选项；只差验证进 `cc-check`。
+
+渐进加载只控制读多少上下文，不允许把该审的节点省掉。
+
 ## Exit Contract
 
 - Plan / investigation review: directly update `devflow/changes/<change-key>/task.md` with the review findings, decision options, blocked assumptions, and required task changes. Final response only summarizes what was written and the next route.
@@ -104,6 +123,17 @@ Review 的价值在于问题质量，不在于过程记录数量。没有证据
 - PR review: return findings in the response or GitHub review only; do not write local files.
 - Clean review: say `No findings`, name residual verification risk, and route to `cc-check` or `stop`.
 
+## Risk Lanes
+
+复杂实现、跨模块 diff、PR landing 前复审、或 mixed review 默认考虑四条风险 lane。小 diff 可以由一个 combined pass 覆盖，但必须说明 skip reason。
+
+1. Intent / regression: diff 是否兑现意图，是否引入范围外行为、fallback 退化、caller/callee contract 漂移。
+2. Security / privacy: auth、输入验证、注入、secret、敏感数据、默认权限、外部输入信任边界。
+3. Performance / reliability: 热路径重复 I/O、启动/渲染/请求成本、cleanup 泄漏、retry storm、排序/竞态、失败处理。
+4. Contracts / coverage: API/schema/type/config/flag、迁移 fallout、回归测试、日志、metrics、assertion、error path。
+
+这些是审查视角，不是 finding 配额。
+
 ## Finding Rules
 
 每条 finding 必须包含：
@@ -121,6 +151,27 @@ Review 的价值在于问题质量，不在于过程记录数量。没有证据
 
 可以使用只读 reviewer subagent，但输出只在主线程汇总，不写文件。主线程必须验证、去重、降级或拒收 subagent finding。
 
+Subagent 只拿自己的 review packet：scope、delta、node/facet、需要读取的文件、输出格式。不要把完整聊天历史当作 reviewer 上下文。没有 subagent 工具时，主线程按同样 node/facet 串行检查，并在输出中说明 fallback。
+
+## Decision Questions
+
+只有 finding 需要用户判断时才提问。不要在第一个问题处打断整个 review，除非答案会阻塞下一个 node。
+
+格式：
+
+```text
+D<N> - <decision title>
+Evidence: <file/line/diff/log/UI action>
+Risk: <what breaks if ignored>
+Recommendation: <recommended option and why>
+Options:
+A) <smallest safe fix> - impact
+B) <broader cleanup> - impact
+C) <defer> - risk
+```
+
+Plan / investigation review 的 decision question 写进 `task.md`。Implementation review 的 repair options 留在当前回复，等待用户选择。
+
 ## Output
 
 按 review 类型输出：