code-review-graph/opencode配置/skill/project-review/SKILL.md

name, description

name	description
project-review	Whole-project or single-feature code review (not diff-based) using graph-wide analysis and objective scoring

Project Review

Review the entire codebase or a single feature/module, independent of the git diff. Two scopes, driven by the user's instruction:

• whole-project: "对项目代码进行全面审查", "全面审查", "整个项目" → review every source file in the graph.
• feature: "审查 <功能/模块> 的代码" (e.g. payment, auth) → review only the code related to the target.

This skill is READ-ONLY. Every finding is presented to the user for a manual fix decision. Never apply code changes, commit, or push.

Token Efficiency Rules

• ALWAYS start with get_minimal_context(task="project review"). Use detail_level="minimal" on all calls; escalate to "standard" only when a metric or finding needs evidence.
• Whole-project deep-read is a sub-agent pipeline, not a main-context loop. 主上下文不逐文件深读 500+ 文件；改为 Step 5.5 并行子代理分组深读。主上下文预算 ≤14 calls + N 子代理（见 Step 5.5）。

Step 0 - Parse the scope

Read the user's instruction and set scope: whole-project (contains 全面/整个项目/所有/all) or feature + target (extract the feature/module keyword). Declare both in the report header.

快速参考：审查 agent 的精简流程指引来自 get_docs_section(section="project-review")（引擎 docs/LLM-OPTIMIZED-REFERENCE.md），该文档已同步 review_data schema（reviewed_files 数组、coverage 全字段透传含三件套字段、metrics 带 note、仅五客观指标）。完整 schema 以本 SKILL.md 与 references/report-schema.md 为准。

Step 1 - Graph ready

1. Call build_or_update_graph_tool() to ensure the graph is current.
2. Call get_minimal_context_tool(task="project review") for stats and community overview.

Step 2 - Architecture map

Call get_architecture_overview_tool(detail_level="minimal") and list_communities_tool(detail_level="minimal") to map the module structure.

Step 3 - High-risk scan (whole-project)

Call get_knowledge_gaps_tool(), get_hub_nodes_tool(), get_bridge_nodes_tool(), find_large_functions_tool() and get_surprising_connections_tool() to locate hotspots, chokepoints, untested areas and odd coupling.

Step 4 - Objective scoring

• whole-project: score_review_tool(all_files=True) scores every source file in the graph.
• feature: locate the target files with semantic_search_nodes_tool(query=<target>) and query_graph_tool(pattern="children_of", target=<target>), then score_review_tool(changed_files=<files>) and get_impact_radius_tool(changed_files=<files>) for the blast radius.
• 指标集约束：报告的 metrics 只透传 score_review_tool 返回的五个客观指标（sql_risk / exception_coverage / redundancy_rate / high_risk_density / vulnerability_risk）。禁止手工追加 requirement_coverage / logic_alignment / llm_trust_boundary / shell_injection / enum_completeness 等 LLM 判定指标；review_data.llm_judged 一律传空 []。

Step 5 - Chain decomposition

Inspect the scored code across eight categories (interface, business, data, utility, error handling, security, performance, observability) and apply the gstack CRITICAL sub-pass (SQL & Data Safety, Race Conditions, LLM Output Trust Boundary, Shell Injection, Enum Completeness). Mark each ✅ / ⚠️ / —.

Step 5.5 - 并行深读流水线（whole-project 强制，覆盖率达标的唯一可行路径）

引擎 v2.5.0 新增 deep_read_plan_tool / save_coverage_index_tool，coverage_tool 增加 gate / include_prior。主上下文无法逐文件深读 500+ 文件，必须用并行子代理分组深读，否则全库覆盖永远卡在 2-5%。覆盖率为文件数口径：已深读文件数 / 总文件数。

目标：全库覆盖 ≥85% 且 高风险覆盖 ≥95%（双目标 gate="both"，standard 档位）且每个深读文件通过三件套质量门禁（①单元完整性=100% ②行覆盖≥95% ③防伪抽验≤15次/轮，见 references/deep-read-pipeline.md §〇）。深读计划按风险权重贪心，85% 的全库计划会先选满全部高风险文件，天然同时逼近高风险 95%。

流程：

a. 调 deep_read_plan_tool(gate="overall", target_coverage=85, include_prior=True)
   → 返回分组清单 groups[{name, weight, files[]}] + remaining_files
   （include_prior=True 自动排除上一轮已深读且未变更的文件，实现增量）
b. 按组并行派发 explore 子代理（每次 4-6 个并行，分多批）。
   每个子代理深读该组**全部**文件，返回（**落盘到临时目录，勿回传大 JSON**）：
   - outputs[]：每文件含 path / total_lines / read_ranges[[s,e]..] /
     semantic_units[{range,kind,name,note}] / findings[]
   - findings[]：每条含 severity/category/confidence/file:line/message/fix，
     **无 file:line 证据的条目视为未深读**（该文件须重读）
   prompt 模板见 references/deep-read-pipeline.md
   ⚠️ **禁止用 `DEEPREAD_CONFIRM: <路径|总行数|已读范围|单元数>` 单行摘要替代结构化 JSON**：
      主代理必须拿到每文件的 `read_ranges`（分段数组）与 `semantic_units`（逐单元
      {range,kind,name}）并落盘，否则 coverage_tool 无法做行/单元门禁，报告会
      "无行覆盖" 且引擎 fail-closed 会全部判缺口。子代理 prompt 必须直接复制
      deep-read-pipeline.md §二 的模板，不得自创简化格式。
c. 每波子代理完成后跑三件套门禁（**B 阶段已落地，引擎原生支持**）：
   - 主代理首选：coverage_tool(deep_read_files=<verified_files>, gate="both+line",
     file_read_ranges=<{rel:[[s,e]..]}>, file_semantic_units=<{rel:[{range,kind,name}]}>)
     → 引擎返回 line_coverage_pct / unit_coverage_pct / line_gap_files / unit_gap_files / unit_exempt_files
   - 引擎不可用时的兜底：python skills/project-review/scripts/aggregate_deep_read.py <repo_root> <落盘目录>
   - line_gap ∪ unit_gap → 补读队列；verified → 计入本轮 deep_read_files
d. 防伪抽验（**强制，每波必做，三件套③**）：
   - 每波子代理完成后立即执行，与 c 门禁同步；**每组抽 2 个文件、每文件抽 2-3 个语义单元**回读比对 note（每波 ≤40 次 read，全审查约 50-72 次分摊到各波）
   - 回读：用 read 打开源文件对应 range，比对子代理上报的 semantic_units.note 是否与实际内容相符
   - 结果落盘 `spot_check_<batch>.json`（schema：groups_sampled / files_sampled / units_sampled / fake_read_found / groups_rereread / samples[{group,file,unit,range,note_match,in_read_ranges}]）
   - 抽到假读 → 该组重读并升级抽验率（同组改抽 2 文件×3 单元）
   - ⚠️ 各波 spot_check 必须聚合后在 Step 8 注入 `review_data.spot_check`（顶层字段），否则报告渲染"未执行 🔴"且 verify-spot-check.ps1 exit 1
e. 主代理汇总全部 verified_files（去重）→
   coverage_tool(deep_read_files=<verified_files>, gate="both+line", include_prior=True) 复算
   （include_prior 自动复用跨轮索引中 SHA 未变的文件及其 read_ranges）
f. 未达标（文件数 <85%/<95% 或 行覆盖 <95% 或 单元有缺口）→
   对 coverage 返回的 priority_deep_read_files / line_gap_files / unit_gap_files 补一轮 → 循环直至全达标
   ⚠️ **禁止降级**：unit_gap_files 或 line_gap_files 非空时，**不得**改回 `gate="both"` 静默跳过三件套；
     必须补轮重读至空，或显式在报告中标注"三件套未达标 🔴"并列出缺口文件。
g. G2：对 silent_files 抽 15% 深读（见 Step 7.5）
h. 报告生成后：save_coverage_index_tool(deep_read_files=<verified_files>, file_read_ranges=<{rel:[[s,e]..]}>)
   → 写 .code-review-graph/coverage-index.json（v2：file + per-file SHA + ranges，SHA 来自 nodes.file_hash）

约束：

• 子代理数量：whole-project 508 文件 ≈ 14-16 组（后端 6 组 / 前端 8 组，见 references/deep-read-pipeline.md 分组表）。
• 质量控制（三件套，必须全部通过才算深读）：
  • ① 单元完整性：semantic_units 与图谱单元差集 = 空（one-to-one 匹配，宽 range 不能冒充；严格模式：Props interface / Type / 小函数也必须逐一列出）。巨型文件（仅当最大单元行占比>80%）豁免，按行覆盖校验。
  • ② 行覆盖：union(read_ranges) / 真实行数 ≥95%（分母为真实文件行数，非图节点 line_end——后者有 ±1 偏差）。
  • ③ 防伪抽验：主代理每波必做，每组抽 2 文件 × 2-3 单元，每波 ≤40 次 read；结果落盘 spot_check 并注入报告。引擎无法防假读，抽样是唯一手段。
  • 每条 finding 必须带 file:line 证据。
• 若引擎工具 deep_read_plan_tool 不可用（旧版本），退化为：先 coverage_tool 取 priority_deep_read_files 手动分组派发。
• 增量语义：include_prior=True 时，变更文件（SHA 不同）自动失效需重读，防止"上轮读过"掩盖新代码。

🔒 诚实声明（三件套③的防伪边界）：防伪抽验的真实性（主代理是否真读了文件）引擎与脚本均无法验证——verify-spot-check.ps1 只能验证声明完整性（抽了、单元数>0、range 落在 read_ranges 内）。真实回读依赖主代理行为准则。此为引擎防伪能力的已知边界（deep-read-pipeline.md §〇）。

Step 6 - Manual adjudication (READ-ONLY)

Present every finding with severity (🔴 blocker / 🟡 major / 🔵 minor), confidence (1-10), file:line and a proposed fix. Group by severity and ask the user per batch: fix / skip / self-fix. 🔴 blockers cannot be batch-skipped. Do not modify code.

Step 7 - Acceptance gate

Any 🔴 blocker → verdict ❌ FAIL. Classify each finding as Ready / Needs Fix / Unusable.

Step 7.5 - 覆盖度自检（必须执行，防"审完了"由感觉决定）

按 CODE_REVIEW_GUIDE_ZH.md §3.5 的覆盖度保障机制，报告前完成三件事：

1. 深读名单完整性（G1）：确认名单外文件是"被评估过"而非"被忽略"；未被任何信号点名的文件记入 "未深读文件清单"，在报告中显式列出。
2. 静默抽检（G2）：调用 coverage_tool 取返回的 silent_files（未被任何信号点名的文件），随机抽 15% 深读；发现 ≥1 major → 该文件升级全量深读，并同社区/同类追加抽检一轮。抽检记录附入报告（抽了几份 / 几个 major / 有无升级）。
3. 三件套质量门禁复核（G1.5）：报告前复核 Step 5.5 的三件套聚合结果——line_gap_files ∪ unit_gap_files 必须为空（已补读至空）；verified_files 与 coverage_tool 的 deep_read_files 一致；防伪抽验记录（抽了几组/几个单元/有无假读）附入报告。
4. 覆盖度计算（G3）：
   • whole-project：调用 coverage_tool(deep_read_files=<本轮实际深读文件>, gate="both+line")，引擎自动计算三重口径（文件数口径 + 三件套质量口径）：
     • 全库覆盖 = coverage_pct（已深读文件数 / 全部源文件数）
     • 高风险覆盖 = high_risk_coverage_pct（已深读高风险文件数 / 信号点名文件数）
     • 双口径门禁（G3）：gate="both+line" 时 target_reached 要求全库 ≥85% 且 高风险 ≥95% 且 行覆盖 ≥95% 且 单元完整性无缺口（标准档位，三件套 AND）。gate="both" 保持原语义（仅前两项）。target_reached=false → 报告顶部标 🔴 覆盖不足。
     • 缺口信息：返回值含 remaining_files_to_target（还差多少文件数）与 priority_deep_read_files（按风险权重降序的待深读文件）——据此驱动 Step 5.5 的补轮深读。
     • 增量：include_prior=True 合并跨轮覆盖索引（.code-review-graph/coverage-index.json）中 SHA 未变的已深读文件。
   • feature（单功能）：调用 coverage_tool(deep_read_files=<本轮实际深读文件>, gate="line+unit", file_read_ranges=<ranges>, file_semantic_units=<units>)——只做行覆盖 ≥95% + 单元完整性无缺口，不做全库/高风险文件数覆盖检查（引擎返回 coverage_pct/high_risk_coverage_pct 为 null，报告只渲染行/单元覆盖区块，不渲染全库/高风险行）。target_reached=false（行/单元未达标）→ 禁止生成报告，执行补读闭环（见下）直至达标。
     • ⚠️ 三件套数据必传（行覆盖非 0 的前提）：feature 主上下文深读每个文件时，必须边读边累积 file_read_ranges={<rel>:[[s,e],...]}（已读行区间）与 file_semantic_units={<rel>:[{"range":[s,e],"kind","name"},...]}（文件内语义单元），再传给 coverage_tool。不传则 fail-closed 行覆盖=0%，报告标"行覆盖 0%"且 verify-line-coverage.ps1 exit 1 拦截。
     • 🔁 补读闭环（硬性，未达标禁止出报告）：若 target_reached=false，不得生成报告。必须对 line_gap_files/unit_gap_files/missing_data_files 列出的文件补读缺失行区间/语义单元，重跑 coverage_tool，直至 target_reached=true。无法读全的文件移出 deep_read_files（line+unit 不看文件数，只保留真正读满 ≥95% 的文件）。报告生成后跑 verify-line-coverage.ps1，exit 1 → 补读重新生成。

将覆盖度结果完整透传到 review_data.coverage（直接把 coverage_tool 返回值全部字段传入：coverage_pct/high_risk_coverage_pct/grade/deep_read_count/total_files/high_risk_total_files/high_risk_deep_count/deep_read_weight/total_weight/target_reached/target/overall_target/high_risk_target/gate/line_coverage_pct/unit_coverage_pct/line_gap_files/unit_gap_files/unit_exempt_files/missing_data_files/remaining_files_to_target/remaining_weight_to_target/priority_deep_read_files/uncovered_files/silent_files/note），不要手挑子集，否则计数字段渲染为 0/0 或 N/A。报告会自动渲染 ## 覆盖度 区块（含行/单元覆盖）。若 line_coverage_pct 为 null（未跑 both+line 或未传三件套），报告会显式标"行覆盖：未执行 🔴"，且 verify-line-coverage.ps1 会 exit 1 拦截。 feature 走 gate="line+unit" 时 coverage_pct/high_risk_coverage_pct 为 null 属正常，勿因 null 误判为失败；reviewed_files 必须传本轮深读文件数组，报告顶部以可折叠列表（details/summary）展示审查文件。

前置健康检查：调用 community_health_tool，若 needs_postprocess=true（nodes.community_id 归属率 <90%），先 code-review-graph postprocess 重建社区归属再计算，否则覆盖度失真。

Step 7.6 - 覆盖度自检验证（必须执行，防"优化没生效"）

当 coverage_tool / community_health_tool / score_review_tool / dedupe_findings_tool / generate_report_tool / deep_read_plan_tool / save_coverage_index_tool 任一工具不可用，或报告缺 ## 覆盖度 区块时，按本步骤自检。机制未生效时禁止用 CLI 兜底继续审查，先修复环境。详见 docs/plans/review-coverage-guarantee-plan.md 第八章。

1. 环境自检（阻断）：确认可用工具含上述 7 件套；缺失 → 检查本地源码 D:\code-review-graph\code-review-graph-main 版本为 2.5.0，opencode.json 与 .mcp.json 均指向 .venv\Scripts\code-review-graph.exe（非 uv run/uvx）。
2. 进程自检：Get-Process code-review-graph, uv 应无残留 serve/uv 进程；残留进程会锁 .venv\Scripts\code-review-graph.exe，导致 uv run 报 os error 32 → MCP 起不来。清理：taskkill /PID <pid> /T /F。
3. 引擎自检：community_health_tool() 应返回 needs_postprocess=false、attribution_pct>=90；coverage_tool(deep_read_files=[...], gate="both+line", file_read_ranges=<ranges>, file_semantic_units=<units>) 应返回 coverage_pct/high_risk_coverage_pct/line_coverage_pct/unit_coverage_pct/line_gap_files/unit_gap_files/unit_exempt_files/target_reached/remaining_weight_to_target/priority_deep_read_files/uncovered_files/silent_files 全字段；deep_read_plan_tool 应返回 groups/planned_files。
4. 恢复路径：杀残留进程 → uv sync（D:\code-review-graph\code-review-graph-main）修复 venv → 重启 opencode 新会话 → 重新执行本步骤 1-3 直到 PASS。

Step 8 - Report

Call generate_report_tool(review_data=<REQUIRED SCHEMA>) to write code-review-report.html and code-review-report.md (default format="both").

报告生成后（Step 8.6 命名自检通过后）必须执行： save_coverage_index_tool(deep_read_files=<本轮全量深读清单>, file_read_ranges=<{rel:[[s,e]..]}>) —— 写跨轮覆盖索引 .code-review-graph/coverage-index.json（v2：file + per-file SHA + ranges，SHA 来自 nodes.file_hash）。下一轮审查 include_prior=True 时自动复用未变更文件及其行区间，实现增量覆盖，多轮后增量归零即全覆盖。

⚠️ review_data 精确 Schema（必须严格遵循，否则报告只剩类别/位置）

工具在 scoring.py::build_report_data 中只读取以下键。用错键名/字段名会静默丢内容。

顶层键（均为可选项，但 findings 缺了就没有问题清单）：

顶层键	值类型	说明
verdict	"PASS" / "FAIL"	结论
scope	str	只允许 "whole-project" / "feature" / "change-level"。❌ 禁止传功能名（如 "evm"）——verify 脚本按此判定是否检查行覆盖/抽验，传错会绕过门禁
tier	str	如 "standard"
timestamp	str	如 "2026-08-06T15:24:47"
files	str	审查文件列表（逗号分隔，兼容字段）
reviewed_files	list[str]	本轮审查的文件数组（如 ["server/src/api/evm_api.rs", ...]；也可传逗号分隔字符串，引擎会自动拆分）。whole-project/feature 必传；报告顶部以可折叠列表（details/summary）展示，缺省时回退 files 逗号拆分
baseline	str	git SHA
quality_score	int/float	0-10
counts	dict	如 {"blocker":0,"major":3,"minor":5}（MD 只读 critical/informational 键）
metrics	dict	{指标名: {grade, value, note}}，值必须是 dict；note 必传（透传 score_review_tool 返回的 note/evidence，否则指标"说明"列为空）。❌ 传扁平标量（如 "sql_risk": 3）会被静默丢弃。仅含五个客观指标（sql_risk/exception_coverage/redundancy_rate/high_risk_density/vulnerability_risk，见 Step 4 指标集约束）；引擎会过滤 blast_radius/objective_grade 等非五指标键
findings	list[dict]	问题清单（必须用 findings，不能用 issues）
manual_review	list[str]	人工复核项
llm_judged	list[str]	保留兼容字段，一律置空 []，不再新增 LLM 判定指标
spot_check	dict	防伪抽验记录（顶层字段，非嵌 coverage）。whole-project/feature 必传，否则报告渲染"防伪抽验：未执行 🔴"且 verify-spot-check.ps1 exit 1。schema：{groups_sampled, files_sampled, units_sampled, fake_read_found, groups_rereread, samples:[{group,file,unit,range,note_match,in_read_ranges}]}
summary	str	审查摘要

findings 每条必须的字段：

字段	说明	反例（会导致丢失）
path	文件路径（与 line 合成 location）	❌ 传合并字符串 location
line	行号（int，与 path 合成 location）	❌ 省略 line 导致无位置
message	问题描述（工具读 summary 或 message）	❌ 用 title/detail
fix	修复建议	❌ 用 title/detail
severity	"blocker"/"major"/"minor"
category	如 "business"/"security"
confidence	int 1-10

完整示例（可直接替换占位复制）

{"verdict": "PASS", "scope": "feature", "tier": "standard", "timestamp": "2026-08-06T15:24:47",
 "files": "server/src/api/evm_api.rs, server/src/domain/evm.rs",
 "reviewed_files": ["server/src/api/evm_api.rs", "server/src/domain/evm.rs"],
 "baseline": "<sha>", "quality_score": 7.5,
 "counts": {"blocker": 0, "major": 1, "minor": 0},
 "metrics": {"sql_risk": {"value": 0, "grade": "good", "note": "全部参数化，无注入风险。"}},
 "findings": [
   {"path": "server/src/services/workflow_service.rs", "line": 111,
    "severity": "major", "category": "business", "confidence": 8,
    "message": "workflow 更新 completion_percentage 后未失效 EVM 缓存，5 分钟 TTL 内显示过期数据。",
    "fix": "在 update_state 中调用 EvmService::invalidate_evm_cache(project_id, None)。"}
 ],
 "manual_review": ["确认 list_evm_cases 无 data_scope 是否为有意设计"],
 "summary": "发现 1 个 major。SQL 全部参数化无注入风险，无 blocker，结论 PASS。"}

常见错误（自查清单）：

• ❌ 用 issues 键 → 工具只读 findings，结果 问题清单（0）
• ❌ finding 用 title/detail → 工具读 message/fix，结果只剩类别+位置
• ❌ finding 直接传 location 字符串 → 工具由 path+line 合成，结果位置为空
• ❌ metrics 传扁平标量（"sql_risk": 0）→ 工具要求 {grade, value, note} dict

Step 8.5 - 生成后自检（必须执行，防止空报告回归）

生成报告后必须打开生成的 .md 文件验证，全部通过才算完成：

1. ## 问题清单（N） 中 N == findings 数量（不是 0）
2. 每条 issue 同时含问题描述、位置、修复建议 三要素（位置形如 `server/...:111`）
3. ## 客观指标 表格存在且非空（若传了 metrics）——若缺失，多为 metrics 值不是 {grade, value, note} dict（扁平标量被静默丢弃），需修正后重新生成
4. ## 客观指标 表恰好 5 行（sql_risk / exception_coverage / redundancy_rate / high_risk_density / vulnerability_risk）——出现其他指标名说明手工注入了 LLM 判定指标，违反 Step 4 指标集约束，需移除后重新生成
5. 若发现缺描述/缺修复建议/问题数=0 → 用上述 schema 修正 review_data 后重新调用 generate_report_tool 覆盖，直到通过

Step 8.6 - 报告命名自检（必须执行，防止报告落错位置/缺时间戳）

生成完成后，对仓库运行命名自检脚本（脚本独立于 code-review-graph CLI，任何版本可用）：

powershell -File "C:\Users\Administrator\.config\opencode\skills\project-review\verify-report.ps1" -Repo <repo_root>

• 退出码 0 → 通过：所有报告都在 docs/reviews/ 且文件名带 -YYYY-MM-DD-HHMMSS 后缀。
• 退出码 1 → 存在根目录残留 code-review-report.*（漏传 output_path 的强信号）。用 -Fix 自动归档，或直接以正确 output_path="docs/reviews/{name}-review-{YYYY-MM-DD-HHMMSS}" 重新调用 generate_report_tool 覆盖，然后重跑脚本确认退出码 0。
• 脚本列出的 historic naming warnings 无需处理（仅提示），但本次生成的报告必须满足规范。

Step 8.7 - 行级覆盖自检（必须执行，防止"无行覆盖还全绿"）

生成完成后，对最新报告运行行覆盖自检脚本（独立于 code-review-graph CLI，任何版本可用）：

powershell -File "C:\Users\Administrator\.config\opencode\skills\project-review\verify-line-coverage.ps1" -Repo <repo_root>

• 退出码 0 → 通过：whole-project/feature 报告含行覆盖字段且 ≥95%（三件套数据完整）。
• 退出码 1 → 阻塞：报告覆盖度区块没有行覆盖（漏跑 gate="both+line"/line+unit 或漏传三件套）或行覆盖 <95%。必须补读（Step 7.5 补读闭环）后重新生成报告，再重跑，直到退出码 0。
• ⚠️ scope 判定：脚本只对 change-level 跳过；自定义 scope 值（如 "evm"、"issues"）只要报告含 ## 覆盖度 区块，同样按行覆盖 ≥95% 检查——scope 传功能名不会绕过门禁。

Step 8.8 - 防伪抽验自检（必须执行，防止"漏抽验还全绿"）

whole-project / feature 审查必须执行防伪抽验（三件套③），并校验报告含抽验记录。生成完成后对最新报告运行：

powershell -File "C:\Users\Administrator\.config\opencode\skills\project-review\verify-spot-check.ps1" -Repo <repo_root>

• 退出码 0 → 通过：报告覆盖度区块含防伪抽验字段且单元数 >0（Step 5.5 抽验已执行并注入 review_data.spot_check）。
• 退出码 1 → 阻塞：报告无防伪抽验字段，或渲染"未执行 🔴"。必须补抽验（Step 5.5 d）+ 注入 spot_check + 重新生成报告后重跑，直到退出码 0。
• ⚠️ scope 判定：同 Step 8.7——只对 change-level 跳过；自定义 scope 值（如 "evm"）含 ## 覆盖度 区块时同样检查抽验。
• 诚实声明：该脚本只能验证抽验声明完整性（抽了、单元数>0），无法验证主代理是否真读了文件——真实回读依赖行为准则，此为引擎防伪能力的已知边界。
• Step 8.6（命名）、Step 8.7（行覆盖）、Step 8.8（防伪抽验）三脚本必须全过才算审查完成。

Archive naming: output the report to docs/reviews/ with output_path=<base>/{scope}-review-{YYYY-MM-DD-HHMMSS} (e.g. docs/reviews/evm-feature-review-2026-08-06-151522) so the filename carries an exact timestamp and avoids overwriting same-day reviews. Scope value examples: full-project (whole project), {feature}-feature (feature), pr-{branch} (change-level). 不传 output_path 时工具默认写到仓库根目录 code-review-report.*——这是违规命名，必须在 Step 8.6 用 verify-report.ps1 检出并修复。

更详细的字段对照和完整模板见 references/report-schema.md。

Output Format

Project Review: N issues (X blocker, Y major, Z minor) — verdict: ✅ PASS / ❌ FAIL. List each issue with severity, confidence, file:line, problem, and proposed fix.

Token Efficiency Rules

• ALWAYS start with get_minimal_context(task="project review") before any other graph tool.
• Use detail_level="minimal" on all calls. Only escalate to "standard" when minimal is insufficient.
• whole-project 深读是子代理流水线（Step 5.5），不是主上下文循环。 主上下文预算 ≤14 tool calls；深读通过并行 explore 子代理（每次 4-6 个）完成，每个子代理返回 deep_read 确认清单 + findings[]（带 file:line 证据）。目标：每轮全库覆盖 ≥80% 且高风险 ≥80%（gate="both"），并通过跨轮索引增量累积。