cc-devflow 4.5.11 → 4.5.12

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

@@ -1,151 +1,9 @@
 # Plan Review Branch
 
-Use this reference when the review target is a plan, investigation handoff, or mixed branch whose plan contract may be wrong.
+Read:
 
-## Intake
+1. `task.md`
+2. relevant roadmap or issue text
+3. affected code/tests/docs
 
-Read, in order:
-
-1. `planning/design.md` or `planning/analysis.md`
-2. `planning/tasks.md`
-3. `planning/task-manifest.json`
-4. `change-meta.json`
-5. related roadmap/spec/docs/code referenced by the plan
-
-If no change directory exists, review the user-provided plan text and clearly mark missing durable artifacts.
-
-## Review Shape
-
-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
-
-Use a native strategy review question set:
-
-- Is this the right problem?
-- Is the stated user/business outcome direct or a proxy?
-- What happens if we do nothing?
-- What does the 12-month ideal look like?
-- What existing code or workflow already solves part of this?
-
-Output:
-
-```text
-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:
-
-- component boundaries
-- data flow and shadow paths
-- state transitions
-- security boundaries
-- rollback shape
-- testability seam
-- parallelization risk
-
-Required diagram for non-trivial plans:
-
-```text
-Entry -> validate -> transform -> persist -> output
-  |        |            |            |          |
- nil     invalid      exception    conflict   stale
- 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.
-
-Check:
-
-- first, second, third thing the user sees
-- loading / empty / error / success / partial states
-- responsive and accessibility intent
-- 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.
-
-Check:
-
-- target developer/operator persona
-- time to first value
-- install/run/debug/upgrade path
-- 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:
-
-1. Current reality tree: symptoms, causes, enabling conditions.
-2. Conflict diagram: why the obvious fix conflicts with a real need.
-3. Future reality tree: what the proposed fix changes and what it may break.
-
-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:
-
-- repeated implementation steps with slight variations
-- parallel data sources
-- task split by technical layer instead of behavior
-- fake abstraction or one-adapter seam
-- missing owner for shared state
-- hand-wavy "handle edge cases" or "add validation"
-
-Each planning smell must become a plan finding and route to `cc-plan`.
-
-## Output Requirements
-
-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
-- plan artifacts read
-- strategy/engineering/design/DX facets used
-- diagrams produced
-- in-scope bad smells
-- decisions needed
-- reroute recommendation
-
-If any plan facet changes the task list or implementation contract, route to `cc-plan`.
+Find scope, architecture, test-strategy, and ambiguity problems. Report findings in the response only. Do not write review files.

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

@@ -1,221 +1,13 @@
-# CC-Review Methods
+# Review Methods
 
-Use this reference for every `cc-review` run. It defines the shared method library. Load branch-specific references for concrete workflow steps.
+Pick only the methods that match the current risk:
 
-## Method Selection
+- diff review
+- test-quality review
+- security review
+- performance review
+- API contract review
+- UI/browser review
+- documentation/PR body review
 
-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 |
-| --- | --- |
-| unclear goal | goal tree |
-| repeated symptom | current reality tree |
-| hidden tradeoff | conflict diagram |
-| 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 `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.
-
-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 `review-ledger.jsonl` or on-demand rendered Markdown and preserve raw reviewer output in `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 `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.
-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
-
-### Goal Tree
-
-Use when the plan has too many proposed actions and not enough outcome clarity.
-
-```text
-GOAL
-├── necessary condition A
-│   ├── measurable signal
-│   └── blocked by
-├── necessary condition B
-└── NOT IN SCOPE
-```
-
-### Current Reality Tree
-
-Use for bugs and recurring failures.
-
-```text
-SYMPTOM
-├── direct cause
-│   └── deeper cause
-├── enabling condition
-└── missing control
-```
-
-### Conflict Diagram
-
-Use when two requirements appear incompatible.
-
-```text
-Objective
-├── Need A -> Want X
-└── Need B -> Want not-X
-Assumption to break: ...
-```
-
-### Future Reality Tree
-
-Use before recommending a non-trivial redesign.
-
-```text
-CHANGE
-├── desired effect
-├── possible negative branch
-│   └── prevention
-└── verification signal
-```
-
-### Logic Tree
-
-Use for implementation reviews.
-
-```text
-Entry point
-├── path A
-│   ├── happy
-│   ├── empty
-│   └── error
-└── path B
-```
-
-## Code Smell Taxonomy
-
-Only report smells inside the current requirement blast radius or smells made worse by the current work.
-
-| Smell | Review question | Preferred fix shape |
-| --- | --- | --- |
-| rigidity | Does a small change force unrelated edits? | move decision to one owner |
-| duplication | Is the same logic repeated with small variations? | reuse existing helper or make one narrow helper |
-| cycle | Do modules know each other's internals? | invert dependency or extract boundary |
-| fragility | Can one change break unrelated behavior? | isolate side effects and add focused tests |
-| obscurity | Is intent hidden behind clever names or control flow? | rename, split, or make data shape explicit |
-| data-clump | Do fields always travel together? | group them into one object/value |
-| unnecessary-complexity | Is abstraction solving a hypothetical future? | delete seam or collapse to direct code |
-
-## Severity
-
-- `critical`: ships wrong behavior, data/security risk, silent failure, broken root cause, or impossible verification.
-- `important`: likely maintenance, test, UX, DX, performance, or operability problem in current scope.
-- `advisory`: good improvement but not required for this change.
-
-## Confidence
-
-- `9-10`: directly verified in code, artifact, command output, UI run, or log.
-- `7-8`: strong evidence from nearby patterns and diff.
-- `5-6`: plausible but needs confirmation; mark as verify-first.
-- `<5`: do not put in main findings unless critical impact.
-
-## Decision Questions
-
-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:
-
-```text
-D<N> - <decision title>
-Evidence: <concrete artifact/path/line/log/UI action>
-Risk: <what breaks if ignored>
-Recommendation: A because <principle>
-Options:
-A) <fix now> (recommended) - impact
-B) <defer> - impact
-C) <skip> - impact
-STOP: wait for the user answer before continuing.
-```
-
-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.
+Each finding needs evidence, impact, recommendation, and route. Do not write process files.

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

@@ -3,24 +3,10 @@
 set -euo pipefail
 
 # ------------------------------------------------------------
-# 收集 cc-review 的增量上下文
+# 收集 cc-review 的 Git 增量上下文，不读取过程文件
 # ------------------------------------------------------------
 
-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/review-ledger.jsonl"
-legacy_ledger="$review_dir/cc-review-ledger.jsonl"
-report="$review_dir/cc-review-report.md"
-plan="$review_dir/cc-review-plan.md"
-findings="$review_dir/review-findings.json"
-legacy_findings="$review_dir/cc-review-findings.json"
+base_ref="${1:-origin/main}"
 
 head_sha="$(git rev-parse HEAD)"
 base_sha=""
@@ -28,60 +14,15 @@ if git rev-parse --verify "$base_ref" >/dev/null 2>&1; then
   base_sha="$(git merge-base "$base_ref" HEAD)"
 fi
 
-reviewed_sha=""
-ledger_for_read="$ledger"
-if [[ ! -f "$ledger_for_read" && -f "$legacy_ledger" ]]; then
-  ledger_for_read="$legacy_ledger"
-fi
-
-if [[ -f "$ledger_for_read" ]]; then
-  reviewed_sha="$(
-    sed -n 's/.*"headSha"[[:space:]]*:[[:space:]]*"\([^"]*\)".*/\1/p' "$ledger_for_read" |
-      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 "$ledger" "$findings" "$plan" "$report" "$legacy_ledger" "$legacy_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"
+if [[ -n "$base_sha" ]]; then
+  git diff --name-status "$base_sha...HEAD"
 else
   git diff --name-status HEAD
 fi
-
-if [[ -f "$ledger_for_read" ]]; then
-  echo
-  echo "RECENT_LEDGER"
-  tail -n 20 "$ledger_for_read"
-fi

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

@@ -40,7 +40,7 @@
 
 1. 现有 `devflow/roadmap.json` / `devflow/ROADMAP.md` / `devflow/BACKLOG.md`
 2. `CLAUDE.md`、`README*`、`TODOS.md`
-3. 项目语言和持久决策：`devflow/specs/INDEX.md`、相关 capability specs、当前 roadmap/backlog、历史 `planning/design.md` / `planning/analysis.md`、`change-meta.json`、长期 design decision
+3. 项目语言和持久决策：`devflow/specs/INDEX.md`、相关 capability specs、当前 roadmap/backlog
 4. 最近相关 docs / specs / plans
 5. 最近相关提交、当前工作树状态、正在推进的 requirement
 6. 现实 forcing functions：deadline、distribution、资源、依赖、当前卡点

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

@@ -35,7 +35,7 @@ writes:
     when: "legacy projects are being migrated into devflow/roadmap.json"
 entry_gate:
   - "Read current roadmap, backlog, related capability specs, and surrounding repo context before proposing direction."
-  - "Load cc-devflow native language and durable-decision sources (`devflow/specs/`, current roadmap/backlog, prior `planning/design.md` or `planning/analysis.md`, and `change-meta.json`) before naming stages, capabilities, users, or backlog items."
+  - "Load cc-devflow native language and durable-decision sources (`devflow/specs/`, current roadmap/backlog, prior `planning/design.md` or `planning/analysis.md`) before naming stages, capabilities, users, or backlog items."
   - "Confirm this is a project-direction problem, not a single requirement execution problem."
   - "Run the Project Direction Gate before evidence-maturity routing: classify the user's goal as founder/business, internal company project, hackathon/demo, open-source/research, learning, side project, infrastructure, or recovery."
   - "Classify planning posture and evidence maturity before selecting the route or forcing questions."
@@ -156,7 +156,7 @@ Builder 模式（hackathon、open-source/research、learning、side-project）
 2. 先判断这是“项目方向问题”还是“单 requirement 执行问题”。
 3. 如果输入是多个独立子系统的混合目标，先拆成阶段和 `RM` 候选；不要继续追问某个子系统的实现细节。
 4. 先做一次上下文扫描，不能跳过现有事实直接写愿景。
-5. 先读取 cc-devflow 原生项目语言与持久决策：`devflow/specs/INDEX.md`、相关 capability specs、`devflow/ROADMAP.md`、`devflow/BACKLOG.md`、历史 `planning/design.md` / `planning/analysis.md` 和 `change-meta.json`；不存在时静默跳过，但术语或决策冲突必须写进 roadmap。
+5. 先读取 cc-devflow 原生项目语言与持久决策：`devflow/specs/INDEX.md`、相关 capability specs、`devflow/ROADMAP.md`、`devflow/BACKLOG.md`；不存在时静默跳过，但术语或决策冲突必须写进 roadmap。
 6. 方向没被批准前，不准把 roadmap 偷偷下放成实现任务。
 
 ## Context Sweep
@@ -165,7 +165,7 @@ Builder 模式（hackathon、open-source/research、learning、side-project）
 
 1. 当前 `devflow/ROADMAP.md` / `devflow/BACKLOG.md` 的主线、版本、已停放事项。
 2. `devflow/specs/INDEX.md` 与相关 capability specs 的边界、状态、open gaps。
-3. 项目语言 / 决策上下文：`devflow/specs/INDEX.md`、相关 capability specs、当前 roadmap/backlog、历史 `planning/design.md` / `planning/analysis.md`、`change-meta.json` 和长期 design decision。
+3. 项目语言 / 决策上下文：`devflow/specs/INDEX.md`、相关 capability specs、当前 roadmap/backlog 和长期 design decision。
 4. `CLAUDE.md`、`README*`、`TODOS.md`、最近相关 docs / specs / plans。
 5. 最近相关提交、当前分支脏状态、正在进行中的 requirement。
 6. 真实 forcing functions：deadline、发布窗口、资源上限、依赖、distribution、adoption / trust / delivery 卡点。

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

@@ -1,5 +1,12 @@
 # CC-Simplify Skill Changelog
 
+## v1.4.2 - 2026-05-13
+
+- replace reviewer-agent JSONL findings with short response-only finding lines
+- keep dedupe and confidence rules without requiring JSON schemas or process files
+- clarify that simplify output is a compact report in the response, not a durable JSON document
+- remove old no-op and verification-report wording from simplify output rules
+
 ## v1.4.1 - 2026-05-10
 
 - make `cc-simplify` itself the explicit trigger for automatic read-only subagent review in ClaudeCode and Codex environments

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

@@ -1,7 +1,17 @@
 ---
 name: cc-simplify
-version: 1.4.1
+version: 1.4.2
 description: "Use when changed code needs an automatic subagent-backed simplification pass for scope drift, reuse, code quality, efficiency, test quality, and confidence-gated smell fixes before cc-check or cc-act."
+reads:
+  - devflow/changes/<change-key>/task.md
+  - current Git diff
+writes:
+  - path: code changes
+    durability: working-tree
+    required: false
+  - path: test changes
+    durability: working-tree
+    required: false
 ---
 
 # CC-Simplify
@@ -30,7 +40,7 @@ ONLY FIX CONFIRMED SMELLS. DO NOT BEAUTIFY BY GUESS.
    - stack signals: `package.json` / `pyproject.toml` / `go.mod` / `Cargo.toml` / etc.
    - test framework signals: `jest` / `vitest` / `pytest` / `go test` / etc.
    - scope flags: API / auth / backend / frontend / migration / docs / release
-   - related `planning/tasks.md` / `change-meta.json` / capability specs
+   - related `task.md` / capability specs
    - already-run verification, if any
 3. 如果变更跨多个互不相关模块，先按模块分组；不要让一个 cleanup pass 变成大扫除。
 4. 只审当前 diff 新增或本次改动扩大后的坏味道。历史债只在它阻挡当前交付或被本次 diff 放大时进入清理范围。
@@ -50,7 +60,7 @@ ONLY FIX CONFIRMED SMELLS. DO NOT BEAUTIFY BY GUESS.
 - 不依赖 repo-local `.codex/agents/*.toml` 自定义 agent 名称来完成核心流程。自定义 agent 可以作为增强，但主流程必须能依赖 Codex 内置 `explorer` / `default` 或宿主内置 subAgent 机制。
 - 只把只读评审交给智能体；主线程负责最终判断和实际编辑。
 - 每个智能体拿到同一份完整 diff、相关任务/设计/spec 路径、当前 repo 根目录。
-- 智能体不能改文件，只输出结构化 findings。
+- 智能体不能改文件，只输出短 findings；不要写报告文件。
 - 如果当前运行时没有子智能体工具，或工具调用被上层策略禁止，主线程按同样清单顺序执行，并在报告里写 `Agents used: no (subagent tool unavailable)`；不要伪造子智能体结果。
 - 小 diff 也要尝试启动子智能体；如果资源或宿主限制不适合三路并行，至少启动一个合并维度的只读 reviewer。
 - 条件 specialist 只在对应 scope 出现时启用；不要为了“完整”启动无关评审。
@@ -66,22 +76,17 @@ ONLY FIX CONFIRMED SMELLS. DO NOT BEAUTIFY BY GUESS.
 ```text
 你是 cc-simplify 的只读评审智能体。不要编辑文件。
 输入：repo root、完整 diff、相关任务/spec 路径、你的评审维度。
-输出：每行一个 JSON finding；没有发现时只输出 NO FINDINGS。
+输出：每行一个 finding；没有发现时只输出 NO FINDINGS。
 没有证据的猜测不要输出为 finding。
 ```
 
-Finding JSONL schema：
+Finding line shape:
 
-```json
-{"severity":"critical|important|minor","confidence":8,"path":"file","line":12,"category":"reuse|scope|quality|efficiency|testing|security|api-contract|release","summary":"...","evidence":"...","fix":"...","fingerprint":"file:12:category","specialist":"name","test_stub":"optional"}
+```text
+severity | confidence | file:line | category | evidence | fix | route
 ```
 
-字段要求：
-
-- 必填：`severity`、`confidence`、`path`、`category`、`summary`、`evidence`、`fix`、`specialist`
-- 可选：`line`、`fingerprint`、`test_stub`
-- `confidence` 用 1-10；低于 5 的 finding 不能进入自动修复列表。
-- `test_stub` 只给能用一个小测试抓住的问题；架构判断不要伪造测试。
+字段要求：`severity`、`confidence`、`file:line`、`category`、`evidence`、`fix`、`route`。`confidence` 用 1-10；低于 5 的 finding 不能进入自动修复列表。
 
 ### 推荐三个智能体
 
@@ -93,7 +98,7 @@ Finding JSONL schema：
 
 1. 是否遗漏了任务要求。
 2. 是否多做了未要求功能。
-3. 是否改变行为、边界或 invariant，却没有同步 `change-meta.json` 或 capability spec。
+3. 是否改变行为、边界或 invariant，却没有同步 `task.md` 或 capability spec。
 4. 是否把 bug 修复伪装成新需求，或把新需求伪装成 cleanup。
 5. 是否应该 reroute：
    - 设计范围变了 -> `cc-plan`
@@ -126,7 +131,7 @@ Finding JSONL schema：
 2. 热路径膨胀：启动、请求、渲染、轮询、事件处理里新增阻塞工作。
 3. 重复 IO / 网络 / API 调用、N+1、整文件读取但只需要局部数据。
 4. missed concurrency：互不依赖的读文件、搜索、请求、验证命令被串行执行。
-5. recurring no-op update：轮询或 reducer 明明没有变化却通知下游。
+5. redundant update：轮询或 reducer 明明没有变化却通知下游。
 6. TOCTOU：先检查文件存在再操作；应直接操作并处理错误。
 7. 内存和生命周期：无界数组/map/cache、listener 未清理、timer 未释放。
 8. 测试坏味道：
@@ -152,13 +157,13 @@ Finding JSONL schema：
 
 ## Phase 3: 汇总和去重 findings
 
-先解析 JSONL；非 JSON 行丢弃，`NO FINDINGS` 表示该 source 没有发现。
+先解析 finding lines；`NO FINDINGS` 表示该 source 没有发现。无法定位文件、证据或修复路径的行丢弃。
 
 Fingerprint 规则：
 
-1. 优先使用 finding 自带 `fingerprint`。
-2. 否则用 `{path}:{line}:{category}`。
-3. 没有 `line` 时用 `{path}:{category}:{summary}`。
+1. 优先用 `{file}:{line}:{category}`。
+2. 没有 `line` 时用 `{file}:{category}:{evidence}`。
+3. 证据相同、修复相同的 finding 合并。
 
 同一 fingerprint 的 finding 合并：
 
@@ -221,7 +226,7 @@ Decision：
 
 1. **代码事实**：打开对应文件和相邻实现，确认问题真实存在。
 2. **使用事实**：用 `rg` 查调用方，确认不是 reviewer 缺上下文。
-3. **需求事实**：对照 `planning/tasks.md`、`change-meta.json`、capability spec，确认没有误删必要行为。
+3. **需求事实**：对照 `task.md`、capability spec，确认没有误删必要行为。
 4. **验证事实**：明确修复后用什么命令或检查证明没有回归。
 
 架构类 finding 还必须过删除测试：想象删除这个模块、helper、wrapper 或 seam。
@@ -283,7 +288,7 @@ Decision：
 - Verification run:
 - Next step: `cc-check` / `cc-act` / `cc-plan` / `cc-investigate`
 
-如果 `cc-simplify` 修改了代码或验证口径，下一步必须回 `cc-check`，不能带旧 report-card 继续 `cc-act`。
+如果 `cc-simplify` 修改了代码或验证口径，下一步必须回 `cc-check`，不能带旧验证结论继续 `cc-act`。
 
 ## Do Not