paper-writing

ワークフロー 3：論文執筆パイプライン

各レビュー担当者枠の前に、選択可能なレビュー担当者に従ってください： 呼び出しを解決 → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP） を、正規のヘルパーリゾルバー経由で reviewer_route.py とともに使用し、この 枠のティア、新しいコンテキスト、ソース／画像入力、決定論的なゲートを維持します。 以下の Codex の例／固定設定は backend=codex にのみ適用されます。それ以外のルートでは それぞれの初回呼び出し／返信の契約を使用します。ルートと実際に返された ID を保存してください。 利用できない選択肢は REVIEW_UNAVAILABLE とします。実際の ファミリー／完了状況／スコープに基づいて採否を判定します。 レビュー担当者を含む子プロセスには、呼び出し時のレビュー担当者／モデル／労力の オーバーライドを引き継ぎます。生成ワーカーに変更はありません。

$ARGUMENTSを対象とする、完全な論文執筆ワークフローを実行します。

概要

このスキルは、5 つのサブスキルを単一の自動パイプラインに連結します：

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

各フェーズは、前のフェーズの出力を基に進みます。最終成果物は、LaTeX ソースとコンパイル済み PDF を含む、洗練されレビュー済みの paper/ ディレクトリです。

このハイブリッドパックでは、パイプライン自体に変更はありませんが、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 ID、http(s) URL。Overleaf の URL／ID は受け付けません。まず /overleaf-sync setup <id> でクローンし、ローカルのクローンパスを指定してください。

厳格なルール（契約の全文は tools/extract_paper_style.py の docstring を参照）：

• 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 — 4 つの必須監査（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`](../shared-references/integration-contract.md) §2 に従って解決）。終了コードが 0 以外の場合、最終レポートはブロックされます。

**回避策：**従来の「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>"。（執筆側のフェーズです。引き継ぎは許可されますが、以下の査読者／監査者フェーズにはスタイル参照を渡してはいけません。）

この処理の内容：

• 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：合意に基づく受け入れ基準（執筆開始前）

計画には論文に含める内容を記載します。CONTRACT では「完了」の定義を示します — 最初のセクションを執筆する前に対立的に合意し、最後に評価する、 検証可能なアサーションのチェックリストです。（計画は範囲を定め、 CONTRACT は評価対象を定めます。）

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 の場合は、要求に応じて CONTRACT を修正し、 mcp__codex__codex-reply で再送信します（同じスレッドを使用します — 交渉は1つの会話で行います）。最大3ラウンドです。

4. フォールバック — パイプラインを決して停止させないでください。 第3ラウンドでも no の場合は、未解決の要求を「## Disputed」セクションに一字一句そのまま記録し、 status: contested とします。異議ありの CONTRACT は「CONTRACT が誤っている場合に 人間を介入させる」ための明確なトリガーであるため、この1つの判断については AUTO_PROCEED より優先されます。処理を一時停止し、異議を人間に提示して判断を仰いでください。 人間から応答がない場合（無人／夜間の実行）は処理を続行します。ただし、異議ありの CONTRACT では結果に制約がかかります。フェーズ 6.0 では異議のないアサーションのみを ゲートの対象とし、最終レポートでは Submission-ready: no と設定して、異議を 一字一句そのまま再掲します。人間が戻った時点で判断を仰ぎます。

出力：PAPER_ACCEPTANCE_CONTRACT.md（status: accepted | contested、 ラウンド数、査読者スレッド ID）。受け入れ後、CONTRACT は凍結されます — フェーズ 2〜5 はこれに基づいて作業し、編集はしません。執筆中にアサーションが （単に都合が悪いのではなく）本当に誤りだと判明した場合は、CONTRACT に関する問題として、 チェックポイントで提示してください。黙って書き換えてはいけません。

境界：/paper-claim-audit（フェーズ 4.7、5.5）はコンテキストを一切与えずに実行します — CONTRACT は執筆側のゲートであり、主張の監査者には決して渡しません （独立性を保つことが目的です。2つの異なるネットです）。

Phase 2：図の生成

— style-ref: <source> が $ARGUMENTS に渡され、上記のヘルパーが成功した場合、このパイプラインのすべての執筆側サブスキル呼び出し（Phases 1、2b、3、5）に — style-ref: <source> を追加します。レビュー担当／監査担当の呼び出し（Phases 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 はデータプロットと比較表を扱います。アーキテクチャ図、パイプライン図、手法のイラストは、以下の Phase 2b で扱います。

Phase 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 と同じ多段階ワークフローですが、レンダラーは異なります）
• 最適な用途：GEMINI_API_KEY を必要とせずに GPT-image スタイルのレンダラーを使いたいユーザー。既存の Codex / ChatGPT Plus/Pro の利用枠を使います
• 出力：figures/ai_generated/figure_final.png + latex_include.tex + review_log.json（/paper-illustration-image2 SKILL の finalize ステップから出力されます。このステップは、integration-contract §2 に従って解決される正規の paper_illustration_image2.py ヘルパーに処理を委譲します）
• 前提条件（ARIS の標準的な Claude Code + Codex の併用環境に加えて）：ローカルの Codex app-server にサインインしている必要があります（codex debug app-server send-message-v2 "ping" が成功すること）。また、専用の MCP ブリッジを登録する必要があります。初回に実行する claude mcp add コマンドについては mcp-servers/codex-image2/README.md を参照してください。事前確認は /paper-illustration-image2 に委譲してください（ヘルパーは正規のチェーンを介して解決されます）。または、tools/paper_illustration_image2.py preflight --workspace . のシムからヘルパーを直接呼び出し、この方法に依存する前に確認してください。
• 実験的： このレンダラーは Codex debug app-server を介して呼び出されますが、Codex はこれを不安定なインターフェースとして文書化しています。codex-image2 が安定するまでは、本番投稿のワークフローでは figurespec または gemini を優先してください。

illustration: false の場合 — 完全にスキップします。データ以外の図はすべて手動で作成し（draw.io、Figma、TikZ）、Phase 3 の前に figures/ に配置する必要があります。 適切なモードの選択：

• 正式なアーキテクチャ／ワークフロー／トポロジー図 → figurespec（デフォルト）
• 自然なスタイルの手法概念イラストで、GEMINI_API_KEY がある場合 → gemini
• 手法概念イラストで、Gemini のキーより ChatGPT Plus/Pro の利用枠を優先する場合 → 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?

執筆時の不変条件（すべての執筆・改訂ステップ）： 各主張をその根拠に合わせて調整し、直接的に述べます。一般的な留保は「限界」セクションのみに記載します。執筆指示を原稿の内容にしてはいけません（「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 を作成します
• 以前のセクション構成から残った古いファイルを削除します
• 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

Phase 5：自動改善ループ

/auto-paper-improvement-loop を呼び出して、論文を仕上げます。

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

— style-ref: <source> が $ARGUMENTS に渡され、上記のヘルパーが成功している場合は、呼び出しに — style-ref: <source> を追加します。/auto-paper-improvement-loop "paper/ — style-ref: <source>" のように指定してください。改善ループのレビュアーサブエージェントには、引き続きスタイル参照は渡されません（ループ自体の 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 として保存

一般的な改善項目（調整は両方向に行います）：

• 前提とモデルの不一致を修正する
• 実際の過大な主張を、裏付けのある範囲に絞るとともに、裏付けのある主張を明確に述べ、冗長な留保表現を削除する
• 散在する一般的な注意書きを「制限事項」にまとめる
• 不足している解釈や記法を追加する
• 「制限事項」をより具体的にする（重大な制限が欠けている場合のみ — 水増しはしない）
• 必要に応じて理論に沿った実験を追加する

出力： 比較用の PDF 3 件と PAPER_IMPROVEMENT_LOG.md。

フォーマットチェック（改善ループのステップ 8 に含まれます）：最終再コンパイル後、はみ出した hbox（余白を超えるコンテンツ）を自動検出して修正し、ページ数が投稿先の上限内かを確認して、コンパクトな書式を確保します。位置に応じたしきい値を適用します。本文のはみ出しはサイズにかかわらず完了を妨げます。付録のはみ出しは 10pt を超える場合のみ、参考文献のはみ出しは 20pt を超える場合のみ、完了を妨げます。

Phase 5.5：論文の主張の最終監査（投稿必須ゲート）

/auto-paper-improvement-loop の完了後、論文に数値の主張が含まれ、機械可読な生の結果ファイルが存在する場合は、最終報告の前に /paper-claim-audit を再実行します。

Phase 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：反論可能性の敵対的レビュー（理論・スコープ重視の論文）

フェーズ 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

適用条件（フェーズ 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 の実行に回します（このスキルのステップ 5.5 で、検出事項が修正リストに自動的にマージされます）。

この位置が適切な理由： フェーズ 5（ループ）はスコアの最適化を行い、フェーズ 5.5（主張の監査）は数値を検証し、フェーズ 5.8（引用の監査）は引用を検証します。しかし、各要素はすべて局所的に正しいにもかかわらず、論文が実際に証明している内容を誇張しているケースは、いずれの監査でも検出できません。反論可能性のチェックは、論文の要点とスコープを対象とする専用の確認です。

フェーズ 5.8：引用の監査（提出ゲート）

最終的な論文主張の監査を通過した後、/citation-audit を実行し、すべての \cite{...} について、存在、メタデータの正確性、文脈上の適切性という 3 つの観点から検証します。これは、証拠と主張の保証スタックにおける 4 番目かつ最後の層です（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

4 つの監査層の中で、これが最も診断に有効な理由： まったく架空の引用は簡単に見抜けます。危険なのは、実在する論文を、その論文が実際には裏付けていない主張の根拠として使うことです（文脈の誤った引用）。これはメタデータだけを確認するチェックでは見逃され、提出の信頼性を損ないます。実行には壁時計時間で大きなコストがかかります（各項目についてウェブ検索が必要です）。保存のたびではなく、提出ごとに 1 回実行してください。

実証的な動機： 実際の提出作業では、複数の実在する論文が、実際には裏付けていない文脈で引用されていました。また、メタデータが解決されていなかったため、少なくとも 1 件の bib エントリが author = "Anonymous" のまま提出されました。改善ループも数値的な主張の監査もこれらを検出できず、新たにウェブ検索で確認したことで初めて明らかになりました。

フェーズ 5.9：完全性フォレンジック（提出物の自己監査 — デフォルトで有効）

/integrity-forensics ランチャーを paper/（絶対パス）に対して実行します。SHA でピン留めされた Anti-Autoresearch スイープ（エビデンス台帳、9 つの監査者ディメンション、決定論的な判定）に続いて、型付きポリシーゲートと追記専用の義務台帳を実行します。自己監査は、成果物が許す可観測性のレベルで実行されます（code/ と results/ が存在する場合は L2 で、外部レビュー担当者が実行できるものより厳格です）。

実行タイミング（ここで再導出します。.aris/assurance.txt だけを信用しないでください。Phase 0 が実行されなかった再開後の実行や、ファイルが古くなっている場合に、デフォルトで有効なゲートを黙ってスキップしてはなりません）：

1. Phase 0 / Phase 6.0 と同じルールで、$ARGUMENTS から保証レベルを再導出します（明示的な — 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 がスキップされた場合や、書き込みに失敗した場合でも、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 とある）、ファイルを導出したレベルで上書きし、チャットに1行の警告を表示します。 ⚠️ .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 を使って解決した同じ $ARIS_REPO/tools/verify_paper_audits.sh（#366）を順に試します。このチェーンでは常にレイヤー 1 → 2 → 3 → 4 の順に試します。export ARIS_REPO=~/… を設定しても、レイヤー 1 と 2 が存在しない場合にレイヤー 3 の有効な参照先が保証されるだけであり、レイヤー 4 が動作するのは、環境変数もプロジェクトマニフェストも 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 レコードを含みます）。検証ツールは4つすべてを必要とします。

ベリファイアの実行

shared-references/integration-contract.md §2、Policy A — gate を参照し、正規の厳密かつ安全なチェーンを使って $AUDIT_VERIFIER を解決します。assurance: submission では、ベリファイアは不可欠です。ヘルパーを解決できない場合、SKILL は未検証の submission-ready という主張を出す代わりに、Final Report を中止します。

# 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

• Exit 0 — 必須の監査がすべて存在し、JSON スキーマが有効で、ハッシュが最新であり、ブロッキング判定がありません。Final Report を書く前に、paper/.aris/audit-verifier-report.json から overall_assurance を読み取ってください。Exit 0 は、accepted（ファミリー横断／独立レビュー）と provisional（同一ファミリー内またはレガシーレビュー。先に進めますが、独立した承認を主張できません）の両方を対象とします。Final Report の Submission-ready 行には、終了コード単独ではなく、必ずこのフィールドの値を使用します。
• Exit 1 — paper/.aris/audit-verifier-report.json をそのままユーザーに提示し、Final Report の生成を拒否して、失敗した各行に対する具体的な修正方法を列挙します。
  • MISSING → 該当する監査を再実行します
  • STALE → 監査の実行後に論文ファイルが編集されています。該当する監査を再実行します
  • BLOCKING_VERDICT（FAIL / BLOCKED / ERROR）→ 根本的な問題を修正してから、監査を再実行します
  • SCHEMA_INVALID → 監査成果物の形式が不正です。監査を再実行します

ベリファイアは簡単に再実行できます（1 秒未満）。問題を修正したら、成功を宣言する前に再実行してください。

任意の強化（デフォルトではありません）

フックレベルでの強制、つまりベリファイアが失敗している間、ハーネスによって Stop イベントが物理的に阻止されるようにしたいチームは、~/.claude/settings.json に Stop フックを登録できます。

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

これはここで説明していますが、必須ではありません。Phase 6.0 の「ベリファイアを真実の情報源とする」パターンが、リポジトリのデフォルトの動作です。

---

Phase 6.1 — Final Report（提出ゲートが成功してからのみ実行。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 分	いいえ
2. 図表	5-15 分	いいえ
3. LaTeX 執筆	15-30 分	はい ✅
4. コンパイル	2-5 分	いいえ
5. 改善	15-30 分	はい ✅

合計： ナラティブレポートから洗練された PDF まで、論文全体で約45-90 分です。