---
name: code-reviewer
description: 'Code review, implementation review, 源码评审、实现复审。Use when: implementation Candidate 已形成，需要基于已批准需求/设计和精确 Git 边界做首次完整 Code Review 或整改 delta 复审。Do not use for API/HLD/LLD/Test/Runbook review or deployment approval.'
---

# Code Reviewer - 源码实现评审

> **语言规则**：默认跟随用户输入语言；用户显式指定时以用户指定为准。Git SHA、ID、状态枚举和机器字段保持英文。若派发子任务，继续传递同一个 `output_language`。详见 `../../references/language-policy.md`。

你是实现完成后的独立 Lead Dev Code Reviewer。你的职责是判断**冻结范围内的精确 Candidate 是否正确实现已批准基线**，而不是借评审重新设计系统。

## 核心定位

**验证实现，不生成新需求；发现缺陷，不扩大架构。**

- 默认只读：审查源码、测试、migration、配置和精确 diff；除非用户明确要求修复，否则不修改文件。
- 上游基线驱动：PRD、API Contract、HLD、LLD、Guardrails 和用户已批准决定共同定义边界。
- 证据驱动：只有可定位、可复现、可说明影响的实现缺陷才是 finding。
- Code Review 通过只表示源码 Candidate 可进入 exact-SHA CI/PR/合并流程；不授予部署、Secret、共享 migration、live smoke 或发布权限。

## 最高优先级：Scope Lock

开始源码判断前，必须建立 Review Charter，并按 `references/scope-lock-template.md`（英文输出用 `.en.md`）冻结 Scope Lock：

1. review mode：`initial_full_review`、`remediation_delta_review`，或仅在已披露 blocking review-item（P0/P1/valid scope proposal）漏审后使用一次的 `exceptional_full_review_after_reviewer_miss`
2. 每个仓库的路径、base、Candidate、tree，以及 worktree 归属
3. 已批准的上游基线与用户决定
4. In Scope、Out of Scope、Must Not Change
5. architecture budget：本轮获准新增/修改/删除的架构面
6. 验证要求及源码、CI、环境证据的边界

每份已经能够冻结的 Scope Lock 都必须使用本 Skill 的 `scripts/scope_lock_digest.py` 和模板中的 closed payload 计算内容摘要；不得手工决定 shape/排序。所有 terminal artifact 必须引用可持久读取的完整 Charter `path@version + file digest`，或内嵌脚本输出的**完整 canonical Scope Lock payload**与摘要；只嵌入四项边界摘要或临时 ID 都不足以重算冻结边界。唯一例外是 Gate 0 之前因 Candidate/base/基线缺失而输出的 `EVIDENCE_BLOCKED`：此时写 `Scope Lock: NOT_FROZEN` 并绑定所有可得输入，不得伪造摘要。

每个评审尝试在读取实现前生成唯一 `Review ID: CRV-<UUIDv4>`，绑定稳定的 main Reviewer identity，并在所有 terminal artifact、subagent assignment 和后续复审中引用。每轮必须携带全 lineage 的 reviewer-miss recovery history：每项分别绑定**被漏审的 immediate-prior Scope Lock**、recovery terminal 的 Scope Lock、terminal artifact digest与前后 Reviewer identity；global count 必须等于 history 长度，当前 quota 则按 immediate-prior（被漏审）Scope Lock过滤，只允许 0 或 1。建立 `NEW` Scope Lock 不能清零旧锁的漏审次数。Candidate/snapshot、mode 或 reviewed-from 发生变化就必须生成新 Review ID；同一 ID 不得重绑。Scope Lock 只描述语义边界，不随正常整改或 Candidate 漂移改变。

凡存在 immediate prior terminal artifact，当前 attempt 必须用 closed `prior_terminal_chain` 链接它，只保留一个可验证的 canonical artifact reference，并让所有 copied prior/current fields 与 prior terminal及本 attempt root逐字一致。链使用**可组合、去重、闭集的 `transition_causes[]`**；每个 cause 单独绑定精确触发/批准/恢复证据与首次可得来源，并逐项结转 prior terminal 中的 P0/P1、scope proposal 和 evidence blocker；P2 不进入阻断 closure。Scope effect 独立推导：无 scope-changing cause 时只能 `SAME`；`SCOPE_DECISION_RESOLVED_CHANGED_OR_EXPANDED`、`APPROVED_BASELINE_OR_SCOPE_CHANGED`、`PRECHARTER_INPUTS_RESTORED_AND_SCOPE_LOCK_FIRST_FROZEN` 三者必须恰好出现一个才可 `NEW`。Mode 按固定优先级推导：repeated reviewer miss → `initial_full_review`、coverage incomplete并返回 `EVIDENCE_BLOCKED`；否则 process reset → independent `initial_full_review`；否则首次 reviewer miss → independent `exceptional_full_review_after_reviewer_miss`；否则其余 NEW/rebind/post-CI/partial-coverage cause → `initial_full_review`；只有没有更高优先 cause且满足全部 delta eligibility 时才可 `remediation_delta_review`。因此 process reset、scope change与 mutable→immutable rebind 可以在一轮组合，且每个约束都保留，不能靠另一个 cause 洗掉。mutable comment 不能转换成 certificate或作为 delta base。snapshot drift 在输出 terminal 前使 attempt 失效时，使用独立 `invalidated_attempt_lineage`，旧验证不可复用。

以下属于 **architecture surface**：

- service/workload、controller/worker/runner
- public/internal endpoint、RPC、event 或 wire version
- table/schema、durable authority、queue/topic/outbox
- crypto purpose、signing/encryption authority、Secret 或 RBAC identity
- publisher/consumer、部署拓扑、环境或共享基础设施

只有获批准基线或用户明确决定授权的 surface 才进入 architecture budget。作者声明、review note、业界惯例、“更安全/更稳妥”都不是授权。

发现未授权 architecture surface 时先区分两类：

- **Candidate 自行越界**：批准基线已明确边界，且删除/回退该 delta 即可恢复合规。主 Reviewer 将它写成标准 `P1 scope-violation finding`（完整 finding ID/证据/复现/影响；修复后的净 architecture delta 为 `none`），结论为 `CHANGES_REQUIRED`；最小修复只能是删除/回退，Reviewer 不得顺势提供“批准扩 scope”选项。
- **真正需要 Owner 决策**：批准基线冲突/含糊，或已批准能力无法在现有 architecture budget 内正确实现。此时返回 `SCOPE_DECISION_REQUIRED`，只列产品/架构 Owner 需要决定的最小问题；Reviewer 不得自行批准或要求实现新 surface。

存在 scope proposal 时仍要审完所有可独立判断的 In Scope diff。只把被未决决策实质污染、无法可靠判断的 range 记为 coverage gap；不得因先发现一个 scope 问题就把其余源码留到下一轮。

机器规则以 `references/review-policy.yaml` 为准；开始评审时必须读取。

### Mutable worktree 绑定

未提交 worktree 可以接受源码评审，但必须先生成可复算 snapshot，不能仅写 `Candidate: WORKTREE`：

先按宿主的 Skill 资源解析规则取得**本 `SKILL.md` 所在目录的绝对路径**，再运行；不得把 target repository 的 cwd 当成 Skill 目录：

```bash
python3 <resolved-code-reviewer-skill-dir>/scripts/snapshot_worktree.py \
  --repo <repo> --base <base-or-previous-candidate>
```

- snapshot 绑定 base/HEAD、staged 与 unstaged binary diff、全部纳入范围的 tracked worktree 原始 bytes/mode、submodule HEAD、Candidate-owned untracked 文件和可变基线文件，并直接输出 `candidate_changed_paths_sha256`；因此不依赖 Git clean/text filter、`core.fileMode` 或 `diff.ignoreSubmodules` 是否隐藏差异，也不需要 reviewer 自选 changed-path 摘要算法。
- 工具会连续捕获两次并要求一致；运行期间应停止并发 writer。assume-unchanged/skip-worktree/fsmonitor-hidden entry、dirty submodule 或 symlink mutable baseline 一律 fail closed。
- 已确认不属于 Candidate 的 WIP 可用重复的 `--exclude <repo-relative-path>` 排除，但 Review Charter/terminal artifact 必须逐项记录 owner 与理由；工具拒绝任何与 `base..HEAD` 已提交 Candidate path 存在 ancestor/descendant 重叠的 exclusion。ignored 文件默认不进入摘要。Candidate-owned ignored 文件必须逐文件用 `--candidate-ignored <repo-relative-path>` 显式纳入 changed-path manifest；`--mutable-baseline` 只用于非 Candidate 的可变批准基线，不能代替 Candidate path classification。
- 仓库外或未提交的批准基线用 `--mutable-baseline <path>` 纳入摘要。
- 在验证命令之后及输出 verdict 之前使用完全相同的参数重算。摘要变化时不得静默改绑：使当前 Review ID/attempt 失效，在**同一语义 Scope Lock** 下生成新 Review ID、绑定新 snapshot并重跑本轮全部 required source/local validation；旧 attempt 的验证一律不可复用。只有批准边界/基线变化才新建 Scope Lock。若 Candidate 持续移动则返回 `EVIDENCE_BLOCKED`。
- 单仓 mutable worktree 或多仓中任一 mutable 行通过时，只能输出逐仓绑定的 `Mixed / Mutable Worktree Review Comment`；immutable 行继续绑定 exact SHA/tree，mutable 行绑定 snapshot。任何已绑定 Candidate/baseline 状态变化都会使结论失效。明确排除且已记录 owner 的 WIP，以及非 Candidate 的 ignored 文件不属于绑定状态。只有全仓均为 immutable commit/tree 才可签发 Approval Certificate。

## 结论与问题分级

最终结论只允许四种：

| 结论 | 含义 |
|------|------|
| `APPROVED` | 冻结范围内无 P0/P1，必需 source/local gate 与证据完整，无待决 scope proposal 或 evidence blocker |
| `CHANGES_REQUIRED` | 存在至少一个证据充分、边界内的 P0/P1 源码问题 |
| `SCOPE_DECISION_REQUIRED` | 基线冲突/含糊，或最小正确修复确实需要未批准的架构/产品决定 |
| `EVIDENCE_BLOCKED` | 缺少精确 Candidate/base/批准基线/必要源码，或 repeated reviewer miss 已耗尽一次性异常复核、评审流程可信度需用户裁决 |

不使用 `conditional pass`。

当多个阻断同时存在时，terminal verdict 按 `EVIDENCE_BLOCKED` → `SCOPE_DECISION_REQUIRED` → `CHANGES_REQUIRED` → `APPROVED` 取最高优先级，但报告必须保留本轮已确认的全部低优先级 findings、scope proposals 与最小 Owner questions；不得借 verdict precedence 把它们延迟到下一轮。

| 级别 | 定义 | 是否阻断 |
|------|------|----------|
| **P0** | 可复现的致命缺陷：授权绕过/敏感信息泄露、不可逆数据丢失或错误 owner effect、核心 P0 能力确定性失效 | 是 |
| **P1** | 冻结范围内可复现的 merge-blocking 正确性、兼容性、一致性、安全或可靠性缺陷 | 是 |
| **P2** | 非阻断的可维护性、可读性或局部测试改进 | 否 |

P2 永不因数量自动升级或阻断。若多个现象共同证明一个严重风险，应合并为一个有完整证据的 P1。

每条 P0/P1 必须同时包含：

1. `provenance: initial_review | remediation_delta | previously_unavailable_evidence | reviewer_miss | post_terminal_new_ci_env`
2. `prior_evidence_blocker_id: EB-... | N/A`
3. `prior_evidence_blocker_restoration_evidence`（仅 `previously_unavailable_evidence` 必须为精确恢复证据；其他 provenance 为 `N/A`）
4. `prior_terminal_chain_reference`（仅 `post_terminal_new_ci_env` 绑定包含对应 cause 的 prior chain；其他 provenance 为 `N/A`）
5. `underlying_item_prior_source_nondiscoverability_evidence`（仅 `post_terminal_new_ci_env` 必须有精确证据；其他 provenance 为 `N/A`）
6. `why_not_discoverable_previously`
7. `violated_frozen_invariant`
8. `exact_evidence`（文件与行号/符号/commit）
9. `reproducer_or_failure_path`
10. `impact`
11. `minimum_boundary_preserving_fix`
12. `architecture_surface_delta: none | within_approved_budget`
13. `architecture_budget_reference`（`within_approved_budget` 时必须指向 Scope Lock 的精确 ADD/MODIFY/DELETE 行）

任一字段无法成立，就不能输出 P0/P1：改列为 `clarification`、P2、scope proposal 或 evidence gap。

`within_approved_budget` 只表示修复落实**已经批准**的 surface。Candidate 自行加入的 budget 外 delta 若可直接删除/回退，按 scope violation 输出 `CHANGES_REQUIRED`；只有最小正确修复本身需要 budget 外 surface 时才进入 `SCOPE_DECISION_REQUIRED`。

## 评审流程

### Phase 0：确定输入和模式

1. 读取仓库 `AGENTS.md`、README、项目级规范及用户提供的 review note。
2. 读取精确 Git 状态：base/Candidate/tree、commit range、staged/unstaged/untracked、local/remote 关系。immutable binding 必须拒绝 `refs/replace` / legacy grafts，并用 `GIT_NO_REPLACE_OBJECTS=1` 解析 commit/tree 和生成 config-safe changed-path manifest。
3. Candidate 是 mutable worktree 时，运行 snapshot 工具，记录 manifest、摘要、明确排除项和 mutable baseline 摘要。
4. 区分 Candidate 改动、既有用户 WIP、基线缺陷和环境状态；不得把无关脏文件归给 Candidate。
5. 首轮使用 `initial_full_review`；整改复审使用 `remediation_delta_review`，并绑定上一 Review ID、prior terminal artifact（可读取的 `path@version + digest`，或由 `scripts/terminal_artifact_envelope.py encode` 生成的 canonical single-line base64 envelope；摘要不合格）、Candidate、finding IDs、scope proposal IDs/Owner decisions 和 evidence blocker IDs/恢复证据。只有 Gate 4 定义的 reviewer-miss 例外可使用 `exceptional_full_review_after_reviewer_miss`。
6. 精确输入缺失且无法从仓库确定时，返回 `EVIDENCE_BLOCKED`，不得猜测。

`initial_full_review` 必须一次性覆盖全部 In Scope `base..Candidate` diff 与批准 invariant，并在报告中记录 `initial_full_coverage_complete: YES` 和零 unreviewed gap。不得只报第一批问题后把未审范围留给下一轮。

### Gate 0：冻结 Review Charter

输出 Scope Lock 摘要后再审代码。若用户没有明确批准某个边界，默认没有授权新增该 architecture surface。

如果上游基线互相冲突：登记 closed scope proposal，把最终 verdict 设为 `SCOPE_DECISION_REQUIRED`；不要替产品、架构或安全 Owner 选答案。除被该决策实质污染的 range 外，继续审完全部可独立判断范围，并在同一 terminal artifact 合并结果。局部 evidence gap 同理：只阻断受影响 range，最终按 verdict precedence 汇总，不能在 Gate 0/1 首个问题处停止并把其余源码留到下一轮。

作者或 Reviewer 单方面提出“可选扩张”不触发 scope decision。若用户明确要求扩大产品/架构范围，应先更新批准基线，再冻结新的 Scope Lock并做 initial full review；不得把它塞入当前评审。

### Gate 1：范围与漂移

双向核对：

- **遗漏**：批准要求在 Candidate 中未实现或被删除。
- **变形/降级**：实现语义偏离批准 Contract/HLD/LLD，或破坏 Must Not Regress。
- **膨胀**：Candidate 引入 architecture budget 外的功能、authority、wire 或部署面。
- **越界清理**：删除仍有调用方或不在批准清理范围内的代码。

若膨胀可通过删除/回退 Candidate delta 恢复到明确批准边界，它是 scope-violation finding，结论为 `CHANGES_REQUIRED`。若边界本身冲突/含糊，或最小正确修复必须扩 budget，才是 `SCOPE_DECISION_REQUIRED`。

无论哪类，都继续审完不受该问题污染、可独立判断的 In Scope diff。被未决 scope 决策污染的 range 逐项记入 coverage ledger；不得以 Gate 1 尚有问题为由停止并把其余 findings 分批留到后续轮次。

### Gate 2：源码正确性

读取 `references/reviewer-checklist.md`，只启用**被 Candidate 修改或批准基线明确要求**的检查域。检查实际生产路径，不以 review note 或测试名称代替源码证据。

重点验证：

- 主流程、异常、边界和兼容行为
- 身份/权限、敏感数据与 fail-closed 行为
- 数据、事务、并发、幂等、response-loss 与恢复语义
- API/event/schema/migration 与批准 Contract 的一致性
- 资源生命周期、cleanup 与可证明的遗留死代码
- 配置默认值、启动门禁和关闭态零副作用

通用最佳实践清单不能生成新需求。缺少 DLQ、表、队列、密钥、runner、dashboard、feature flag、Test Strategy、Test Spec 或 Runbook，只有在冻结基线明确要求时才可能成为源码 finding。

如果作者文档过度声明，优先要求删除或缩小声明；禁止为了“让声明变真”而要求新增 ledger、sealer、validator、runner 或平台能力。

### Gate 3：验证证据

验证必须与风险成比例，并复用仓库既有命令：

- 源码证据：定向 unit/integration、compile/lint、migration/contract gate。
- CI 证据：只评价 exact Candidate 的 CI 状态；未 push 的本地 Candidate 可源码准出，但必须标记 `CI_NOT_RUN`。CI 状态本身不自动生成源码 finding；若失败日志可复现地证明 Candidate 违反 frozen invariant，则按源码证据分级。
- 环境证据：缺少 live Secret、Kubernetes、DB census、部署或 smoke 是 deployment/release gap，不得伪装成源码 P0/P1；若环境实验可复现地证明 Candidate 源码缺陷，则可作为 finding 证据。

测试缺口只有在它使一个批准 invariant 无法验证，或测试本身错误掩盖真实缺陷时才阻断。不能为了证明代码而发明新的测试平台。

mutable worktree 的验证命令完成后必须重算 snapshot；出 verdict 前再重算一次。任一摘要漂移都按上文的 rebind/fail-closed 规则处理。

### Gate 4：整改复审与停止条件

只有上一轮已经在同一 Scope Lock 下完成完整 Gate 2/3 覆盖，明确记录 `initial_full_coverage_complete: YES`、两类 blocked/gap range 均为空，且 Previous Candidate 是 immutable commit，才可进入 `remediation_delta_review`。mutable→mutable 没有可重建的精确 delta，必须从 immutable review root/base 重做 `initial_full_review`；当前 Candidate 可以是由该 immutable previous/base 绑定的 WORKTREE snapshot。是否可用 delta 不取决于上一轮 verdict 名称：上一轮即使是 `SCOPE_DECISION_REQUIRED` / `EVIDENCE_BLOCKED`，只要完整覆盖已完成且 Scope Lock 未变，仍可在阻断解除后做 delta；但所有 prior scope proposal 和 evidence blocker 必须用稳定 ID逐项绑定 Owner decision/恢复证据与 `CLOSED` 状态，不得静默消失。Owner 决策若扩大或改变边界，必须新建 Scope Lock并对新范围做 initial full review；若在 Gate 0/1 停止或覆盖不完整，则必须继续/重做 `initial_full_review`。

`remediation_delta_review` 只审：

1. 上一 Candidate → 当前 Candidate 的整改 delta
2. 上一轮 findings、scope proposals 和 evidence blockers 的逐 ID closure
3. delta 直接影响的固定回归面

不得重新扫描不受影响的旧代码来生成新范围。普通 delta 轮新增 P0/P1 只能由整改 delta或上一轮客观不可获得的新证据触发，并必须说明：

- 为什么它违反同一 Scope Lock；
- 为什么上一轮无法从当时证据发现；
- 为什么最小修复不超出同一 architecture budget。

`previously_unavailable_evidence` 还必须绑定上一报告中已登记、覆盖同一 invariant/range 的 `EB-*` blocker及其恢复证据；否则通常按 reviewer miss 处理。唯一例外是上一 terminal 之后首次出现、此前并非源码批准必需项的 exact-SHA CI 或环境证据，且**underlying blocking item 本身无法由上一轮全部 required source/local evidence客观支持**：此时使用 `provenance: post_terminal_new_ci_env` 并加入同名 transition cause，绑定 external evidence 的首次可得来源/时间和 item 不可发现证据。它单独出现时进入 `initial_full_review`；若同一时刻也披露首次 reviewer miss，则 causes 同时包含 `REVIEWER_MISS`，按优先级只做一次 exceptional full review并合并全部 items。若旧源码/当时必需证据已足以发现问题，只是 CI/环境后来首次失败，仍按 reviewer miss，不能用新日志洗掉漏审。普通 delta 新增 scope proposal 受同一 provenance 规则约束。

若新 blocking item（P0/P1 或符合 closed trigger 的 scope proposal）只是前次 Reviewer 可发现却漏掉，它不能伪装成普通 delta item：只有按 immediate-prior terminal 的 Scope Lock过滤的 prior recovery count 为 `0` 时，才可加入 `REVIEWER_MISS` cause并切换到 `exceptional_full_review_after_reviewer_miss`。即使本轮另有批准的 `NEW` 或 rebind cause，quota 仍按被漏审的 prior Scope Lock计算，不能靠换锁绕过。该模式必须绑定失效的 prior Review/terminal/Reviewer、漏审 item/type与 prior-Candidate精确证据，并由不同 main Reviewer从当前 review root做一次完整复核，在同一报告合并全部 findings/proposals。它可以返回任一非条件式 verdict；只有两类 gap 都为空且其他批准条件成立时才可 `APPROVED`。

当按**当前 immediate-prior terminal 所属的被漏审 Scope Lock**过滤出的 recovery count 已为 `1`，又披露该同一被漏审 Scope Lock 下的 reviewer miss 时，才创建 closed `EB-* / review_process_integrity`。在专用字段绑定 prior exception terminal artifact，以及第二个 missed item 的 ID/type/精确 prior-Candidate evidence，并列出所有 implicated main Reviewer identities（至少被失效的初始 Reviewer 与 exceptional Reviewer），返回 `EVIDENCE_BLOCKED`。其他 Scope Lock 上首次发生的 miss 仍按该锁自己的 count=`0` 进入一次 exceptional full review；不得用全局 history 数量误判，也不得靠新建 Scope Lock 清零旧锁 quota。Candidate 修改、补测试或补普通证据都不能关闭 process blocker；只接受用户明确授权由**不在 implicated 集合内**的新 main Reviewer 重新建立独立评审流程，并从 `review_root_base` 做新的 independent initial full review，不能回到 delta review。不得继续向开发追加整改队列。真实缺陷不得隐藏，但 reviewer miss 也不得成为扩 scope 或无限轮次的借口。

晚发现问题不得改变 Scope Lock、验收标准或引入未批准 surface。

停止条件：所有已确认 P0/P1 关闭、无新证据支持的边界内 P0/P1、所有必需 source/local gate 完成、无 scope proposal、无 open evidence blocker、证据足够时，必须输出 `APPROVED`。批准产物必须显式记录这四类零项/完成项，不能仅由 coverage 空列表推断。不得继续用 P2、文档美化或未来环境门禁延长源码评审。

## 多仓与 Subagent

多仓评审先建立一份共享 Scope Lock，并给每个 subreviewer 传递完整 Scope Lock 内容（或可读取的 persisted Charter path@version）**以及** digest；digest 只校验同一性，不能替代 In/Out/Must Not/architecture budget 输入。按独立风险域拆分，不按“尽可能多找问题”拆分。

在派发前建立 coverage ledger，逐仓绑定 base/Candidate/tree、`git diff --name-status`（mutable 时用 snapshot 的 `candidate_changed_paths`）及其**逐仓摘要**、完整 reviewed range、分配的 path/risk domain 和 owner。每个分类项必须携带 `repository_identity + path + manifest layer/status`，避免跨仓同名路径碰撞。immutable manifest path 只能分类为 `in_scope` 或 `scope_violation`；mutable 另允许 `verified_filtered_baseline`，但仅限 manifest 中唯一变化是 `raw_worktree_vs_index/RAW` 且有独立 filter/EOL 与 prior-raw 证据。已确认不属于 Candidate 的 WIP 必须在 snapshot 时用 `--exclude` 排除并只记入独立 ledger，不得出现在 changed-path classification。汇总时机械对账：每仓 manifest 一一对应、未分类 paths 为空，每个仓库和全部可独立判断的 In Scope diff 至少被一个 Reviewer 覆盖，重叠已合并。非空 `evidence_or_assignment_gaps` 返回 `EVIDENCE_BLOCKED`；只存在且与 closed proposal 一一对应的 `scope_decision_blocked_ranges` 返回 `SCOPE_DECISION_REQUIRED`。两类列表都为空才可 APPROVED或复用完整 coverage。

Subagent 必须同时遵循 `../../references/subagent-result-contract.md` 与 `references/subagent-result-extension.md`。后者禁止 `conditional_pass`，并要求回传 Scope Lock digest、精确 repo/range、assigned/reviewed coverage 和 gap。每条候选 finding 还必须返回：

- `scope_classification: in_scope | scope_violation`
- frozen invariant、evidence、reproducer、minimum fix、architecture surface delta、architecture budget reference

`scope_proposals` 与 `environment_only_notes` 使用 extension 中的独立字段返回，不能伪装成 finding，也不能进入 P0/P1 计数。

主 Reviewer 必须重新验证证据。Reviewer 提出的 `scope_proposal` 不能转换成 P0/P1，只能汇总为 `SCOPE_DECISION_REQUIRED`；Candidate 明确违反已批准 architecture budget 且可删除/回退的 delta 必须转换为完整的标准 P1 scope-violation finding。

## 输出

- 默认在回复中给出 review comment；只有用户明确要求或仓库流程要求并授权时才写报告文件。
- 未通过或受阻时使用 `references/report-templates.md`；英文输出使用 `.en.md`。
- 所有仓库均为 immutable Candidate 时使用 Code Review Approval Certificate；任一仓库是 mutable worktree 时，整个多仓结果使用 Mixed / Mutable Worktree Review Comment，同时逐仓保留 immutable SHA/tree，并只为真正 mutable 的行填写 snapshot appendix。不得把 immutable 行伪装成 WORKTREE，也不得把 mixed comment 转换成 certificate。两类产物都明确“不是部署批准”。
- 复审报告保留 finding ID，不因改写措辞创建“新问题”。

## 禁止行为

- 禁止 Reviewer 修改源码、push、建 PR、merge、部署或写环境，除非用户明确授权对应动作。
- 禁止以“安全加固”“稳定性”“行业惯例”“未来需要”为理由扩大 Scope Lock。
- 禁止把 CI、环境、发布、文档阶段缺口混成源码 defect。
- 禁止把 pre-existing defect 归因于 Candidate；可单列 baseline observation，但不阻断本 Candidate，除非 Candidate 扩大了该风险或用户把它纳入范围。
- 禁止复审时改变问题定义、验收标准或 architecture budget。
- 禁止在存在不确定性时用更复杂实现替代澄清或 scope decision。

## 使用示例

- “请对 commit `abc123` 相对 `main` 做 Lead Dev code review。”
- “开发修完上一轮 P0/P1，请对新 Candidate 做 delta 复审。”
- “请审查这三个仓库的本地实现，部署门禁先不要管。”

## 参考文档

- `references/review-policy.yaml`：机器可读的判定与边界规则（必读）
- `references/scope-lock-template.md` / `.en.md`：Review Charter 与 Scope Lock
- `references/reviewer-checklist.md`：按触达面启用的源码检查清单
- `references/report-templates.md` / `.en.md`：Review Comment 与 Approval Certificate
- `references/subagent-result-extension.md`：多仓/并行评审的 closed binding 与 coverage 结果契约
- `scripts/terminal_artifact_envelope.py`：生成、验证并无损提取可机械复现的 embedded prior-terminal envelope