resubmit-pipeline

再投稿パイプライン：テキストのみの微修正モード

各レビュアースロットの前に必ず、レビュアーの選択に従ってください。 呼び出しの解決 → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP） の順に確認し、正規のヘルパーリゾルバーを通じて reviewer_route.py を使用します。その際、 このスロットのティア、新規コンテキスト、ソース／画像入力、決定的なゲートを維持してください。 以下の Codex の例／固定指定は backend=codex にのみ適用されます。それ以外のルートでは、 それぞれの初回呼び出し／返信の契約を使用します。ルートと実際に返された ID を保存してください。 選択したレビュアーが利用できない場合は REVIEW_UNAVAILABLE とします。実際の ファミリー／完了状況／スコープに基づいて採否を分類してください。レビュアーを含む子プロセスには、 呼び出し側のレビュアー／モデル／エフォートのオーバーライドを渡してください。 生成ワーカーに変更はありません。

テキストのみの制約のもと、完成度の高い論文を新しい投稿先向けに仕上げます：$ARGUMENTS

目的

ARIS の執筆ワークフローの多くは、入力がナラティブ形式のレポート（ワークフロー 3）、または実験／参考文献の変更／構成の編集がまだ必要な執筆中の論文であることを想定しています。再投稿は、これらとは根本的にスコープが異なります。

• 論文はすでに完成しています。証明と実験は完了しており、参考文献も精選されています。
• ユーザーは、以前の投稿先で受けた査読者の懸念を反映して再投稿したいと考えていますが、新しい実験、新たな引用、フレームワークの変更は望んでいません（LLM の幻覚への懸念、再投稿までの厳しいスケジュール、限られた計算予算が理由です）。
• 元の投稿ディレクトリは読み取り専用です。新しい投稿は、既存の状態を決して変更せず、隣接する別ディレクトリに作成する必要があります。
• 投稿先によってページ数の上限が、元の投稿先より短い場合があります（例：ワークショップのカメラレディ版から 9 ページの本論へ）。

既存のスキルはいずれも近接する領域を扱いますが、この構成作業全体には対応していません。/rebuttal は OpenReview 形式の回答書を作成するもので、論文内の微修正には対応しません。/auto-paper-improvement-loop は各ラウンドを実行するエンジンですが、元にする原稿の選択、投稿先フォーマットへの移行、編集許可リストの設定、査読者のフィードバックの取り込み、変更しない項目の決定がすでに済んでいることを前提としています。/resubmit-pipeline は、このオーケストレーションの不足を補います。

使用する場面

• 理論論文またはシステム論文が投稿先 A で不採録となり、限られた期間（1～2 週間以内）で投稿先 B に再投稿したい場合。
• 3 つの入力がそろっている場合：投稿先 A の形式で整えた完成済み論文ディレクトリ、投稿先 B の形式／テンプレート／スタイルファイル、以前の査読レポート。
• 定理の再導出、新しい実験の実施、参考文献の変更を明示的に望まない場合。

使用しない場面

• 論文にまだ実験が必要な場合 — まず /experiment-bridge → /auto-review-loop を使用してください。
• 論文にまだ構成の書き直しや新しいセクションの追加が必要な場合 — /paper-writing（ワークフロー 3）を使用してください。
• 査読者への回答書そのものを書きたい場合 — /rebuttal（ワークフロー 4）を使用してください。
• 査読者のフィードバックが新しい定理または新しいフレームワークを求めている場合 — 開始前にユーザーに確認してください。このケースを検出した場合、このスキルは reason_code: out_of_scope_microedit を付けて BLOCKED を出力します。

定数

• REVIEWER_MODEL = /auto-paper-improvement-loop のデフォルト（Codex MCP 経由の gpt-6-astra）を継承します。ただし、ユーザーが — reviewer-model: gpt-5.4（レガシー）または選択したバックエンドで有効な別のモデルを指定した場合を除きます。backend=codex の場合、既存スキルの慣例に従い、すべてのレビュアー呼び出しで推論の強度は xhigh に固定されます。
• ROUNDS = 2（デフォルト。/auto-paper-improvement-loop の収穫逓減の基準に準拠）。第 2 ラウンドのチェックポイントでユーザーが明示的に承認した場合に限り、フェーズ 2 で収束していないと報告された場合に第 3 ラウンドを実行します。
• EFFORT = max（再投稿のデフォルト。再投稿は重要度が高いため）。時間が非常に限られている場合、ユーザーは — effort: balanced で上書きできます。
• EDIT_WHITELIST_PATH = <paper-base-dir>/../<NewVenue>/.aris/edit_whitelist.yaml（フェーズ 0 で自動生成。ユーザーはカスタムパスで上書きできます）。
• NEVER_OVERWRITE = true（常時。これは厳守すべき契約であり、以前の投稿ディレクトリは変更されません）。
• ASSURANCE_LEVEL = submission（デフォルト。再投稿は常に実際の投稿を対象とします）。

入力

必須入力は 3 つです。

1. paper-base-dir — 会場 A の形式に整えられた論文です。main.tex（または同等のエントリーファイル）、sec/ または sections/、references.bib（または同等のファイル）、およびコンパイル済みの main.pdf（見た目のレビューに使用）を含む必要があります。
2. — target-venue: <name> — 次のいずれかです：iclr、icml、neurips、aaai、ijcai、colm、tmlr、uai、または other。このスキルは、<paper-base-dir>/templates/<venue>.{sty,tex,bst} または認識済みのテンプレートディレクトリに会場のスタイルファイルがあることを想定しています。other の場合、ユーザーは — target-style-dir: <path> を指定します。
3. — review-corpus: <path> — 前の投稿先のレビュアーレポートを .txt または .md ファイル（できればレビュアーごとに 1 ファイル）として格納したディレクトリです。--review-corpus が省略された場合、このスキルは reason_code: missing_review_corpus とともに BLOCKED を出力します。再投稿の主な目的は、こうした懸念に対応することだからです。

任意入力：

• — reviewer-model: gpt-5.4 — デフォルトのレビュアー（gpt-6-astra）を上書きします。レガシーな再現性が必要な場合や、旧クォータ枠を利用する場合に指定します。
• — rounds: <int> — デフォルトの 2 を上書きします。
• — assurance: draft — 必須ゲートを緩和します（デフォルトは submission）。
• — effort: balanced — 時間が差し迫っている場合に max を緩和します。
• — skip-anonymity-scan — フェーズ 0.5 の匿名性チェックをスキップします（TMLR などの二重盲検でない会場でのみ有効です。それ以外では WARN となります）。
• — overleaf-target: <project-id> — フェーズ 4 のプッシュに使用する Overleaf プロジェクト ID です（/overleaf-sync setup に従います）。

パイプライン

フェーズ 0：物理的な分離の設定（既存ファイルは一切編集しない）

Resubmit における最も重要な不変条件は、過去の投稿ディレクトリを決して上書きしないことです。新しい投稿先のディレクトリは、過去のすべての投稿先と同階層に配置します。

# Resolve target-venue → new sibling dir name (capitalized)
NEW_VENUE_DIR="$(dirname "$PAPER_BASE_DIR")/$(echo "$TARGET_VENUE" | sed 's/.*/\u&/')"

# Atomic dir create — `mkdir` (not `mkdir -p`) fails fast if the dir exists,
# avoiding the TOCTOU race window of `[ -e ] && exit; mkdir -p`. The mkdir
# itself must succeed exactly once; if a concurrent run gets there first,
# this errors out per resubmit-pipeline's never-overwrite invariant.
mkdir "$NEW_VENUE_DIR" 2>/dev/null || {
    echo "ERROR: $NEW_VENUE_DIR already exists; resubmit-pipeline never overwrites prior submissions. Pick a different target-venue or rename the existing dir." >&2
    exit 1
}
mkdir -p "$NEW_VENUE_DIR/.aris"

構成ルール（すべて cp を使い、\input{../...} やシンボリックリンクは使いません）：

1. main.tex — 投稿先の .sty に合わせて新規作成します。ひな形として templates/<venue>.tex を使い、ベース投稿先の main.tex からコピーするのは \title{}、\author{}、アブストラクトのインクルード行、セクションの入力行だけです。新しい main.tex はすべて $NEW_VENUE_DIR/ 内に置きます。
2. sec/（または sections/） — 物理的に cp -r $PAPER_BASE_DIR/sec/ $NEW_VENUE_DIR/sec/ を実行します。**シンボリックリンクを作成したり、新しい main から \input{../sec/...} を使ったりしないでください。**シンボリックリンクは Overleaf の zip エクスポートを壊します。また、ディレクトリをまたぐ \input は共有プールを変更し、過去の投稿に影響します。
3. math_commands.tex（およびセクションが依存するその他のマクロファイル）— $NEW_VENUE_DIR/ 内に物理的に cp します。
4. Figure/（または figures/） — ディレクトリをコピーします（cp -r）。パスに関する注意点：既存のセクションでは \includegraphics{Figure/foo.pdf} と指定されている可能性があります。子ディレクトリから \graphicspath{{../Figure/}} を設定すると、../Figure/Figure/foo.pdf と解決され、誤りになります。Figure/ を直接コピーする（推奨）か、\graphicspath{{../}} を使ってください。
5. 参考文献 — 新しい main.tex に \bibliographystyle{<venue-bst>} と \bibliography{../references} を直接記述します。すでに独自の \bibliography{} コマンドを含む既存の ref.tex や references.tex を \input してはいけません（パス解決が気づかないうちに壊れます）。
6. .aris/ — $NEW_VENUE_DIR/.aris/ を作成し、assurance.txt に submission と記述します（検証ツールが想定する場所に合わせます）。

フェーズ 0 の出力：ソースファイル一式を含む新しい同階層ディレクトリです。テキスト内容はまだ編集せず、コンパイル可能な状態にします。

フェーズ 0.5：ヘルスチェックと匿名性スキャン（テキスト編集はまだ行いません）

監査や編集を始める前に、新しい投稿先のスタイルで論文が問題なくコンパイルでき、投稿先がダブルブラインドの場合は匿名性スキャンに合格する必要があります。

コンパイルとページ数：

cd "$NEW_VENUE_DIR"
latexmk -C
latexmk -pdf -interaction=nonstopmode -halt-on-error main.tex 2>&1 | tee compile.log

コンパイルに失敗した場合：verdict: BLOCKED, reason_code: phase_0_5_compile_failed を含む RESUBMIT_REPORT.json を出力し、エラーをユーザーに提示して停止します。よくある原因：math_commands.tex のマクロ不足、投稿先のスタイルで定義されていないコマンド、\graphicspath の問題。

投稿先の上限とページ数の比較（まず測定してください。決めつけないでください）：

PAGES=$(pdfinfo main.pdf | awk '/^Pages:/ {print $2}')
LIMIT=$(grep -oE "page_limit: [0-9]+" "$NEW_VENUE_DIR/templates/$TARGET_VENUE.tex" | awk '{print $2}')
echo "Pages: $PAGES, Limit: $LIMIT, Delta: $((PAGES - LIMIT))"

PAGES > LIMIT の場合は、ページ削減のヒューリスティック（下記の「ページ削減ヒューリスティック」を参照）に従うため、フェーズ 2 をキューに追加します。

匿名性スキャン（— skip-anonymity-scan が渡され、かつ投稿先がダブルブラインドでない場合に限りスキップします）：

スキャンでは 5 つの層を確認します（提案の 1 層スキャンでは不十分でした）。

1. 表面的な識別情報：著者の姓、所属、機関名、研究室のコードネーム、過去の資金提供タグ ID（grep -E "$(echo $AUTHOR_SURNAMES | tr ' ' '|')|$(echo $AFFILIATIONS | tr ' ' '|')"）。
2. 自己引用の表現："we showed in [...]" や "in our prior work [...]" のように、論文の著者自身を示す文がないか確認します。該当箇所は、三人称の "X et al. [year] shows..." に書き換える必要があります。Grep 正規表現：\b(we|our|my|I)\s+(showed|proved|demonstrated|prior work|earlier paper|previous paper)\b。
3. 謝辞と資金提供：acknowledgments.tex（または \acknowledgments{} ブロック）を確認し、特定機関への謝辞、助成金 ID、名前の挙がった共同研究者を探します。ダブルブラインド投稿ではコメントアウトします。
4. 他会場での査読応答への言及：脚注と本文を確認し、"this paper builds on rebuttal at venue X" や "addressing reviewer N's concern from venue X" のような表現を探します。匿名性を損ない、過去に不採択だったことを示すため、完全に削除する必要があります。
5. 内部コードネームとプロジェクトリンク：研究室を特定できる可能性のあるリポジトリ URL（github.com/<user>/<project>）、Slack チャンネル名、内部 Wiki リンク、データセットのコードネームを検索します。

5 つの層のいずれかで該当箇所が見つかった場合は、verdict: BLOCKED, reason_code: anonymity_scan_failed を含む RESUBMIT_REPORT.json を出力し、該当箇所を項目ごとにユーザーへ提示します。フェーズ 1 に進む前に、修正を承認するか、リスクを受け入れるかをユーザーが決定する必要があります。層 4～5 も層 1～3 と同様にブロック対象です。他会場での査読応答への言及や内部コードネームは、過去の投稿先での身元と研究室の身元の両方を示します。これらは異なる形でダブルブラインドに違反します。

残存する色付け／余白コメントのスキャン：

カメラレディ版の作成サイクルから残った \revise{...}、\fix{...}、\new{...}、\todo{...}、\todonotes{...}、\textcolor{red}{...} を検索して一覧表示します。残すか（投稿先によっては改訂箇所を示す囲みが許可されています）、削除するかはユーザーが決定します。

フェーズ 0.5 の出力：初期ページ数、匿名性スキャンの概要、残存する色付けの一覧、オーバーフル hbox の数を記載した BASELINE.md。

フェーズ 1：監査（編集ゼロ）

3 つの監査を並行して実行します。いずれも検出のみです。新しいディレクトリのソースファイルを読み込みますが、監査成果物以外は何も書き込みません。

スキル	目的	成果物
/proof-checker $NEW_VENUE_DIR/main.tex --restatement-check	以前の査読者が指摘した定理の欠落を特定し、主張と再述の間で場所をまたいだ一貫性を確認	PROOF_AUDIT.json + .md
/paper-claim-audit $NEW_VENUE_DIR/	数値の忠実性（本文中のすべての数値が、証明または結果ファイルで裏付けられていること）	PAPER_CLAIM_AUDIT.json + .md
/citation-audit $NEW_VENUE_DIR/ — soft-only	不適切な文脈での引用と誤った帰属を検出し、「引用文を控えめにする」ための対応に割り当てます（書誌情報の編集は行いません）	CITATION_AUDIT.json + .md

重要：3 つ目の監査は、必ず — soft-only を付けて実行してください。このフラグがない場合、citation-audit は書誌情報の変更を前提とする KEEP/FIX/REPLACE/REMOVE の判定を出力しますが、これは再投稿時の「書誌情報を編集しない」という制約に適合しません。--soft-only を指定すると、同じ指摘が、フェーズ 2 で使用できる、該当箇所ごとの文の書き換え案に変換されます。

以前の査読者の懸念事項を並行して個別化します：

For each file under $REVIEW_CORPUS:
    Read the reviewer report.
    Atomize into discrete concerns: severity (critical / major / minor),
      type (assumption / novelty / scope / rigor / experiment-coverage / framing),
      addressability (text-fixable / partial / unaddressable-under-constraints).
    Append to KNOWN_WEAKNESSES.md with stable IDs (W1, W2, ...).

KNOWN_WEAKNESSES.md のスキーマ：

- id: W1
  severity: major
  type: scope
  source: reviewer_2_venue_a
  concern: "Theorem 3 states a generic result but the proof only handles a specific regime."
  addressability: text-fixable
  recommended_fix: "Narrow Theorem 3's title to 'restricted regime'; add scope qualifier in abstract."
- id: W2
  severity: critical
  type: experiment-coverage
  source: reviewer_3_venue_a
  concern: "No comparison against [prior method X]."
  addressability: unaddressable-under-constraints
  recommended_fix: "Acknowledge in Limitations that this comparison is left for future work."

フェーズ 1 の出力：4 つの成果物（3 つの監査結果と KNOWN_WEAKNESSES.md）。すべてフェーズ 2 への入力となります。

フェーズ 2：自動改善ループによる対象を絞ったテキストの微修正

このフェーズが中核となります。/auto-paper-improvement-loop は、2 つの安全機構を設定して呼び出します。

1. — edit-whitelist <path> — 許可されるパスと禁止される操作を列挙する YAML ファイルです。フェーズ 0 で $NEW_VENUE_DIR/.aris/edit_whitelist.yaml に自動生成されます：

   allowed_paths:
     - "sec/*.tex"
     - "main.tex"
     - "appendix.tex"
   forbidden_paths:
     - "**/*.bib"
     - "**/*.sty"
     - "**/*.bst"
     - "../*Submission/**"           # all prior submission dirs
     - "../*Camera/**"
     - "templates/**"
   forbidden_operations:
     - new_cite                       # blocks \cite{...}, \citep{...}, \citet{...}, \citeauthor{...}
     - new_bibitem                    # blocks \bibitem{...} additions
     - new_theorem_env                # blocks \begin{theorem|lemma|proposition|corollary} additions
     - numerical_claim                # blocks adding numbers / percentages / metrics not present in original
   rationale: "Resubmit mode: text-only microedits, paper structure frozen by user constraint."
   

2. auto-loop の HUMAN_CHECKPOINT による各ラウンドの diff ゲート — /auto-paper-improvement-loop は --rounds、--reviewer-model、--resume-after-round-checkpoint フラグを受け付けません（これらは CLI にありません）。MAX_ROUNDS = 2 定数と REVIEWER_MODEL = gpt-6-astra のデフォルト値を使用し、ラウンドごとのゲートには既存の HUMAN_CHECKPOINT 機構を使います。そのため、再投稿パイプラインは HUMAN_CHECKPOINT = true を設定してループを1 回だけ実行し、各ラウンドで一時停止して、オーケストレーターが diff を確認できるようにします：

   # Snapshot the new venue dir BEFORE auto-loop runs (for diff baseline,
   # works whether or not paper-base-dir is a git repo)
   SNAPSHOT_DIR="$NEW_VENUE_DIR/.aris/snapshots/round-0"
   mkdir -p "$SNAPSHOT_DIR"
   rsync -a --exclude='.aris' --exclude='*.pdf' --exclude='*.aux' \
         "$NEW_VENUE_DIR/" "$SNAPSHOT_DIR/"
   
   # Single auto-loop invocation; rounds + checkpoints are loop-internal.
   # The whitelist file is the only resubmit-specific param.
   /auto-paper-improvement-loop "$NEW_VENUE_DIR/" \
       --edit-whitelist "$NEW_VENUE_DIR/.aris/edit_whitelist.yaml" \
       — assurance: submission \
       — effort: "$EFFORT" \
       — human checkpoint: true
   

   ループ内では、各ラウンドの終了時にあるチェックポイントで、再投稿オーケストレーターが次の内容を確認します：

   for ROUND in 1 2; do  # auto-loop's MAX_ROUNDS = 2
     # auto-loop pauses at HUMAN_CHECKPOINT after each round
     # diff this round vs prior snapshot (works without git)
     diff -ruN "$NEW_VENUE_DIR/.aris/snapshots/round-$((ROUND-1))" "$NEW_VENUE_DIR" \
         > "$NEW_VENUE_DIR/.aris/round-$ROUND-diff.txt"
   
     # Whitelist compliance check on the diff
     check_whitelist_compliance "$NEW_VENUE_DIR/.aris/round-$ROUND-diff.txt" \
                                  "$NEW_VENUE_DIR/.aris/edit_whitelist.yaml"
   
     # Selective regression audits (only fire if relevant files touched)
     if grep -qE 'theorem|lemma|proposition|corollary' "$NEW_VENUE_DIR/.aris/round-$ROUND-diff.txt"; then
         /proof-checker "$NEW_VENUE_DIR/main.tex" --restatement-check
     fi
     if grep -qE '[0-9]+(\.[0-9]+)?\s*(%|±|x|×)' "$NEW_VENUE_DIR/.aris/round-$ROUND-diff.txt"; then
         /paper-claim-audit "$NEW_VENUE_DIR/"
     fi
   
     # Snapshot this round for next-round diff
     rsync -a --exclude='.aris' --exclude='*.pdf' --exclude='*.aux' \
           "$NEW_VENUE_DIR/" "$NEW_VENUE_DIR/.aris/snapshots/round-$ROUND/"
   
     # Convergence check — see "Convergence Criteria" section below
     # If converged, signal HUMAN_CHECKPOINT to terminate early
   done
   

   git diff HEAD~1..HEAD ではなくスナップショットを rsync する方法を採用する理由：paper-base-dir が Git リポジトリであるとは限らず、Git リポジトリの場合でも、1 回の auto-loop ラウンド内の中間状態ごとにコミットが作成されるわけではありません。rsync によるスナップショットはリポジトリに依存しません。

3. 編集内容と懸念事項の対応付け — 提案される編集はすべて、（a）ID 付きの KNOWN_WEAKNESSES.md の項目、または（b）フェーズ 1 の監査指摘のいずれかに対応付ける必要があります。対応付けのない編集は、ループの査読プロンプトによって却下されます。これは、ループの査読プロンプトのテンプレートで強制されます（再投稿パイプラインの呼び出しでは、「すべての修正に W ID または監査指摘 ID を記載すること」というカスタム追加指示を渡します）。

ループの査読プロンプトへの入力（連結して使用）：

• フェーズ 1 の監査レポート 3 件（PROOF_AUDIT.md、PAPER_CLAIM_AUDIT.md、CITATION_AUDIT.md）
• KNOWN_WEAKNESSES.md
• カスタム追加指示：「再投稿を査読しています。ユーザーの制約はテキストのみの微修正です。提案する修正には必ず、KNOWN_WEAKNESSES の W ID または監査指摘 ID のいずれかを記載してください。対応付けのない修正は却下します。編集許可リストは必ず守ってください。」

フェーズ 2 の出力：ラウンドごとの差分、rejected_by_edit_whitelist リスト、および収束状況を記載した PAPER_IMPROVEMENT_LOG.md。

フェーズ 3：敵対的ゲート

/kill-argument $NEW_VENUE_DIR/

/kill-argument に --difficulty パラメーターはありません。以前の提案ドラフトでは、存在しないフラグが参照されていました。このスキルは常に Codex gpt-6-astra + ultra（ディープ監査ティア）を使用し、標準の 2 スレッド Attack-Adjudication プロトコルを実行します。assurance レベル（再提出では submission に設定）によって、FAIL が最終レポートをブロックするかどうかが決まります。

kill-argument の出力は残存リスクの報告であり、自動書き換えの指示ではありません。敵対的な査読者は、ユーザーが禁止したフレームワークの変更を要求する場合があります。裁定ステップは、指摘事項のうち、テキストの修正で対応できるものとユーザーへのエスカレーションが必要なものを振り分けるためにあります。

Read $NEW_VENUE_DIR/KILL_ARGUMENT.json
For each decomposed_point with verdict in {still_unresolved, partially_answered}:
    If severity_if_unresolved == critical:
        If recommended_fix is text-only AND maps to allowed paths:
            Append to "extra round queue"
        Else:
            Append to "user escalation queue" with note "outside text-only constraint"

追加ラウンドのキューが空でなく、かつユーザーの予算が許す場合：フェーズ 2 のラウンドをもう 1 回実行します。それ以外の場合：停止し、エスカレーションが必要な事項のキューを、エスカレーション内容を記したメモ（「制約のもとでは修正できない事項はこちらです。提出前に判断してください」）とともに提示します。

フェーズ 4：最終コンパイル + 差分レポート + Overleaf へのプッシュ

最終コンパイル：

/paper-compile $NEW_VENUE_DIR/main.tex --venue $TARGET_VENUE

/paper-compile はページ数の上限、フォント、参考文献の解決、図のはみ出しを確認し、COMPILE_REPORT.json を出力します。ページ数の上限を超えた場合は、ページ縮小ヒューリスティックを実行します（下記参照）。

最終的な paper-claim-audit のゼロコンテキストパス：

/paper-claim-audit $NEW_VENUE_DIR/

フェーズ 2 の微修正によって、結果に裏付けられていない数値的な主張が誤って追加されていないことを確認します。

インテグリティ・フォレンジックの再実行（デフォルトで ON。スキップするには — self_forensics: false）： 再提出では数値がずれることがまさに起こりやすく、テキストのみの確認は低コストです。すべての微修正後に $NEW_VENUE_DIR/ に対して /integrity-forensics を実行します（ラウンドの途中では実行しないでください。One Forbidden Loop を参照）。観測可能性のレベルは、存在するものに基づいて上流に判定させます（L1 と決めつけないでください。code/ と results/ がリンクされている場合は、より厳格なチェックが実行されます）。ゲートが BLOCK になった場合は、Overleaf へのプッシュ前に停止し、義務事項をそのまま提示します。再提出に固有のルールが 1 つあります。このパイプラインでは参考文献が凍結されるため、citation-replaced は許容される修正タイプではありません。引用に関する義務事項には、人間の承認を得て waive を指定するか、参考文献の凍結を緩和してもらうためにユーザーへエスカレーションする必要があります。

Overleaf へのプッシュの直前（および実行を再開した場合はその都度）、現在の $ARGUMENTS を再解析します。— self_forensics: false が含まれていない場合は、python3 "$GATE_HELPER" fresh --paper-dir "$NEW_VENUE_DIR/" --anti-ar-commit "$ANTI_AR_COMMIT" が終了コード 0 で終了することを必須とします。ゲートの確認後に微修正または再コンパイルが行われた場合は、状態が STALE と判定され、再実行が必要になります。以前の実行で指定したオプトアウトは引き継がれません。

差分レポート：

diff -u $PAPER_BASE_DIR/main.tex $NEW_VENUE_DIR/main.tex > $NEW_VENUE_DIR/.aris/DIFF_REPORT.md
for f in $PAPER_BASE_DIR/sec/*.tex; do
    base=$(basename $f)
    diff -u "$f" "$NEW_VENUE_DIR/sec/$base" >> $NEW_VENUE_DIR/.aris/DIFF_REPORT.md
done

これは、エクスポートの前にユーザーがざっと確認できるように渡します。

Overleaf へのプッシュ（— overleaf-target: <project-id> が渡された場合）：

すべて /overleaf-sync setup と /overleaf-sync push に委ねます。並行する別のプッシュ方法を作らないでください。/overleaf-sync setup はトークンをキーチェーン内に保持する処理（トークンがエージェントに渡ることはありません）に対応しており、/overleaf-sync push は共有 Overleaf の状態に書き込む前に確認ゲートを設けています。

/overleaf-sync setup $OVERLEAF_TARGET   # one-time, user confirms in their terminal
/overleaf-sync push                      # confirmation-gated push from $NEW_VENUE_DIR

overleaf-target が指定されていない場合は、Overleaf へのプッシュをスキップし、ユーザーに /overleaf-sync setup <id> を手動で実行するか、ディレクトリを ZIP 形式でエクスポートするよう伝えます。

ページ縮小ヒューリスティック

Phase 0.5 または Phase 4 でページ超過が検出された場合、この順序どおりのヒューリスティックを適用します。ページ制限を満たした時点で停止してください。各ステップは編集ホワイトリストによって完全に制約されています（定理の変更、参考文献の変更、フレームワークの変更は禁止です）。

1. 結論を圧縮する（通常、1～2 段落の「今後の課題」は、それぞれ 2～3 文に短縮できます）。削減量：0.3～0.7 ページ。
2. 概要／序論の曖昧な表現を簡潔にする（「本論文では、私たちは」→「私たちは」に変更。「よく知られているように」を削除し、要点から始めます）。削減量：0.2～0.4 ページ。
3. 重要度の低い図を付録に移動する（主張の中心となる議論に必要な情報を含まない図）。削減量：図 1 点あたり 0.5～1 ページ。
4. 証明の概略／詳述した補足説明を付録に移動する（本文には定理の記述と 1 行の証明の直観を残し、完全な証明は付録に移動します）。削減量：0.5～2 ページ。
5. 関連研究の説明を圧縮する（文献ごとの比較を比較表に置き換えます）。削減量：0.3～0.5 ページ。

このヒューリスティックで禁止されていること：実験を削除すること、本文から定理を削除すること、引用を削除すること（参考文献は凍結されています）。ステップ 5 の後も論文がページ制限を超えている場合は、RESUBmit_REPORT.json に verdict: BLOCKED, reason_code: page_shrink_failed_under_constraints を出力し、ユーザーに提示してください。制約を緩和するか、別の投稿先を選ぶかはユーザーが決定する必要があります。

収束基準（Phase 2 の停止条件）

Phase 2 のラウンドごとのループは、次の 3 つすべてを満たした時点で終了します。

1. そのラウンドの査読者出力に、新たな CRITICAL または MAJOR の、テキスト修正で対応可能な指摘がない（累積され重複排除された弱点リストと比較）。
2. ページ数の制限を満たしている — /paper-compile がページ数 ≤ 投稿先の制限を報告する。
3. すべての監査でブロッキングがない — /proof-checker、/paper-claim-audit、/citation-audit --soft-only のすべてが verdict ∈ {PASS, NOT_APPLICABLE} を返す（WARN/FAIL/BLOCKED/ERROR ではない）。

ROUNDS（デフォルトは 2）を終えても (1)/(2)/(3) のいずれかを満たしていない場合は、追加ラウンドを続けるかどうかをユーザーに確認するチェックポイントを出力します（自動延長はしません）。ユーザーが追加ラウンドを明示的に承認した場合は、デフォルトの上限 2 を超えて続行できます。

このパターンは /rebuttal Phase 7 の「新たな実質的問題がなくなった時点で終了する」方法を踏襲しています。同じ形式が再投稿にも適しています。

マスター RESUBMIT_REPORT.md 台帳

再投稿の実行ごとに、$NEW_VENUE_DIR/RESUBMIT_REPORT.{md,json} にマスターレポートを 1 つ作成し、以下を記録します。

• ソースディレクトリ、投稿先、使用した投稿先スタイルファイル、実行開始／終了時刻
• すべての成果物への参照：BASELINE.md、PROOF_AUDIT.json、PAPER_CLAIM_AUDIT.json、CITATION_AUDIT.json、KNOWN_WEAKNESSES.md、PAPER_IMPROVEMENT_LOG.md、KILL_ARGUMENT.json、COMPILE_REPORT.json、DIFF_REPORT.md
• フォレンジックの結果（オプトアウトしていない場合）：.aris/forensics/gate.json のゲート判定および、一覧にある OPEN の義務すべてを原文どおり記載 — fresh によって通過した WARN にも、人による判断待ちの指摘が残っています。それらをこの台帳に必ず記載し、成果物から黙って除外してはいけません。
• 消費したすべての入力ファイルの SHA256 ハッシュ（verify_paper_audits.sh との互換性のため）
• すべてのスレッド ID（Phase 1 の監査、Phase 2 の査読ラウンド、Phase 3 の kill-argument 用 2 スレッド）
• audit_skill: resubmit-pipeline、verdict ∈ {PASS, WARN, FAIL, NOT_APPLICABLE, BLOCKED, ERROR}、reason_code: <一覧にあるコードのいずれか>
• 判断ログ：ユーザーによるチェックポイントの承認／拒否／エスカレーションを、すべてタイムスタンプ付きで記録
• 「スキップした制約」：ユーザーによる上書き指定（例：— skip-anonymity-scan、— rounds 3）が渡された場合は、その理由とともに記録

スキーマは shared-references/assurance-contract.md に準拠しています（必須の監査すべてで共通のスキーマです）。これにより、resubmit-pipeline の実行をフォレンジックに再現できます。

失敗モード

このスキルは、7 種類の判定のいずれかを出力します（保証契約にある 6 種類に加え、チェックポイントで一時停止中の実行時状態 USER_DECISION）：

判定	reason_code	発生条件	対応
PASS	clean_resubmit	すべてのゲートに合格し、会場の制限内で最終 PDF がコンパイルされた	投稿する
WARN	partially_addressed_concerns	すべての MUST-FIX ゲートに合格したが、一部の KNOWN_WEAKNESSES に対処できない	ユーザーが未対処の項目を確認し、認識したうえで投稿する
FAIL	kill_argument_unresolved_critical	フェーズ 3 で、テキストのみの制約下では修正できない still_unresolved の重大な指摘が明らかになる	ユーザーが制約の緩和、フレームワークの変更へのエスカレーション、別の会場の選択を判断する
NOT_APPLICABLE	not_a_resubmit	--review-corpus に以前のレビューがない、またはディレクトリが新規ドラフトと思われる	ユーザーは代わりに /paper-writing を使用する
USER_DECISION	awaiting_phase_<N>_checkpoint	フェーズ 0.5 の匿名化修正チェックポイント、フェーズ 2 のラウンド終了時差分ゲート、フェーズ 3 のエスカレーションキュー、またはフェーズ 4 のページ数削減承認でスキルが一時停止した	ユーザーがチェックポイントのプロンプトに応答すると、マスターレジャーに記録されたユーザーの判断を反映してスキルが再開する
BLOCKED	phase_0_setup_blocked	新しい会場のディレクトリがすでに存在する、またはテンプレートファイルが見つからない	ユーザーが競合を解決して再実行する
BLOCKED	phase_0_5_compile_failed	新しい会場のスタイルで初回のコンパイルに失敗する	監査の実行前にユーザーがコンパイルエラーを修正する
BLOCKED	anonymity_scan_failed	フェーズ 0.5 で、ユーザーの承認が必要な表層的な識別子または自己引用のパターンが検出される	ユーザーが修正を承認するか、— skip-anonymity-scan を渡す（ダブルブラインドでない場合のみ）
BLOCKED	missing_review_corpus	--review-corpus が指定されておらず、検出もされない	ユーザーが以前のレビューを提供する
BLOCKED	page_shrink_failed_under_constraints	ページ数削減のヒューリスティックを使い切っても、論文がページ数制限を超えている	ユーザーが制約を緩和するか、別の会場を選ぶ
BLOCKED	out_of_scope_microedit	KNOWN_WEAKNESSES の分析で、新たな実験／新たな定理／フレームワークの変更を必要とする重大な懸念が 1 件以上判明する	ユーザーがエスカレーションするかどうかを判断する（再投稿パイプラインを中止し、完全な Workflow 1.5 + 3 を使用する）
ERROR	audit_failure / loop_failure	いずれかのサブスキルが ERROR を出力する	サブスキルのレポートを確認し、修正して再試行する

BLOCKED は回復可能です。ERROR は予期しないサブスキルの失敗を示します。投稿を妨げるのは FAIL と回復不能な BLOCKED のみです。

重要なルール

• 以前の投稿ディレクトリを上書きしないでください。 これは最も厳格な不変条件です。対象ディレクトリがすでに存在する場合、スキルはフェーズ 0 で中止します。
• Bib は凍結されています。 引用監査の指摘はすべて --soft-only を通じて処理され、bib の編集ではなくテキスト書き換えの提案として出力されます。
• 編集許可リストは必ず守ってください。 フェーズ 2 の各ラウンドでは許可リストを遵守します。却下事項は PAPER_IMPROVEMENT_LOG.md に記録され、ラウンドのチェックポイントでユーザーにラウンドごとの要約が提示されます。
• ラウンドごとの差分ゲートは必須です。 複数ラウンドにわたるずれは、再投稿で最もリスクの高い失敗モードです（ラウンド 1 でのわずかな表現の軟化と、ラウンド 2 での別のわずかな軟化が重なると、論旨の枠組みに意味のある変化が生じることがあります）。オーケストレーターは、次のラウンドに進む前に各ラウンドの差分を必ず確認しなければなりません。
• 収束基準は固定です。 デフォルトは 2 ラウンドです。3 ラウンド目には、ラウンド 2 のチェックポイントでユーザーの明示的な承認が必要です。ループが自動で延長されることはありません。
• 匿名性スキャンは 5 層です。 表層的な識別子、自己引用の表現、謝辞、反論間の参照、内部コードネームを対象とし、grep author surnames だけではありません。
• フェーズ 3（致命的な論拠）は、残存リスクの報告であり、自動書き換えではありません。 裁定者が示す still_unresolved の重大な指摘には、ラウンドをやみくもに追加するのではなく、ユーザーによるエスカレーションが必要な場合があります。
• Overleaf へのプッシュは /overleaf-sync に委ねます。 別の仕組みを作らないでください。
• マスターの RESUBMIT_REPORT.md 台帳は必須です（assurance: submission）。

出力契約

• <NEW_VENUE_DIR>/main.tex + sec/ + main.pdf — コンパイル済みの新しい投稿
• <NEW_VENUE_DIR>/RESUBMIT_REPORT.md + RESUBMIT_REPORT.json — マスター台帳（必須）
• <NEW_VENUE_DIR>/BASELINE.md — フェーズ 0.5 の健全性スナップショット
• <NEW_VENUE_DIR>/KNOWN_WEAKNESSES.md — 安定した ID を付与した、過去の査読者の懸念事項の個別項目
• <NEW_VENUE_DIR>/PROOF_AUDIT.json + .md — フェーズ 1 の証明監査
• <NEW_VENUE_DIR>/PAPER_CLAIM_AUDIT.json + .md — フェーズ 1 の論文主張監査
• <NEW_VENUE_DIR>/CITATION_AUDIT.json + .md — フェーズ 1 の引用監査（--soft-only モード）
• <NEW_VENUE_DIR>/PAPER_IMPROVEMENT_LOG.md — フェーズ 2 の各ラウンドの記録
• <NEW_VENUE_DIR>/KILL_ARGUMENT.json + .md — フェーズ 3 の敵対的ゲート
• <NEW_VENUE_DIR>/COMPILE_REPORT.json — フェーズ 4 のコンパイルおよびページ数制限の確認
• <NEW_VENUE_DIR>/DIFF_REPORT.md — ベース会場の本文との差分全体
• <NEW_VENUE_DIR>/.aris/edit_whitelist.yaml — フェーズ 0 で生成されるホワイトリスト
• <NEW_VENUE_DIR>/.aris/round-N-diff.txt — ゲート用の各ラウンドの差分
• <NEW_VENUE_DIR>/.aris/traces/<phase>/<date>_runNN/ — フェーズごとの Codex トレース

新しい会場ディレクトリが成果物です。以前の会場ディレクトリには変更を加えません。

レビューのトレース

すべてのフェーズにおける Codex MCP レビュアーの呼び出しは、shared-references/review-tracing.md に従って、<NEW_VENUE_DIR>/.aris/traces/<phase-name>/<date>_run<NN>/ にトレースを保存します。/kill-argument の両方のスレッドは個別に保持されます。マスターの RESUBMIT_REPORT.json の trace_path フィールドは、トレースの最上位ディレクトリを指します。

注記

• このスキルは、既存の複数のスキル（proof-checker、paper-claim-audit、citation-audit、auto-paper-improvement-loop、kill-argument、paper-compile、overleaf-sync）を統括し、最近追加された 2 つのパラメーター（/auto-paper-improvement-loop --edit-whitelist、/citation-audit --soft-only）も使用します。再投稿パイプラインに依存する前に、それらのパラメーターが現在の SKILL.md バージョンに対応していることを確認してください。
• 5 層の匿名性スキャンは、再投稿モードではダブルブラインドでない会場のカメラレディ原稿をダブルブラインドの会場に投稿することが多いため、/paper-compile の一般的な自己引用警告よりも意図的に詳細になっています。
• ページ数削減のヒューリスティックは、順序が決まっています（結論を圧縮 → 慎重な表現を絞り込む → 重要度の低い図を移動 → 証明の概略を移動 → 関連研究の文章を圧縮）。この順序は「リスクの低いものから高いものへ」となるよう調整されています。結論の圧縮は主に編集上の変更ですが、証明の概略の移動は読み進める流れを変えます。ページ数制限を満たした時点で、できるだけ早く終了してください。
• RESUBMIT_REPORT.json のスキーマは、shared-references/assurance-contract.md に厳密に準拠しています。これにより、再投稿の実行をフォレンジックに再現できます。注：verify_paper_audits.sh は現在、RESUBMIT_REPORT.json を MANDATORY_AUDITS リストに含めていません（検証ツールが確認するのは証明／論文主張／引用／kill-argument です）。再投稿で使用される必須監査ファイル 4 つ（これらは <NEW_VENUE_DIR>/ 内にあります）は、通常どおり検証ツールに認識されます。RESUBMIT_REPORT.json はオーケストレーター独自の台帳であり、現時点では検証ツールが必須とする成果物ではありません。ユーザーが再投稿を検証ツール経由の投稿ゲートにしたい場合は、別途フォローアップとして検証ツールに追加します。