code-quorum

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Read-only boundary

只读边界

The whole workflow inspects and reports. No agent in it edits reviewed files, generates or applies patches, commits, or begins remediation; recommendations point at a later, separately authorized workflow. Reproduce claims only with non-mutating commands or in disposable isolation that cannot alter the reviewed workspace.

整个工作流仅执行检查和报告。其中任何Agent都不会编辑被审查文件、生成或应用补丁、提交代码，也不会启动修复工作；相关建议将指向后续需单独授权的工作流。仅使用非修改性命令复现结论，或在不会更改被审查工作区的一次性隔离环境中复现。

Confirm agents

确认Agent机制

Confirm the worker mechanism before touching the review scope.

Use the runtime's native subagent abstraction for the whole quorum. The reviewer names below are rubrics, not required configured agent names: create one fresh blind child per selected rubric and include that rubric in its task packet.

Every reviewer is a blind agent: fresh context, no prior conclusions, no reviewer passes in the delegator context. Concurrency is optional; blindness is required. When no mechanism can create blind agents, stop and return an execution-unavailable response naming the missing capability.

Complete this step when one mechanism can create a blind agent per reviewer.

在处理审查范围之前，先确认工作器机制。

整个审查组使用运行时原生的子Agent抽象。下方列出的审查员名称是审查维度，而非必须配置的Agent名称：为每个选定的审查维度创建一个全新的盲子Agent，并将该审查维度纳入其任务包中。

每个审查员都是盲Agent：全新上下文，无预先结论，委托方上下文中不保留任何审查过程记录。并发是可选的；盲性是必须的。如果没有机制可以创建盲Agent，停止并返回执行不可用的响应，说明缺失的能力。

当存在可为每个审查员创建盲Agent的机制时，完成此步骤。

Resolve scope

确定审查范围

Resolve explicit scope first. Otherwise resolve, in order, pending changes against

HEAD

including staged changes, unstaged tracked changes, and relevant untracked files; a branch from its merge-base; an associated pull request; a recent commit; or named task artifacts. Record any supplied or associated issue, pull-request description, specification, or acceptance criteria as the requirements source; record its absence. Never infer a whole-repository review. Flag unusually large inferred ranges.

Complete this step when the exact diff, range, or files and the requirements source or its absence can be stated.

首先明确指定的审查范围。如果没有明确指定，则按以下顺序确定范围：相对于

HEAD

的未提交变更，包括暂存变更、未暂存的已跟踪文件变更、以及相关的未跟踪文件；某分支相对于其合并基点的变更；关联的拉取请求；最近的一次提交；或指定的任务产物。记录所有提供的或关联的issue、拉取请求描述、规范或验收标准作为需求来源；若不存在则记录缺失。绝不要默认对整个仓库进行审查。对异常大的推断范围进行标记。

当可以明确说明具体的差异、范围或文件，以及需求来源（或其缺失情况）时，完成此步骤。

Select reviewers

选择审查员

Honor explicit reviewer names before named sets before the default set. Apply the user's focus, additions, and exclusions. Accept

simple

and

lightweight

as aliases for

quick

yaml

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

Unless excluded, add

requirements-reviewer

to any set when the requirements source states testable behavior. Load only the selected files from

references/reviewers/

Complete this step when the selection has one interpretation and every selected reviewer has an applicable rubric.

优先级从高到低依次为：明确指定的审查员名称、命名审查组、默认审查组。需考虑用户的关注重点、新增项和排除项。接受

simple

和

lightweight

作为

quick

的别名。

yaml

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/

目录加载选定审查员对应的文件。

当所选审查组只有一种合理解释，且每个选定的审查员都有对应的适用审查规则时，完成此步骤。

Run the quorum

运行审查组

Give every reviewer an identical task packet — scope, source, changed files, requirements source or absence, focus, exclusions, project rules, read-only flag, finding contract — plus its one distinct rubric. Require every material candidate that clears the rubric's evidence bar, ordered by severity;

no_findings

completes a review when none clear it. Create one blind agent per reviewer through the confirmed mechanism, concurrently when capacity allows, sequentially otherwise.

Where the worker mechanism offers acceptance gates, disable them: the reviewers are the acceptance layer, and a gate can falsely fail valid reviewer output.

Wait for every reviewer to return, fail, or time out. Judge each result by its returned report, not the wrapper's lifecycle label — retain a complete report even when the wrapper flags an anomaly, and disclose the anomaly under coverage limitations. A missing reviewer contributes only a coverage limitation — never agreement or

no_findings

. Return an execution failure when no reviewer returns a usable result.

Complete this step when every selected reviewer has a usable result or a recorded failure reason, and at least one usable result exists.

向每个审查员提供相同的任务包——包括范围、源代码、变更文件、需求来源（或缺失情况）、关注重点、排除项、项目规则、只读标志、审查发现约定——再加上其专属的审查规则。要求输出所有达到审查规则证据标准的实质性候选问题，按严重程度排序；如果没有符合标准的问题，返回

no_findings

表示审查完成。通过已确认的机制为每个审查员创建一个盲Agent，容量允许时并发执行，否则顺序执行。

如果工作器机制提供验收门控，请将其禁用：审查员本身就是验收层，门控可能会错误地判定有效的审查员输出为失败。

等待所有审查员返回、失败或超时。根据返回的报告而非包装器的生命周期标签来判断每个结果——即使包装器标记了异常，也要保留完整报告，并在覆盖范围限制中披露该异常。缺失的审查员仅计为覆盖范围限制——绝不视为同意或

no_findings

。如果没有审查员返回可用结果，则返回执行失败。

当每个选定的审查员都有可用结果或已记录失败原因，且至少存在一个可用结果时，完成此步骤。

Normalize candidates

标准化候选问题

Normalize every candidate to

finding-v1

yaml

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]

Require every field. List in

source_reviewers

only reviewers whose own report contains a materially equivalent claim — selection alone is not attribution evidence. Complete this step when every candidate conforms or has a rejection reason.

将所有候选问题标准化为

finding-v1

格式：

yaml

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

中列出自身报告包含实质等效主张的审查员——仅被选中不能作为归属依据。当所有候选问题都符合格式要求或已有拒绝理由时，完成此步骤。

Synthesize

综合分析

Merge candidates by root cause. Remove style-only, speculative, pre-existing, and out-of-scope claims. Resolve disagreement from source evidence. Count a second reviewer as corroboration only when it contributes materially independent evidence, a distinct trigger, or a distinct failure mode.

Complete this step when each candidate is merged into a retained candidate or rejected with a reason.

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

当每个候选问题都被合并为保留项或被有理由拒绝时，完成此步骤。

Verify

验证

Resolve every retained candidate against source, safeguards, and tests. Use proportionate verification: trace the relevant code path, inspect callers and contracts, consult authoritative framework or platform behavior, and reproduce when the claim warrants it. Assign

verified

partially-verified

unresolved

, or

rejected

and record the method and evidence. Move important unresolved candidates to Open questions with the evidence that would settle them.

Complete this step when every retained candidate has a status, method, evidence, and report destination or rejection reason.

对照源代码、安全保障措施和测试，验证每个保留的候选问题。采用与问题相称的验证方式：跟踪相关代码路径、检查调用方和契约、参考权威框架或平台行为，并且在主张需要时进行复现。标记为

verified

（已验证）、

partially-verified

（部分验证）、

unresolved

（未解决）或

rejected

（已拒绝），并记录验证方法和证据。将重要的未解决候选问题移至“待解答问题”章节，并附上可解决该问题的证据。

当每个保留的候选问题都有状态、验证方法、证据，以及报告去向或拒绝理由时，完成此步骤。

Prioritize and report

优先级排序与报告

Assign severity using these canonical meanings:

```
critical
```
: catastrophic, actively dangerous, or irreversible impact.
```
high
```
: material, ship-blocking defect.
```
medium
```
: important defect that is normally nonblocking.
```
low
```
: minor risk or worthwhile improvement.

Use

medium

as the reporting floor. Lower it to

low

only when the user explicitly asks for all recommendations. Build the verdict and every report section exclusively from candidates that meet the reporting floor; below-floor candidates are silently excluded and have no effect on the verdict.

Keep severity, verification, and disposition separate. Dispositions mean:

```
block
```
: a verified material finding.
```
address
```
: a verified or partially verified actionable finding whose known impact is nonblocking.
```
consider
```
: a verified low-risk simplification from the selected simplification reviewer.

Place important unresolved candidates and partially verified candidates with potentially ship-blocking impact only in Open questions; state the evidence that would settle them, and exclude them from the verdict. Omit rejected findings unless the user requests provenance. Use P0-P3 aliases only when requested.

Render the report exactly in this template — each section once, in this order, omitting Consider and Open questions when empty:

markdown

undefined

使用以下标准定义分配严重程度：

```
critical
```
：灾难性的、具有现实危险性的或不可逆的影响。
```
high
```
：实质性的、阻碍发布的缺陷。
```
medium
```
：重要的缺陷，通常不阻碍发布。
```
low
```
：轻微风险或值得改进的点。

以

medium

作为报告的最低严重程度门槛。仅当用户明确要求所有建议时，才将门槛降至

low

。仅使用达到报告门槛的候选问题构建结论和所有报告章节；低于门槛的候选问题将被静默排除，不对结论产生任何影响。

将严重程度、验证状态和处理方式分开。处理方式定义如下：

```
block
```
：已验证的实质性问题。
```
address
```
：已验证或部分验证的可操作问题，已知影响不阻碍发布。
```
consider
```
：来自选定的简化审查员的已验证低风险简化建议。

仅将重要的未解决候选问题和可能阻碍发布的部分验证候选问题放在“待解答问题”中；说明可解决该问题的证据，且不将其纳入结论。除非用户要求提供来源信息，否则省略已拒绝的问题。仅在被要求时使用P0-P3别名。

严格按照此模板生成报告——每个章节仅出现一次，按此顺序排列，若“建议考虑”和“待解答问题”为空则省略：

markdown

undefined

Verdict

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

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

Do next

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

```
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>

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>)

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

Open questions

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

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

Coverage

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


Every Do next item and every finding carries an exact `file:lines` location — when a reviewer supplied only a file or block name, resolve the line numbers from source before reporting. Do next lists every `block` and `address` item ordered by severity, one imperative line each; verified `consider` items from the simplification reviewer live only in Consider. Findings are numbered in Do next order so the checklist and the detail cross-reference by number.

Complete this step when the report matches the template: every reported candidate meets the reporting floor; every finding has severity, verification, and disposition; every finding, Do next item, and Consider item has an exact `file:lines` location; every finding has a one-sentence fix; each Do next entry names its finding; and each open question names the evidence that would settle it.

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


每个“下一步行动”项和每个问题都必须带有精确的`file:lines`位置——如果审查员仅提供了文件名或代码块名，需在报告前从源代码中解析出行号。“下一步行动”按严重程度排序列出所有`block`和`address`项，每项为一条祈使句；来自简化审查员的已验证`consider`项仅放在“建议考虑”章节中。问题按“下一步行动”的顺序编号，以便检查清单和详细内容可以通过编号相互对应。

当报告符合以下模板要求时完成此步骤：所有报告的候选问题都达到报告门槛；每个问题都有严重程度、验证状态和处理方式；每个问题、下一步行动项和建议考虑项都有精确的`file:lines`位置；每个问题都有一句话的修复建议；每个下一步行动条目都对应其问题；每个待解答问题都说明了可解决该问题的证据。