paper-writing

工作流 3：论文写作流水线

每个审稿人时段开始前，请遵循 可选审稿人： 通过规范的辅助解析器解析调用 → .aris/reviewer.json → Claude Code 默认配置（Codex MCP）， 并使用 reviewer_route.py，同时保留此时段的等级、新鲜上下文、来源/图像输入和确定性门控。 下方的 Codex 示例/固定配置仅适用于 backend=codex；其他路由使用各自的首次调用/回复契约。保存路由和实际返回的身份； 无法使用的选项标记为 REVIEW_UNAVAILABLE。根据实际的类别/完成情况/范围判定是否接受。 将调用中的审稿人/模型/effort 覆盖项传递给包含审稿人的子任务。生成工作进程保持不变。

为以下内容编排完整的论文写作工作流：$ARGUMENTS

概览

此技能将五个子技能串联为一个自动化流水线：

/paper-plan → /paper-figure → /paper-write → /paper-compile → /auto-paper-improvement-loop
  (outline)     (plots)        (LaTeX)        (build PDF)       (review & polish ×2)

每个阶段都基于前一阶段的输出构建。最终交付物是经过润色和审阅的 paper/ 目录，其中包含 LaTeX 源文件和编译后的 PDF。

在此混合包中，流水线本身保持不变，但 paper-plan 和 paper-write 使用适配 Orchestra 的共享参考，以增强故事框架和行文指导。

常量

• VENUE = ICLR — 目标会议。选项：ICLR、NeurIPS、ICML、CVPR、ACL、AAAI、ACM、IEEE_JOURNAL（IEEE Transactions / Letters）、IEEE_CONF（IEEE 会议）。会影响样式文件、页数限制和引用格式。
• MAX_IMPROVEMENT_ROUNDS = 2 — 改进循环中的审阅→修复→重新编译轮数。
• REVIEWER_MODEL = gpt-6-astra — 通过 Codex MCP 用于计划审阅、图表审阅、写作审阅和改进循环的模型。
• AUTO_PROCEED = true — 在各阶段之间自动继续。设为 false 可在每个阶段后暂停并等待用户批准。
• HUMAN_CHECKPOINT = false — 设为 true 时，改进循环（阶段 5）会在每轮审阅后暂停，让你查看评分并提供自定义修改说明。设为 false（默认值）时，循环将完全自主运行。此设置会传递给 /auto-paper-improvement-loop。
• ILLUSTRATION = figurespec — 阶段 2b 的架构/插图生成器：figurespec（默认，通过 /figure-spec 确定性地将 JSON 转换为 SVG，最适合架构/工作流/拓扑图）、gemini（通过 /paper-illustration 使用 AI 生成，最适合定性方法示意图；需要 GEMINI_API_KEY）、codex-image2（通过本地 Codex 原生图像桥接调用 /paper-illustration-image2，使用 AI 生成；无需外部 API 密钥，使用你的 ChatGPT Plus/Pro 额度；实验性功能）、mermaid（通过 /mermaid-diagram 使用 Mermaid 语法，免费，最适合流程图）或 false（跳过阶段 2b，仅手动处理）。

行内覆盖：/paper-writing "NARRATIVE_REPORT.md" — venue: NeurIPS, illustration: gemini, human checkpoint: true IEEE 示例：/paper-writing "NARRATIVE_REPORT.md" — venue: IEEE_JOURNAL

输入

此流水线接受以下任一输入：

1. NARRATIVE_REPORT.md（最佳）——包含论点、实验、结果和图表的结构化研究叙述
2. 研究方向 + 实验结果——该技能将先协助起草研究叙述
3. 现有的 PAPER_PLAN.md——跳过阶段 1，从阶段 1.5开始（仍会执行契约协商；只有恢复真正的 1.5 之前的旧版运行时才可以跳过；此时阶段 6.0 的第 0 行会记录“无契约”）

输入越详细（尤其是图表描述和定量结果），输出质量越高。

可选：风格参考（— style-ref: <source>，选择启用）

允许用户引导生成论文的结构风格（章节顺序、定理密度、句子节奏、图表密度、参考文献风格），使其接近用户欣赏的参考论文。默认关闭——用户未传入 — style-ref 时，行为与之前完全相同。

当 $ARGUMENTS 中包含 — style-ref: <source> 时，在 Phase 1（paper-plan）之前，先运行辅助工具：

# Resolve $STYLE_HELPER via the canonical strict-safe chain (see
# shared-references/integration-contract.md §2). Policy A — gate:
# unresolved helper means --style-ref cannot be satisfied, so abort.
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
STYLE_HELPER=".aris/tools/extract_paper_style.py"
[ -f "$STYLE_HELPER" ] || STYLE_HELPER="tools/extract_paper_style.py"
[ -f "$STYLE_HELPER" ] || { [ -n "${ARIS_REPO:-}" ] && STYLE_HELPER="$ARIS_REPO/tools/extract_paper_style.py"; }
[ -f "$STYLE_HELPER" ] || {
  echo "ERROR: extract_paper_style.py not resolved at .aris/tools/, tools/, \$ARIS_REPO/tools/, or via ~/.aris/repo." >&2
  echo "       Fix: rerun bash tools/install_aris.sh or smart_update.sh (refreshes ~/.aris/repo), export ARIS_REPO, or copy the helper to tools/." >&2
  echo "       --style-ref cannot be satisfied; aborting." >&2
  exit 1
}
STYLE_STATUS=0
CACHE=$(python3 "$STYLE_HELPER" --source "<source>") || STYLE_STATUS=$?
case "$STYLE_STATUS" in
  0) ;;                                       # share $CACHE/style_profile.md with downstream WRITER phases only
  2) echo "warning: style-ref skipped (missing optional dep)" >&2 ;;
  3) echo "error: --style-ref source failed; aborting pipeline" >&2 ; exit 1 ;;
  *) echo "error: helper failed unexpectedly; aborting pipeline" >&2 ; exit 1 ;;
esac

然后仅将 — style-ref: <source> 传递给写作侧子技能：

• /paper-plan（Phase 1）——大纲结构
• /paper-write（Phase 3）——逐节撰写正文
• /paper-illustration（Phase 2b）——图表结构匹配，可选

接受的来源：本地 TeX 目录 / 文件、本地 PDF、arXiv 编号、http(s) URL。拒绝 Overleaf URL / ID——请先通过 /overleaf-sync setup <id> 克隆，然后传入本地克隆路径。

严格规则（完整约定见 tools/extract_paper_style.py 文档字符串）：

• 仅将 style_profile.md 用作结构指导。匹配章节数量倾向、定理密度、标题长度分布、句子节奏、数学公式展示比例、引用风格。
• 绝不复制缓存中任何内容的正文、论断、示例或术语。
• 绝不向审阅 / 审计子技能传递 — style-ref（或缓存内容）——Phase 4.5（/proof-checker）、Phase 4.7 / 5.5（/paper-claim-audit）、Phase 5（/auto-paper-improvement-loop 审阅者）、Phase 5.8（/citation-audit）必须仅基于产物运行。跨模型审阅独立性见 ../shared-references/reviewer-independence.md。

流程

Phase 0：保证级别设置

解析当前生效的 assurance 级别并将其持久化，以便 Phase 6 的外部验证器读取相同的值。在流程开始时、Phase 1 之前运行一次。

解析顺序（采用首个匹配项）：

1. $ARGUMENTS 中显式指定的 — assurance: draft | submission
2. 根据 — effort: 推导
   • lite / balanced → draft（默认值，与当前行为完全一致）
   • max / beast → submission
3. 默认值：draft

操作：

mkdir -p paper/.aris
echo "<resolved-level>" > paper/.aris/assurance.txt   # draft or submission

各级别对后续流程的影响：

• draft——沿用现有行为。仅当内容检测器匹配时才运行审计（Phase 4.5 / 4.7 / 5.5 / 5.8）。缺少产物不会阻塞流程。允许静默跳过。
• submission——将四项强制审计（proof-checker、paper-claim-audit、citation-audit、kill-argument）视为关键门禁。每项子审计都必须生成其 JSON 产物（PASS / WARN / FAIL / NOT_APPLICABLE / BLOCKED / ERROR）——不得静默跳过。Phase 6 会运行 verify_paper_audits.sh（规范名称；解析方式见 shared-references/integration-contract.md §2）；若退出码非零，则阻止生成最终报告。

**例外选项：**希望沿用旧行为“beast = 只增加深度，不设审计门禁”的用户，可以显式传入 — effort: beast, assurance: draft。此设置有效，但不建议用于正式投稿。完整约定见 shared-references/assurance-contract.md。

在 Phase 1 之前，于行内说明解析后的级别：

📋 Assurance: <level> (derived from effort: <effort>)
   <either "current behavior, no audit gate" OR "mandatory audits gated by verify_paper_audits.sh (resolved per integration-contract §2)">

阶段 1：论文规划

调用 /paper-plan 创建结构大纲：

/paper-plan "$ARGUMENTS"

如果 $ARGUMENTS 中传入了 — style-ref: <source>，且上述辅助工具执行成功，则在调用中附加 — style-ref: <source>：/paper-plan "<topic> — style-ref: <source>"。（撰写方阶段——允许转发；下文的审阅方／审计方阶段不得看到 style ref。）

此操作的内容：

• 解析 NARRATIVE_REPORT.md，提取主张、证据和图表说明
• 构建主张－证据矩阵——每项主张都对应证据，每项实验都支持一项主张
• 设计章节结构（根据论文类型设置 5–8 个章节）
• 规划图表放置位置及其数据来源
• 搭建引用结构框架
• GPT-6-Astra 审阅计划的完整性

输出：PAPER_PLAN.md，包含章节计划、图表计划和引用框架。

**检查点：**向用户展示计划摘要。

📐 Paper plan complete:
- Title: [proposed title]
- Sections: [N] ([list])
- Figures: [N] auto-generated + [M] manual
- Target: [VENUE], [PAGE_LIMIT] pages

Shall I proceed with figure generation?

• 用户批准（或 AUTO_PROCEED=true）→ 进入阶段 1.5。
• 用户要求修改→ 调整计划并重新展示。

阶段 1.5：协商验收契约（开始撰写前）

计划说明论文将包含什么；契约说明“完成”的标准——这是一份可测试断言清单，在撰写第一节之前通过对抗式协商确定，并在最后进行评分。（计划划定边界；契约规定评分标准。）

1. 执行方提出草案。根据 PAPER_PLAN.md 和 NARRATIVE_REPORT.md，起草 PAPER_ACCEPTANCE_CONTRACT.md：包含 10–20 项可测试断言，涵盖以下内容——每项核心主张都有明确的证据来源（文件／表格）；摘要中的每个数字都可追溯到结果文件；标题／摘要必须包含的范围限定语；必须存在的图表及其各自必须展示的内容；章节完整性（例如，“局限性部分列出 ≥2 项真实局限，而非含糊其辞”）；投稿场所的限制（页数上限、匿名要求）。每项断言都必须能通过阅读最终 PDF 和结果文件进行核验——不能凭感觉判断（“写作清晰”不是断言；“每个缩略词都在首次出现时给出定义”才是）。少于约 10 项断言，关卡就会流于形式；超过约 20 项，协商则会陷入琐碎细节。

2. 审阅方提出异议（使用新线程——协商采用对抗式方式）：

   请先处理此审阅方席位；以下示例使用 backend=codex。

   mcp__codex__codex:
     model: gpt-6-astra
     config: {"model_reasoning_effort": "xhigh"}
     prompt: |
       You are negotiating the acceptance contract for a paper BEFORE it is
       written. Read these files directly:
       - Plan: <abs path>/PAPER_PLAN.md
       - Proposed contract: <abs path>/PAPER_ACCEPTANCE_CONTRACT.md
       - Evidence inventory: <abs path>/NARRATIVE_REPORT.md (+ results/ paths)
   
       Push back on the contract, not the plan: (a) assertions that are
       untestable or vibes — demand a checkable rewrite; (b) missing
       assertions — claims in the plan that no assertion covers, numbers with
       no traceability assertion, foreseeable overclaim risks with no scope
       assertion; (c) assertions the evidence inventory cannot possibly
       satisfy — flag now, not after writing. End with exactly one line:
       CONTRACT_ACCEPTED: yes    or    CONTRACT_ACCEPTED: no
       followed by your numbered revision demands if no.
   
       === 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.
   

   如果回复缺少 CONTRACT_ACCEPTED: 行，或该行格式错误，则视为 no；通过 codex-reply 请求更正判定——此次更正往返不计入协商轮次。

3. **迭代。**如果判定为 no，则根据要求修改契约，并通过 mcp__codex__codex-reply 重新提交（使用同一线程——协商属于同一场对话）。最多 3 轮。

4. 回退方案——绝不让流水线停滞。如果第 3 轮结束时判定仍为 no： 将未解决的要求逐字记录在契约的“## 有争议”部分，并将其标记为 status: contested。存在争议的契约正是“契约有误时引入人工介入”的触发条件，因此这会覆盖 AUTO_PROCEED，仅针对这一项决策暂停，并将争议提交人工裁决。如果没有人工回复（无人值守／夜间运行），则继续执行——但存在争议的契约会限制最终结果：阶段 6.0 仅对无争议断言进行把关，最终报告必须将 Submission-ready: no，并逐字复述争议；待人工返回后再进行裁决。

输出：PAPER_ACCEPTANCE_CONTRACT.md（status: accepted | contested、轮次数、审阅线程 ID）。契约一经接受即冻结——阶段 2–5 按契约执行，不得修改。如果撰写过程中发现某项断言确实有误（而非仅仅不方便），则属于契约问题：应在检查点提出，不得悄悄改写。

边界：/paper-claim-audit（阶段 4.7、5.5）保持零上下文——契约是撰写方关卡，绝不会传给主张审计器（保持其独立性正是目的；两者使用不同的神经网络）。

阶段 2：图表生成

如果在 $ARGUMENTS 中传入了 — style-ref: <source>，且上面的辅助程序运行成功，则在此流程中每次调用写作侧子技能时（阶段 1、2b、3、5），都追加 — style-ref: <source>。不要在调用审阅者／审计者时追加此参数（阶段 4.5、4.7、5.5、5.8）。

调用 /paper-figure 以生成数据驱动的图表和表格：

/paper-figure "PAPER_PLAN.md"

功能：

• 从 PAPER_PLAN.md 读取图表计划
• 根据 JSON/CSV 数据生成 matplotlib/seaborn 图表
• 生成 LaTeX 对比表格
• 创建 figures/latex_includes.tex，方便插入
• GPT-6-Astra 审查图表质量和说明文字

**输出：**包含 PDF、生成脚本和 LaTeX 代码片段的 figures/ 目录。

范围：paper-figure 负责数据图表和对比表格。架构图、流程图和方法示意图由下方的阶段 2b 处理。

阶段 2b：架构图与示意图生成

如果 illustration: false，则完全跳过此步骤。

如果论文计划中包含架构图、流程图、审计级联图或方法示意图，则根据 illustration 参数调用相应的生成器：

当 illustration: figurespec 时（默认）——调用 /figure-spec：

/figure-spec "[architecture/workflow description from PAPER_PLAN.md]"

• 确定性 JSON → SVG 矢量渲染（可编辑、可复现）
• 适用于：系统架构、工作流流水线、审计级联、分层拓扑
• 输出：figures/*.svg + figures/*.pdf（通过 rsvg-convert）+ figures/specs/*.json
• 无需外部 API，完全在本地运行

如果传入了 — style-ref: <source>，且上面的辅助程序运行成功，也要在下面的调用中追加 — style-ref: <source>。

当 illustration: gemini 时——调用 /paper-illustration：

/paper-illustration "[method description from PAPER_PLAN.md or NARRATIVE_REPORT.md]"

• Claude 规划 → Gemini 优化 → Nano Banana Pro 渲染 → Claude 审查（评分 ≥ 9）
• 适用于：定性方法示意图、自然风格图示、结果网格
• 输出：figures/ai_generated/*.png
• 需要 GEMINI_API_KEY 环境变量

当 illustration: mermaid 时——调用 /mermaid-diagram：

/mermaid-diagram "[method description from PAPER_PLAN.md]"

• 生成 Mermaid 语法图表（流程图、时序图、类图、状态图等）
• 适用于：轻量级流程图、状态机、简单时序图
• 输出：figures/*.mmd + figures/*.png
• 免费，无需 API 密钥

当 illustration: codex-image2 时——调用 /paper-illustration-image2：

/paper-illustration-image2 "[method description from PAPER_PLAN.md or NARRATIVE_REPORT.md]"

• Claude 规划 → Codex 原生图像生成器渲染 → Claude 审查（与 gemini 使用相同的多阶段工作流，但渲染器不同）
• 适用于：希望使用 GPT-image 风格渲染器且无需 GEMINI_API_KEY 的用户；使用你现有的 Codex / ChatGPT Plus/Pro 配额
• 输出：figures/ai_generated/figure_final.png + latex_include.tex + review_log.json（由 /paper-illustration-image2 SKILL 的 finalize 步骤生成；该步骤会调用规范的 paper_illustration_image2.py 辅助程序，解析方式见 integration-contract §2）
• 前置条件（除 ARIS 标准的 Claude Code 与 Codex 共存配置外）：本地 Codex app-server 必须已登录（codex debug app-server send-message-v2 "ping" 成功），并且必须已注册专用 MCP bridge——一次性 claude mcp add 命令请参见 mcp-servers/codex-image2/README.md。可委托 /paper-illustration-image2 执行预检（它会通过规范链解析辅助程序），也可直接通过 shim tools/paper_illustration_image2.py preflight --workspace . 调用辅助程序，在依赖此路径前进行确认。
• **实验性：**此渲染器通过 Codex debug app-server 调用，而 Codex 文档指出该接口不稳定。在 codex-image2 稳定之前，生产提交流程请优先使用 figurespec 或 gemini。

当 illustration: false 时——完全跳过。所有非数据类图表都必须手动创建（draw.io、Figma、TikZ），并在阶段 3 前放入 figures/。 选择合适的模式：

• 正式的架构图 / 工作流图 / 拓扑图 → figurespec（默认）
• 自然风格的方法概念插图，且拥有 GEMINI_API_KEY → gemini
• 方法概念插图，优先使用 ChatGPT Plus/Pro 配额，而非 Gemini 密钥 → codex-image2
• 快速流程图 / 状态机 → mermaid
• 完全手动控制 → false

这些模式相辅相成，并非互斥：在同一篇论文中，你可以针对不同图表使用不同的 illustration 覆盖设置，多次重新调用生成器。

检查点： 列出生成的图表和手动制作的图表。

📊 Figures complete:
- Data plots (auto, Phase 2): [list]
- Architecture/illustrations (auto, Phase 2b, mode=<illustration>): [list]
- Manual (need your input): [list]
- LaTeX snippets: figures/latex_includes.tex

[If manual figures needed]: Please add them to figures/ before I proceed.
[If all auto]: Shall I proceed with LaTeX writing?

写作准则（适用于每一步起草和修订）： 让每项主张都与其证据相匹配，并直接陈述；一般性注意事项仅放在 Limitations 部分；写作指示绝不是论文内容（“不要提及 X”意味着省略 X，而不是写“我们未涉及 X”）；润色语气绝不能改变论文所掌握的事实；论文应当是一场发布，而不是进度报告——围绕最有力的优势组织内容，让每项实验都承担论证任务，将不利数据保留在表格中，并且只有在证据支持时才将其解释为权衡，绝不叙述挫败经历。/paper-write 包含完整的 CONFIDENT PROSE、HONEST LIMITS 合约。

第 3 阶段：LaTeX 写作

调用 /paper-write，按章节生成 LaTeX：

/paper-write "PAPER_PLAN.md"

如果 $ARGUMENTS 中传入了 — style-ref: <source>，且上述辅助程序成功运行，则在调用时附加 — style-ref: <source>：/paper-write "PAPER_PLAN.md — style-ref: <source>"。

此操作将：

• 按照计划撰写每个章节，并使用规范的 LaTeX 格式
• 插入 figures/latex_includes.tex 中的图表引用
• 根据引文脚手架构建 references.bib
• 清理之前章节结构留下的过期文件
• 自动清理参考文献（删除未引用的条目）
• 润色以消除 AI 风格（删除 “delve”、“pivotal”、“landscape”……）
• GPT-6-Astra 对每个章节进行质量审查

输出： 包含 main.tex、sections/*.tex、references.bib、math_commands.tex 的 paper/ 目录。

检查点： 报告各章节的完成情况。

✍️ LaTeX writing complete:
- Sections: [N] written ([list])
- Citations: [N] unique keys in references.bib
- Stale files cleaned: [list, if any]

Shall I proceed with compilation?

第 4 阶段：编译

调用 /paper-compile 构建 PDF：

/paper-compile "paper/"

此操作将：

• 使用 latexmk -pdf 自动进行多轮编译
• 自动修复常见错误（缺少软件包、未定义引用、BibTeX 语法错误）
• 最多尝试编译 3 次
• 编译后检查未定义引用、页数和字体嵌入情况
• 使用 pdftotext 精确验证页码
• 检测过期文件

输出： paper/main.pdf

检查点： 报告编译结果。

🔨 Compilation complete:
- Status: SUCCESS
- Pages: [X] (main body) + [Y] (references) + [Z] (appendix)
- Within page limit: YES/NO
- Undefined references: 0
- Undefined citations: 0

Shall I proceed with the improvement loop?

第 4.5 阶段：证明验证（仅限理论论文）

如果论文不包含定理、引理或证明，请跳过此阶段。

if paper contains \begin{theorem} or \begin{lemma} or \begin{proof}:
    Run /proof-checker "paper/"
    This invokes GPT-6-Astra xhigh to:
    - Verify all proof steps (hypothesis discharge, interchange justification, etc.)
    - Check for logic gaps, quantifier errors, missing domination conditions
    - Attempt counterexamples on key lemmas
    - Generate PROOF_AUDIT.md with issue list + severity

    If FATAL or CRITICAL issues found:
        Fix before proceeding to improvement loop
    If only MAJOR/MINOR:
        Proceed, improvement loop may address remaining issues
else:
    skip — no proofs, no action

第 4.7 阶段：论文主张审计

如果不存在结果文件，请跳过（例如，不含实验的综述论文或立场论文）。

if results/*.json or results/*.csv or outputs/*.json exist:
    Run /paper-claim-audit "paper/"
    Fresh zero-context reviewer compares every number in the paper
    against raw result files. Catches rounding inflation, best-seed
    cherry-pick, config mismatch, delta errors.

    If FAIL:
        Fix mismatched numbers before improvement loop
    If WARN:
        Proceed, but flag for manual verification
else:
    skip — no experimental results to verify

阶段 5：自动改进循环

调用 /auto-paper-improvement-loop 润色论文：

/auto-paper-improvement-loop "paper/"

如果 $ARGUMENTS 中传入了 — style-ref: <source>，且上述辅助程序已成功运行，则在调用时附加 — style-ref: <source>：/auto-paper-improvement-loop "paper/ — style-ref: <source>"。改进循环的审阅子 Agent 仍然看不到样式参考（该循环自身的 SKILL 禁止传入它）；只有修复实施阶段会使用它。

具体流程（2 轮）：

**第 1 轮：**GPT-6-Astra xhigh 审阅整篇论文 → 找出 CRITICAL/MAJOR/MINOR 问题 → Claude Code 实施修复 → 重新编译 → 保存为 main_round1.pdf

**第 2 轮：**GPT-6-Astra xhigh 冷审重新编译后的草稿（全新审阅——没有修复摘要，也没有延续对话内容）→ 找出剩余问题 → Claude Code 实施修复 → 重新编译 → 保存为 main_round2.pdf

常见改进（校准可能双向调整）：

• 修复假设与模型不匹配的问题
• 将确实过度的主张收窄到证据支持的范围，并直接陈述有依据的主张，删除冗余的保留措辞
• 将分散的通用注意事项整合到 Limitations 中
• 补充缺失的解释和符号说明
• 让 Limitations 更具体（仅在缺少重要限制时进行——切勿凑内容）
• 视需要添加与理论一致的实验

**输出：**三份用于比较的 PDF，以及 PAPER_IMPROVEMENT_LOG.md。

格式检查（包含在改进循环第 8 步中）：最终重新编译后，自动检测并修复溢出版心的 hbox（超出页边距的内容），核实页数是否符合会议限额，并确保排版紧凑。根据位置设定阈值：正文中任何溢出版面都会阻止完成，无论超出多少；附录中超出 10pt 以上才会阻止完成；参考文献中超出 20pt 以上才会阻止完成。

阶段 5.5：论文最终主张审计（提交前的强制关卡）

/auto-paper-improvement-loop 完成后，只要论文包含数值主张且存在机器可读的原始结果文件，就必须在最终报告前重新运行 /paper-claim-audit。

使用与阶段 4.7 相同的检测器：

• 对 paper/main.tex 和 paper/sections/*.tex 运行数值主张正则表达式检测
• 在 results/、outputs/、experiments/ 和 figures/ 中搜索 .json、.jsonl、.csv、.tsv、.yaml 或 .yml 原始证据文件

如果两个检测器都检测到内容，则此阶段为强制步骤，并会阻止最终报告。 如果存在数值主张，但未找到原始结果文件，则停止并警告用户，然后才能宣布论文已完成。 如果不存在数值主张，则跳过。

NUMERIC_CLAIMS=$(rg -n -e '[0-9]+(\.[0-9]+)?\s*(%|\\%|±|\\pm|x|×)' \
  -e '(accuracy|BLEU|F1|AUC|mAP|top-1|top-5|error|loss|perplexity|speedup|improvement)' \
  paper/main.tex paper/sections 2>/dev/null || true)

RAW_RESULT_FILES=$(find results outputs experiments figures -type f \
  \( -name '*.json' -o -name '*.jsonl' -o -name '*.csv' -o -name '*.tsv' -o -name '*.yaml' -o -name '*.yml' \) 2>/dev/null | head -200)

if [ -n "$NUMERIC_CLAIMS" ] && [ -n "$RAW_RESULT_FILES" ]; then
    Run /paper-claim-audit "paper/"
    If FAIL:
        Fix mismatched numbers before the final report
elif [ -n "$NUMERIC_CLAIMS" ]; then
    Stop and warn: the paper contains numeric claims but no raw evidence files were found
fi

**经验依据：**在一次真实的投稿流程中，最终论文声称实验网格比原始 JSON 中实际包含的范围更窄，且一个容差值被向下舍入，低于实际相对误差。这两处问题直到最后一轮手动调用 paper-claim-audit 后才被发现；改进循环未能检测到它们。

阶段 5.6：反方论证审查（理论 / 范围主张较多的论文）

Phase 5.5（主张审计）通过后，只要论文以理论为主，或在标题或摘要中明确提出范围 / 普适性主张，就运行 /kill-argument。这是最终的对抗性检查，用于补充主张 / 引用 / 证明审计：这些审计验证局部正确性（数字相符、引用有效、定理得到证明）；反方论证则检验标题级别的过审能力——论文整体能否经受资深领域主席可能写出的最严厉拒稿意见。

THEORY_ENV_COUNT=$(rg -c '\\begin\{(theorem|lemma|proposition|corollary)\}' paper/main.tex paper/sections 2>/dev/null | awk -F: '{s+=$2} END {print s+0}')
SCOPE_HINT=$(rg -i 'general(ization)?|broad|universal|across|any [A-Za-z]+ model|holds for' paper/sections/0*abstract* 2>/dev/null | head -1)

if [ "$THEORY_ENV_COUNT" -ge 5 ] || [ -n "$SCOPE_HINT" ]; then
    /kill-argument "paper/"
    KILL_VERDICT=$(jq -r '.verdict' paper/KILL_ARGUMENT.json)
    KILL_REASON=$(jq -r '.reason_code' paper/KILL_ARGUMENT.json)
fi

门控条件（取决于 Phase 0 中解析出的 assurance 级别）：

Assurance 级别	是否检测到 THEORY/SCOPE	行为
submission	是	强制执行。FAIL 会阻止最终报告；WARN 需要用户明确确认；BLOCKED/ERROR 会阻止最终报告（未经对抗性审查不得提交）。
submission	否	跳过——写入 KILL_ARGUMENT.json，其中包含 verdict: NOT_APPLICABLE, reason_code: not_theory_or_scope_paper，以便提交验证器查看记录。
internal / draft	是	建议执行。如果用户传入 — kill-argument: true，则运行；否则跳过。会记录 WARN/FAIL，但不会阻止流程。
internal / draft	否	跳过。

/kill-argument 本身不会编辑论文；它会写入 KILL_ARGUMENT.{md,json}。如果发现 still_unresolved critical 问题，则将其加入下一轮 /auto-paper-improvement-loop 队列（该技能的 Step 5.5 会自动将发现的问题合并到修复清单中）。

为什么这一步放在这里最合适： Phase 5（循环）以优化分数为目标，Phase 5.5（主张审计）验证数字，Phase 5.8（引用审计）验证引用——这些都无法发现这样的情况：所有局部组件都正确，但论文仍夸大了实际证明的内容。反方论证是专门用于检查标题范围主张的环节。

阶段 5.8：引用审计（提交门控）

最终的论文主张审计通过后，运行 /citation-audit，从三个方面验证每个 \cite{...}：是否存在、元数据是否正确，以及上下文是否恰当。这是证据与主张保障体系的第四层，也是最后一层（experiment-audit → result-to-claim → paper-claim-audit → citation-audit）。

if paper/references.bib (or paper.bib) exists and contains entries cited from sec/*.tex:
    Run /citation-audit "paper/"
    Fresh cross-family reviewer (gpt-6-astra via Codex MCP) with web/DBLP/arXiv lookup
    verifies each entry:
      (i)   EXISTENCE — paper resolves at claimed arXiv ID / DOI / venue
      (ii)  METADATA — author names, year, venue, title match canonical sources
      (iii) CONTEXT — cited paper actually establishes the claim it supports

    Output:
      - CITATION_AUDIT.md (human-readable per-entry verdict report)
      - CITATION_AUDIT.json (machine-readable verdict ledger)
      - Per-entry verdicts: KEEP / FIX / REPLACE / REMOVE

    If any REPLACE or REMOVE verdicts:
        Surface to user for human approval — never auto-modify content claims
    If only FIX verdicts (metadata corrections):
        Apply with user confirmation, then recompile
    If all KEEP:
        Pass — bibliography clean for submission
else:
    skip — no bib file or no citations

为什么这四层审计中它最具诊断价值： 明显伪造的引用很容易识别。真正危险的失败模式，是用一篇真实论文来支持它实际并未确立的主张（上下文错误的引用）——这类问题会漏过仅检查元数据的审计，并损害投稿可信度。运行成本较高（每条引用都需要进行网络检索）；每次投稿运行一次，不要每次保存时都运行。

经验依据： 在一次真实的投稿流程中，有几篇真实论文被引用来支持它们实际上并不支持的内容，至少还有一个参考文献条目的 author = "Anonymous" 未经解析便提交了。这些问题都未被改进循环或数字主张审计发现；只有重新进行网络检索审查才将其揭示出来。

阶段 5.9：完整性取证（提交前自审 — 默认开启）

在 paper/（绝对路径）上运行 /integrity-forensics 启动器：执行 SHA 固定的 Anti-Autoresearch 扫描 — 证据台账、九个审计维度、确定性裁定 — 随后运行类型化策略门禁和仅追加的义务台账。自审会根据产物所允许的可观测性级别运行（若存在 code/ + results/，则为 L2 — 比任何外部审查者能运行的级别都严格）。

运行时机（在此重新推导 — 不要只信任 .aris/assurance.txt；如果恢复运行时 Phase 0 从未执行，或该文件已过期，则不得静默跳过默认开启的门禁）：

1. 根据 $ARGUMENTS 重新推导保证级别，使用与 Phase 0 / Phase 6.0 相同的规则（显式的 — assurance: 优先；否则 max/beast → submission；否则为 draft）。
2. 解析 $ARGUMENTS，查找 — self_forensics: true | false。
3. 然后：
   • submission → 默认开启。仅在显式设置 — self_forensics: false 时选择退出 — 将回执保存为记录： mkdir -p paper/.aris/forensics && echo "opted-out: — self_forensics: false in \$ARGUMENTS" > paper/.aris/forensics/opt_out.txt （在最终报告中记录为 Forensics: skipped (opted out)）。 该回执记录的是本次运行的决定；它不授权后续任何运行跳过 — Phase 6.0 会自行重新解析 $ARGUMENTS。
   • draft → 默认关闭，除非设置 — self_forensics: true。

门禁处理（退出码 1 = BLOCK：上游 HARD_FLAGS、REVIEW_UNAVAILABLE 或未关闭的关键义务）：

• 拒绝生成最终报告 — 遵循与验证器 FAIL 相同的处理原则。原样呈现上游 REPORT.md 和义务；绝不可通过改写来弱化措辞。
• 将每项义务转交给对应的修复入口（/integrity-forensics 步骤 3 中的类别表）：数值 → 根据结果文件重新计算；引文 → /citation-audit；证明 → /proof-checker；范围/基线/评估设计 → 将其作为审稿人输入交给 /auto-review-loop，或交由人工处理。
• 只能通过 forensics_gate.py resolve（类型化、带哈希的证据）或由人工 waive 来关闭义务。自 2026-08 起，上游报告会列出审计器提出的每项建议，而不是决定哪些建议不计入，因此应预期义务会更多，也应预期其中一些建议会被你判定为错误 — 对这类建议，附上理由后 waive 是正常处理方式，而非最后手段。绝不要为了“让扫描停止标记问题”而修改论文 — 消失但未解决的发现仍会使门禁关闭（UNRESOLVED_DISAPPEARANCE）。
• WARN（SOFT_FLAGS / 未关闭的非关键义务）：可以继续，但最终报告必须在 Forensics 项下列出这些内容 — 包括扫描从未运行过的维度；evaluate 和 fresh 都会打印这些维度。WARN 可以出现在不完整扫描之上：只有在其他情况下结果本会显示干净时，上游才会将不完整性纳入判定结果。
• 零权重的 AIS 风格印象：仅供参考 — 可作为上下文提供给 /auto-paper-improvement-loop，但绝不可作为门禁依据。

阶段 6：最终报告

阶段 6.0 — 提交关卡

撰写最终报告前，先确定当前的保证级别。这里使用与阶段 0 相同的推导规则，确保在跳过阶段 0 或阶段 0 写入失败时，beast / max / — assurance: submission 调用不会悄然降级为草稿。

关卡处的解析（重新推导；不要只相信 .aris/assurance.txt）：

1. 解析 $ARGUMENTS，查找显式的 — assurance: draft | submission 或 — effort: lite | balanced | max | beast 指令。
2. 推导预期级别：
   • 显式的 assurance: 优先
   • 否则，lite / balanced → draft，max / beast → submission
   • 否则为 draft
3. 读取 paper/.aris/assurance.txt。如果文件不存在，立即写入推导出的级别。
4. 如果文件中的值与推导出的级别不一致（例如，文件中写的是 draft，但 $ARGUMENTS 写的是 beast），则用推导出的级别覆盖文件，并在聊天中显示一行警告： ⚠️ .aris/assurance.txt was draft but $ARGUMENTS says submission; overriding.
5. 在阶段 6 的其余部分中，以重新推导出的级别为准。

# Final authoritative value, written and read from the same source
ASSURANCE=<derived-from-$ARGUMENTS>        # draft | submission
mkdir -p paper/.aris
echo "$ASSURANCE" > paper/.aris/assurance.txt

如果 ASSURANCE=draft，直接跳到下方的最终报告模板——默认的 balanced 用户仍维持当前行为，不作更改。

如果 ASSURANCE=submission，先运行下方的飞行前检查清单，然后运行验证器。验证器的退出代码是唯一可信依据——不要根据对话记忆自行宣称“审计已完成”。

提交飞行前检查清单

在阶段 6.0 开始时原样打印此检查清单，并在继续前确认每一行。这样可以防止模型跳过审计却声称已运行的常见失误。

📋 Submission audits required before Final Report:
   [ ] 0. PAPER_ACCEPTANCE_CONTRACT.md (Phase 1.5): re-read every assertion
          against the final PDF + results files; each → satisfied / violated /
          disputed-at-negotiation. ANY violated undisputed assertion blocks the
          Final Report until fixed or the human explicitly waives it (waivers
          recorded in the contract file). Contract absent (pre-1.5 run) → mark
          "no contract" and continue.
   [ ] 1. /proof-checker        → paper/PROOF_AUDIT.json
   [ ] 2. /paper-claim-audit    → paper/PAPER_CLAIM_AUDIT.json
   [ ] 3. /citation-audit       → paper/CITATION_AUDIT.json
   [ ] 4. Resolve $AUDIT_VERIFIER per integration-contract.md §2 (Policy A),
          then: bash "$AUDIT_VERIFIER" paper/ --assurance submission
   [ ] 5. Integrity forensics (Phase 5.9, default ON at submission). FIRST
          re-parse the CURRENT $ARGUMENTS — an opt_out.txt receipt left by a
          PREVIOUS run never carries over; it is a record for the report line,
          not an authorization.
          - current $ARGUMENTS has `— self_forensics: false` → skipping is
            legal; write/refresh paper/.aris/forensics/opt_out.txt.
          - otherwise the whole check is ONE command:
            `python3 "$GATE_HELPER" fresh --paper-dir paper/ --anti-ar-commit
            "$ANTI_AR_COMMIT"` (the pin constant from /integrity-forensics;
            an old-pin gate must be re-audited) — exit 0 ⟺ a
            gate exists ∧ no paper file changed after it ∧ it matches the
            current obligations ledger ∧ its decision is pass-capable (an
            ALLOWLIST: WARN / NO_NEW_BLOCKER — an unknown or missing token
            never passes). Exit 1 → the sweep never saw this text (or the
            gate is BLOCK): run Phase 5.9 NOW, before the Final Report —
            BLOCK is blocked, same as a verifier FAIL.
   [ ] 6. Block Final Report iff verifier exit code != 0 OR row 0 found a
          violated undisputed assertion OR row 5 is red. (THREE separate
          gates: row 0 is graded by instruction against the contract; the
          verifier checks audit JSONs only — verify_paper_audits.sh does NOT
          read the contract; row 5 reads the forensics gate artifact.)

下方“运行验证器”中的解析器会依次尝试 .aris/tools/verify_paper_audits.sh（由 install_aris.sh 创建）， 然后是 tools/verify_paper_audits.sh（仓库内运行），接着是 $ARIS_REPO/tools/verify_paper_audits.sh（由环境变量设置或从清单推导出的 路径），最后是通过全局指针文件 ~/.aris/repo（#366）解析出的相同 $ARIS_REPO/tools/verify_paper_audits.sh。该链始终按 1 → 2 → 3 → 4 的顺序 尝试；设置 export ARIS_REPO=~/… 仅在第 1 层和第 2 层不存在时，确保 第 3 层有有效目标；只有在环境变量和项目清单都未设置 ARIS_REPO 时，才会 使用第 4 层。

调用四项审计

每项子审计都在一个全新的 Codex 线程中运行（绝不使用 codex-reply，也绝不将先前审计的输出作为上下文传入——这可依据 shared-references/reviewer-independence.md 保持审查者独立性）。

每项子审计始终会生成其 JSON 产物，即使内容检测器未检测到相关内容也不例外。检测结果为否的运行会生成判定 NOT_APPLICABLE；禁止静默跳过。请参阅每项审计的 SKILL.md 中的“提交产物生成”部分。

顺序：

1. /proof-checker "paper/" → 写入 paper/PROOF_AUDIT.json（如果论文不包含定理 / 引理 / 证明，则生成 NOT_APPLICABLE）
2. /paper-claim-audit "paper/" → 写入 paper/PAPER_CLAIM_AUDIT.json（如果论文没有数值声明，则生成 NOT_APPLICABLE；如果存在数值声明但缺少原始结果文件，则生成 BLOCKED）
3. /citation-audit "paper/" → 写入 paper/CITATION_AUDIT.json（如果没有 .bib 文件或没有 \cite{...} 用法，则生成 NOT_APPLICABLE）
4. paper/KILL_ARGUMENT.json 已在阶段 5.6 写入（包括适用于非理论论文的 NOT_APPLICABLE 记录）——验证器要求这四项全部齐备。

运行验证器

通过规范的严格安全链解析 $AUDIT_VERIFIER（参见 shared-references/integration-contract.md §2，Policy A — gate）。在 assurance: submission 模式下，验证器至关重要：如果无法解析辅助程序，SKILL 会中止最终报告，而不会生成未经验证的 submission-ready 声明。

# Resolve the audit verifier (Policy A — gate).
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
AUDIT_VERIFIER=".aris/tools/verify_paper_audits.sh"
[ -f "$AUDIT_VERIFIER" ] || AUDIT_VERIFIER="tools/verify_paper_audits.sh"
[ -f "$AUDIT_VERIFIER" ] || { [ -n "${ARIS_REPO:-}" ] && AUDIT_VERIFIER="$ARIS_REPO/tools/verify_paper_audits.sh"; }
[ -f "$AUDIT_VERIFIER" ] || {
  echo "ERROR: verify_paper_audits.sh not resolved at .aris/tools/, tools/, \$ARIS_REPO/tools/, or via ~/.aris/repo." >&2
  echo "       assurance=submission requires the verifier; aborting Final Report." >&2
  echo "       Fix: rerun bash tools/install_aris.sh or smart_update.sh (refreshes ~/.aris/repo), export ARIS_REPO, or copy the helper to tools/." >&2
  exit 1
}

bash "$AUDIT_VERIFIER" paper/ --assurance submission

• 退出代码 0 — 所有强制审计均已提供，符合 JSON schema，哈希为最新状态，且没有阻断性判定。编写最终报告前，请读取 paper/.aris/audit-verifier-report.json 中的 overall_assurance — 退出代码 0 涵盖 accepted（跨领域／独立审查）和 provisional （同领域或旧版审查；可以继续，但不得声称已获独立认可）两种状态。最终报告中的“已准备好提交”一行应取自该字段，而不能仅依据退出代码。
• 退出代码 1 — 将 paper/.aris/audit-verifier-report.json 原样呈现给用户，拒绝生成最终报告，并列出每个失败项的具体补救措施：
  • MISSING → 重新运行相应审计
  • STALE → 审计运行后论文文件有过编辑；重新运行受影响的审计
  • BLOCKING_VERDICT（FAIL / BLOCKED / ERROR）→ 修复根本问题，然后重新运行审计
  • SCHEMA_INVALID → 审计产物格式错误；重新运行审计

验证器运行开销很低（< 1 s）。修复任何问题后，请先重新运行验证器，再宣称全部通过。

可选的强化措施（非默认）

希望在 hook 层面实施强制约束的团队——也就是说，验证器显示红色时，运行框架会在物理层面阻止 Stop 事件——可以在 ~/.claude/settings.json 中注册 Stop hook：

{
  "hooks": {
    "Stop": [
      {"command": "bash <ARIS_REPO>/tools/verify_paper_audits.sh paper/ --assurance submission"}
    ]
  }
}

此处提供了相关文档，但并非必需。Phase 6.0 的“验证器即真相”模式是仓库的默认行为。

---

Phase 6.1 — 最终报告（仅在提交门禁通过后运行， 或在 assurance=draft 时直接运行）

# Paper Writing Pipeline Report

**Input**: [NARRATIVE_REPORT.md or topic]
**Venue**: [ICLR/NeurIPS/ICML/CVPR/ACL/AAAI/ACM/IEEE_JOURNAL/IEEE_CONF]
**Assurance**: [draft | submission]
**Submission-ready**: [yes | provisional | no]   
**Forensics**: [NO_NEW_BLOCKER | WARN: <n> open obligations | BLOCK | skipped (opted out) | skipped (draft)]   
**Date**: [today]

## Pipeline Summary

| Phase | Status | Output |
|-------|--------|--------|
| 0. Assurance Setup | ✅ | paper/.aris/assurance.txt = [draft\|submission] |
| 1. Paper Plan | ✅ | PAPER_PLAN.md |
| 1.5 Acceptance Contract | [accepted\|contested\|no contract] ([N] rounds) | PAPER_ACCEPTANCE_CONTRACT.md |
| 2. Figures | ✅ | figures/ ([N] auto + [M] manual) |
| 3. LaTeX Writing | ✅ | paper/sections/*.tex ([N] sections, [M] citations) |
| 4. Compilation | ✅ | paper/main.pdf ([X] pages) |
| 5. Improvement | ✅ | [score0]/10 → [score2]/10 |
| 4.5 Proof Audit | [PASS\|WARN\|FAIL\|NOT_APPLICABLE\|BLOCKED\|ERROR] | PROOF_AUDIT.{md,json} |
| 5.5 Paper Claim Audit | [PASS\|WARN\|FAIL\|NOT_APPLICABLE\|BLOCKED\|ERROR] | PAPER_CLAIM_AUDIT.{md,json} |
| 5.8 Citation Audit | [PASS\|WARN\|FAIL\|NOT_APPLICABLE\|BLOCKED\|ERROR] | CITATION_AUDIT.{md,json} |
| 6.0 Assurance Verifier | [OK\|STALE\|BLOCKING_VERDICT\|HAS_ISSUES\|SCHEMA_INVALID\|MISSING] per audit; exit [0\|1] overall (N/A if draft) | .aris/audit-verifier-report.json |

## Improvement Scores
| Round | Score | Key Changes |
|-------|-------|-------------|
| Round 0 | X/10 | Baseline |
| Round 1 | Y/10 | [summary] |
| Round 2 | Z/10 | [summary] |

## Deliverables
- paper/main.pdf — Final polished paper
- paper/main_round0_original.pdf — Before improvement
- paper/main_round1.pdf — After round 1
- paper/main_round2.pdf — After round 2
- paper/PAPER_IMPROVEMENT_LOG.md — Full review log
- paper/PROOF_AUDIT.{md,json} — Proof-obligation verification (always emitted at `assurance=submission`; `NOT_APPLICABLE` when no theorems)
- paper/PAPER_CLAIM_AUDIT.{md,json} — Numerical claim verification (always emitted at `assurance=submission`; `NOT_APPLICABLE` when no numeric claims; omitted in `draft` mode if Phase 5.5 detector was negative)
- paper/CITATION_AUDIT.{md,json} — Bibliography verification (always emitted at `assurance=submission`; `NOT_APPLICABLE` when no `.bib` or no `\cite{...}`; omitted in `draft` mode if Phase 5.8 detector was negative)
- paper/.aris/audit-verifier-report.json — External verifier report (submission only)

## Remaining Issues (if any)
- [items from final review that weren't addressed]

## Next Steps
- [ ] Visual inspection of PDF
- [ ] Add any missing manual figures
- [ ] Submit to [venue] via OpenReview / CMT / HotCRP

输出协议

所有输出文件均须遵循以下共享协议：

• 输出版本控制协议 — 先写入带时间戳的文件，再复制到固定名称
• 输出清单协议 — 将每项输出记录到 MANIFEST.md
• 输出语言协议 — 注意：论文撰写始终输出用于投稿的英文 LaTeX

关键规则

• 大型文件处理：如果 Write 工具因文件过大而失败，请立即改用 Bash（cat << 'EOF' > file）分块写入。不要征求用户许可——直接静默处理。
• 不要跳过阶段。 每个阶段都以前一阶段为基础——跳过会导致错误。
• 阶段间检查点：当 AUTO_PROCEED=false 时，展示结果并等待批准。
• 先准备手动图表。 如果论文需要架构图或定性结果，用户必须在 Phase 3 前提供。
• 进入改进循环前必须成功编译。 先修复所有错误。
• 保留所有 PDF。 用户需要 round0/round1/round2 进行比较。
• 记录所有内容。 流程报告应完整自含。
• 遵守页数限制。 如果论文超过投稿场所的页数限制，请在进入改进循环前提出具体的删减建议。

与其他工作流配合使用

/idea-discovery "direction"         ← Workflow 1: find ideas
implement                           ← write code
/run-experiment                     ← deploy experiments
/auto-review-loop "paper topic"     ← Workflow 2: iterate research
/paper-writing "NARRATIVE_REPORT.md"  ← Workflow 3: you are here
                                         submit! 🎉

Or use /research-pipeline for the Workflow 1+2 end-to-end flow,
then /paper-writing for the final writing step.

典型时间安排

阶段	时长	可以休息吗？
1. 论文计划	5-10 min	否
2. 图表	5-15 min	否
3. LaTeX 撰写	15-30 min	是 ✅
4. 编译	2-5 min	否
5. 改进	15-30 min	是 ✅

总计： 从叙述性报告到润色完成的 PDF，完整论文约需 45-90 min。