code-quorum

只读边界

整个工作流只检查并报告。过程中没有任何 Agent 会编辑已审查的文件、生成或应用补丁、提交更改或开始修复；建议仅指向后续另行授权的工作流。只能通过不会修改内容的命令，或在不会影响已审查工作区的一次性隔离环境中复现问题陈述。

确认 Agent

在接触审查范围之前，确认工作机制。

整个评审团都使用运行时原生的子 Agent 抽象。以下评审者名称是评审标准，而非必须配置的 Agent 名称：为每项选定的评审标准创建一个全新的盲审子 Agent，并在其任务包中注明该评审标准。

每位评审者都是盲审 Agent：使用全新上下文，不得有先前结论，委派者上下文中不得有评审轮次。是否并发执行可选，但必须保持盲审。如果没有任何机制可以创建盲审 Agent，则停止并返回执行不可用响应，指出缺少的能力。

当存在一种机制可以为每位评审者创建盲审 Agent 时，即完成此步骤。

确定范围

优先确定明确指定的范围。否则，按以下顺序确定：相对于 HEAD 的待处理更改（包括暂存更改）、未暂存的受跟踪更改、相关的未跟踪文件；某分支相对于其合并基点的更改；关联的拉取请求；近期提交；或指定的任务制品。将任何提供或关联的问题描述、拉取请求说明、规格说明或验收标准记录为需求来源；若不存在，也要记录。不得推断要审查整个代码库。若推断出的范围异常大，则予以标记。

当能够说明确切的差异、范围或文件，以及需求来源或其缺失情况时，即完成此步骤。

选择评审者

优先遵循明确指定的评审者名称，其次是指定的评审者集合，最后才是默认集合。应用用户指定的关注点、补充项和排除项。接受 simple 和 lightweight 作为 quick 的别名。

quick:
  - correctness-reviewer
  - silent-failure-hunter
default:
  - correctness-reviewer
  - failure-mode-reviewer
  - silent-failure-hunter
full:
  - correctness-reviewer
  - failure-mode-reviewer
  - silent-failure-hunter
  - simplification-reviewer
  - test-behavior-reviewer

除非被排除，否则只要需求来源中列出了可测试行为，就将 requirements-reviewer 加入任意集合。仅加载 references/reviewers/ 中选定的文件。

当评审者选择结果只有一种解释，且每位选定的评审者都有适用的评审标准时，即完成此步骤。

运行评审团

向每位评审者提供完全相同的任务包——范围、来源、已更改文件、需求来源或其缺失情况、关注点、排除项、项目规则、只读标记、问题报告约定——并附上其各自独有的评审标准。要求报告每个达到该评审标准证据门槛的重要候选问题，并按严重程度排序；若没有任何候选问题达到门槛，则以 no_findings 完成评审。通过已确认的机制，为每位评审者创建一个盲审 Agent；若容量允许，则并发执行，否则依次执行。

如果工作机制提供验收关卡，则将其禁用：评审者负责验收，而关卡可能错误地判定有效的评审结果不合格。

等待每位评审者返回结果、失败或超时。根据评审者返回的报告，而非包装器的生命周期标签来判断结果——即使包装器标记异常，也要保留完整报告，并在覆盖限制中披露该异常。缺失的评审者只构成覆盖限制，绝不代表达成一致或 no_findings。如果没有任何评审者返回可用结果，则返回执行失败。

当每位选定的评审者都已返回可用结果或记录了失败原因，且至少有一份可用结果时，即完成此步骤。

规范化候选问题

将每个候选问题规范化为 finding-v1：

title: Concrete failure or concern
location: { file: path/to/file, lines: 10-18 }
category: correctness
severity: critical | high | medium | low
claim: What is wrong
trigger: Conditions that expose it
impact: Resulting behavior or risk
evidence: [Relevant code-path evidence]
recommendation: Direction for addressing it
source_reviewers: [reviewer-name]

所有字段均为必填项。source_reviewers 仅列出其自身报告包含实质等同问题陈述的评审者——仅仅被选中并不足以作为归因证据。当每个候选问题均符合规范，或均有拒绝原因时，即完成此步骤。

综合

按根本原因合并候选项。删除仅涉及风格、推测性、预先存在和超出范围的主张。根据源代码证据解决分歧。只有当第二位审查者提供了实质上独立的证据、不同的触发条件或不同的故障模式时，才将其视为佐证。

当每个候选项都已合并到一个保留候选项中，或已说明原因并予以驳回时，完成此步骤。

验证

根据源代码、防护措施和测试，逐一核实所有保留候选项。按比例进行验证：追踪相关代码路径，检查调用方和契约，查阅权威的框架或平台行为说明，并在主张需要时复现。指定 verified、partially-verified、unresolved 或 rejected，并记录方法和证据。将重要的未解决候选项移至 Open questions，并说明哪些证据可以解决问题。

当每个保留候选项都有状态、方法、证据，以及报告去向或驳回理由时，完成此步骤。

排定优先级并报告

根据以下规范含义指定严重性：

• critical：造成灾难性、当前危险或不可逆的影响。
• high：重大且阻碍发布的缺陷。
• medium：重要但通常不阻碍发布的缺陷。
• low：轻微风险或值得改进之处。

报告严重性以 medium 为下限。只有在用户明确要求列出所有建议时，才降低到 low。仅根据达到报告下限的候选项构建结论和每个报告章节；低于下限的候选项应静默排除，且不得影响结论。

将严重性、验证状态和处置方式分开。处置方式含义如下：

• block：已验证的重大问题。
• address：已验证或部分验证、可采取行动且已知影响不阻碍发布的问题。
• consider：由选定的简化审查者提出、已验证的低风险简化建议。

仅将重要的未解决候选项，以及可能造成阻碍发布影响的部分验证候选项，放入 Open questions；说明哪些证据可以解决问题，并将其排除在结论之外。除非用户要求提供来源信息，否则省略已驳回的问题。仅在用户要求时使用 P0-P3 别名。

严格按照以下模板呈现报告——每个章节只出现一次，顺序如下；Consider 和 Open questions 为空时省略：

## Verdict

<One sentence: **Merge**, **Merge after fixes**, or **Do not merge** — with the deciding reason.>

Scope: <range/PR · files · +/− lines> · Reviewers: <usable/selected> (<mechanism>)

## Do next

- [ ] `path/to/file:lines` — <imperative action> (finding 1)

## Findings

### 1. <Concrete failure in plain words> — <severity> · <disposition>

- **Where:** `path/to/file:lines` — <function or block name>
- **What:** <claim and trigger, at most two sentences>
- **Impact:** <resulting behavior or risk, one sentence>
- **Fix:** <one imperative sentence>
- **Verification:** <status> · <source reviewers>

## Consider

- `path/to/file:lines` — <one-line suggestion> (<source reviewers>)

## Open questions

- <Unresolved claim> — <the evidence that would settle it>

## Coverage

<Isolation, reviewer failures, and limitations in two or three lines.>

每个 Do next 条目和每个问题都必须包含精确的 file:lines 位置——如果审查者只提供了文件或代码块名称，则报告前应从源代码中确定行号。Do next 应按严重性排序，列出所有 block 和 address 项，每项占一行并使用祈使句；简化审查者提出的已验证 consider 项仅放在 Consider 中。Findings 按 Do next 顺序编号，以便清单与详情通过编号交叉引用。

当报告符合模板时，完成此步骤：每个报告的候选项都达到报告下限；每个问题都有严重性、验证状态和处置方式；每个问题、Do next 条目和 Consider 条目都有精确的 file:lines 位置；每个问题都有一句话说明修复方法；每个 Do next 条目都指出对应的问题；每个开放问题都说明哪些证据可以解决问题。