rebuttal

工作流 4：答辩

每次调用审稿人时，请遵循可选审稿人中的说明： 通过规范的辅助解析器调用 reviewer_route.py，按以下顺序解析调用参数 → .aris/reviewer.json → Claude Code 默认值（Codex MCP）， 并保留此轮的层级、新鲜上下文、源文件／图像输入和确定性门控。 下方的 Codex 示例／固定配置仅适用于 backend=codex；其他路由使用各自的首次调用／回复约定。保存路由和实际返回的身份信息； 不可用的选项记为 REVIEW_UNAVAILABLE。根据实际类别／完成情况／范围对接受情况进行分类。 将调用中的审稿人／模型／effort 覆盖参数传递给包含审稿人的子流程。生成工作线程不变。

为以下内容准备并维护有依据且符合会议要求的答辩：$ARGUMENTS

范围

此技能针对以下场景进行了优化：

• 严格字符数／字数限制下的纯文本答辩（例如，ICML 单文档）
• 逐审稿人串回复，每位审稿人的回复单独显示（例如，OpenReview 风格）
• 有共同问题和审稿人特定问题的多位审稿人
• 初始答辩后的后续轮次
• 安全起草，确保不捏造、不作过度承诺，并完整回应所有问题

此技能不会：

• 自动运行新实验
• 自动生成新的定理主张
• 编辑或上传修订版 PDF
• 向 OpenReview／CMT／HotCRP 提交内容

如果用户已有新结果、推导或经批准的承诺，此技能可将其作为用户确认的证据纳入答辩。

生命周期位置

Workflow 1:   idea-discovery
Workflow 1.5: experiment-bridge
Workflow 2:   auto-review-loop (pre-submission)
Workflow 3:   paper-writing
Workflow 4:   rebuttal (post-submission external reviews)

常量

• VENUE = ICML — 默认会议。如有需要可覆盖。
• RESPONSE_MODE = TEXT_ONLY — v1 默认值。
• REVIEWER_MODEL = gpt-6-astra — Codex 后端的默认模型。用于内部压力测试。手动后端使用用户选择的模型；该模型必须是已识别且来自不同系列的模型（OpenAI、Anthropic、Google、DeepSeek、Moonshot/Kimi、Qwen）。
• REVIEWER_BACKEND = codex — 默认值：Codex MCP（xhigh）。使用 — reviewer: oracle-pro 可切换为 Oracle MCP，或使用 — reviewer: manual 切换为 Manual Review MCP。如果 manual-review MCP 不可用，请停止并打印安装命令；不要回退到 Codex。参见 shared-references/reviewer-routing.md。
• MAX_INTERNAL_DRAFT_ROUNDS = 2 — 起草 → lint → 修改。
• VENUE_MODE = single_document — 若所有审稿人共用一份作者回复，则使用 single_document；若每个审稿人讨论串独立呈现，则使用 per_reviewer_thread。如不明确，请在起草前确认会议/界面。此设置会影响 Phase 4/7 的输出形式。
• STRESS_TEST_ROUNDS_BASE = 1 — 对完整回复集进行一轮外部审稿人评议。对于 reviewer_priority: pivotal 的回复，增加针对性轮次；当审稿人不再提出新的实质性问题时终止。硬性上限为 5 轮。
• MAX_FOLLOWUP_ROUNDS = 3 — 每个审稿人讨论串最多 3 轮后续交流。
• AUTO_EXPERIMENT = false — 为 true 时，如果策略计划指出审稿人提出的问题需要新的实证证据，则自动调用 /experiment-bridge 运行补充实验。为 false 时（默认），暂停并向用户说明证据缺口，由用户手动处理。
• QUICK_MODE = false — 为 true 时，仅运行 Phase 0-3（解析审稿意见、拆解问题、制定策略）。输出 ISSUE_BOARD.md + STRATEGY_PLAN.md 后停止；不进行起草或压力测试。适用于快速了解审稿人的诉求，以便决定如何回复。
• REBUTTAL_DIR = rebuttal/
• RENDER_HTML = true — 为 true 时（默认），在 Phase 6 / Phase 8 定稿后，自动将 rebuttal/REBUTTAL_DRAFT_rich.md（面向审稿人的详细草稿）渲染为 HTML。使用完整 Codex 审阅关卡（最终的投稿前交付内容，面向审稿人的内容，渲染保真度很重要）。纯文本 PASTE_READY.txt 不会被渲染（该文件按设计为带字符数统计的纯文本）。设为 false 可跳过，或传入 — render html: false。

覆盖示例：/rebuttal "paper/" — venue: NeurIPS, character limit: 5000

审稿人调用约定

调用审稿人进行压力测试时，根据 REVIEWER_BACKEND 分支处理：

若 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: [已保存的 manual-review threadId] prompt: [后续提示词] config: {"model_reasoning_effort": "xhigh", "executor_model": "", "require_reviewer_model": true}

提示词一致性：发送给 manual 的提示词必须与 Codex 收到的文本完全相同。 两种后端均须进行审阅追踪。

必需输入

1. 论文源文件 — PDF、LaTeX 目录或叙述性摘要
2. 原始审稿意见 — 粘贴的文本、Markdown 或带审稿人 ID 的 PDF
3. 会议规则 — 会议名称、字符/字数限制、是否仅允许纯文本或可提交修订版 PDF、呈现模式（共用一份回复，或使用独立的审稿人讨论串）
4. 当前阶段 — 初次 rebuttal 或后续轮次

如果缺少会议规则、篇幅限制或呈现模式，请停止并先询问，再起草。

安全模型

三道硬性关卡——任一项未通过，都不得定稿：

1. 来源关卡——每条事实陈述都必须对应以下来源之一：paper、review、user_confirmed_result、user_confirmed_derivation 或 future_work。没有来源 = 阻止继续。
2. 承诺关卡——每项承诺都必须对应以下类别之一：already_done、approved_for_rebuttal 或 future_work_only。未经批准 = 阻止继续。
3. 覆盖关卡——每项审稿人关切最终都必须标记为：answered、deferred_intentionally 或 needs_user_input。不得遗漏任何问题。

工作流

阶段 0：恢复或初始化

1. 如果存在 rebuttal/REBUTTAL_STATE.md → 从记录的阶段继续
2. 否则 → 创建 rebuttal/，初始化所有输出文档
3. 加载论文、审稿意见、会议规则以及任何经用户确认的证据

阶段 1：验证输入并规范化审稿意见

1. 验证会议规则是否明确
2. 将所有审稿人文本逐字整理到 rebuttal/REVIEWS_RAW.md
3. 在 rebuttal/REBUTTAL_STATE.md 中记录元数据
4. 如果存在歧义，请暂停并询问

阶段 2：拆分并分类审稿人关切

创建 rebuttal/ISSUE_BOARD.md。

针对每项原子关切，记录：

• issue_id（例如 R1-C2）
• reviewer、round、raw_anchor（简短引文）
• issue_type：assumptions / theorem_rigor / novelty / empirical_support / baseline_comparison / complexity / practical_significance / clarity / reproducibility / other
• severity：critical / major / minor
• reviewer_stance：positive / swing / negative / unknown
• reviewer_priority：standard / pivotal
  • pivotal — 如果回应得当，该审稿人的意见很可能影响最终决定：评分较低或处于临界状态，关切可以解决，并且其影响力或把握度足以产生影响。阶段 3 会为此投入额外的撰写和压力测试资源。
• response_mode：direct_clarification / grounded_evidence / nearest_work_delta / assumption_hierarchy / narrow_concession / future_work_boundary / structural_distinction
  • structural_distinction — 用于应对“你的方法可以归约为 X / 只是通用的 Y / 已被 Z 涵盖”这类质疑。处理方式：认可局部归约；指出你的参数化所保留、而 X/Y/Z 未能涵盖的结构特征，并以具体机制（定理依赖关系、推导步骤或实证结果）作为依据。没有支撑机制时，绝不可仅用修辞来应对。
• status：open / answered / deferred / needs_user_input

阶段 3：制定策略计划

创建 rebuttal/STRATEGY_PLAN.md。

1. 找出 2-4 个可解决共同关切的全局主题
2. 为每项问题选择回应方式
3. 制定字符数预算（开篇占 10-15%，逐位审稿人回应占 75-80%，结尾占 5-10%）——适用于 single_document 模式；在 per_reviewer_thread 模式下，改为设置每个讨论串的字数/字符数目标
4. 识别关键审稿人——其投票或信心变化最可能影响最终决定的审稿人，尤其是关切可以解决而非出于立场之时。在 ISSUE_BOARD.md 中将其标记为 reviewer_priority: pivotal。关键审稿人可以不止一位。为其投入不成比例的撰写和压力测试资源。
5. 识别受阻主张（缺乏依据或未经批准）
6. 如果仍有未解决的阻碍 → 暂停并告知用户 任何会影响最终判断的人工回应都必须以 Reviewer-Model: <exact-model-id> 开头——将本次会话实际运行的模型作为 executor_model 提供。缺失、未知或属于同一模型系列的身份信息均不能作为免责依据；不得猜测，应输出 REVIEW_UNAVAILABLE。如果无法确定执行器 模型，则无法证明人工审查具有跨模型系列的独立性——应在报告中如实说明，而不是作出断言。

QUICK_MODE 退出条件：如果 QUICK_MODE = true，则在此处停止。向用户展示 ISSUE_BOARD.md + STRATEGY_PLAN.md，并汇总：每位审稿人的问题数量、共同与独有的关切、建议优先级以及证据缺口。随后用户可决定继续撰写完整答辩（/rebuttal — quick mode: false）或手动撰写。

阶段 3.5：证据冲刺（当 AUTO_EXPERIMENT = true 时）

如果 AUTO_EXPERIMENT 为 false，则完全跳过此阶段 — 改为暂停并向用户说明证据缺口。

如果策略计划指出需要新的实证证据来解决的问题（标记为 response_mode: grounded_evidence，且 evidence_source: needs_experiment）：

1. 根据审稿人的关切生成一份精简实验计划：

   • 要运行什么（消融、基线比较、规模扩展、条件检查）
   • 成功标准（什么结果能满足审稿人）
   • 预计 GPU 小时数

2. 使用精简实验计划调用 /experiment-bridge：

   /experiment-bridge "rebuttal/REBUTTAL_EXPERIMENT_PLAN.md"
   

3. 等待结果，然后更新 ISSUE_BOARD.md：

   • 将已完成的实验标记为 user_confirmed_result
   • 更新相关问题卡片的证据来源

4. 如果实验失败或结果不确定：

   • 将回应模式切换为 narrow_concession 或 future_work_boundary
   • 不要捏造正面结果

5. 将实验结果保存到 rebuttal/REBUTTAL_EXPERIMENTS.md，以便追踪来源。

时间限制：如果预计 GPU 小时数超过 rebuttal 截止时间，则跳过并标记为需人工处理。

阶段 4：撰写初始 rebuttal

根据 VENUE_MODE 创建草稿文件：

• single_document 模式 → 一个 rebuttal/REBUTTAL_DRAFT_v1.md
• per_reviewer_thread 模式 → 每位审稿人一个 rebuttal/Reviewer_<ID>_response.md（不创建顶层的 REBUTTAL_DRAFT_v1.md）

结构取决于 VENUE_MODE：

• single_document — 一个 REBUTTAL_DRAFT_v1.md：

  1. 简短开场 — 感谢审稿人 + 2-4 项总体问题解决方案
  2. 按审稿人分别编号回应 — 回答 → 证据 → 含义
  3. 简短结尾 — 已解决的问题 / 尚存问题 / 接收理由

• per_reviewer_thread — 每位审稿人一个内容完整、可独立阅读的 Reviewer_<ID>_response.md：

  1. 简要回应该审稿人关注的重点
  2. 编号列出 W#/Q# 的回应（回答 → 证据 → 含义）
  3. 可选的共享实验设置段落（见下文“可复用设置块”）
  • 每个文件都必须能独立阅读。不要引用“参见审稿人 X 的回应”。不要添加总体开场。

每个问题的默认回应模式：

• 第 1 句：直接回答
• 第 2-4 句：基于证据进行说明
• 最后一句：说明对论文的影响

可复用设置块（per_reviewer_thread 模式）。 如果多份审稿人回应需要相同的实验设置或指标定义，请撰写规范的 SETUP_METRICS_BLOCK.md。在每份需要它的审稿人文件中一致地复用。目标长度 ≤ 150 词；仅在确实需要针对特定审稿人补充内容时，才在正文中扩展。一次修改、处处更新，避免不同讨论串中的内容出现偏差。

成功 rebuttal 的内容经验法则：

• 证据胜于断言
• 先讲总体叙事，再讲针对各位审稿人的细节（仅适用于 single_document 模式）
• 对反直觉的观点给出具体数字
• 处理新颖性争议时，指出最接近的既有研究 + 精确差异
• 审稿人意见正确时，作出有限让步
• 对理论问题，区分核心假设与技术假设
• 也要回应友善的审稿人 应对审稿人的策略：
• 针对每个关切提供最低限度的充分证据。 通常给出一个数值锚点即可：与该审稿人的具体要求直接对应的指标。删去其他审稿人关心的指标——内容臃肿会削弱答复。
• 明确说明预先注册的校准方式。 如果阈值或留出集是在检查生成样本之前确定的，请明确说明，例如：“在检查任何生成样本之前，已在留出集上设定。” 几乎不增加字数，却能有效化解选择性报告的质疑。仅在确实如此时使用。
• 提前说明不明显的设计选择。 如果实验设置存在不明显的注意事项（算力匹配 ≠ 轮次匹配、非典型的随机种子方案、受限的参数子集等），请具体说明；如有助于解释设计选择，也请给出数字。这样可以预先防范对方的对抗性逆向分析。
• 强调结构性区别，而非否认。 如果审稿人声称你的工作可归结为／被某个通用框架涵盖，不要否认这种归结。指出你的参数化保留了哪些通用框架不具备的结构特征——参见 response_mode: structural_distinction。
• 让步，但不放弃主张。 如果审稿人部分正确，请明确接受这一局部观点，然后说明哪些内容仍然成立，以及为何这些内容仍然支持论文的贡献。让步时，同时指出仍成立的定理、机制、实证结果或适用范围条件。

硬性规则：

• 绝不编造实验、数字、推导、引用或链接
• 绝不承诺用户尚未批准的事项
• 如果没有有力证据，宁可少说，不要多说

仅限 single_document 模式：还需生成 rebuttal/PASTE_READY.txt（纯文本，并精确计算适用于 OpenReview/CMT 粘贴框的字符数）。在 per_reviewer_thread 模式下，跳过此产物——每个 Reviewer_<ID>_response.md 本身就是对应讨论串的粘贴目标。

还需生成 rebuttal/REVISION_PLAN.md——总体修订清单。

本文档是反驳稿中所有已承诺（明确或隐含）的论文修订事项的唯一事实来源。它用于帮助作者在提交反驳后跟踪后续落实情况，也为 Phase 5 的承诺门禁提供可据以验证的具体产物。

结构：

1. 标题信息

   • 论文标题、会议、字符数限制、反驳轮次
   • 返回 ISSUE_BOARD.md、STRATEGY_PLAN.md、REBUTTAL_DRAFT_v1.md 的链接

2. 总体清单——使用一份扁平的 GitHub 风格清单，涵盖所有修订事项，以便作者在定稿版／修订版 PDF 中逐项完成后勾选：

   ## Overall Checklist
   
   - [ ] (R1-C2) Add assumption hierarchy table to Section 3.1 — commitment: `approved_for_rebuttal` — owner: author — status: pending
   - [ ] (R2-C1) Clarify novelty delta vs. Smith'24 in Section 2 related work — commitment: `already_done` — status: verify wording
   - [ ] (R3-C4) Add runtime breakdown figure to Appendix B — commitment: `future_work_only` — status: deferred, note in camera-ready
   - ...
   

   清单项必须是原子化的（每行对应一处论文修改），并且每项都必须引用其 issue_id，以便追溯到 ISSUE_BOARD.md。

3. 分组视图——将相同事项分别按 (a) 论文章节／位置和 (b) 严重程度重新分组，以便作者高效规划修订工作。

4. 承诺摘要——统计 already_done / approved_for_rebuttal / future_work_only 的数量，并列出任何阻碍进展的 needs_user_input 事项。

5. 范围外事项记录——记录不会触发论文修订的审稿人关切（例如 deferred_intentionally、无需修改的 narrow_concession），并为每项提供一句理由。这样清单才能如实反映情况：不会有任何事项悄然消失。

REVISION_PLAN.md 规则：

• 每项清单内容都必须至少对应 ISSUE_BOARD.md 中的一个 issue_id。
• REBUTTAL_DRAFT_v1.md 中每项暗示要修改论文的承诺，都必须出现在清单中——如果未列入计划，即违反承诺门禁。
• 绝不添加缺乏反驳稿依据或用户确认依据的事项。
• 在重新运行／后续轮次中，应就地更新复选框状态，而不是从头重新生成。

第 5 阶段：安全验证

运行所有 lint 检查：

1. 覆盖度 — 每个问题都对应到草稿中的锚点
2. 来源 — 每个事实性句子都有来源
3. 承诺 — 所有承诺均已获批，且草稿中的每项论文修改承诺都作为检查清单项目出现在 REVISION_PLAN.md 中（反之亦然——计划中不能有孤立项目）
4. 语气 — 标记强硬、卑微或回避的措辞
5. 一致性 — 各评审回复之间没有矛盾
6. 字数限制 — 精确计算字符数；若超出则压缩（冗余内容 → 友好措辞 → 开场白 → 措辞调整，绝不删除关键答复）
7. 线程内上下文（仅限 per_reviewer_thread 模式）——每份评审文件都必须能在不阅读其他评审文件的情况下理解。标记任何“参见 Reviewer X”之类的引用，或依赖跨线程上下文但未定义的术语。
8. 对抗性设计选择扫描 — 针对每项实验性主张，询问：“敌意评审者能否找出我尚未披露的非显而易见设计选择（算力匹配、冻结子集、采样协议）？”若能，则在 Setup 段落中添加一句说明。范围比来源检查更窄；重点在于设计选择而非事实来源。

第 6 阶段：外部评审者压力测试

使用所选后端。对于 codex：

先解决这个评审者槽位；以下是 backend=codex 示例。

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    Stress-test this rebuttal draft:
    [raw reviews + issue board + draft + venue rules]

    1. Unanswered or weakly answered concerns?
    2. Unsupported factual statements?
    3. Risky or unapproved promises?
    4. Tone problems?
    5. Paragraph most likely to backfire with meta-reviewer?
    6. Minimal grounded fixes only. Do NOT invent evidence.

    Verdict: safe to submit / needs revision

对于手动方式： 使用 mcp__manual_review__review，并采用相同的提示词以及上文 Reviewer Calling Convention 中包含身份信息的配置（executor_model + require_reviewer_model: true）。

迭代。 在完整草稿上运行基础轮次。然后针对每条 reviewer_priority: pivotal 的回复运行重点后续轮次，直至评审者不再提出新的实质性问题。总轮次上限为 5 轮。将每轮结果保存到 rebuttal/MCP_STRESS_TEST_round<N>.md；轮次编号最高的文件代表最终状态。如果仍有任何硬性安全阻碍 → 修改后再定稿。

第 7 阶段：定稿

输出取决于 VENUE_MODE：

single_document 模式 — 生成两个版本：

1. rebuttal/PASTE_READY.txt — 严格版

   • 纯文本，字符数精确，符合投稿平台限制
   • 可直接粘贴到投稿平台界面
   • 不含 Markdown 格式或其他内容

2. rebuttal/REBUTTAL_DRAFT_rich.md — 扩展版

   • 结构相同，但包含更多细节：更完整的解释、补充证据、可选段落
   • 对超出严格版限制的部分标注 [OPTIONAL — cut if over limit]
   • 作者可阅读此版本以了解完整论证，然后手动决定保留、删减或改写哪些内容
   • 有助于后续轮次——额外材料已预先写好

per_reviewer_thread 模式 — 每位评审者生成一个文件：

1. rebuttal/Reviewer_<ID>_response.md — 每位评审者对应一份自包含文件，可直接粘贴到相应的评审线程中
2. rebuttal/SETUP_METRICS_BLOCK.md — 可选的规范 Setup/metrics 文本，供多个评审文件重复使用
3. rebuttal/SUPPLEMENTARY_FIG_PDF/（可选）——当投稿平台不允许修改 PDF，但允许匿名图表链接时，生成符合平台要求的补充 PDF。不要硬编码匿名托管平台或排版样式；应选择目标平台接受的方案。

两种模式都要执行：

4. 更新 rebuttal/REBUTTAL_STATE.md
5. 刷新 rebuttal/REVISION_PLAN.md，确保整体检查清单与最终草稿一致（添加项目，将 already_done 标为已勾选，并保留所有 pending 项目）
6. 向用户展示：
   • 对于 single_document：PASTE_READY.txt 的字符数与投稿平台限制；供审阅的 REBUTTAL_DRAFT_rich.md
   • 对于 per_reviewer_thread：每位评审者对应的文件列表及字数；如有使用则列出 SETUP_METRICS_BLOCK.md；如有生成则列出补充 PDF
   • REVISION_PLAN.md 检查清单——待处理／已批准／已延期项目的数量
   • 剩余风险 + 需要人工批准的语句

阶段 8：后续轮次

收到新的审稿意见时：

1. 将原文逐字附加到 rebuttal/FOLLOWUP_LOG.md
2. 链接到现有问题，或创建新问题
3. 仅起草增量回复（不要全文重写）
4. 原位更新 rebuttal/REVISION_PLAN.md——添加后续意见引入的任何新检查项，勾选作者已完成的事项，并保持现有事项的状态为最新
5. 重新运行安全检查
6. 如有助于保持连贯性，使用适当的回复工具（遵循审稿人调用约定）
7. 规则：从技术层面升级，而非在措辞上升级；若审稿人正确则予以承认；若审稿人态度坚定且没有新证据，则停止争论

阶段 9：渲染 HTML 视图（当 RENDER_HTML = true 时自动执行，默认开启）

阶段 6（初始答辩）或阶段 8（后续轮次）完成后，定稿 rebuttal/REBUTTAL_DRAFT_rich.md，并对详细草稿调用 /render-html：

/render-html "rebuttal/REBUTTAL_DRAFT_rich.md"

使用完整 Codex 审查关卡（面向审稿人的提交前交付物——渲染保真度很重要；丰富草稿包含由作者控制的格式，审稿人应准确看到作者的预期呈现效果）。输出：rebuttal/REBUTTAL_DRAFT_rich.html，其中嵌入源文件 SHA256，并附带 .review.json 文件。

不要渲染 rebuttal/PASTE_READY.txt——它是按设计精确控制字符数的纯文本，并非结构化产物。

非阻塞：如果 /render-html 失败（缺少辅助工具、Codex MCP 不可用、文件写入错误），记录失败，并将答辩阶段视为已完成——PASTE_READY.txt 和 REBUTTAL_DRAFT_rich.md 是规范输出。

如果 RENDER_HTML = false，则跳过。

关键规则

• 大型文件处理：如果 Write 失败，则静默地使用 Bash heredoc 重试。
• 绝不捏造。 不得编造证据、数字、推导、引用或链接。
• 绝不夸大承诺。 只承诺用户明确批准的事项。
• 全面覆盖。 跟踪并处理每一条审稿意见。
• 保留原始记录。 原样存储评审意见和 MCP 输出。
• 结构遵循 VENUE_MODE。 single_document → 总体开场，包含共性意见，并按审稿人编号逐一详述。per_reviewer_thread → 不设总体开场；每位审稿人的文件均独立完整。
• 也要回复友善的审稿人。 强化支持性的表述。
• 给元审稿人的结尾。 总结已解决的问题、未解决的问题及接收理由。
• 证据胜于修辞。 优先提供推导和数字，而非叙述。
• 有选择地让步。 坦诚且范围有限的让步，胜过笼统否认。
• 不要在无望的争论上浪费篇幅。 回复一次，然后继续。
• 遵守限制。 字符预算是硬性约束。
• 干净地续跑。 重新运行时从 REBUTTAL_STATE.md 继续。
• 防幻觉引用。 新增的任何参考文献都必须经过 DBLP → CrossRef → [VERIFY]。

评审追踪

每次调用审稿工具（mcp__codex__codex、mcp__codex__codex-reply、mcp__manual_review__review 或 mcp__manual_review__review_reply）后，按照 shared-references/review-tracing.md 保存追踪记录（Policy C — 取证级；绝不可静默跳过）。使用 save_trace.sh（依照 shared-references/integration-contract.md §2 中的调用链确定路径），或直接将文件写入 .aris/traces/<skill>/<date>_run<NN>/。遵循 --- trace: 参数（默认值：full）。