gstack Review Army 拆解：ship 落地前的并行专家审查、置信度校准与 Fix-First 自动收敛

导读：本文以 gstack 仓库 ship 技能中 sections/review-army.md 所定义的「Step 9/9.1/9.2/9.3 上线前审查（Pre-Landing Review）」为主线，完整讲解 gstack 如何在下发 ship 指令时对 diff 执行结构级审查、按 1-10 置信度分级所有 findings、并行派发 Testing/Security/Performance 等专家子代理、再用 Red Team 兜底与跨轮次去重，最后通过 Fix-First 规则自动修复直至收敛。读完你将掌握一套可直接复用的多代理代码审查协议：从范围探测、专家选择与自适应门控，到 JSON findings 的合并、指纹去重、质量评分与审查日志持久化。

---

一、Step 9 在 ship 工作流中的位置

gstack 将「发版」能力收敛在 ship/SKILL.md 技能中，其第 9 步正是「Pre-Landing Review：审查测试无法捕捉的结构性问题」。按 ship/sections/manifest.json 的段落注册表，review-army.md 段落的触发条件是「进入 pre-landing review 与专家派发（Step 9）」，与 Step 10 Greptile 评论处理、Step 11 对抗性审查与 learnings 刷新形成一条完整的发版前闸门链路。

本段落由同名模板 ship/sections/review-army.md.tmpl 自动生成（文件头注明 "AUTO-GENERATED from review-army.md.tmpl — do not edit directly"，重生成命令为 bun run gen:skill-docs），模板中的 {{CONFIDENCE_CALIBRATION}}、{{DESIGN_REVIEW_LITE}}、{{REVIEW_ARMY}}、{{CROSS_REVIEW_DEDUP}} 四个占位符在渲染时被填充成最终指令文本。其代码生成源头位于 scripts/resolvers/review-army.ts，该 resolver 注释自述为「self-learning roadmap Release 2」：为 /review 与 /ship 生成「并行专家评审」指令散文，并根据目标技能动态切换小节编号（ship 使用 9.1/9.2，独立 /review 使用 4.5/4.6）。

值得注意的运行时差异：当宿主（host）为 Codex 时，resolver 直接返回空字符串——Review Army 只在 Claude 侧运行（见 review-army.ts 的 generateReviewArmy 中 if (ctx.host === 'codex') return ''）。

二、两遍（Two-Pass）基础审查

在进入专家派发之前，Step 9 要求主代理先完成一次全 diff 的结构审查：

1. 读取 ~/.claude/skills/gstack/review/checklist.md（仓库对应文件为 review/checklist.md）。如果该文件无法读取，必须 STOP 并报告错误，不允许静默跳过；
2. 执行 git diff origin/<base> 获取完整 diff（范围限定在功能改动上，base 为刚 fetch 的最新分支）；
3. 按两遍策略应用审查清单：
   • Pass 1（CRITICAL）：SQL & Data Safety（SQL 字符串插值、TOCTOU 竞态、绕过模型校验直写 DB、N+1 查询）、LLM Output Trust Boundary（LLM 产出写入 DB/邮件/向量库前的格式校验、SSRF、存储型提示注入）；
   • Pass 2（INFORMATIONAL）：其余全部类别，包括 Async/Sync 混用、列名安全、死代码、LLM Prompt 问题、完整性缺口、时间窗安全、边界类型强转、视图/前端、分发与 CI/CD 流水线。

review/checklist.md 明确将 Test Gaps、Dead Code、Magic Numbers、Conditional Side Effects、Performance & Bundle Impact、Crypto & Entropy 六类划给「并行子代理专家」处理，基础清单不做重复劳动——这正是整套架构「分而治之」的设计起点：主代理跑确定性规则，专家子代理跑深度领域审查。

三、置信度校准（Confidence Calibration）

Review Army 对每个 finding 强制要求 1-10 的置信度评分，并配套严格的展示规则：

分数	含义	展示规则
9-10	通过阅读具体代码得到验证，能演示出确凿 bug 或利用路径	正常展示
7-8	高置信度模式匹配，极可能正确	正常展示
5-6	中等置信度，可能是误报	带警告展示："Medium confidence, verify this is actually an issue"
3-4	低置信度，模式可疑但也许没问题	从主报告中抑制，仅放入附录
1-2	纯猜测	仅在严重度为 P0 时才报告

Finding 标准格式

[SEVERITY] (confidence: N/10) file:line — description

实际示例（来自原文档）：

[P1] (confidence: 9/10) app/models/user.rb:42 — SQL injection via string interpolation in where clause
[P2] (confidence: 5/10) app/controllers/api/v1/users_controller.rb:18 — Possible N+1 query, verify with production logs

置信度分级的工程意义是「宁可进附录，不可污染主报告」：3-4 分结果仍会保留在附录中供审计校准，但不会出现在关键 Pass 的输出里，从而保护阅读者对「已展示 findings」的信任度。

四、Pre-emit 验证闸门（#1539）：杀死 "field doesn't exist" 误报类

在任何 finding 进入报告之前，闸门强制要求两步验证（对应 issue #1539）：

1. 引用触发该 finding 的具体代码行——file:line 加上触发它的那行代码原文。若 finding 是「model Y 上不存在字段 X」，就必须引用 class Y 中该字段应存在位置的代码行；若说「dict.get() 可能返回 None」，就要引用 dict 的初始化代码；若说「A 与 B 之间有竞态」，A 和 B 两边的代码都要引用；
2. 引用不出来 = 未验证。该 finding 置信度强制压到 4-5（从主报告抑制、进附录），供审查者审计校准。不允许通过编造一个投机性的 7+ 置信度来绕过闸门。

Framework-meta 提示

当符号由框架元编程生成——Django Meta 内部类、Rails has_many/scope、SQLAlchemy relationship/Column、TypeORM 装饰器、Sequelize init/belongsTo、Prisma 生成客户端、迁移历史——应引用元构造本身（Meta 块、迁移、装饰器、schema 文件），而不是指望在类体里找到字面量名称。验证语义是「我读到了创建该符号的源码」，而非「我 grep 了名字没找到」。更深层的框架感知验证（模型内省、迁移历史感知、ORM 方言探测）被刻意排除在轻量闸门之外，留待设计文档 ~/.gstack-dev/plans/1539-framework-aware-review.md。

闸门消灭的误报类别（以 Django Sprint 2.5 #1539 实测为基准）

误报类别	闸门为何能捕获
"field doesn't exist on model"	强制引用 model 类体或 Meta，字段不存在变得显而易见
"dict.get() might be None"	强制引用 dict 初始化（如 Django form 的 cleaned_data 以 {} 初始化）
"save() might lose fields"	强制引用 ORM 签名或模型定义
"update_fields might miss X"	强制引用字段集合；X 若不存在，误报不证自明

校准学习回路

如果报告了一个置信度 < 7 的 finding 且用户确认为真实问题，这是一次校准事件——说明你的初始置信度打低了。此时应把修正后的模式记录为 learning，让未来的审查能以更高置信度命中同类问题（learnings 的检索命令 gstack-learnings-search 会在下文专家派发中复用）。

五、Design Review（条件触发，diff 限定）

是否做设计审查由 gstack-diff-scope <base> 判定（该命令同时被 Step 9.1 的专家选择复用）：

source <(~/.claude/skills/gstack/bin/gstack-diff-scope <base> 2>/dev/null)

• 若 SCOPE_FRONTEND=false：静默跳过设计审查，不产生任何输出；
• 若 SCOPE_FRONTEND=true，执行以下步骤：

1. 检查 DESIGN.md：若仓库根存在 DESIGN.md 或 design-system.md 则必须读取，所有设计 findings 以其为校准基准——被 DESIGN.md 认可的模式不予标记；不存在时退回通用设计原则；
2. 读取设计清单（仓库内为 review/design-checklist.md）。读不到则带备注跳过："Design checklist not found — skipping design review."；
3. 通读每个被改的前端文件（读完整文件，不只看 diff hunks），前端文件按清单中的模式识别；
4. 逐项应用设计清单并分类：
   • [HIGH] 机械性 CSS 修复（outline: none、!important、font-size < 16px）→ 归类 AUTO-FIX；
   • [HIGH/MEDIUM] 需要设计判断 → 归类 ASK；
   • [LOW] 意图式检测 → 以 "Possible — verify visually or run /design-review" 呈现；
5. findings 汇入审查输出中独立的 "Design Review" 标题下，与代码审查 findings 合并进入同一 Fix-First 流程；
6. 写入审查就绪看板（Review Readiness Dashboard），调用设计审查专用日志命令：

~/.claude/skills/gstack/bin/gstack-review-log '{"skill":"design-review-lite","timestamp":"TIMESTAMP","status":"STATUS","findings":N,"auto_fixed":M,"commit":"COMMIT"}'

替换规则：TIMESTAMP = ISO 8601 时间；STATUS = 0 findings 时为 "clean"，否则 "issues_found"；N = findings 总数；M = 自动修复数；COMMIT = git rev-parse --short HEAD 的输出。

7. Codex 设计声音（可选，可用则自动）：先探测 Codex 是否可用，再对 diff 做一次轻量设计检查：

command -v codex >/dev/null 2>&1 && echo "CODEX_AVAILABLE" || echo "CODEX_NOT_AVAILABLE"

若 Codex 可用，运行 7 项 litmus 检查（每项 YES/NO）：① 品牌/产品在第一屏是否明确可辨？② 是否有一个强的视觉锚点？③ 仅扫标题能否理解页面？④ 每个区块是否只有一个职责？⑤ 卡片是否真的必要？⑥ 动效是在强化层级还是在营造氛围？⑦ 去掉所有装饰性阴影后设计是否依然有高级感？同时标记硬性否决项：通用 SaaS 卡片栅格当第一印象、美图弱品牌、强标题无清晰行动点、文字背后杂乱图、多区块重复同一情绪陈述、无叙事目的的轮播、用叠卡片替代布局的 App UI。最终只输出 5 条最重要的设计 findings，要求引用 file:line，执行命令带 5 分钟超时（timeout: 300000）并检查 stderr。所有错误均不阻塞——认证失败、超时或空响应时带简短备注跳过即可，Codex 输出呈现在 CODEX (design): 标题下与清单 findings 合并。

六、Step 9.1：Review Army 专家派发

探测栈与范围

source <(~/.claude/skills/gstack/bin/gstack-diff-scope <base> 2>/dev/null) || true
# Detect stack for specialist context
STACK=""
[ -f Gemfile ] && STACK="${STACK}ruby "
[ -f package.json ] && STACK="${STACK}node "
[ -f requirements.txt ] || [ -f pyproject.toml ] && STACK="${STACK}python "
[ -f go.mod ] && STACK="${STACK}go "
[ -f Cargo.toml ] && STACK="${STACK}rust "
echo "STACK: ${STACK:-unknown}"
DIFF_BASE=$(git merge-base origin/<base> HEAD)
DIFF_INS=$(git diff "$DIFF_BASE" --stat | tail -1 | grep -oE '[0-9]+ insertion' | grep -oE '[0-9]+' || echo "0")
DIFF_DEL=$(git diff "$DIFF_BASE" --stat | tail -1 | grep -oE '[0-9]+ deletion' | grep -oE '[0-9]+' || echo "0")
DIFF_LINES=$((DIFF_INS + DIFF_DEL))
echo "DIFF_LINES: $DIFF_LINES"
# Detect test framework for specialist test stub generation
TEST_FW=""
{ [ -f jest.config.ts ] || [ -f jest.config.js ]; } && TEST_FW="jest"
[ -f vitest.config.ts ] && TEST_FW="vitest"
{ [ -f spec/spec_helper.rb ] || [ -f .rspec ]; } && TEST_FW="rspec"
{ [ -f pytest.ini ] || [ -f conftest.py ]; } && TEST_FW="pytest"
[ -f go.mod ] && TEST_FW="go-test"
echo "TEST_FW: ${TEST_FW:-unknown}"

这段脚本产出三个关键决策信号：STACK（ruby/node/python/go/rust 或 unknown，注入专家上下文）、DIFF_LINES（专家是否派发的规模门槛）、TEST_FW（为专家的 test_stub 生成提供框架骨架）。仓库对应的真实实现可对照 review-army.ts。

读取专家命中率（自适应门控的前提）

~/.claude/skills/gstack/bin/gstack-specialist-stats 2>/dev/null || true

专家选择规则

Always-on（每次 ≥ 50 行改动的审查都派发）：

1. Testing — 读 ~/.claude/skills/gstack/review/specialists/testing.md（仓库路径 review/specialists/testing.md，Scope 标为 "Always-on (every review)"，覆盖缺负路径测试、边界值覆盖、隔离违规、flaky 模式、安全执行测试缺失五类）；
2. Maintainability — 读 ~/.claude/skills/gstack/review/specialists/maintainability.md。

若 DIFF_LINES < 50： 跳过全部专家，打印 "Small diff (N lines) — specialists skipped."，直接进入 Fix-First 流程。

条件触发（匹配对应 scope 信号才派发）： 3. Security — 若 SCOPE_AUTH=true，或 SCOPE_BACKEND=true 且 DIFF_LINES > 100； 4. Performance — 若 SCOPE_BACKEND=true 或 SCOPE_FRONTEND=true； 5. Data Migration — 若 SCOPE_MIGRATIONS=true； 6. API Contract — 若 SCOPE_API=true； 7. Design — 若 SCOPE_FRONTEND=true，复用已有设计审查清单。

自适应门控（Adaptive Gating）

通过 scope 门控的条件专家还需再经过命中率门控，数据来自 gstack-specialist-stats：

• 标记 [GATE_CANDIDATE]（10+ 次派发中 0 findings）→ 跳过，打印 "[specialist] auto-gated (0 findings in N reviews)."；
• 标记 [NEVER_GATE] → 无论命中率如何都派发。Security 与 Data Migration 是「保险型」专家，静默时也必须运行——这正是 review/specialists/security.md 将其 Scope 声明为 "When SCOPE_AUTH=true OR (SCOPE_BACKEND=true AND diff > 100 lines)" 仍建议永不被门控淘汰的原因。

强制旗标： 若用户提示包含 --security、--performance、--testing、--maintainability、--data-migration、--api-contract、--design 或 --all-specialists，无论门控结果如何都强制包含该专家。

最终打印选择结果： "Dispatching N specialists: [names]. Skipped: [names] (scope not detected). Gated: [names] (0 findings in N+ reviews)."

并行派发与子代理 Prompt

选中的专家在同一条消息里以多个 Agent 工具调用一次性全部启动，保证并行执行。每个专家子代理拥有全新上下文，不受此前审查偏见影响。每个子代理的 prompt 由四部分组成：

1. 已读入的专家清单全文；
2. 栈上下文："This is a {STACK} project."；
3. 该领域的过往 learnings（如有），用领域学习检索命令拉取：

~/.claude/skills/gstack/bin/gstack-learnings-search --type pitfall --query "{specialist domain}" --limit 5 2>/dev/null || true

若命中，追加 "Past learnings for this domain: {learnings}"；

4. 核心指令（固定模板）：

"You are a specialist code reviewer. Read the checklist below, then run DIFF_BASE=$(git merge-base origin/<base> HEAD) && git diff "$DIFF_BASE" to get the full diff. Apply the checklist against the diff.

For each finding, output a JSON object on its own line: {"severity":"CRITICAL|INFORMATIONAL","confidence":N,"path":"file","line":N,"category":"category","summary":"description","fix":"recommended fix","fingerprint":"path:line:category","specialist":"name"}

Required fields: severity, confidence, path, category, summary, specialist. Optional: line, fix, fingerprint, evidence, test_stub.

If you can write a test that would catch this issue, include it in the test_stub field. Use the detected test framework ({TEST_FW}). Write a minimal skeleton — describe/it/test blocks with clear intent. Skip test_stub for architectural or design-only findings.

If no findings: output NO FINDINGS and nothing else. Do not output anything else — no preamble, no summary, no commentary."

子代理配置要点：

• subagent_type: "general-purpose"；
• 每次专家 Agent 调用都必须显式传 run_in_background: false ——自 Claude Code v2.1.198 起子代理默认后台运行，而所有专家必须在 merge 前完成，因此仅仅省略该旗标已不再等价于前台执行；
• 任一专家失败或超时：记录失败后继续，用成功专家的结果收尾——「专家是增量的，部分结果好于没有结果」。

该 Prompt 的组装逻辑（含栈探测、test_framework 探测、学习注入、JSON schema 文本）可在 review-army.ts 的 generateSpecialistDispatch 中溯源。

七、Step 9.2：结果收集、合并与去重

解析

对每个专家的输出：

1. 若为 "NO FINDINGS"——跳过；
2. 否则逐行按 JSON 解析，非合法 JSON 行直接跳过；
3. 全部 findings 收集为一张带专家名标签的列表。

指纹与去重

• 计算指纹：优先使用自带的 fingerprint 字段；否则回退为 {path}:{line}:{category}（有 line 时）或 {path}:{category}；
• 按指纹分组，同一指纹的多个 finding：保留置信度最高者，标记 "MULTI-SPECIALIST CONFIRMED ({specialist1} + {specialist2})"，置信度 +1（上限 10），并注明确认专家。

置信度闸门（合并后复用）

• 7+：正常展示；
• 5-6：带警告 "Medium confidence — verify this is actually an issue"；
• 3-4：移入附录（从主 findings 抑制）；
• 1-2：完全抑制。

PR 质量评分

合并后计算质量分并记录：

quality_score = max(0, 10 - (critical_count * 2 + informational_count * 0.5))

上限 10。critical 权重 2 分、informational 权重 0.5 分，天然激励「少而准」的 critical 报告。

合并输出格式

SPECIALIST REVIEW: N findings (X critical, Y informational) from Z specialists

[For each finding, in order: CRITICAL first, then INFORMATIONAL, sorted by confidence descending]
[SEVERITY] (confidence: N/10, specialist: name) path:line — summary
  Fix: recommended fix
  [If MULTI-SPECIALIST CONFIRMED: show confirmation note]

PR Quality Score: X/10

这些 findings 与 Step 9 清单 Pass 的 findings 一起流入 Fix-First 流程（item 4），Fix-First 启发式同样适用——专家 findings 遵循相同的 AUTO-FIX vs ASK 分类。

编译 per-specialist 统计

为每个专家（testing、maintainability、security、performance、data-migration、api-contract、design、red-team）记录审查日志对象：

• 已派发：{"dispatched": true, "findings": N, "critical": N, "informational": N}；
• 被 scope 跳过：{"dispatched": false, "reason": "scope"}；
• 被门控跳过：{"dispatched": false, "reason": "gated"}；
• 不适用（如 red-team 未激活）：从对象中省略。

Design 专家虽使用 design-checklist.md 而非专家 schema 文件，仍须计入统计。该对象需留待 Step 5.8 写入 review-log。

八、Red Team 兜底派发（条件触发）

激活条件： DIFF_LINES > 200，或任一专家产生了 CRITICAL finding。

激活后额外派发一个前台（非后台）子代理，它收到：① review/specialists/red-team.md 的 red-team 清单；② Step 9.2 的合并 findings（让它知道哪些已被抓到）；③ git diff 命令。其 prompt 核心是：「代码已被 N 个专家审查并发现以下问题……你的任务是找出他们遗漏的。聚焦跨切面关注点、集成边界问题和专家清单未覆盖的失效模式。」输出仍遵循同一 JSON schema，标记 "specialist":"red-team"，并入 Fix-First 前的 findings 列表。若返回 NO FINDINGS 则记录 "Red Team review: no additional issues found."；失败或超时则静默跳过。

九、Step 9.3：跨轮次审查去重

合并结果归类前，先检查本分支此前的审查中用户是否已跳过某些 finding：

~/.claude/skills/gstack/bin/gstack-review-read

解析输出时注意：只有 ---CONFIG--- 之前的行才是 JSONL 条目（输出尾部 ---CONFIG--- 与 ---HEAD--- 页脚需忽略）。对每个含 findings 数组的条目：收集所有 action: "skipped" 的指纹及其 commit。若存在被跳过指纹，取该次审查之后变更的文件列表：

git diff --name-only <prior-review-commit> HEAD

对每个当前 finding（Step 9 清单 Pass 与 Step 9.1-9.2 专家的合并结果），若指纹匹配某条此前被跳过的 finding 且文件不在变更集内，则抑制该 finding——「用户有意跳过且相关代码未变」。打印 "Suppressed N findings from prior reviews (previously skipped by user)"。只抑制 skipped，绝不抑制 fixed/auto-fixed（后者可能回归，必须重查）。无历史审查则静默跳过。

十、Fix-First 流程与自动收敛循环

1. 分类：按 review/checklist.md 中的 Fix-First 启发式，将清单 Pass 与专家审查（9.1-9.2）的全部 findings 分为 AUTO-FIX 与 ASK 两类。经验法则：机械修复、资深工程师无需讨论即可应用的 → AUTO-FIX（死代码、N+1、与代码矛盾的过期注释、魔数命名化、缺失的 LLM 输出校验、版本/路径不一致等）；合理工程师可能有分歧的 → ASK（安全、竞态、设计决策、超过 20 行的大改、枚举完整性、删除功能、任何改变用户可见行为的东西）。Critical findings 默认偏 ASK，informational 默认偏 AUTO-FIX；
2. 自动修复：逐条应用 AUTO-FIX，每修一条输出一行 [AUTO-FIXED] [file:line] Problem → what you did；
3. 剩余 ASK 汇总为一个 AskUserQuestion：逐项列出编号、严重度、问题与建议修复，每项给出 A) Fix / B) Skip，并给出总体 RECOMMENDATION（≤ 3 个 ASK 时可改用单独提问）；
4. 修复后闭环（全自动契约 #2391）：一旦有修复（自动或用户批准），按文件名提交（git add <fixed-files> && git commit -m "fix: pre-landing review fixes"），然后留在本次调用内循环：对修复后的代码重跑测试套件（Step 5），再对更新后的 diff 重跑本审查（Step 9 items 2-6），直到某一整轮应用了 零 修复——测试全绿且审查干净——才进入 Step 12。绝不停下来让用户再次运行 /ship，修复-重跑循环中不存在用户决策点；
5. 收敛上限：3 轮修复。若第 3 轮仍在应用修复，STOP 并报告反复出现的 findings——无法收敛的审查是真需要人眼的阻塞项，而不是一次重跑请求；
6. 无修复时输出汇总：Pre-Landing Review: N issues — M auto-fixed, K asked (J fixed, L skipped)；无问题则输出 Pre-Landing Review: No issues found.；
7. 最终汇总头部格式为 Pre-Landing Review: N issues (X critical, Y informational)。

十一、审查日志持久化（review-log）

将审查结果写入持久化日志，供 Step 19 的 PR body 与就绪看板使用：

~/.claude/skills/gstack/bin/gstack-review-log '{"skill":"review","timestamp":"TIMESTAMP","status":"STATUS","issues_found":N,"critical":N,"informational":N,"quality_score":SCORE,"specialists":SPECIALISTS_JSON,"findings":FINDINGS_JSON,"commit":"'"$(git rev-parse --short HEAD)"'","via":"ship"}'

字段语义与替换规则：

• TIMESTAMP（ISO 8601）、STATUS（无问题 "clean"，否则 "issues_found"）及各 N 值来自汇总计数；
• via:"ship" 用于与独立 /review 运行区分（ship/SKILL.md 的看板渲染按 via 字段标注来源，如 "CLEAR (DIFF via /ship)"）；
• quality_score = Step 9.2 的 PR Quality Score；若因小 diff 跳过专家，填 10.0；
• specialists = Step 9.2 编译的 per-specialist 统计对象，例如 {"testing":{"dispatched":true,"findings":2,"critical":0,"informational":2},"security":{"dispatched":false,"reason":"scope"}}；
• findings = 逐条记录数组，每条含 {"fingerprint":"path:line:category","severity":"CRITICAL|INFORMATIONAL","action":"ACTION"}，ACTION 为 "auto-fixed"、"fixed"（用户批准）或 "skipped"（用户选择 Skip）。

审查输出需保存——它将进入 Step 19 的 PR body。

十二、源码佐证与验证路径

Review Army 是一套真实可追踪的机制，仓库内可从三层验证：

1. 生成层：scripts/resolvers/review-army.ts 用 generateSpecialistSelection、generateSpecialistDispatch、generateFindingsMerge、generateRedTeam 四个纯函数拼装全部指令散文，且确认了 Codex 宿主被裁剪的运行时差异；
2. 模板层：ship/sections/review-army.md.tmpl 通过 {{CONFIDENCE_CALIBRATION}} 等占位符把 ship/sections/review-army.md 组装进 ship 技能；ship/sections/manifest.json 以被动注册表方式将其绑定到 Step 9 触发条件；
3. 端到端验证层：test/skill-e2e-review-army.test.ts 以真实 fixture 演练多条关键路径——例如 "Migration Safety" 场景在 db/migrate/ 变更时断言 Data Migration 专家激活、"N+1 Performance" 场景用 Ruby 后端文件断言 Performance 专家激活、"Quality Score" 场景直接校验 PR Quality Score: X/10 的输出与计算公式（测试中还通过夹具 test/fixtures 中的 SQL/Ruby 样例驱动评审结果，可据此判断专家是否真的在按 checklist 产出 JSON findings）。

值得注意的是，完整 Review Army 协议的目标宿主是 Claude Code 环境（依赖其 Agent 工具实现并行子代理派发）；当运行在 Codex 等非 Claude 宿主时，该段落会被 resolver 直接裁掉——这是部署层面的一个明确边界，引用协议时需留意宿主前提。

综合来看，Review Army 的本质是「把一次巨型的单点审查拆成一次可扩展的多代理流水线」：确定性规则留在主代理（两遍清单），深度与广度交给并行专家（scope 门控 + 命中率门控 + 强制旗标），遗漏风险由 Red Team 兜底，噪声由预发布验证闸门与跨轮次去重压制，而收敛性则由 Fix-First 启发式和「3 轮修复上限」来保证——最终沉淀为带 via:"ship" 标记、可被就绪看板回读的持久化审查日志。