cc-devflow 4.5.7 → 4.5.9

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

@@ -1,7 +1,7 @@
 ---
 name: cc-review
-version: 1.0.0
-description: Use when a complex requirement, bug fix, plan, or implementation diff needs an optional deep multi-round review beyond cc-check. Routes plan-stage material through strategy/design/engineering/DX review methods, routes execution-stage code through diff/code-quality/E2E review, identifies in-scope code smells, and writes durable cc-review findings before rerouting to cc-plan, cc-do, or cc-check.
+version: 1.3.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 这个方案
   - review 这个复杂需求
@@ -18,27 +18,50 @@ reads:
   - references/plan-review-branch.md
   - references/implementation-review-branch.md
   - references/e2e-and-plugin-verification.md
+  - scripts/collect-review-context.sh
 writes:
+  - path: devflow/changes/<change-key>/review/cc-review-plan.md
+    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
+    durability: durable
+    required: false
+    when: subagent reviewers are used
   - path: devflow/changes/<change-key>/review/cc-review-findings.json
     durability: durable
     required: false
 effects:
   - optional deep review
+  - read-only reviewer agent dispatch
+  - risk-lane finding aggregation
   - durable findings
   - reroute recommendation
 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.
+  - 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.
   - 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-report.md records branch classification, scope, methods used, findings, user decisions needed, and next route.
-  - Plan-stage reviews record strategy/design/engineering/DX facets only when applicable.
-  - Implementation-stage reviews include diff evidence, code-smell evidence, test and E2E/plugin verification evidence when applicable.
+  - 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.
+  - 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.
+  - No artificial finding cap was applied; review stops only when planned nodes are checked, skipped with reason, or blocked.
+  - Main thread validates subagent findings before promoting them to final findings; no subagent output is trusted blindly.
   - The next action is exactly one of cc-plan, cc-do, cc-check, cc-act, or no-op.
 reroutes:
   - when: Plan assumptions, scope, architecture, design, or DX contracts are wrong or incomplete.
@@ -53,11 +76,11 @@ 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 SKILL.md, reload only the branch-specific reference and review-methods.md, then continue with the smallest applicable checklist.
+    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.
 tool_budget:
-  read_files: 12
-  search_steps: 8
-  shell_commands: 10
+  read_files: 24
+  search_steps: 16
+  shell_commands: 16
 ---
 
 # CC-Review
@@ -86,6 +109,8 @@ REVIEW THE RIGHT THING AT THE RIGHT STAGE.
 
 计划还没进入实现时，Review 计划。代码已经改了时，Review diff 和运行效果。两者都有时，先 Review 计划合同，再 Review 实现是否兑现合同。
 
+深度 Review 不能靠“最多列 3 个问题”收尾。必须先制定 Review 计划，再逐节点检查、逐节点记录。问题数量由证据决定，不由输出习惯决定。
+
 ## Read First
 
 1. `PLAYBOOK.md`
@@ -95,6 +120,7 @@ REVIEW THE RIGHT THING AT THE RIGHT STAGE.
    - plan-stage: `references/plan-review-branch.md`
    - implementation-stage: `references/implementation-review-branch.md`
    - UI/runtime/plugin evidence: `references/e2e-and-plugin-verification.md`
+5. When prior review state may exist, run or inspect `scripts/collect-review-context.sh`
 
 ## Use This Skill When
 
@@ -120,25 +146,163 @@ REVIEW THE RIGHT THING AT THE RIGHT STAGE.
 
 ## Harness Contract
 
-- Allowed actions: read artifacts, inspect code and diff, run safe read-only or verification commands, use Browser/Computer Use for behavior proof, write review reports.
-- Forbidden actions: silently rewriting the plan, silently editing production code, turning optional review into mandatory ship gate, or reviewing unrelated historical debt.
+- Allowed actions: read artifacts, inspect code and diff, run safe read-only or verification commands, dispatch read-only reviewer subagents when available, use Browser/Computer Use for behavior proof, write review reports.
+- Forbidden actions: silently rewriting the plan, silently editing production code, turning optional review into mandatory ship gate, reviewing unrelated historical debt, or stopping after a small fixed number of findings while planned nodes remain unchecked.
 - Required evidence: every finding must cite plan text, code path, diff line, command output, browser action, UI state, log line, or explicit missing evidence.
 - Reroute rule: plan contract defects return to `cc-plan`; implementation defects return to `cc-do`; clean deep review proceeds to `cc-check`.
 
+## Independent Reviewer Dispatch
+
+触发 `cc-review` 本身就构成用户对只读 reviewer subAgent 的授权。不要再要求用户补一句“请开启子智能体”。
+
+主线程负责：制定 Review 计划、拆分节点、分配 reviewer、合并 findings、验证证据、去重、决定 quick fix / decision queue / reroute。
+
+只读 reviewer 负责：在独立上下文里审指定节点，不编辑文件，不修改计划，不直接决定最终结论。
+
+### Dispatch Rules
+
+- ClaudeCode 环境：使用可用的 `Task` / subAgent 机制创建只读 reviewer。
+- Codex App / Codex 工具环境：优先使用内置 `explorer` 子智能体；如果只有 `default`，prompt 必须写明只读审查、禁止编辑。
+- 暴露 `spawn_agent` 的 Codex 环境：使用 `spawn_agent(agent_type="explorer", fork_context=false, ...)`。只有在用户明确要求继承完整上下文时才 `fork_context=true`。
+- 不依赖 repo-local 自定义 agent 名称完成核心流程；自定义 agent 只能作为增强。
+- 如果当前运行时没有 subagent 工具，或工具调用被上层策略禁止，主线程按同一节点计划串行执行，并在报告里写 `Agents used: no (subagent tool unavailable)`。
+- subagent 只拿自己的 review packet，不拿主线程完整聊天历史；这样保持独立性。
+- 每个 subagent 必须输出 JSONL findings；没有发现时输出 `NO FINDINGS`。
+- 主线程必须验证 subagent finding 的路径、证据、scope 和置信度，不能因为 reviewer 说了就接受。
+
+### Risk-Lane Review Swarm Profile
+
+复杂实现、跨模块 diff、PR landing 前复审、或用户要求 parallel / swarm review 时，优先把实现节点拆成四类只读风险 lane。小 diff 可以由一个 combined reviewer 覆盖全部 lane，但计划里必须写明。
+
+1. Intent and regression reviewer: 检查 diff 是否兑现意图、是否引入范围外行为漂移、边界和 fallback 是否坏掉、caller/callee 合同是否漂移。
+2. Security and privacy reviewer: 检查 authn/authz、输入验证、注入风险、secret/token/sensitive data 暴露、默认权限扩大、信任未验证数据。
+3. Performance and reliability reviewer: 检查热路径重复 I/O、启动/渲染/请求成本、cleanup 泄漏、retry storm、订阅漂移、排序/竞态/失败处理。
+4. Contracts and coverage reviewer: 检查 API/schema/type/config/flag 不匹配、迁移/兼容 fallout、回归测试缺口、日志/metrics/assertion/error-path 缺失。
+
+这些 lane 是审查视角，不是 finding 配额。主线程必须把 raw findings 合并后再输出：重复项合并，弱证据或 speculative claim 降级或拒收，和冻结意图冲突的 finding 转成 decision question 或 reject。
+
+### Dispatch Heuristics
+
+- Plan review:
+  - Strategy reviewer: outcome, scope, goal tree, do-nothing risk.
+  - Engineering reviewer: architecture, data flow, state, testability, rollback.
+  - Design reviewer: user-visible flows, states, accessibility, visual/interaction risk.
+  - DX reviewer: CLI/API/docs/operator journey, errors, examples.
+  - TOC reviewer: current reality tree, conflict diagram, future reality tree for complex bugs.
+- Implementation review:
+  - Contract reviewer: diff vs plan/investigation contract.
+  - Smell reviewer: rigidity, duplication, cycle, fragility, obscurity, data-clump, unnecessary complexity; may load `cc-simplify`.
+  - Test reviewer: public seam, regression quality, fixture honesty, coverage gaps.
+  - Runtime reviewer: Browser/Computer Use/CLI/log proof for UI or behavior surfaces.
+  - Risk-lane reviewers: intent/regression, security/privacy, performance/reliability, contracts/coverage when a broad diff benefits from parallel independent context.
+
+Large or multi-surface reviews should use at least two independent reviewers when the host supports it. Small reviews should use at least one combined read-only reviewer unless the plan explicitly records why subagent dispatch is unnecessary.
+
+### Reviewer Packet
+
+Each reviewer receives:
+
+```text
+You are a read-only cc-review reviewer. Do not edit files.
+Repo root: <path>
+Review mode: plan | implementation | mixed
+Node ids: <R001,R002>
+Scope: <requirement blast radius>
+Current delta: <base/reviewed sha -> head sha + changed files>
+Required artifacts: <paths>
+Reference to use: <review-methods / plan / implementation / e2e / cc-simplify>
+Output: JSONL findings or NO FINDINGS.
+Finding schema:
+{"nodeId":"R001","severity":"critical|important|advisory","confidence":8,"path":"file","line":12,"smell":"rigidity|duplication|cycle|fragility|obscurity|data-clump|unnecessary-complexity|none","summary":"...","evidence":"...","recommendation":"...","route":"cc-plan|cc-do|cc-check|cc-act|no-op","fingerprint":"...","reviewer":"strategy|engineering|design|dx|toc|contract|smell|test|runtime|intent-regression|security-privacy|performance-reliability|contracts-coverage"}
+```
+
+Low-confidence notes below `5` stay out of final findings unless they point to critical impact. Put those in report notes as leads, not findings.
+
+## Stateful Review Loop
+
+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`
+2. Collect current delta:
+   - `git diff <last-reviewed-sha>...HEAD` when a reviewed SHA exists
+   - otherwise `git diff <base>...HEAD`
+   - changed planning artifacts, changed code, changed tests, changed docs, changed runtime/UI surfaces
+3. Select review tools:
+   - strategy / CEO-style outcome review
+   - engineering review
+   - design review
+   - DX/operator review
+   - TOC root-cause review
+   - code-smell / simplification review
+   - E2E / Browser / Computer Use / logs review
+4. Decide reviewer dispatch:
+   - 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`
+6. Traverse nodes one by one:
+   - review the node
+   - run the smallest useful check for that node
+   - collect subagent JSONL output when assigned
+   - validate and deduplicate reviewer findings
+   - append one ledger record
+   - mark the node `checked`, `skipped`, or `blocked`
+7. Summarize:
+   - quick mechanical fixes
+   - user-decision queue
+   - reroute list
+   - final next skill
+
+When re-reviewing the same file or plan, do not restart from zero. Compare current content with the last reviewed content or SHA, then re-review changed nodes and any dependent nodes made stale by that delta.
+
 ## 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.
-3. Review methods used and methods intentionally skipped.
-4. Findings by severity, each with evidence, smell category when relevant, recommendation, and route.
-5. E2E / Browser / Computer Use evidence when applicable.
-6. Decision questions still needing user input.
-7. Final next action.
+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:
+
+```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/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.
+
 ## Finding Rules
 
 Each finding must include:
@@ -153,14 +317,17 @@ Each finding must include:
 
 Bad smells inside the requested scope are never hidden. Every in-scope smell must produce either a decision question, a routed fix recommendation, or an explicit defer/skip rationale. Ask whether to optimize when the smell is real and the fix is not a purely mechanical local cleanup.
 
+Decision questions are collected after the full independent node pass unless the answer blocks the next node. Present the full decision queue first, then ask the user to confirm decisions one by one. Do not start non-mechanical fixes until those decisions are answered.
+
 ## Progressive Disclosure
 
-Do not load every reference by default.
+Progressive disclosure controls context size, not review depth. Do not load every reference by default, but do build the full review plan first.
 
 1. Always read `review-methods.md`.
 2. Read `plan-review-branch.md` only for plan or mixed reviews.
 3. Read `implementation-review-branch.md` only for implementation or mixed reviews.
 4. Read `e2e-and-plugin-verification.md` only when UI, browser behavior, desktop app behavior, CLI runtime, or Codex plugin chain evidence is relevant.
+5. Read `cc-simplify` only when the review plan selects code-smell, duplication, simplification, or architecture-cleanup nodes.
 
 ## Exit Rule
 

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

@@ -17,6 +17,8 @@ Skip with reason for backend-only, docs-only, or pure planning reviews.
 
 ## Evidence Chain
 
+Each affected path becomes a review node. Do not claim E2E/plugin review is done until each selected path is checked, skipped, or blocked.
+
 1. Identify the user path:
    - page, route, command, app screen, or plugin operation
    - expected visible result
@@ -72,6 +74,8 @@ Add an E2E section to `cc-review-report.md`:
 | ... | Browser / Computer Use / CLI | screenshot, log, command, artifact | pass / fail / blocked |
 ```
 
+Also append one ledger record per flow so a later review can skip unchanged flows or re-open only changed flows.
+
 If blocked, include:
 
 - missing dependency

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

@@ -30,6 +30,19 @@ Out-of-scope files are findings only when they change behavior or expand blast r
 
 ## Diff Review Passes
 
+Turn these passes into review nodes before reporting findings. Every changed file, public behavior, test surface, documentation surface, and UI/runtime flow must belong to a node or have a skip reason.
+
+For complex diffs, assign independent read-only reviewers by facet: contract, smell, test, docs/DX, and runtime. Keep reviewer outputs separate until the main thread validates evidence and merges duplicates.
+
+For broad or PR-landing diffs, prefer the risk-lane review swarm profile from `review-methods.md` before reporting findings:
+
+1. Intent and regression
+2. Security and privacy
+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.
+
 ### 1. Contract Fidelity
 
 Check whether implementation matches the frozen plan or investigation:
@@ -44,6 +57,8 @@ 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`.
+
 Look for:
 
 - copy-paste helper logic
@@ -90,6 +105,25 @@ Flag:
 
 If changed behavior affects README, guides, CLI help, package install, public API, agent skill usage, or examples, check whether docs changed too.
 
+## Delta Node Selection
+
+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`.
+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.
+
+Example:
+
+```text
+R101 implementation.contract.skill-frontmatter
+R102 implementation.smell.review-state
+R103 implementation.tests.distribution
+R104 implementation.docs.workflow-map
+```
+
 ## Fix Policy
 
 `cc-review` does not silently edit code. It writes findings and routes:
@@ -106,6 +140,9 @@ Add to `cc-review-report.md`:
 
 - base branch and diff summary
 - scope check
+- implementation review nodes checked, skipped, or blocked
+- implementation reviewer agents used or fallback reason
+- risk-lane coverage and raw finding triage
 - code smell findings
 - structural findings
 - test and E2E coverage map

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

@@ -16,7 +16,9 @@ If no change directory exists, review the user-provided plan text and clearly ma
 
 ## Review Shape
 
-Run only applicable facets. Do not load every facet when the plan is small.
+First select applicable facets, then create one or more review nodes for each selected facet. Do not load every facet when the plan is small, but do not skip a selected facet merely to keep the answer short.
+
+For complex plans, assign selected facets to independent read-only reviewers when subagent support is available. Strategy, engineering, design, DX, and TOC reviewers should not share intermediate conclusions; the main thread merges their findings after each reviewer returns.
 
 ### 1. Strategy Facet
 
@@ -34,6 +36,12 @@ Output:
 CURRENT -> THIS PLAN -> 12-MONTH IDEAL
 ```
 
+Node examples:
+
+- `plan.strategy.problem-fit`
+- `plan.strategy.outcome-signal`
+- `plan.strategy.do-nothing-risk`
+
 ### 2. Engineering Facet
 
 Review:
@@ -55,6 +63,13 @@ Entry -> validate -> transform -> persist -> output
  empty   wrong type   timeout      duplicate  partial
 ```
 
+Node examples:
+
+- `plan.engineering.boundaries`
+- `plan.engineering.data-flow`
+- `plan.engineering.state-transitions`
+- `plan.engineering.testability`
+
 ### 3. Design Facet
 
 Run only for user-facing UI or interaction flows.
@@ -67,6 +82,12 @@ Check:
 - generic UI or AI slop risk
 - whether live design review will be needed after implementation
 
+Node examples:
+
+- `plan.design.primary-flow`
+- `plan.design.states`
+- `plan.design.responsive-accessibility`
+
 ### 4. DX Facet
 
 Run only for API, CLI, SDK, package, docs, agent skill, MCP, or developer/operator surfaces.
@@ -79,6 +100,12 @@ Check:
 - actionable errors: problem + cause + fix
 - copy-paste examples and escape hatches
 
+Node examples:
+
+- `plan.dx.first-value`
+- `plan.dx.errors`
+- `plan.dx.examples`
+
 ## TOC Root-Cause Pass
 
 For complex bugs, use:
@@ -89,6 +116,12 @@ For complex bugs, use:
 
 If the root cause is not proven, reroute to `cc-investigate`, not `cc-do`.
 
+Record each TOC pass as a separate node so the review can resume:
+
+- current reality tree
+- conflict diagram
+- future reality tree
+
 ## Code Smell Pass In Planning
 
 Plans can contain smells before code exists:
@@ -106,6 +139,8 @@ Each planning smell must become a plan finding and route to `cc-plan`.
 
 Add to `cc-review-report.md`:
 
+- plan review nodes checked, skipped, or blocked
+- plan reviewer agents used or fallback reason
 - plan artifacts read
 - strategy/engineering/design/DX facets used
 - diagrams produced

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
 
-Use only methods that fit the risk:
+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.
 
 | Risk | Method |
 | --- | --- |
@@ -14,6 +14,92 @@ Use only methods that fit the risk:
 | uncertain fix impact | future reality tree |
 | implementation complexity | logic tree and smell scan |
 | UI/runtime mismatch | E2E/plugin verification |
+| code quality or simplification risk | cc-simplify reference plus smell scan |
+| broad implementation diff | risk-lane review swarm profile |
+
+## Review Plan Nodes
+
+Before findings, create ordered nodes:
+
+```text
+R001 plan.strategy.outcome
+  target: planning/design.md
+  method: goal tree
+  check: outcome and scope consistency
+  status: pending
+
+R002 plan.engineering.data-flow
+  target: planning/design.md + referenced code
+  method: engineering facet
+  check: single truth source and state transitions
+  status: pending
+```
+
+Node rules:
+
+- one node reviews one coherent question, artifact, or changed surface
+- every selected method creates at least one node
+- every changed file or user-facing surface is assigned to a node or explicitly skipped
+- every node has an owner: `main` or a named read-only reviewer
+- every node ends as `checked`, `skipped`, or `blocked`
+- no finding limit exists while nodes remain pending
+- when a prior ledger exists, reuse checked nodes only if their target and dependencies did not change
+
+## Independent Reviewer Assignment
+
+Use subagents to preserve independent context when the host supports them.
+
+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 assign two reviewers to the same node unless a critical finding needs a second opinion.
+- Main thread validates reviewer evidence before final findings.
+
+Reviewer result states:
+
+```text
+accepted   -> finding has concrete in-scope evidence
+merged     -> duplicate finding folded into stronger finding
+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`.
+
+## Risk-Lane Review Swarm Profile
+
+Use this profile when a broad implementation diff, PR landing review, or mixed review benefits from independent read-only context. The profile is a default decomposition, not a requirement to manufacture findings.
+
+| Lane | Reviewer question |
+| --- | --- |
+| intent-regression | Does the diff match the intended behavior without extra behavior drift, broken edge cases, fallback loss, or caller/callee contract drift? |
+| security-privacy | Did the diff weaken auth, validation, secret handling, sensitive data boundaries, defaults, or trust of external input? |
+| performance-reliability | Did the diff add duplicate work, hot-path cost, missing cleanup, retry storms, ordering races, or brittle failure handling? |
+| contracts-coverage | Did the diff miss API/schema/type/config/flag alignment, migration fallout, regression tests, logs, metrics, assertions, or error paths? |
+
+Small diffs may use one combined reviewer that covers all lanes. Large or multi-surface diffs should assign separate reviewers for the highest-risk lanes when the host supports subagents.
+
+The main thread owns aggregation:
+
+- Merge duplicate findings under the clearest evidence.
+- Reject style preferences, nits, and speculative concerns with no concrete impact.
+- Downgrade low-confidence notes unless they point to critical impact.
+- Convert intent-unclear claims into decision questions instead of findings.
+- Order final findings by severity, confidence, and current-scope impact.
+
+## Stateful Delta Review
+
+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`.
+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.
+5. Preserve previous clean nodes only when their target content and assumptions are unchanged.
+
+If git cannot identify the delta, mark the delta source as `unknown` and review the full in-scope surface.
 
 ## Thinking Tools
 
@@ -107,7 +193,7 @@ Only report smells inside the current requirement blast radius or smells made wo
 
 ## Decision Questions
 
-Ask only when a finding requires user judgment.
+Ask only when a finding requires user judgment. Do not stop the whole review at the first decision unless that answer blocks the next review node.
 
 Use:
 
@@ -123,4 +209,13 @@ C) <skip> - impact
 STOP: wait for the user answer before continuing.
 ```
 
-Do not batch unrelated issues. One issue, one decision.
+After the node pass, present a decision queue:
+
+```text
+Decision Queue
+├── D1 scope or architecture decision
+├── D2 user-visible behavior decision
+└── D3 test strategy decision
+```
+
+Then ask decisions one by one. Do not batch unrelated issues inside one decision.

package/.claude/skills/cc-review/scripts/collect-review-context.sh

@@ -0,0 +1,80 @@
+#!/usr/bin/env bash
+
+set -euo pipefail
+
+# ------------------------------------------------------------
+# 收集 cc-review 的增量上下文
+# ------------------------------------------------------------
+
+change_dir="${1:-}"
+base_ref="${2:-origin/main}"
+
+if [[ -z "$change_dir" ]]; then
+  echo "Usage: collect-review-context.sh <change-dir> [base-ref]" >&2
+  exit 2
+fi
+
+review_dir="$change_dir/review"
+ledger="$review_dir/cc-review-ledger.jsonl"
+report="$review_dir/cc-review-report.md"
+plan="$review_dir/cc-review-plan.md"
+findings="$review_dir/cc-review-findings.json"
+
+head_sha="$(git rev-parse HEAD)"
+base_sha=""
+if git rev-parse --verify "$base_ref" >/dev/null 2>&1; then
+  base_sha="$(git merge-base "$base_ref" HEAD)"
+fi
+
+reviewed_sha=""
+if [[ -f "$ledger" ]]; then
+  reviewed_sha="$(
+    sed -n 's/.*"headSha"[[:space:]]*:[[:space:]]*"\([^"]*\)".*/\1/p' "$ledger" |
+      tail -n 1
+  )"
+fi
+
+if [[ -z "$reviewed_sha" && -f "$report" ]]; then
+  reviewed_sha="$(
+    sed -n 's/.*Reviewed head SHA:[[:space:]]*`\?\([0-9a-f]\{7,40\}\)`\?.*/\1/p' "$report" |
+      tail -n 1
+  )"
+fi
+
+diff_base="$base_sha"
+if [[ -n "$reviewed_sha" ]] && git rev-parse --verify "$reviewed_sha^{commit}" >/dev/null 2>&1; then
+  diff_base="$reviewed_sha"
+fi
+
+echo "CC_REVIEW_CONTEXT"
+echo "change_dir=$change_dir"
+echo "review_dir=$review_dir"
+echo "base_ref=$base_ref"
+echo "base_sha=${base_sha:-unknown}"
+echo "reviewed_sha=${reviewed_sha:-none}"
+echo "head_sha=$head_sha"
+echo "diff_base=${diff_base:-unknown}"
+
+echo
+echo "PRIOR_REVIEW_FILES"
+for file in "$plan" "$report" "$ledger" "$findings"; do
+  if [[ -f "$file" ]]; then
+    printf 'present %s\n' "$file"
+  else
+    printf 'missing %s\n' "$file"
+  fi
+done
+
+echo
+echo "CHANGED_FILES"
+if [[ -n "$diff_base" ]]; then
+  git diff --name-status "$diff_base...HEAD"
+else
+  git diff --name-status HEAD
+fi
+
+if [[ -f "$ledger" ]]; then
+  echo
+  echo "RECENT_LEDGER"
+  tail -n 20 "$ledger"
+fi