auto-review-loop

自动审查循环：自主改进研究

🔒 请勿将此技能包装在 /loop、/schedule 或 CronCreate 中。 它已在内部循环（审查 → 修复 → 重新审查），且审查者会在同一个 threadId（codex-reply）中保留轮次间记忆。外部计时器每次触发时都会从头开始运行——使用全新的 threadId，审查者记忆也会重置——按照墙上时钟而非产物变更来触发评审：没有任何新信号，却要付出全部令牌成本。如果你想安排任务，请安排它之前的外部等待（实验完成 → 然后运行一次）。请参阅 shared-references/external-cadence.md。

自主迭代：审查 → 实施修复 → 重新审查，直到独立审查者给出符合策略要求的正面评估，或达到 MAX_ROUNDS。

上下文：$ARGUMENTS

常量

• MAX_ROUNDS = 4
• POSITIVE_THRESHOLD：score >= 6/10 AND verdict ∈ {"ready", "almost"} — 两者必须同时满足。这与实际的 Phase-E STOP CONDITION 完全一致；verdict 的取值为 {"ready", "almost", "not ready"}（即使分数很高，只要 verdict 是 "not ready"，也不会停止循环）。此处早期版本的描述使用了 or 和一组过时的 verdict 值（"accept"/"sufficient"/"ready for submission"）——这是内部不一致；AND 形式为准。
• REVIEW_DOC：review-stage/AUTO_REVIEW.md（累积日志）（旧版项目回退使用 ./AUTO_REVIEW.md）
• REVIEWER_MODEL = gpt-6-astra — Codex 后端的默认模型。必须是 OpenAI 模型（例如 gpt-6-astra、gpt-6.1-sol）。手动后端使用用户选择的模型——必须是来自其他模型系列（OpenAI、Anthropic、Google、DeepSeek、Moonshot/Kimi、Qwen）的受认可模型。
• REVIEWER_BACKEND — 如果没有内联或项目级后端选择，则以 auto 启动；Step -1 会为首次审查恰好运行一次双调用原生 marker/challenge 探测。已绑定的 Copilot CLI 根会话使用 copilot-native（内置互补的 rubber-duck 子 Agent）；未绑定或非 Copilot 主机会沿用现有的 codex 默认值。内联或项目级选择 codex、antigravity/gemini、grok、claude-code、oracle-pro、agy 或 manual 时会跳过探测。显式指定 — reviewer: copilot 会保留兼容模式 copilot --agent 驱动方式及其后续 Codex/手动终结器。原生路径会从主机会话事件中获取两个实际模型 ID；不需要 COPILOT_CLI 或调用方提供的 --executor-model。参见 shared-references/reviewer-routing.md。
• OUTPUT_DIR = review-stage/ — 所有审查阶段的输出都放在这里。如果目录不存在，则创建该目录。
• HUMAN_CHECKPOINT = false — 设为 true 时，每轮审查（Phase B）结束后暂停，并向用户展示分数和弱点。等待用户输入后再继续到 Phase C。用户可以：批准建议的修复、提供自定义修改说明、跳过特定修复，或提前停止循环。设为 false（默认值）时，循环将全程自主运行。
• COMPACT = false — 设为 true 时，（1）会在会话恢复时读取 EXPERIMENT_LOG.md 和 findings.md，而不是解析完整日志；（2）会在每轮结束后将关键发现追加到 findings.md。
• REVIEWER_DIFFICULTY = medium — 控制审查者的对抗性程度。分为三个级别：
  • medium（默认）：当前行为——基于 MCP 的审查，由执行者控制审查者看到的上下文。
  • hard：增加审查者记忆（审查者会在多轮中跟踪自身的疑点）+ 辩论协议（执行者可以反驳，由审查者裁定）。
  • nightmare：包含 hard 的所有内容 + 所选审查者直接读取代码仓库（Codex 路径上使用 codex exec）（执行者无法筛选审查者看到的内容）+ 对抗性验证（审查者会独立核查代码是否符合声明）。
• RENDER_HTML = true — 设为 true（默认值）时，循环终止后会通过 /render-html 自动将 review-stage/AUTO_REVIEW.md 渲染为 HTML。使用 --no-review（循环本身就是跨模型审查；HTML 是结构转换）。设为 false 可跳过，或传入 — render html: false。

⚠️ Nightmare 与 Manual 不兼容：如果 REVIEWER_BACKEND = manual 且 REVIEWER_DIFFICULTY = nightmare，则停止并显示： "difficulty: nightmare requires direct repository access and is not compatible with --reviewer: manual. Use difficulty: hard, or select a file-reading reviewer."

💡 覆盖设置：/auto-review-loop "topic" — compact: true, human checkpoint: true, difficulty: hard

审查者调用约定

在任何评审前确定评审者：调用 — reviewer: → 项目 .aris/reviewer.json → 主机默认值。使用 reviewer_route.py，参数为 --host claude-code --tier regular（或实际的 Copilot 主机），根据 integration-contract.md §2 和 reviewer-backends.md 解析。 只有在行内和项目中都未选择后端时，才进入下方的自动主机协议。 配置无效时返回 REVIEW_UNAVAILABLE。 确定主机默认值后，根据该后端解析项目模型/effort；切勿将模型选项带入其他提供方。

将解析出的路由、cwd 和会话 ID 保存到 REVIEW_STATE.json；恢复时还原这些信息，包括请求/报告的模型和实际 effort。提供方/模型/固定会话选项发生变化时，需要新会话。没有路由的旧版状态按下方现有的后端恢复流程处理。将明确的评审指示传递给子评审技能。下方的 Codex 固定配置/示例仅适用于 Codex。

调用评审者时，根据 REVIEWER_BACKEND 分支处理：

如果 REVIEWER_BACKEND ∈ {antigravity, grok, claude-code}： 按 reviewer-backends.md 中选定的首轮/回复协议执行，使用相同的实质性提示词、工件路径和记忆。将 cwd 设为包含评审输入的目录。Medium/hard 使用新会话，然后继续；nightmare 在选定路由上启动全新的对抗性会话以读取工件，并使用下方完整的 Nightmare 验证提示词。必须检查实际代码/结果，而不只是阅读执行者的报告。普通评审和 nightmare 的会话 ID 必须不同。反驳使用提出争议评审的会话。每次调用都要检查是否成功完成以及是否涵盖所需范围。派发前重置完成状态、范围和报告的身份；不得从上一轮继承这些信息。评审不可用或未完成时，返回 REVIEW_UNAVAILABLE。

如果既未提供行内评审者后端，也未提供项目评审者后端： 将 REVIEWER_BACKEND 设为 auto。在首轮的 Step -1，使用规范的四层辅助链解析 copilot_native_evidence.py。 生成新的绑定 <run_id>_r<round>_review_<8-random-hex>，并分别通过两个独立的根 Bash 调用依次调用 marker、等待，然后调用 challenge。 两次调用都要写入字面绑定值和具体解析出的辅助工具路径； Copilot Bash 调用之间不会共享变量。如果 challenge 绑定成功，将 REVIEWER_BACKEND 设为 copilot-native，并将同一个 challenge 用于首轮评审。不要在 Phase A 发起第二次激活 challenge。如果因当前没有绑定 Copilot 根会话而以状态码 3 退出，则使用 codex。 明确的评审指示可跳过此探测。如果辅助工具缺失，则无法进行原生验收；只有在确定外部后端可用时才使用 Codex，否则返回 REVIEW_UNAVAILABLE。

如果 REVIEWER_BACKEND = copilot-native： 读取 challenge 随机数和主机报告的执行者模型。调用主机的原生 task 工具，参数为 agent_type: rubber-duck；不要启动子进程，也不要指定评审者模型。提示词包含独立一行的精确文本 ARIS_REVIEW_NONCE=<nonce>、工件/差异路径、输出约定，以及（第 2 轮及之后的轮次）review-stage/REVIEWER_MEMORY.md。不得包含执行者摘要或修复叙述。task 完成后，调用 copilot_native_evidence.py verify 以创建证据和原始响应工件。验证器必须观察到一个成功关联的 rubber-duck 生命周期，以及已知且不同的主机报告模型系列。 将证据同时传递给 review_gate.py --native-evidence 和 save_trace.sh --backend copilot-native --native-evidence。符合条件的 原生肯定结论可以直接结束；无需外部终结器。原生否定结论将在下一轮使用新的 标记／挑战／子 Agent 继续。每次可能产生判定的原生调用（包括硬模式下的反驳 裁定）都必须有一组唯一的 <run_id, round, purpose> 工件，且恰好对应一个挑战。 缺失、同属／未知家族、格式错误、过期或不匹配的证据都不能作为判定依据。如果 无法进行原生互补调度，则只能回退到明确可用的相反家族后端： Anthropic/Google 执行器 → Codex；OpenAI 执行器 → 使用已报告的非 OpenAI 模型进行手动审查。 否则输出 REVIEW_UNAVAILABLE。完整协议： shared-references/reviewer-routing.md。

如果 REVIEWER_BACKEND = copilot： 必须提供 --executor-model： 如果未提供 → 输出 REVIEW_UNAVAILABLE。 根据 --executor-model 确定执行器家族（参见 reviewer-routing.md）。 路由器选择相反家族的配置文件：

• executor_family=openai → profile="aris-reviewer-claude"（anthropic）
• executor_family=anthropic → profile="aris-reviewer-openai"（openai）
• executor_family=google → profile="aris-reviewer-openai"（openai，默认跨家族配置）
• executor_family=unknown → REVIEW_UNAVAILABLE（关闭式失败）。 验证配置文件 .github/agents/<profile>.agent.md 是否存在。 如果缺失 → REVIEW_UNAVAILABLE。 读取其 model: 字段，将其值设为 REVIEWER_MODEL，根据该模型字符串推导 reviewer_family，并验证它与 executor_family 不同。通过子进程传递相同的值 --model；在 Auto 会话中，绝不可相信调用方提供的家族标签，也不可仅凭配置文件固定模型。 身份保证： --executor-model 是调用方声明的路由输入，不是运行时证明。 记录 executor_model_source: caller-declared、推导出的 family_relation 和 independence_verified: unverified。绝不可将一对不同的模型字符串提升为已独立验证。 能力门槛： copilot --help 必须列出 --model、--effort 和 --allow-tool；否则输出 REVIEW_UNAVAILABLE。 使用 copilot --agent 子进程（文档记录的 Copilot CLI 调用形式）， 并在每次审查调用中使用所选配置文件、--model "$REVIEWER_MODEL"、--effort xhigh 和 --allow-tool=read。 多轮审查： 每轮都要使用相同配置文件启动一个新的 copilot --agent 调用； 审查者记忆通过 review-stage/REVIEWER_MEMORY.md 工件传递。 如果 copilot CLI 不可用 → 本次驱动轮次输出 REVIEW_UNAVAILABLE； 不得静默改用其他传输方式。之后 Copilot 给出的肯定结论仍需要另行记录的 Codex／手动终结器。 完整的 copilot 合约参见 shared-references/reviewer-routing.md。

如果 REVIEWER_BACKEND = codex： 对新的审查线程使用 mcp__codex__codex。 对后续轮次使用 mcp__codex__codex-reply（复用 threadId）。

如果 REVIEWER_BACKEND = manual： 对新的审查线程使用 mcp__manual_review__review，并提供： prompt: [将发送给 Codex 的完全相同提示词] config: {"model_reasoning_effort": "xhigh", "executor_model": "", "require_reviewer_model": true} 保存返回的 threadId。 对后续轮次使用 mcp__manual_review__review_reply，并提供： threadId: [已保存的手动审查 threadId] prompt: [后续提示词] config: {"model_reasoning_effort": "xhigh", "executor_model": "", "require_reviewer_model": true} 可能产生判定的手动响应必须以 Reviewer-Model: <exact-model-id> 开头。根据该模型身份推导 reviewer_family。 缺失、未知或同属一个家族的身份不能作为无罪判定的依据；对于强制升级审查， 输出 REVIEW_UNAVAILABLE，不得猜测。 提示词保真度：人工审查任务必须与 Codex 收到的文本完全一致；传输过程只能添加必需的 Reviewer-Model: 响应格式说明。 审查追踪适用于所有后端。原生追踪数据取自重新验证过的主机事件产物，而非调用方声明的模型。

状态持久化（紧凑恢复）

长时间运行的循环可能会达到上下文窗口上限，从而触发自动压缩。为应对此情况，请在每轮结束后将状态持久化到 review-stage/REVIEW_STATE.json：

{
  "run_id": "run_20260713_a1b2c3d4",
  "round": 2,
  "threadId": null,
  "reviewer_profile": "rubber-duck",
  "reviewer_backend": "copilot-native",
  "executor_model": "claude-sonnet-4.6",
  "executor_model_source": "host-session-event",
  "executor_family": "anthropic",
  "requested_reviewer_model": null,
  "reported_reviewer_model": "gpt-5.5",
  "reviewer_model_source": "host-session-event",
  "reviewer_family": "openai",
  "family_relation": "different",
  "identity_assurance": "host_event_verified",
  "independence_verified": true,
  "native_evidence_id": "cne_0123456789abcdef0123456789abcdef",
  "native_evidence_path": "review-stage/COPILOT_NATIVE_run_20260713_a1b2c3d4_ROUND_2_REVIEW.evidence.json",
  "requires_external_acquittal": false,
  "status": "in_progress",
  "difficulty": "medium",
  "last_score": 5.0,
  "last_verdict": "not ready",
  "pending_experiments": ["screen_name_1"],
  "timestamp": "2026-03-13T21:00:00"
}

• run_id — 每次调用全局唯一。全新启动时生成，格式为 run_<YYYYMMDD>_<8-char-hex>（例如，run_20260713_a1b2c3d4）。在各轮写入期间保持不变。恢复时，从状态文件中读取并原样保留。这样可将所有轮次状态、审查者记忆追加内容和无罪确认收据绑定到同一次运行，防止先前调用中已完成的旧状态影响当前运行的无罪检查。

当 REVIEWER_BACKEND = copilot-native 时，保存证据 ID/路径，以及根据主机事件得出的执行器/审查者模型、派生系列和来源。每轮都会启动一个全新的橡皮鸭子子 Agent，因此会生成新的证据产物；没有持久化的子 Agent 句柄。当 REVIEWER_BACKEND = 兼容模式 copilot 时，保留 reviewer_profile、请求的模型、调用方声明的执行器模型、independence_verified: "unverified" 以及外部终结器义务。对于 codex，保存其 MCP threadId；对于 manual，保存 threadId 和报告的审查者身份。恢复时，使用 reviewer_backend 选择续接机制，并保留 requires_external_acquittal。

每次 Phase E 结束时写入此文件（记录完本轮后）。每次都覆盖——只需保留最新一轮的状态。同一次运行中，run_id 字段在覆盖写入时必须保持不变。

完成时（评估结果为肯定或达到最大轮数），将 "status": "completed"，以免后续调用意外恢复已结束的循环。

仅追加的外部最终审定回执

每当 Copilot 路径将裁定交给外部后端时——无论是在兼容性驱动审查通过后，还是在裁定前原生派发失败后——都必须在 review-stage/ACQUITTAL_LOG.jsonl 中维护一份仅追加的最终审定日志。每行记录完成该轮审查的 Codex／人工审查者。成功的原生结对审查轮次既不需要也不会写入此回执；其证据附属文件就是验收记录。为保持兼容，保留历史文件名：

{"run_id":"run_20260713_a1b2c3d4","round":3,"backend":"codex","effort":"xhigh","verdict":"ready","score":7.5,"executor_model":"claude-sonnet-4-5","executor_model_source":"caller-declared","executor_family":"anthropic","reviewer_model":"gpt-6-astra","reviewer_model_source":"requested","reviewer_family":"openai","family_relation":"different","identity_assurance":"caller_declared","independence_verified":"unverified","trace_id":"auto-review-loop/2026-07-13_run03","timestamp":"2026-07-13T14:22:00Z"}

规则（不可协商）：

规则	详情
仅追加	绝不删除、截断或覆盖行。只能使用 >>。
写入者	只有在 round_requires_external_acquittal 为 true 时，处于 xhigh 努力度的 codex 或 manual 轮次才能写入。Copilot 审查／派发绝不会自行写入最终审定行。
写入时机	在阶段 E 结束时，且经策略批准的最终审定者返回的分数 >= 6，且裁定 ∈ {"ready", "almost"} 之后。普通的默认 Codex 运行不需要此附属文件。
run_id 绑定	每行都包含当前 run_id 和轮次，以便审计 Copilot → 最终审定者的交接过程。
追踪关联	trace_id 必须引用 .aris/traces/ 中的真实追踪记录。回执中的来源和系列字段必须与该追踪记录完全一致。
身份诚实性	根据模型字符串重新推导 family_relation，但保留其来源。对于当前由调用方声明的执行器身份，写入 identity_assurance: "caller_declared" 和 independence_verified: "unverified"；绝不能将不同的字符串提升为独立认证。
不得覆盖	每轮都会覆盖 REVIEW_STATE.json（仅保留最新状态）。ACQUITTAL_LOG.jsonl 绝不会被覆盖——它是永久累积的记录。

存在原因： REVIEW_STATE.json 会在每轮被覆盖。该日志保留了兼容性驱动裁定或原生尝试失败并未自行终止的证据。成功的 copilot-native 裁定则使用其宿主事件证据附属文件。

输出协议

所有输出文件均须遵循以下通用协议：

• 输出版本控制协议 — 先写入带时间戳的文件，再复制到固定名称
• 输出清单协议 — 将每项输出记录到 MANIFEST.md
• 输出语言协议 — 遵循项目的语言设置

工作流

初始化

1. 检查是否存在 review-stage/REVIEW_STATE.json （若未找到，则回退到 ./REVIEW_STATE.json——旧版路径）：
   • 如果两个路径都不存在：全新启动（正常情况，与此功能存在之前的行为相同）
     • 生成 run_id：run_<YYYYMMDD>_<8-char-hex>（例如，run_20260713_a1b2c3d4）。使用 date +%Y%m%d 和 8 个随机十六进制字符。此 run_id 会在所有轮次写入中保持不变，并将免责回执绑定到本次调用。
   • 如果文件存在，且 status 为 "completed"：全新启动（上一轮循环已正常结束——但其 ACQUITTAL_LOG.jsonl 条目会作为审计记录保留，并带有各自的 run_id，对当前运行的停止门控无效）
     • 为本次调用生成新的 run_id。
   • 如果文件存在，且 status 为 "in_progress"，且 timestamp 早于 24 小时前：全新启动（来自已终止／已放弃运行的过期状态——删除文件并重新开始）
     • 生成新的 run_id。
   • 如果文件存在，且 status 为 "in_progress"，且 timestamp 在 24 小时内：恢复运行
     • 读取状态文件以恢复 run_id、round、threadId（或 Copilot 后端的证据／配置文件字段）、reviewer_backend、last_score、pending_experiments
     • 旧版向后兼容：如果状态文件中没有 reviewer_backend，则默认为 codex（Copilot 出现之前的状态未记录此字段）。如果没有 requires_external_acquittal，则默认为 false；旧版默认使用 Codex 的运行不得继承更严格的 Copilot 收尾器状态。如果状态文件中没有 run_id（run_id 出现之前的旧版状态），则生成新的 run_id 并记录日志："No run_id in legacy state file; assigned run_<...> for this resume."
     • 读取 review-stage/AUTO_REVIEW.md，恢复此前轮次的完整上下文 （回退到 ./AUTO_REVIEW.md）
     • 如果 pending_experiments 非空，检查它们是否已完成（例如，检查屏幕会话）
     • 从下一轮恢复（轮次 = 已保存轮次 + 1）
     • 使用 reviewer_backend 确定后续流程：Codex 使用 codex-reply；copilot-native 使用全新的标记／挑战／橡皮鸭／证据循环；兼容模式 copilot 使用带已保存配置文件／模型的全新 copilot --agent 子进程；手动模式使用 manual_review_reply
     • 记录日志："Recovered from context compaction. Resuming at Round N."
2. 阅读项目叙述文档、记忆文件和任何先前的评审文档。当 COMPACT = true 且存在精简文件时：读取 findings.md + EXPERIMENT_LOG.md，而不是完整的 review-stage/AUTO_REVIEW.md 和原始日志，以节省上下文窗口。
3. 阅读近期实验结果（检查输出目录、日志）
4. 根据先前评审，找出当前弱点和未完成的 TODO
5. 初始化轮次计数器 = 1（除非从状态文件恢复）
6. 创建／更新 review-stage/AUTO_REVIEW.md，写入标题和时间戳
7. 如果这是一次全新运行，且没有内联或项目评审后端，则将 REVIEWER_BACKEND 初始化为 auto。第 1 轮的步骤 -1 会执行激活，并在评审中使用 同一挑战。内联或项目评审选择会初始化为所选后端，并跳过激活。不要使用环境 启发式判断。

循环（最多重复 MAX_ROUNDS 次）

步骤 -1 — 解析自动后端并准备一个原生挑战：

• 如果 REVIEWER_BACKEND 为 auto，解析原生辅助工具，并依次运行一次根级 marker 调用和一次根级 challenge 调用。使用绑定值 <run_id>_r<round>_review_<8-random-hex>，并输出到 review-stage/COPILOT_NATIVE_<run_id>_ROUND_<round>_REVIEW.challenge.json。 已绑定的挑战会将 REVIEWER_BACKEND 设为 copilot-native，并将 NATIVE_CHALLENGE 设为该路径。退出码为 3／未绑定时，将 REVIEWER_BACKEND 设为 codex。任何其他失败都遵循 fail-closed 能力规则。
• 如果 REVIEWER_BACKEND 已为 copilot-native（后续轮次或恢复运行时），请按相同的 运行范围命名模式创建一组新的 marker/challenge，并设置 NATIVE_CHALLENGE。未绑定或无效的挑战 不能视为判定，也不能被悄然重新标记。
• 显式指定的外部后端或兼容后端在此步骤中不执行任何操作。

此处创建的挑战将由 Phase A 使用。同一次评审不要再运行另一组 marker/challenge。 运行范围内的文件名是仅追加的审计标识；绝不要传入 --replace 来复用较早调用的证据。

步骤 0 — 快照当前轮次状态： 步骤 -1 解析 auto 后，设置 round_backend = <当前 REVIEWER_BACKEND> 和 round_requires_external_acquittal = <当前 requires_external_acquittal，默认 false>。这些变量标记实际支配当前轮次的后端和义务。如果后续在 Phase B.5.1 中发生兼容驱动升级（copilot → codex/manual），快照仍保留升级前的值，而面向后续的状态则更新为下一轮的值。原生派发失败则不同，因为尚未进行评审：在调用评审器前，按 Phase A 的说明，将两个快照替换为外部回退值。成功的原生调用绝不会设置最终确认义务。Phase E 仅使用生成的快照记录或写入最终确认收据。

Phase A：评审

按 REVIEWER_BACKEND 和 REVIEWER_DIFFICULTY 路由。

对于 antigravity、grok 或 claude-code，使用上述调用约定，并保留以下提示词。 完成所选调用，保存其原始响应和实际报告的模型，然后进入 Phase B。选定其他路由后， 不要再回退到 Codex、Copilot 或 codex exec。

如果 REVIEWER_BACKEND = copilot-native，执行一次新的原生周期：

1. 使用 Step -1 准备的 NATIVE_CHALLENGE。它必须是本轮创建的、作用域限定于本次运行的 ..._ROUND_<round>_REVIEW.challenge.json 工件。 此处不要再次发出标记/挑战。
2. 读取返回的 nonce。调用宿主 Task 工具，设置 agent_type: rubber-duck、使用一个新名称，并确保提示词的第一行 恰好是 ARIS_REVIEW_NONCE=<nonce>。提供 claims、methods/code、 raw results、diff/current inputs 和 reviewer memory 的路径，而非执行器摘要。 要求只输出一个 Score: X/10 和一个 Verdict: ready | almost | not ready，并附上按优先级排序的弱点/最低限度修复/记忆更新。不要传入 model override：Copilot 的互补策略会选择模型。
3. Task 完成后，在新的根目录 Bash 调用中运行 python3 "<resolved-helper>" verify --challenge "$NATIVE_CHALLENGE" --output "review-stage/COPILOT_NATIVE_<run_id>_ROUND_<round>_REVIEW.evidence.json" --response-output "review-stage/COPILOT_NATIVE_<run_id>_ROUND_<round>_REVIEW.response.md"。Phase B 只能使用提取出的响应工件。
4. 退出码为 10（相同/未知系列）、生命周期不完整、响应无效或互补模型不可用，都不构成审查。应用 reviewer-routing.md 中相反系列的回退表；如果没有明确可用的选项， 输出 REVIEW_UNAVAILABLE。绝不要用斜杠提示词、 copilot --agent rubber-duck 或通用子 Agent 模拟 rubber-duck。将证据生成前的 调度失败记录为 --backend copilot-native --status error，且不附证据，然后单独记录实际回退；此错误记录在停止门处不具备 权限。回退前，运行 copilot_native_evidence.py validate-challenge --challenge "$NATIVE_CHALLENGE"，并且 EXECUTOR_MODEL 只能取自该命令的输出。然后：
   • Anthropic/Google 执行器 + 可用的 Codex → 在外部调用前将 REVIEWER_BACKEND 和 round_backend 都设为 codex。
   • OpenAI 执行器 + 报告已知非 OpenAI 模型的人工审查者 → 在外部调用前将这两个值都设为 manual。
   • 对这两种回退都设置 round_requires_external_acquittal=true，清空 NATIVE_EVIDENCE，并将已验证的执行器模型以及回退所用的已解析审查者模型传给 review_gate.py。这会有意使用更严格的外部最终审查分支，该分支会重新推导并强制要求不同系列。如果外部调用未返回可用的审查结果， 输出 REVIEW_UNAVAILABLE。 如果 REVIEWER_BACKEND = copilot，首先根据声明的执行器身份强制进行异系列路由：

• 要求提供 --executor-model <model> 参数。如果缺失 → REVIEW_UNAVAILABLE。停止。
• 根据 executor_model 推导 executor_family：
  • 模型名称包含 gpt、o1、o3、o4、chatgpt → openai
  • 模型名称包含 claude、sonnet、opus、haiku → anthropic
  • 模型名称包含 gemini → google
  • 其他任何情况 → unknown
• 如果 executor_family 为 unknown → REVIEW_UNAVAILABLE（默认拒绝）。停止。
• 将此视为路由选择，而非证明：持久化保存 executor_model_source: caller-declared；除非未来有稳定的运行时信号独立证明父执行器模型，否则推导出的 family_relation: different 仍保持 independence_verified: unverified。
• 路由器选择异系列配置：
  • openai → "aris-reviewer-claude"（anthropic，强制跨系列）
  • anthropic → "aris-reviewer-openai"（openai，强制跨系列）
  • google → "aris-reviewer-openai"（openai 默认配置）
• 确认配置文件 .github/agents/<profile>.agent.md 存在。 如果缺失 → REVIEW_UNAVAILABLE。停止。
• 读取配置文件 frontmatter 中第一个 model: 值，推导其系列，并确认该系列已知且不同于 executor_family。否则，默认拒绝。
• 确认 copilot --help 显示 --model、--effort 和 --allow-tool。 较旧版本或未固定版本的 CLI 均视为 REVIEW_UNAVAILABLE。
• 调整下方的 Codex MCP 调用，改用 copilot --agent 子进程 （Copilot CLI 文档中记录的调用形式）：
  • 将 mcp__codex__codex 替换为 copilot --agent "<profile>" --model "<parsed-model>" --effort xhigh --allow-tool=read --prompt "..."
  • 每轮都使用相同配置调用一次全新的 copilot --agent，并通过 review-stage/REVIEWER_MEMORY.md 产物传递各轮状态。
  • 提示词文本和 Review Tracing 与 Codex 路径相同。
  • 如果 copilot CLI 不可用 → REVIEW_UNAVAILABLE（不回退到 MCP）。
  • 如果 REVIEWER_DIFFICULTY = nightmare，则跳过 Copilot（nightmare 要求使用 Codex exec）：输出 REVIEW_UNAVAILABLE。 请参阅 shared-references/reviewer-routing.md。

如果 REVIEWER_BACKEND ∈ {codex, manual}： 根据上文的 Reviewer Calling Convention，使用对应后端的 MCP 调用。无论使用哪个后端，提示词文本都相同。

中等（默认）——MCP 审查

使用所选后端，向独立审查者发送完整上下文。

对于 codex 后端：

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    [Round N/MAX_ROUNDS of autonomous review loop]

    Review the work directly from its artifacts — executor notes are not
    evidence, so read the files yourself rather than trusting my framing:
    - Claims / paper draft: <path>
    - Methods / code under review: <path(s)>
    - Raw results (verbatim files, not a summary): <path(s)>
    - Changed since last round: <changed-file paths> — read the diff, not my description

    Please act as a senior ML reviewer (NeurIPS/ICML level). Start from the
    assumption that the work is broken somewhere — your job is to find where.
    Be adversarial. Trust nothing the author tells you — verify everything
    yourself.

    1. Score this work 1-10 for a top venue
    2. List remaining critical weaknesses (ranked by severity)
    3. For each weakness, specify the MINIMUM fix (experiment, analysis, or reframing)
    4. State clearly: is this READY for submission? Yes/No/Almost

    Be brutally honest. If, after genuinely trying to break it, the work holds
    up and is ready, say so clearly.

    === SCOPE LIMITS (these bound what you PROPOSE, never what you look for) ===
    Report anything that is actually wrong here — including a rare-looking case, if
    this repo actually produces it. Then keep the fix in scope:
    1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is
       welcome; over-defense is not. Assume a cooperating operator on their own
       machine — a malicious local user is NOT in the threat model.
    2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes.
       Reporting a real defect in hashing code that already exists is fine.
    3. NO speculative machinery: do not add feature flags, migration frameworks,
       compat layers, wrappers, pins, or similar mechanisms unless evidence shows
       a current repo defect they fix or an explicit existing invariant they must
       preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels,
       not evidence. Point to the failing path/artifact or invariant, and check the
       proposal's factual premises, such as whether a named package version exists.
    4. NO corner-case obsession: exotic encodings, symlink races, RTL text and
       millisecond races are out of scope unless you can show the case arises here.
    5. Where a rubric or checklist is genuinely needed, do not over-mechanize
       judgement. A clear sentence a human reads beats a scored table nobody
       maintains.
    Exception: code that runs remote commands, starts a network service, or installs
    an MCP server runs on the user's machine with their credentials — trust-boundary
    findings there are in scope and the default is strict.
    Say plainly when something is correct. Do not manufacture findings.

对于 manual 后端： 使用 mcp__manual_review__review，并传入上文的 prompt 文本以及 config: {"model_reasoning_effort": "xhigh", "executor_model": "<actual executor model>", "require_reviewer_model": true}。保存返回的 threadId。

如果这是第 2 轮或之后的轮次，使用 mcp__codex__codex-reply（codex）或 mcp__manual_review__review_reply（manual），并传入已保存的 threadId。

高难度——MCP 审查 + 审查者记忆

与中等难度相同，但在提示词前添加审查者记忆。使用所选后端。

对于 codex 后端：

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    [Round N/MAX_ROUNDS of autonomous review loop]

    ## Your Reviewer Memory (persistent across rounds)
    [Paste full contents of review-stage/REVIEWER_MEMORY.md here]

    IMPORTANT: You have memory from prior rounds. Check whether your
    previous suspicions were genuinely addressed or merely sidestepped.
    The author (the executor model) controls what context you see — be skeptical
    of convenient omissions.

    Review directly from the artifacts (paths below) — read the files yourself:
    - Claims / methods / code: <path(s)>
    - Raw results: <path(s)>
    - Changed since last round: <changed-file paths> (read the raw diff)

    Please act as a senior ML reviewer (NeurIPS/ICML level).
    1. Score this work 1-10 for a top venue
    2. List remaining critical weaknesses (ranked by severity)
    3. For each weakness, specify the MINIMUM fix
    4. State clearly: is this READY for submission? Yes/No/Almost
    5. **Memory update**: List any new suspicions, unresolved concerns,
       or patterns you want to track in future rounds.

    Be brutally honest. Actively look for things the author might be hiding.

    === SCOPE LIMITS (these bound what you PROPOSE, never what you look for) ===
    Report anything that is actually wrong here — including a rare-looking case, if
    this repo actually produces it. Then keep the fix in scope:
    1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is
       welcome; over-defense is not. Assume a cooperating operator on their own
       machine — a malicious local user is NOT in the threat model.
    2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes.
       Reporting a real defect in hashing code that already exists is fine.
    3. NO speculative machinery: do not add feature flags, migration frameworks,
       compat layers, wrappers, pins, or similar mechanisms unless evidence shows
       a current repo defect they fix or an explicit existing invariant they must
       preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels,
       not evidence. Point to the failing path/artifact or invariant, and check the
       proposal's factual premises, such as whether a named package version exists.
    4. NO corner-case obsession: exotic encodings, symlink races, RTL text and
       millisecond races are out of scope unless you can show the case arises here.
    5. Where a rubric or checklist is genuinely needed, do not over-mechanize
       judgement. A clear sentence a human reads beats a scored table nobody
       maintains.
    Exception: code that runs remote commands, starts a network service, or installs
    an MCP server runs on the user's machine with their credentials — trust-boundary
    findings there are in scope and the default is strict.
    Say plainly when something is correct. Do not manufacture findings.

噩梦级——Codex Exec（GPT 直接读取仓库）

对于 REVIEWER_BACKEND = codex，使用 codex exec 直接审查此仓库。新的 MCP 路由会按上文所述使用全新的文件读取会话，并遵守相同的验证要求：

codex exec "$(cat <<'PROMPT'
You are an adversarial senior ML reviewer (NeurIPS/ICML level).
This is Round N/MAX_ROUNDS of an autonomous review loop.

## Your Reviewer Memory (persistent across rounds)
[Paste full contents of review-stage/REVIEWER_MEMORY.md]

## Instructions
You have FULL READ ACCESS to this repository. The author (the executor model) does NOT
control what you see — explore freely. Your job is to find problems the
author might hide or downplay.

DO THE FOLLOWING:
1. Read the experiment code, results files (JSON/CSV), and logs YOURSELF
2. Verify that reported numbers match what's actually in the output files
3. Check if evaluation metrics are computed correctly (ground truth, not model output)
4. Look for cherry-picked results, missing ablations, or suspicious hyperparameter choices
5. Read NARRATIVE_REPORT.md or review-stage/AUTO_REVIEW.md for the author's claims — then verify each against code

OUTPUT FORMAT:
- Score: X/10
- Verdict: ready / almost / not ready
- Verified claims: [which claims you independently confirmed]
- Unverified/false claims: [which claims don't match the code or results]
- Weaknesses (ranked): [with MINIMUM fix for each]
- Memory update: [new suspicions and patterns to track next round]

Be adversarial. Trust nothing the author tells you — verify everything yourself.

=== SCOPE LIMITS (these bound what you PROPOSE, never what you look for) ===
Report anything that is actually wrong here — including a rare-looking case, if
this repo actually produces it. Then keep the fix in scope:
1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is
   welcome; over-defense is not. Assume a cooperating operator on their own
   machine — a malicious local user is NOT in the threat model.
2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes.
   Reporting a real defect in hashing code that already exists is fine.
3. NO speculative machinery: do not add feature flags, migration frameworks,
   compat layers, wrappers, pins, or similar mechanisms unless evidence shows
   a current repo defect they fix or an explicit existing invariant they must
   preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels,
   not evidence. Point to the failing path/artifact or invariant, and check the
   proposal's factual premises, such as whether a named package version exists.
4. NO corner-case obsession: exotic encodings, symlink races, RTL text and
   millisecond races are out of scope unless you can show the case arises here.
5. Where a rubric or checklist is genuinely needed, do not over-mechanize
   judgement. A clear sentence a human reads beats a scored table nobody
   maintains.
Exception: code that runs remote commands, starts a network service, or installs
an MCP server runs on the user's machine with their credentials — trust-boundary
findings there are in scope and the default is strict.
Say plainly when something is correct. Do not manufacture findings.
PROMPT
)" --skip-git-repo-check 2>&1

主要区别：在噩梦模式下，GPT 会独立读取代码、结果文件和日志。Claude 无法筛选或整理 GPT 看到的内容。这最接近由真正持敌对态度的审查者阅读你的实际论文及补充材料。

阶段 B：解析评估结果

关键：逐字保存评审者的完整原始回复（存入变量，供阶段 E 使用）。对于 copilot-native，必须使用证据辅助工具提取的回复产物，绝不能使用执行者复制的文本。请勿丢弃或概述——原始文本是主要记录。

然后提取结构化字段：

• 分数（数值，1-10）
• 判定（“ready” / “almost” / “not ready”）
• 待办事项（按优先级排序的修复项）

阶段 B.5：更新评审者记忆

解析评估结果后，将内容追加到规范记忆产物 review-stage/REVIEWER_MEMORY.md。两个 Copilot 后端都依赖此文件维持各轮之间的连续性（每个原生子 Agent 或兼容性子进程都是全新的），因此无论 REVIEWER_DIFFICULTY 如何设置，都要执行此更新。不得回退到项目根目录；首次追加前请创建 review-stage/：

# Reviewer Memory

## Round 1 — Score: X/10

### Raw Reviewer Response (verbatim)
[Paste the COMPLETE raw reviewer response here — never summarized or curated by the executor.]

### Memory Update
[Reviewer's own memory update section, if provided — verbatim.]
- **Suspicion**: [what the reviewer flagged]
- **Unresolved**: [concerns not yet addressed]
- **Patterns**: [recurring issues the reviewer noticed]

---

## Round 2 — Score: X/10

### Raw Reviewer Response (verbatim)
[Paste the COMPLETE raw reviewer response here.]

### Memory Update
- **Previous suspicions addressed?**: [yes/no for each, with reviewer's judgment]
- **New suspicions**: [...]
- **Unresolved**: [carried forward + new]

---

规则：

• 仅追加——绝不删除，绝不截断。 此文件是由评审者维护的审计跟踪记录。执行者绝不能概述、整理或编辑先前轮次的内容。逐字追加评审者本轮的完整原始回复，然后在评审者提供记忆更新时追加记忆更新部分。
• 每轮追加的内容都必须是评审者自己的原话——如果评审者的回复包含“Memory update”部分，请将其逐字复制到原始回复之后，作为 ## Round N — Memory Update 子节。
• 下一轮的阶段 A 会将此文件传回给评审者——这是评审者的持久记忆。
• 每次调用评审者之前记录文件的 SHA-256 哈希值，并通过 --memory-hash 传给 save_trace.sh。哈希值应针对提供给本次调用的记忆（调用前的产物），而不是追加后的版本，以便跟踪记录能证明本次调用时使用的是哪份记忆。
• 如果分数逐轮下降，不要只写一条新的记忆： 先对 .aris/traces/ 中两轮的原始 .response.md 文件进行差异比较，找出 发生变化的具体标准（参见 shared-references/review-tracing.md § Debugging With Traces）。记忆文件只是摘要；跟踪记录才是证据。

阶段 B.5.1：停止评估门控

此步骤计算候选转换，而不是立即退出。如果在阶段 B.6 提出了强硬/噩梦级别的反驳，请先完成反驳，并在阶段 E 之前根据最终裁定重新计算门控。只有阶段 E 可以持久化成功停止状态/回执；此前的肯定结果不能跳过待处理的反驳或噩梦验证。

停止条件——按 round_backend（本轮实际运行的后端）分支，绝不能按面向未来的 REVIEWER_BACKEND 分支。使用 review_gate.py 中的可执行转换表；通过 shared-references/integration-contract.md §2 中的规范辅助工具链解析它。其 JSON decision 和 next_backend 字段具有权威性。如果无法解析或执行该辅助工具，请输出 REVIEW_UNAVAILABLE；不得自行推断转换。

每个已完成轮次调用一次门控。只传入模型字符串——辅助工具会在内部推导系列，不接受调用方提供的系列标签。必须根据当前主机的工具配置明确确认后端是否可用；两个终结器默认均不可用：

cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" || exit 1
if [ -z "${ARIS_REPO:-}" ] && [ -f .aris/installed-skills.txt ]; then
    ARIS_REPO=$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills.txt 2>/dev/null) || true
fi
if [ -z "${ARIS_REPO:-}" ] && [ -f "$HOME/.aris/repo" ]; then
    ARIS_REPO=$(cat "$HOME/.aris/repo" 2>/dev/null) || true
fi
REVIEW_GATE=".aris/tools/review_gate.py"
[ -f "$REVIEW_GATE" ] || REVIEW_GATE="tools/review_gate.py"
[ -f "$REVIEW_GATE" ] || { [ -n "${ARIS_REPO:-}" ] && REVIEW_GATE="$ARIS_REPO/tools/review_gate.py"; }
[ -f "$REVIEW_GATE" ] || REVIEW_GATE=""
[ -n "$REVIEW_GATE" ] || { echo "REVIEW_UNAVAILABLE: review_gate.py not resolved" >&2; exit 1; }

GATE_REVIEWER_MODEL="${REPORTED_REVIEWER_MODEL:-${REQUESTED_REVIEWER_MODEL:-${REVIEWER_MODEL:-}}}"
# New routes require this call's reported identity, never the requested alias.
case "$round_backend" in
  antigravity|grok|claude-code) GATE_REVIEWER_MODEL="${REPORTED_REVIEWER_MODEL:-}" ;;
esac
GATE_ARGS=(
  --round-backend "$round_backend"
  --score "$SCORE"
  --verdict "$VERDICT"
  --executor-model "${EXECUTOR_MODEL:-}"
  --reviewer-model "$GATE_REVIEWER_MODEL"
)
case "$round_backend" in
  antigravity|grok|claude-code)
    GATE_ARGS+=(--review-status "${REVIEW_STATUS:-error}")
    [[ "${REVIEW_COMPLETED:-false}" != true ]] || GATE_ARGS+=(--review-completed)
    [[ "${REVIEW_SCOPE_COMPLETE:-false}" != true ]] || GATE_ARGS+=(--review-scope-complete)
    ;;
esac
if [[ "$round_backend" == "copilot-native" ]]; then
  [[ -n "${NATIVE_EVIDENCE:-}" ]] || {
    echo "REVIEW_UNAVAILABLE: native round has no evidence artifact" >&2
    exit 1
  }
  GATE_ARGS+=(--native-evidence "$NATIVE_EVIDENCE")
fi
if [[ "$round_requires_external_acquittal" == "true" ]]; then
  GATE_ARGS+=(--requires-external-acquittal)
fi
if [[ "${CODEX_AVAILABLE:-false}" == "true" ]]; then
  GATE_ARGS+=(--codex-available)
fi
if [[ "${MANUAL_AVAILABLE:-false}" == "true" ]]; then
  GATE_ARGS+=(--manual-available)
fi
if [[ "${MANUAL_IDENTITY_REPORTED:-false}" == "true" ]]; then
  GATE_ARGS+=(--manual-identity-reported)
fi
GATE_JSON=$(python3 "$REVIEW_GATE" "${GATE_ARGS[@]}") || {
  echo "REVIEW_UNAVAILABLE: review gate execution failed" >&2
  exit 1
}

将 GATE_JSON 解析为 JSON；绝不能根据辅助工具的文字说明性 reason 推断转换。review_unavailable 判定为终止状态。对于 escalate 或 continue，将 next_backend 和 requires_external_acquittal 复制到面向未来的状态中；只有 stop 才进入成功终止路径。

• **Antigravity/Grok/Claude Code：**使用实际报告的模型、成功调用状态，以及经过核验的完成情况/范围。模型系列未知或审核不完整时，返回 review_unavailable；负面结果则继续。符合条件的正面结果可以按门控器返回的结果，以 same-family / provisional 或 cross-family / accepted 停止。持久化这些值；传输名称不能确定模型系列。
• **默认 Codex 兼容模式（round_backend = codex，round_requires_external_acquittal = false）：**评分 >= 6 且判定 ∈ {"ready", "almost"} 时，按 Copilot 集成前的原有行为停止。执行器身份仅作为追踪元数据提供，可以缺失；不要将有效的默认 Codex 正面判定转为 REVIEW_UNAVAILABLE。此路径不会写入外部最终审核回执。
• **现有 Oracle/Agy 路由：**在 Copilot 最终审核状态之外显式选择时，其符合条件的正面判定仍保留 Copilot 集成前的停止行为。当 requires_external_acquittal=true 时，它们不能作为有效替代；该状态仅允许 Codex/手动审核。
• **显式手动后端：**正面判定仍要求响应中包含完全匹配的 Reviewer-Model: 标头。缺少身份信息时，返回 REVIEW_UNAVAILABLE。
• **原生 Copilot 轮次（round_backend = copilot-native）：**证据文件为必需项，且由门控器重新验证。由响应得出的 Score/Verdict 必须与 CLI 字段一致。符合条件的正面结果返回 decision: stop 和 identity_assurance: host_event_verified；负面结果则在 copilot-native 上返回 continue。不会设置外部最终审核状态。
• **兼容模式 Copilot 驱动轮次（round_backend = copilot）：**此路径绝不会停止循环。负面判定会在兼容模式 Copilot 上继续。正面判定会返回 decision: escalate，设置 requires_external_acquittal: true，并根据调用方声明的执行器系列选择下一个后端：
  • anthropic 或 google → 有 Codex 时选择 Codex，否则选择手动审核；
  • openai → 仅手动审核（Codex 属于同一系列）；
  • unknown 或没有策略认可的最终审核器 → REVIEW_UNAVAILABLE。
• **外部最终审核轮次（round_requires_external_acquittal = true）：**仅当模型字符串可确定为已知且不同的系列时，Codex/手动审核才可在符合条件的正面判定后停止；手动审核还要求提供其报告的模型标头。这是严格关闭的路由一致性要求，并非独立的执行器认证。记录 identity_assurance: caller_declared 和 independence_verified: "unverified"。最终审核器给出负面判定时，在同一最终审核后端继续，并保留该义务。

兼容模式 Copilot 升级时，在 REVIEW_STATE.json 中更新前瞻性的 reviewer_backend 和 requires_external_acquittal；为 Phase E 保持 round_backend 和 round_requires_external_acquittal 不变。最终审核器返回符合条件的正面判定后，将前瞻标志设为 false 并停止。ACQUITTAL_LOG.jsonl 是仅追加的审核回执，绝不能作为输入，让后续兼容模式 Copilot 判定停止循环。原生证据会直接评估，绝不会查询该日志。

此评估在 Phase B.5 之后运行，以确保终止轮次记忆在退出前始终追加到 review-stage/REVIEWER_MEMORY.md。

阶段 B.6：辩论协议（仅限 hard + nightmare）

如果 REVIEWER_DIFFICULTY = medium，则完全跳过。

解析评审意见后，执行者有机会进行反驳：

步骤 1 — 执行者反驳：

针对评审者指出的每项弱点，执行者撰写结构化回复：

### Rebuttal to Weakness #1: [title]
- **Accept / Partially Accept / Reject**
- **Argument**: [why this criticism is invalid, already addressed, or based on a misunderstanding]
- **Evidence**: [point to specific code, results, or prior round fixes]

执行者反驳规则：

• 必须诚实——不得捏造证据或歪曲结果
• 可以指出评审中的事实错误（评审者误读代码、指标有误等）
• 可以论证某项弱点超出范围，或解决它需要付出不合理的工作量
• 每轮最多反驳 3 项（选择影响最大的项目进行质疑）

步骤 2 — 评审者对反驳作出裁定：

将执行者的反驳发回给评审者，请其作出裁定：

*对于 antigravity/grok/claude-code，在 hard 或 nightmare 模式下：*使用已保存评审会话的续接协议，并提供相同的反驳和证据。检查此裁定是否已完成且范围合适，保存其原始响应，并针对更新后的 Score/Verdict 和实际模型重新运行门禁，然后再保存停止决策。

Hard 模式 — 在反驳步骤中使用所选后端：

*对于 copilot-native：*运行新的标记/挑战，并调用一个全新的原生 rubber-duck Task。提供 review-stage/REVIEWER_MEMORY.md、原始评审响应和 review-stage/ROUND_${ROUND}_REBUTTAL.md 的路径；要求其自行核实引用的文件并返回更新后的 Score/Verdict。使用不同的、按运行范围区分的 ..._ROUND_<round>_REBUTTAL.challenge.json、.evidence.json 和 .response.md 工件，核实该裁定确实包含 Verdict。停止门禁和追踪中使用这些证据（而非辩论前的证据）。

*对于 compatibility copilot：*使用相同配置文件 + review-stage/REVIEWER_MEMORY.md 上下文启动全新的 copilot --agent 子进程：

# Store the generated rebuttal as data; never paste memory/rebuttal text into
# a heredoc body, because either may contain a line matching its delimiter.
MEMORY_FILE="review-stage/REVIEWER_MEMORY.md"
REBUTTAL_FILE="review-stage/ROUND_${ROUND}_REBUTTAL.md"
[[ -f "$MEMORY_FILE" && -f "$REBUTTAL_FILE" ]] || {
  echo "REVIEW_UNAVAILABLE: missing memory or rebuttal artifact" >&2
  exit 1
}
PROMPTFILE="$(mktemp)" || { echo "REVIEW_UNAVAILABLE: mktemp failed" >&2; exit 1; }
trap 'rm -f "$PROMPTFILE"' EXIT
{
cat <<'ARIS_REBUTTAL_HEADER'
[Rebuttal ruling — same reviewer]

## Your Memory From Previous Rounds
ARIS_REBUTTAL_HEADER
cat -- "$MEMORY_FILE"
cat <<'ARIS_REBUTTAL_MIDDLE'

The author rebuts your review:
ARIS_REBUTTAL_MIDDLE
cat -- "$REBUTTAL_FILE"
cat <<'ARIS_REBUTTAL_FOOTER'

For each rebuttal, rule:
- SUSTAINED (author's argument is valid, withdraw this weakness)
- OVERRULED (your original criticism stands, explain why)
- PARTIALLY SUSTAINED (revise the weakness to a narrower scope)

Then update your score if any weaknesses were withdrawn.
Include a Memory Update section at the end of your response.
ARIS_REBUTTAL_FOOTER
} > "$PROMPTFILE"
copilot --agent "$REVIEWER_PROFILE" --model "$REVIEWER_MODEL" \
  --effort xhigh --allow-tool=read --prompt "$(cat "$PROMPTFILE")"

对于 codex：

mcp__codex__codex-reply:
  threadId: [saved]
  # inherits the thread's model/effort — do not re-send
  prompt: |
    The author rebuts your review:

*对于 manual：*使用相同的 threadId 和提示词调用 mcp__manual_review__review_reply。

提示词内容：

    The author rebuts your review:

    [paste executor's rebuttal]

    For each rebuttal, rule:
    - SUSTAINED (author's argument is valid, withdraw this weakness)
    - OVERRULED (your original criticism stands, explain why)
    - PARTIALLY SUSTAINED (revise the weakness to a narrower scope)

    Then update your score if any weaknesses were withdrawn.

Nightmare 模式（codex exec）：

codex exec "$(cat <<'PROMPT'
You are the same adversarial reviewer. The author rebuts your review:

[paste executor's rebuttal]

VERIFY the author's evidence claims yourself — read the files they reference.
Do NOT take their word for it.

For each rebuttal, rule:
- SUSTAINED (verified and valid)
- OVERRULED (evidence doesn't check out or argument is weak)
- PARTIALLY SUSTAINED (partially valid, narrow the weakness)

Update your score. Update your memory.
PROMPT
)" --skip-git-repo-check 2>&1

步骤 3 — 根据裁定更新分数和待办事项：

• 已维持（SUSTAINED）的弱点：从待办事项中移除
• 已推翻（OVERRULED）：保持不变
• 部分维持（PARTIALLY SUSTAINED）：调整范围

将完整辩论记录附加到 review-stage/AUTO_REVIEW.md 中该轮对应的条目下。

人工检查点（如已启用）

如果 HUMAN_CHECKPOINT = false，则完全跳过此步骤。

当 HUMAN_CHECKPOINT = true 时，展示评审结果并等待用户输入：

📋 Round N/MAX_ROUNDS review complete.

Score: X/10 — [verdict]
Top weaknesses:
1. [weakness 1]
2. [weakness 2]
3. [weakness 3]

Suggested fixes:
1. [fix 1]
2. [fix 2]
3. [fix 3]

Options:
- Reply "go" or "continue" → implement all suggested fixes
- Reply with custom instructions → implement your modifications instead
- Reply "skip 2" → skip fix #2, implement the rest
- Reply "stop" → end the loop, document current state

等待用户回复。解析其输入：

• 批准（“go”“continue”“ok”“proceed”）：携带所有建议的修复进入阶段 C
• 自定义指示（其他任何文本）：将其视为阶段 C 的补充/替代指引。酌情与评审者建议合并
• 跳过特定修复（“skip 1,3”）：从待办列表中移除这些修复
• 停止（“stop”“enough”“done”）：终止循环，跳转到终止阶段

飞书通知（如已配置）

解析分数后，检查 ~/.claude/feishu.json 是否存在且模式不是 "off"：

• 发送 review_scored 通知：“第 N 轮：X/10 — [verdict]”，并附上排名前三的弱点
• 如果处于交互模式且 Verdict 为 “almost”：将其作为检查点发送，并等待用户回复是继续还是停止
• 如果配置不存在或模式为 off：完全跳过（不执行任何操作）

阶段 C：实施修复（如未停止）

按优先级从高到低处理每项待办事项：

1. 代码更改：编写/修改实验脚本、模型代码、分析脚本
2. 运行实验：通过 SSH + screen/tmux 部署到 GPU 服务
3. 分析：运行评估、收集结果、更新图表/表格
4. 文档：更新项目笔记和评审文档

优先级规则：

• 跳过需要过多计算资源的修复（标记为需人工跟进）
• 跳过依赖不可用外部数据/模型的修复
• 如果重新构建表述/分析和新实验都能解决问题，优先选择前者
• 始终实施指标增补（成本低、影响大）

阶段 D：等待结果

如果已启动实验：

• 监控远程会话，直到完成
• 从输出文件和日志中收集结果
• 训练质量检查——如果已配置 W&B，则调用 /training-check，确认训练状态正常（无 NaN、无发散、无停滞）。如果 W&B 不可用，则静默跳过。在下一轮审核中标记任何质量问题。

阶段 E：记录本轮

追加到 review-stage/AUTO_REVIEW.md：

## Round N (timestamp)

### Assessment (Summary)
- Score: X/10
- Verdict: [ready/almost/not ready]
- Key criticisms: [bullet list]

### Reviewer Raw Response

<details>
<summary>Click to expand full reviewer response</summary>

[Paste the COMPLETE raw response from the reviewer here — verbatim, unedited.
This is the authoritative record. Do NOT truncate or paraphrase.]

</details>

### Debate Transcript (hard + nightmare only)

<details>
<summary>Click to expand debate</summary>

**Executor Rebuttal:**
[paste rebuttal]

**Reviewer Ruling:**
[paste ruling — SUSTAINED / OVERRULED / PARTIALLY SUSTAINED for each]

**Score adjustment**: X/10 → Y/10

</details>

### Actions Taken
- [what was implemented/changed]

### Results
- [experiment outcomes, if any]

### Status
- [continuing to round N+1 / stopping]
- Difficulty: [medium/hard/nightmare]

写入 review-stage/REVIEW_STATE.json，包含当前的 run_id、轮次、threadId、已解析的路由/会话/cwd、请求和报告的模型/实际 effort、完成情况/范围、独立性/验收情况、评分、判定、reviewer_backend、requires_external_acquittal 和待处理实验。run_id 字段 MUST 从初始化开始保持不变；每轮都不要重新生成。

对于 antigravity、grok 或 claude-code 的肯定停止，在 ACQUITTAL_LOG.jsonl 中追加一条回执，记录本次运行/轮次/后端、实际模型/effort、评分/判定、门禁独立性/验收情况以及实际 trace 路径。这是本轮的审计记录，不是授予后续验收的输入。暂定停止必须继续标记为暂定。下方现有的 Copilot 最终确认回执保持独立且不变。

状态文件中的后端标记： REVIEW_STATE.json 中的 reviewer_backend 字段控制下一轮的续接机制（恢复时使用），而不是刚记录的这一轮。在阶段 E 中：

• 使用 round_backend（在第 0 步的轮次开始时快照）标记 AUTO_REVIEW.md 文档中的当前轮次（例如，“审核后端：copilot-native”）。
• 使用 round_requires_external_acquittal 判断当前轮次是否由 Copilot 触发最终确认。在状态文件中，将 requires_external_acquittal 写为面向下一轮的义务。
• 将 REVIEW_STATE.json 中的 reviewer_backend 写为应控制下一轮的值——它要么是（a）当前轮次的后端（若未发生升级，则保持不变），要么是（b）在阶段 B.5.1 中设置的升级后端。绝不要用 round_backend 替代这个面向下一轮的字段。
• 如果未发生升级，则 round_backend == reviewer_backend（自然安全）。
• 对于 native 轮次，持久化 native_evidence_id、native_evidence_path、两个 host-event 模型 ID/来源、family_relation: different 和 identity_assurance: host_event_verified。绝不要从文字说明中复制这些字段。

如果 round_backend ∈ {codex, manual} 且 round_requires_external_acquittal = true 且 score >= 6 且 verdict ∈ {"ready", "almost"}： 向 review-stage/ACQUITTAL_LOG.jsonl 追加一条外部最终确认记录：

{"run_id":"<current-run_id>","round":<N>,"backend":"<codex|manual>","effort":"xhigh","verdict":"<ready|almost>","score":<score>,"executor_model":"<from-trace>","executor_model_source":"caller-declared","executor_family":"<derived-from-executor_model>","reviewer_model":"<from-trace-or-manual-Reviewer-Model>","reviewer_model_source":"<requested|backend-reported>","reviewer_family":"<derived-from-reviewer_model>","family_relation":"different","identity_assurance":"caller_declared","independence_verified":"unverified","trace_id":"<skill>/<YYYY-MM-DD>_run<NN>","timestamp":"<ISO8601>"}

使用 >>（追加），绝不要使用 >。根据模型字符串重新推导两个 family，并拒绝未知或属于同一 family 的组合，但原样复制模型来源和 assurance 字段，不要将其升级。trace_id MUST 是 .aris/traces/ 下相对于该目录的实际 trace 目录路径（例如 auto-review-loop/2026-07-13_run01），且与 save_trace.sh 中的 RUN_ID 格式一致：<YYYY-MM-DD>_run<NN>，并带有 skill 名称子目录前缀。不要伪造合成的 trace_... 标识符。

追加到 findings.md（当 COMPACT = true 时）：本轮每个关键发现各写一行：

- [Round N] [positive/negative/unexpected]: [one-sentence finding] (metric: X.XX → Y.YY)

轮次计数器加一 → 返回阶段 A。

终止

循环结束时（评估为正面或达到最大轮数）：

1. 将 review-stage/REVIEW_STATE.json 中的 "status" 更新为 "completed"
2. 将最终摘要写入 review-stage/AUTO_REVIEW.md
3. 根据结论更新项目笔记
4. 编写方法／流程描述，并将其写入 review-stage/AUTO_REVIEW.md 的 ## Method Description 部分——用简洁的 1–2 段描述最终方法、其架构和数据流。这将作为工作流 3 中 /paper-illustration 的输入，使其能够自动生成架构图。
5. 根据结果生成论点——调用 /result-to-claim，将 review-stage/AUTO_REVIEW.md 中的实验结果转换为结构化的论文论点。输出：CLAIMS_FROM_RESULTS.md。这将工作流 2 与工作流 3 衔接起来，使 /paper-plan 能直接使用经过验证的论点，而不必从头提取。如果未安装 /result-to-claim，则跳过此步骤（不生成 CLAIMS_FROM_RESULTS.md；/paper-plan 按照之前的做法从叙述中提取论点），但绝不能伪造该文件或其中的判定结果。如果该命令已运行，但其输出以 verdict: REVIEW_UNAVAILABLE 开头，则保留该文件原样（不要覆盖或改述），并在 AUTO_REVIEW.md 中注明论点尚未裁定——后续论文阶段不得将其视为已验证。
6. 如果在没有正面评估的情况下达到最大轮数而停止：
   • 列出剩余阻碍因素
   • 估算逐项解决所需的工作量
   • 建议手动继续还是调整方向
7. 飞书通知（如已配置）：发送包含最终分数变化表的 pipeline_done
8. 渲染 HTML 视图（如果 RENDER_HTML = true，默认值）：对累积的审查日志调用 /render-html：

   /render-html "review-stage/AUTO_REVIEW.md" --no-review --state review-stage/REVIEW_STATE.json
   

   显式传入 --state（辅助程序不会自动发现旁置文件）。如果 REVIEW_STATE.json 不存在，则省略 --state 标志。HTML 文件将生成于 review-stage/AUTO_REVIEW.html，并嵌入源文件的 SHA256。非阻塞：如果 /render-html 失败，记录错误并继续——HTML 只是便捷功能，并非终止的前提条件。如果 RENDER_HTML = false，则跳过。

关键规则

• 大文件处理：如果 Write 工具因文件大小而失败，立即改用 Bash（cat << 'EOF' > file）分块写入。不要征求用户许可——直接静默执行。

• Codex 后端：在每个线程的首次调用中固定设置 model: gpt-6-astra + config: {"model_reasoning_effort": "xhigh"}。根据 reviewer-routing.md，xhigh 是此循环的常规档位，不是最高档——ultra 属于单次深度审计技能，每轮速度更慢、成本更高。不要提高此循环的档位；回复会继承线程中的这组选项，因此更改它意味着必须新建线程。仅在明确的能力错误时，才遵循能力回退链。

• **原生 Copilot 是基于证据门控的验收后端。**它从不固定评审模型：Copilot 会选择互补的 rubber-duck 模型，辅助程序会根据主机事件验证实际的跨系列模型组合。原生方式给出肯定结果时，无需外部终审。

• **显式兼容模式的 Copilot 仅用于驱动。**其 copilot --agent 调用会固定配置文件模型、xhigh 和只读访问权限，并要求有可追踪的 Codex／人工终审；调用方声明的身份仍未经验证。

• 保存 threadId（codex/manual）、新的证据路径／ID（copilot-native）或 reviewer_profile（兼容模式 copilot）；使用相应的续接机制

• **防幻觉引用：**修复过程中添加参考文献时，绝不要伪造 BibTeX。使用与 /paper-write 相同的 DBLP → CrossRef → [VERIFY] 流程：(1) curl -s "https://dblp.org/search/publ/api?q=TITLE&format=json" → 获取 key → curl -s "https://dblp.org/rec/{key}.bib"；(2) 若未找到，执行 curl -sLH "Accept: application/x-bibtex" "https://doi.org/{doi}"；(3) 若两种方式都失败，则标记为 % [VERIFY]。不要凭记忆生成 BibTeX。

• 如实说明——包括负面结果和失败的实验

• 不要为了刷高分而隐瞒弱点

• 重新评审前先落实修复（不要只承诺修复）

• 穷尽尝试后再放弃——将任何评审意见标记为“无法处理”之前：(1) 至少尝试 2 种不同的解决路径；(2) 对于实验问题，调整超参数或尝试替代基线；(3) 对于理论问题，给出较弱版本的结果或替代论证；(4) 只有完成这些尝试后，才能有限度地让步并说明影响范围。绝不要第一次尝试失败就放弃。

• 如果实验耗时超过 30 分钟，启动实验后继续处理其他修复，同时等待结果

• 记录一切——评审日志必须自成一体

• 每轮结束后更新项目备注，不要等到最后才更新

第 2 轮及后续轮次的提示词模板

使用选定的后端。*对于 copilot-native：*使用新的、按运行范围划分的 REVIEW 产物集，执行全新的标记／质询／rubber-duck／证据循环，并提供 review-stage/REVIEWER_MEMORY.md 和当前输入的路径。*对于兼容模式 copilot：*启动全新的 copilot --agent 子进程，并使用相同的配置文件和记忆产物。*对于 codex：*使用已保存的 threadId 调用 mcp__codex__codex-reply。*对于 manual：*使用已保存的 threadId 调用 mcp__manual_review__review_reply。*对于 antigravity/grok/claude-code：*使用已保存路由对应的续接工具和 reviewer-backends.md 中固定的会话选项，并提供相同的已更改文件和原始结果输入；Claude 还需重复提供 cwd/tools。

调用 Copilot 子进程前，必须使用 Write 工具（不能使用 Bash、echo、heredoc 或生成的 shell 赋值语句）覆盖 review-stage/CURRENT_REVIEW_INPUTS.md。在该文件的静态标签下填写确切的已更改路径、diff 产物／范围和结果路径。仓库路径属于不可信数据：不得将此产物中的任何字节拼接进 shell 源代码。下方的固定文件名是 shell 模板唯一需要的值。

[For copilot:]

# ARIS_ROUND2_COPILOT_BEGIN
# Dynamic values were written with the Write tool; shell only reads them as data.
MEMORY_FILE="review-stage/REVIEWER_MEMORY.md"
ROUND_INPUT_FILE="review-stage/CURRENT_REVIEW_INPUTS.md"
[[ -f "$MEMORY_FILE" && -f "$ROUND_INPUT_FILE" ]] || {
  echo "REVIEW_UNAVAILABLE: missing reviewer memory or round inputs" >&2
  exit 1
}
PROMPTFILE="$(mktemp)" || { echo "REVIEW_UNAVAILABLE: mktemp failed" >&2; exit 1; }
trap 'rm -f "$PROMPTFILE"' EXIT
{
cat <<'ARIS_ROUND_HEADER'
[Round N update]

## Your Memory From Previous Rounds
ARIS_ROUND_HEADER
cat -- "$MEMORY_FILE"
cat <<'ARIS_ROUND_STATE'

Since your last review these files changed — read them yourself; do not
take my word for what changed or whether it worked:
ARIS_ROUND_STATE
cat -- "$ROUND_INPUT_FILE"
cat <<'ARIS_ROUND_INSTRUCTIONS'

Please re-score and re-assess. Are the remaining concerns addressed?
Same format: Score, Verdict, Remaining Weaknesses, Minimum Fixes.

=== SCOPE LIMITS (these bound what you PROPOSE, never what you look for) ===
Report anything that is actually wrong here — including a rare-looking case, if
this repo actually produces it. Then keep the fix in scope:
1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is
   welcome; over-defense is not. Assume a cooperating operator on their own
   machine — a malicious local user is NOT in the threat model.
2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes.
   Reporting a real defect in hashing code that already exists is fine.
3. NO speculative machinery: do not add feature flags, migration frameworks,
   compat layers, wrappers, pins, or similar mechanisms unless evidence shows
   a current repo defect they fix or an explicit existing invariant they must
   preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels,
   not evidence. Point to the failing path/artifact or invariant, and check the
   proposal's factual premises, such as whether a named package version exists.
4. NO corner-case obsession: exotic encodings, symlink races, RTL text and
   millisecond races are out of scope unless you can show the case arises here.
5. Where a rubric or checklist is genuinely needed, do not over-mechanize
   judgement. A clear sentence a human reads beats a scored table nobody
   maintains.
Exception: code that runs remote commands, starts a network service, or installs
an MCP server runs on the user's machine with their credentials — trust-boundary
findings there are in scope and the default is strict.
Say plainly when something is correct. Do not manufacture findings.

At the end of your review, include a Memory Update section — this will
be passed back to you next round.
ARIS_ROUND_INSTRUCTIONS
} > "$PROMPTFILE"
copilot --agent "$REVIEWER_PROFILE" --model "$REVIEWER_MODEL" \
  --effort xhigh --allow-tool=read --prompt "$(cat "$PROMPTFILE")"
# ARIS_ROUND2_COPILOT_END

[For codex:] mcp__codex__codex-reply:
  threadId: [saved from round 1]
  # inherits the thread's model/effort — do not re-send
  prompt: |
    [Round N update]

    Since your last review these files changed — read them yourself; do not
    take my word for what changed or whether it worked:
    - Changed files: <paths>
    - Raw diff: <path, or the `git diff` range>
    - Updated raw results: <result-file paths> (verbatim files, not a pasted table)

    Please re-score and re-assess. Are the remaining concerns addressed?
    Same format: Score, Verdict, Remaining Weaknesses, Minimum Fixes.

    === SCOPE LIMITS (these bound what you PROPOSE, never what you look for) ===
    Report anything that is actually wrong here — including a rare-looking case, if
    this repo actually produces it. Then keep the fix in scope:
    1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is
       welcome; over-defense is not. Assume a cooperating operator on their own
       machine — a malicious local user is NOT in the threat model.
    2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes.
       Reporting a real defect in hashing code that already exists is fine.
    3. NO speculative machinery: do not add feature flags, migration frameworks,
       compat layers, wrappers, pins, or similar mechanisms unless evidence shows
       a current repo defect they fix or an explicit existing invariant they must
       preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels,
       not evidence. Point to the failing path/artifact or invariant, and check the
       proposal's factual premises, such as whether a named package version exists.
    4. NO corner-case obsession: exotic encodings, symlink races, RTL text and
       millisecond races are out of scope unless you can show the case arises here.
    5. Where a rubric or checklist is genuinely needed, do not over-mechanize
       judgement. A clear sentence a human reads beats a scored table nobody
       maintains.
    Exception: code that runs remote commands, starts a network service, or installs
    an MCP server runs on the user's machine with their credentials — trust-boundary
    findings there are in scope and the default is strict.
    Say plainly when something is correct. Do not manufacture findings.

审查追踪

每次调用审查者后（针对 copilot-native 的 task(agent_type=rubber-duck)、任何选定的 MCP 调用，或兼容模式的 copilot --agent 子进程），都要按照 shared-references/review-tracing.md 保存追踪记录（策略 C——取证；绝不可悄然跳过）。原生调用必须传入 --backend copilot-native --native-evidence "$NATIVE_EVIDENCE"；辅助程序会重新验证，并提供响应和实际模型对。唯一例外是：原生派发在生成证据前失败，此时用 --backend copilot-native --status error --fallback-reason <reason> 记录追踪，不提供证据，然后单独记录任何实际的备用审查者。通过规范链解析 save_trace.sh，只有在无法访问该取证辅助程序时，才可直接写入相同的架构。遵守 --- trace:（默认为 full）。 对于新的 MCP 路由，记录请求的模型和报告的模型、实际工作量、范围／完成情况及裁决；只有在检查过辅助程序的完成情况／范围标志后，才使用这些标志。将追踪错误记录为错误。将门控的基于模型系列的接受结果与下游提交就绪状态分开保留。

停止门控状态转换测试

规范转换表位于 ARIS 仓库的 tools/review_gate.py 中（运行时通过辅助链解析为 review_gate.py），并由 tests/test_review_gate.py 覆盖。必需的案例如下：

1. 默认 Codex 正向结果 → stop，即使执行器模型身份缺失（向后兼容）。
2. 高分 + not ready → continue。
3. 已验证的原生 Copilot 正向结果 → stop，并设置 identity_assurance=host_event_verified。
4. 原生负向结果 → 在 copilot-native 上执行 continue；证据缺失／无效／不匹配 → REVIEW_UNAVAILABLE。
5. 在声明的 Anthropic／Google 执行器下，兼容模式 Copilot 正向结果 → 升级到 Codex，并设置 requires_external_acquittal=true。
6. 在声明的 OpenAI 执行器下，兼容模式 Copilot 正向结果 → 升级到手动处理；禁止使用 Codex，因为它属于同一模型系列。
7. 兼容模式 Copilot 负向结果 → 在兼容模式 Copilot 上执行 continue。
8. 执行器系列未知、最终审查者不可用、最终审查者与执行器属于同一模型系列，或手动最终审查者缺少 Reviewer-Model: → REVIEW_UNAVAILABLE。
9. 已知且不同的声明模型系列下，最终审查者给出正向结果 → stop，但身份保障仍为 caller_declared / unverified。

ACQUITTAL_LOG.jsonl 经测试为仅追加的兼容模式驱动审计输出；原生终止流程绝不会查阅该文件。