cc-devflow 4.5.11 → 4.5.12

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

@@ -1,7 +1,7 @@
 ---
 name: cc-review
-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.
+version: 2.1.2
+description: Use when a plan, bug fix, PR, or implementation diff needs review findings. It finds concrete problems and routes them without writing process files.
 triggers:
   - 深度 review 这个方案
   - review 这个复杂需求
@@ -13,65 +13,50 @@ triggers:
   - run cc-review
 reads:
   - PLAYBOOK.md
-  - CHANGELOG.md
   - references/review-methods.md
   - 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/review-ledger.jsonl
-    durability: durable
+  - path: current response
+    durability: ephemeral
     required: true
-  - path: devflow/changes/<change-key>/review/review-findings.json
+  - path: devflow/changes/<change-key>/handoff/pr-brief.md
     durability: durable
     required: false
-    when: actionable findings need machine consumption
-  - path: devflow/changes/<change-key>/review/review-agent-results.jsonl
+    when: review findings must be reflected in PR text
+  - path: devflow/postmortems/incidents/<date>-<change-key>.md
     durability: durable
     required: false
-    when: subagent reviewers are used
+    when: review exposes a recurring failure worth preserving
 effects:
   - optional deep review
   - read-only reviewer agent dispatch
-  - risk-lane finding aggregation
-  - durable findings
+  - finding aggregation
   - 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 `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.
-  - 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.
+  - 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.
+  - 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:
-  - 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.
-  - 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.
+  - Findings are listed first, ordered by severity and backed by concrete file/line, command, diff, UI, log, or missing-evidence proof.
+  - Every finding has impact, recommendation, and route: cc-plan, cc-do, cc-check, cc-act, or stop.
+  - In-scope code smells are either findings, explicit defers, or clean with reason.
+  - If no issues are found, the answer says so and names residual test or evidence risk.
+  - No process file was created.
 reroutes:
   - when: Plan assumptions, scope, architecture, design, or DX contracts are wrong or incomplete.
     target: cc-plan
-  - when: Implementation findings require code, test, docs, or UI behavior changes.
+  - when: Implementation findings require code, test, docs, UI behavior, logs, or PR text changes.
     target: cc-do
   - when: Deep review is clean and only fresh evidence verification remains.
     target: cc-check
 recovery_modes:
-  - name: branch-reclassification
-    when: The review started on the wrong branch type or new evidence shows both plan and implementation need review.
-    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 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.
+  - name: scope-reset
+    when: The review starts drifting into unrelated historical debt.
+    action: Return to the current diff, task.md, or PR scope and discard out-of-scope notes.
 tool_budget:
   read_files: 24
   search_steps: 16
@@ -84,233 +69,60 @@ tool_budget:
 
 ## Role
 
-`cc-review` 是可选的深度 Review 节点。
-
-它不替代 `cc-check`。`cc-check` 负责流程式证据验收和 pass/fail/blocked 裁决；`cc-review` 负责在复杂需求、复杂 bug、架构风险、UI/DX 风险、代码坏味道出现时做更深的多轮审查。
-
-## Runtime Output Policy
+`cc-review` 是可选的深度审查节点。它只做一件事：找出当前范围内真实存在的问题。
 
-写入任何 durable Markdown 或 JSON metadata 前，先运行 `cc-devflow config resolve --format policy`。
-
-- `Output language` 是机器约束，`review/review-ledger.jsonl`、`review/review-findings.json` 和 on-demand rendered Markdown 中新增的人类可读摘要必须记录并遵守它。
-- `agent_preferences` 是用户偏好建议，只影响表达方式和结构选择，不覆盖本 Skill 的 Review 边界。
-- 如果配置解析失败，先修配置或向用户说明阻塞，不要用默认语言继续生成正式文档。
+它不写过程文件，不维护 review 状态机。需要保留的事实进入 Git commit、PR 文件，或者在复发/事故场景进入尸检 incident。
 
 ## Iron Law
 
 ```text
-REVIEW THE RIGHT THING AT THE RIGHT STAGE.
+FIND THE REAL PROBLEM. DO NOT CREATE REVIEW ARTIFACTS.
 ```
 
-计划还没进入实现时，Review 计划。代码已经改了时，Review diff 和运行效果。两者都有时，先 Review 计划合同，再 Review 实现是否兑现合同。
-
-深度 Review 不能靠“最多列 3 个问题”收尾。必须先制定 Review 计划，再逐节点检查、逐节点记录。问题数量由证据决定，不由输出习惯决定。
+Review 的价值在于问题质量，不在于过程记录数量。没有证据就不报；有证据就直接报。
 
 ## Read First
 
-1. `PLAYBOOK.md`
-2. `CHANGELOG.md`
-3. `references/review-methods.md`
-4. Branch-specific reference:
-   - 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
+1. `references/review-methods.md`
+2. Plan review: `references/plan-review-branch.md`
+3. Implementation review: `references/implementation-review-branch.md`
+4. UI/runtime/plugin review: `references/e2e-and-plugin-verification.md`
 
-- 复杂需求或复杂 bug 需要比 `cc-check` 更深的 Review。
-- `cc-plan` 已有方案，但你怀疑范围、根因、架构、测试或 DX 没压实。
-- `cc-do` 已经实现，但你要在进入 `cc-check` 前找设计坏味道、代码坏味道和端到端落地风险。
-- 需要检查僵化、冗余、循环依赖、脆弱性、晦涩性、数据泥团、不必要复杂。
-- UI 或 Codex 插件链路需要用浏览器、电脑操作、日志和点击验证证明实际效果。
-
-不要把每个小改动都送进 `cc-review`。简单、低风险、证据充分的变更直接走 `cc-check`。
+只按触发条件读取参考，不默认打开全部文件。
 
 ## Branch Classifier
 
-先分类，再加载详细方法：
-
-| Branch | Signal | Load |
+| Branch | Signal | Review target |
 | --- | --- | --- |
-| `plan` | 用户说“先别写代码”、只有 `planning/design.md` / `planning/analysis.md`，或没有实现 diff | `plan-review-branch.md` |
-| `implementation` | 当前分支已有代码 diff、review comment、UI 改动、测试改动或用户说“Review 代码” | `implementation-review-branch.md` |
-| `mixed` | 计划和实现都存在，且实现可能偏离计划 | 先 plan，再 implementation |
-
-如果分类不清，先读 change artifacts 和 diff。仍然不清时，用一个 Decision Question 问用户，不要猜。
-
-## Harness Contract
-
-- 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 `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`
-   - 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. 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
-   - 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
-
-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/review-findings.json` only when findings need machine consumption by later agents.
-
-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.
+| `plan` | 用户说先 review 方案、只有 `task.md` / docs / issue | scope, contract, architecture, test strategy |
+| `implementation` | 当前分支已有 code/test/docs diff | diff, behavior, tests, smells, regression risk |
+| `PR` | 用户要求 review PR | PR diff, body accuracy, CI/test proof, merge risk |
+| `mixed` | 方案和实现都变了 | plan contract first, then implementation conformance |
 
 ## Finding Rules
 
-Each finding must include:
+每条 finding 必须包含：
 
 - severity: `critical` / `important` / `advisory`
-- confidence: 1-10
-- scope: why this is inside the current requirement blast radius
-- evidence: concrete path, line, artifact, command, browser action, or log
-- smell: one of `rigidity`, `duplication`, `cycle`, `fragility`, `obscurity`, `data-clump`, `unnecessary-complexity`, or `none`
-- recommendation: exact next move
-- route: `cc-plan`, `cc-do`, `cc-check`, `cc-act`, or `no-op`
-
-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.
+- scope: 为什么属于当前请求范围
+- evidence: 文件行、diff、命令输出、浏览器动作、日志、截图或明确缺失的证据
+- impact: 它会导致什么错误、回归、维护成本或用户问题
+- recommendation: 最小修复动作
+- route: `cc-plan` / `cc-do` / `cc-check` / `cc-act` / `stop`
 
-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.
+代码坏味道包括 rigidity、duplication、cycle、fragility、obscurity、data-clump、unnecessary complexity。范围内发现就报；不在范围内只作为 defer 或不提。
 
-## Progressive Disclosure
+## Subagents
 
-Progressive disclosure controls context size, not review depth. Do not load every reference by default, but do build the full review plan first.
+可以使用只读 reviewer subagent，但输出只在主线程汇总，不写文件。主线程必须验证、去重、降级或拒收 subagent finding。
 
-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.
+## Output
 
-## Exit Rule
+只输出当前回复或 GitHub review，不写过程文件。默认结构：
 
-`cc-review` is complete only when the next route is unambiguous:
+1. Findings: severity, file/line, evidence, impact, fix.
+2. Questions: only when they block the next route.
+3. Risk: residual test or evidence gap.
+4. Route: `cc-plan` / `cc-do` / `cc-check` / `cc-act` / `stop`.
 
-- `cc-plan`: revise design, scope, root cause, UI/DX contract, or task split.
-- `cc-do`: fix implementation, tests, docs, UI behavior, logs, or review findings.
-- `cc-check`: deep review is clean enough for evidence verification.
-- `cc-act`: only when a fresh `cc-check` pass already exists.
-- `no-op`: review found no relevant issue and no downstream action is needed.
+没有问题时直接说 `No findings`，并说明还没验证的风险。

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
 
-Record E2E evidence in `review-ledger.jsonl` and render it into Markdown on demand:
+Report E2E evidence in the review response:
 
 ```markdown
 ## E2E / Plugin Evidence
@@ -74,7 +74,7 @@ Record E2E evidence in `review-ledger.jsonl` and render it into Markdown on dema
 | ... | 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.
+Keep the evidence in the response or PR brief. Later reviews use Git diff, PR text, and current verification output instead of ledger files.
 
 If blocked, include:
 

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

@@ -1,152 +1,12 @@
 # Implementation Review Branch
 
-Use this reference when the review target is code, tests, docs, UI behavior, or a current branch diff.
+Read:
 
-## Intake
+1. current Git diff
+2. `task.md`
+3. changed code and tests
+4. fresh command output when available
 
-Read, in order:
+Review behavior, regression risk, security, reliability, test quality, and code smells inside the current blast radius.
 
-1. current branch and base branch
-2. `git diff <base>...HEAD --stat`
-3. full diff for changed files
-4. `planning/design.md` or `planning/analysis.md`
-5. `planning/tasks.md` and `planning/task-manifest.json`
-6. changed code plus direct importers/callers for enum, state, API, and behavior changes
-
-If no plan exists, infer intent from user request, commits, TODOs, and PR body if present. Mark intent confidence.
-
-## Scope Check
-
-Produce:
-
-```text
-Scope Check: CLEAN | DRIFT DETECTED | REQUIREMENTS MISSING
-Intent: ...
-Delivered: ...
-Diff surface: ...
-```
-
-Out-of-scope files are findings only when they change behavior or expand blast radius.
-
-## 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 `review-ledger.jsonl` and raw reviewer output when separate reviewers are used.
-
-### 1. Contract Fidelity
-
-Check whether implementation matches the frozen plan or investigation:
-
-- required tasks done
-- rejected scope not implemented
-- root cause still true
-- expected spec delta honored
-- behavior visible at public seam
-
-### 2. Code Smell Scan
-
-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 `review-ledger.jsonl`.
-
-Look for:
-
-- copy-paste helper logic
-- broad catch-all errors
-- parameter clumps
-- shallow pass-through modules
-- internal mocks driving production design
-- new branch forests where a data shape would collapse cases
-- hidden state or multiple truth sources
-- cycles between modules
-
-### 3. Structural Risk
-
-Check:
-
-- security and trust boundaries
-- enum/value completeness outside the diff
-- migrations and rollback
-- concurrency and double-submit
-- external service failures
-- logs/metrics for new paths
-
-### 4. Test Quality
-
-Build a coverage map:
-
-```text
-CODE PATHS                         USER/RUNTIME FLOWS
-file.ts                            feature flow
-├── [tested] happy                 ├── [tested] main path
-├── [gap] empty                    ├── [gap] double action
-└── [gap] upstream error           └── [gap] navigate away / timeout
-```
-
-Flag:
-
-- no regression test for changed behavior
-- tests only assert implementation shape
-- tests mock internal modules instead of public seam
-- fixture lies with missing fields or type casts
-- no UI/E2E proof for user-visible change
-
-### 5. Documentation and DX
-
-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 `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.
-
-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:
-
-- mechanical local issue -> `cc-do` with direct fix recommendation
-- architecture/contract issue -> `cc-plan`
-- clean implementation -> `cc-check`
-
-If the user explicitly asks to fix findings in the same turn, switch to `cc-do` behavior after writing the review report.
-
-## Output Requirements
-
-Record in `review-ledger.jsonl` and render on-demand Markdown when a human report is needed:
-
-- 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
-- docs/DX notes
-- final route
-
-Write `review-findings.json` when there are actionable findings that later agents need to consume.
+Findings stay in the response or PR text. Do not write process files.