light-typesetting

組版 · ステージ 11

承認済みの著者成果物を、再現可能な PDF 投稿バンドルにまとめます。作業は LaTeX をコンパイルするだけではありません。来歴を保持し、一貫性のあるエンジン／バックエンドを選択し、依存関係を事前チェックし、収束するまでコンパイルし、最初の根本原因を特定し、プロファイルに基づく投稿却下チェックを実行して、会場との照合に必要な正確な PDF／ページ情報を渡します。

実際のビルドを実行する前に typesetting-resource-map.md を読んでください。機械可読アーティファクトを書き込む、または使用する前に references/build_contract.md を読んでください。references/latex_errors.md は、ソース箇所が特定された最初のエラーが判明した後にのみ使用してください。templates/ の会場テンプレートは、現在の著者キットに合致する場合にのみ使用してください。バンドルされたコピーは出発点であり、現在の会場の正式な情報ではありません。

妥協できない境界

• 引用の delivery.json、references.bib、citekey-audit.json を使用します。delivery.status=DELIVERED、宣言済みの deliverable_hashes、引用に関する失敗がないこと、クレームレビューの未処理項目がないことを必須とします。宣言された引用成果物は、引用の納品ディレクトリ内の相対パスでなければならず、ビルドのスナップショットでは監査、失敗、クレームレビューのサイドカーを来歴の下に保持する必要があります。ステージングされたキーとコンパイルを確認します。DOI の存在、メタデータの競合、撤回、クレームとの関連性を再判定してはいけません。
• 図ファイル、宣言された寸法／DPI、ソースマニフェストを使用します。マニフェストは light.figure_delivery.v1 または light.figure_build.v1 であり、埋め込まれたファイルハッシュが宣言済みの出力ハッシュと一致することを必須とします。実証的な図の納品では、結果分析との関連付けを確認した証拠を必須とします。存在、埋め込み、フロート／レイアウト、コンパイルを確認します。視覚表現の誠実性、科学的内容、出版サイズ向けの生成をやり直してはいけません。
• 承認済みの論文執筆原稿を使用します。ページ数の制限を満たすために、クレーム、参考文献、実験、数値を捏造してはいけません。
• ページ数、匿名性、テンプレート、フォント、ページボックスの規則は、ユーザーの入力、または URL／日付の来歴を伴う最新の正式な指示からのみ取得します。全会場共通の制限を埋め込んではいけません。
• ツール／リソースの障害は UNAVAILABLE とします。原稿の ERROR と呼んだり、PASS としたり、納品を DELIVERED としたりしてはいけません。
• ステージ 11 の重要な範囲は組版に限定します。セキュリティ／ネットワーク／ツールが利用できないことを理由に、範囲を拡大してはいけません。ROUTES にキー 11 はありません。ステージ 11 内で失敗を修正し、逆向きの遷移を決して作ってはいけません。

ローカル LaTeX 環境の契約

実際に PDF をビルドする場合、成功を報告する前にローカルのツールチェーンを検出します。

• コア：Python 標準ライブラリと、TeX Live、MiKTeX、MacTeX、TinyTeX などの LaTeX ディストリビューション。
• コンパイルドライバー：latexmk を優先します。tectonic は、サポートされるバックエンドが原稿に合致する場合にのみ使用します。
• エンジン：ソース／プロファイルのトリガーに基づいて選択する pdflatex、xelatex、lualatex。
• 参考文献処理：従来の \bibliography{} には bibtex、biblatex には biber を使用します。ただし、明示的に別の指定がある場合を除きます。
• PDF チェック：ページボックス、ページ数、埋め込みフォントの情報が必要な場合は pdfinfo と pdffonts。

コンパイラー、エンジン、バックエンド、パッケージ、PDF 検査ツールが不足している場合は、状態を UNAVAILABLE とし、不足しているコンポーネントを説明して、インストール／設定するか、ツールチェーンを切り替えるかユーザーに尋ねます。システムツールを黙ってインストールしてはいけません。不足しているツールチェーンを原稿のエラーと呼んではいけません。また、実際に PDF が生成され、その PDF をチェックしていない限り、PDF を納品済みと報告してはいけません。

ワークフロー

1. 入力契約を固定する

templates/typesetting_input.json をコピーします。以下を記録します。

• 論文執筆のエントリーポイントと、必要なすべてのソースファイル
• 各図のソース、相対パスでの出力先、寸法／DPI、および納品／ビルドマニフェスト
• 引用の delivery.json と、ステージングする BibTeX ファイル名。参照先ファイルとのハッシュを一致させるため、引用を編集した後に納品物を再生成する必要があります
• light.typesetting_venue_profile.v1。ソースの種類、該当する場合は URL、確認日、ルールを含めます

会場のルールが不明な場合は、null、0、または未設定のままにします。他の会場や前年のテンプレートから推測しないでください。

2. コンパイル前の事前チェック

python scripts/build_submission.py --spec typesetting-input.json --preflight-only

来歴を保持した source/ スナップショットを必須とします。入力の不足、\input／\include、画像、ラベル／参照、引用納品のスキーマ／ステータス、納品物のハッシュ、納品された citekey の監査、空の引用失敗／レビュー引き継ぎ、ステージング済みの有効な citekey、図のマニフェスト出力ハッシュ、実証図のエビデンス紐付け、ドキュメントクラス、必須パッケージ、ローカルでのパッケージ利用可否を確認します。反復ごとに新しい空の出力ディレクトリを使用してください。ビルダーは古い実行ディレクトリを拒否します。

分類：

エビデンス	状態
原稿／図／BibTeX／キー／ラベルの不足、上流ハッシュの古さ、未解決の引用レビュー、未確認の実証図エビデンス、またはバックエンドの競合	ERROR
必須のエンジン／バックエンド／パッケージ／ツールがない、または実行できない	UNAVAILABLE
ブロッカーなし	PASS

3. エンジンと参考文献バックエンドを選択する

fontspec、xeCJK、ctex、unicode-math、または polyglossia がある場合は XeLaTeX を検出します。Lua を起動する要素がある場合は LuaLaTeX、それ以外は pdfLaTeX を検出します。従来の \bibliography は BibTeX、biblatex は、backend= オプションに別の指定がない限り、Biber として検出します。

プロファイルのエンジンと、XeLaTeX／LuaLaTeX を必須とするソース上のトリガーが競合する場合、またはプロファイルのバックエンドとソースが異なる場合は、根本原因を示す ERROR で停止します。BibTeX と Biber を混在させないでください。プロファイルで、pdfLaTeX 互換のソースに XeLaTeX を意図的に選択することはできます。絶対パスでの実行ファイルの場所、バージョン確認、作業ディレクトリ、コマンド配列、シェルでの表現を記録します。

4. コンパイルして収束状態を分類する

python scripts/build_submission.py --spec typesetting-input.json

ローカルの latexmk を優先し、対応するバックエンドが一致する場合に限り Tectonic を使用します。相対パスの入力を解決できるよう、スナップショットの原稿ディレクトリからコンパイルします。latexmk のルール／実行記録、ログ／PDF の SHA-256、ページ数を保存します。

コンパイル状態は、次の4つに厳密に分類します。

• PASS：終了コードがゼロで、PDF が存在し、未解決の cite／ref や再実行のシグナルが残っていない。
• ERROR：原稿／バックエンド／入力が原因でビルドが失敗した、または PDF がない。
• UNAVAILABLE：必須のローカルツール／リソースを起動または完了できなかった。
• UNRESOLVED：PDF は存在するが、引用／参照の収束が完了していない。

ERROR と UNRESOLVED は終了コード 1 で終了します。UNAVAILABLE はコマンドゲートの境界では終了コード 0 ですが、未納品の状態です。

5. 最初の根本原因から診断する

compile-report.json を読み、その後、ログ全体を確認します。二次的な警告より先に、最初の file.tex:line、コンパイラメッセージ、平易な言葉での原因を報告します。最も早いエラーを最初に修正し、最小限の修正を1つ行った後に再コンパイルします。文章を書き換えたり、データを削除したり、架空の参考文献を追加したりして、問題を黙って解消しないでください。

修正ループで同じシグネチャが繰り返された場合は、推測による編集を行わず、停止して UNRESOLVED と報告します。

6. プロファイルに基づくデスク却下ゲートを実行する

python scripts/desk_reject_gate.py `
  --tex typesetting-build/source/paper.tex `
  --pdf typesetting-build/compile/paper.pdf `
  --bib typesetting-build/source/references.bib `
  --log typesetting-build/compile/paper.log `
  --profile venue-profile.json `
  --report desk-reject-findings.json

客観的なプロファイル違反は、重大な問題となる場合があります。ページ数上限の超過、著者名または PDF の Author メタデータが匿名化されていないこと、ドキュメントクラスの誤り、必須パッケージの不足、ページサイズの誤り、フォントが埋め込まれていないことなどです。TODO、謝辞、自己参照、リンク、ボックスに関する警告は、現在有効な公式プロファイルで客観的なハードルールとして定められていない限り、警告のままにします。

静的チェックでは、意味的な匿名性を証明したり、会場の曖昧な文言を解釈したり、最終的な見た目の品質を評価したりすることはできません。投稿前に、レンダリングされた PDF と最新の公式アナライザー／投稿規定を確認してください。

7. 標準アーティファクトを出力する

以下を必須とします。

• build-manifest.json；
• compile-report.json とコンパイルログ；
• compliance-report.json と desk-reject の指摘事項；
• 生成された場合は PDF；
• 失敗または実行できない場合は failure.json；
• venue-handoff.json；
• delivery.json。

compile=PASS、compliance=PASS、かつ compliance の重大な指摘がゼロの場合に限り、 DELIVERED にできます。 失敗したレポートは保持してください。失敗から修正に至った経緯の証拠になります。

8. 証拠をひとまとめにせず、準備状況を判定する

ローカルの準備状況パケットを作成し、次を実行します。

python scripts/submission_readiness.py `
  --input templates/submission-readiness.example.json --as-of YYYY-MM-DD `
  --out submission-readiness-report.json

公開テンプレートは意図的に UNKNOWN となっており、終了コード 1 で終了する必要があります。状態の連鎖は INVENTORIED → SOURCE_BUILDABLE → TECHNICALLY_CHECKED → VISUALLY_CHECKED → METADATA_MATCHED → VENUE_READY → USER_APPROVED です。コンパイルの終了コードが 0 でも、未解決の参照、コンパイル時の page_count、 同一 PDF への紐付け、ページごとのレンダリングとレビュー、メタデータの匿名性、最新の公式プロファイル、 正確な論文種別との紐付けを省略することはできません。visual.source_pdf_sha256、 metadata.source_pdf_sha256、compliance.source_pdf_sha256、および user_approval.pdf_sha256 がある場合は、その値が compile.pdf_sha256 と一致する必要があります。 visual.page_count は compile.page_count と一致する必要があります。各ページの visual 行には render_sha256、render_tool、review_status=PASS、reviewer／reviewer_id、 および未来の日付ではない reviewed_at が必要です。compliance 行には、プロファイルと同じ venue および article_type も記載する必要があります。Artifact の Available／Functional／Reusable／Reproduced／Replicated はそれぞれ別個の状態として扱います。スクリプトは証拠を記録しますが、ACM や会場のバッジを付与することはありません。

9. ステージ 11 を実行して引き継ぐ

compile コマンドゲートと desk_reject 指摘チェックポイントを実行します。

python ../light-orchestrator/scripts/run_checkpoint.py `
  --file .light/passport.yaml --stage 11 `
  --gate "compile=python scripts/compile_driver.py --compile paper.tex --outdir build --json-out compile-report.json --quiet" `
  --findings desk-reject-findings.json --ts <ISO8601> --write

重大な失敗があった場合は、ステージ 11 を修正し、delivered になるまで再実行します。会場に引き継ぐ際は、 venue-handoff.json に記載された PDF のパス／ハッシュ、ページ数、ページサイズ、プロファイルのソース、 および compliance レポートを照合します。ROUTES[11] を主張したり、逆方向の遷移を作成したりしないでください。 --quiet を使うと Windows のコマンドゲートでロケールに依存しなくなります。完全な診断記録は compile-report.json に保持されます。

実行すること／確認すること／決してしないこと

実行すること：

• 変更前に、宣言された入力のスナップショットを取得します。
• 事前チェック、コンパイル、レンダリング済み PDF のレビュー、desk-reject ゲート、チェックポイントを実行します。
• 正確なコマンド、ハッシュ、ステータス、失敗時のアーティファクトを保持します。

確認すること：

• 会場の規則またはソースが不足している、あるいは曖昧な場合は確認します。
• 科学的内容の削除、参考文献システムの変更、またはユーザーの公式テンプレートの置き換えを行う前に確認します。
• 意味上の匿名性や、判断が難しいレイアウトについて、人による確認を求めます。

決してしないこと：

• 実行していないコンパイル、収束、ページ数、メタデータチェックを実行したと主張しないでください。
• ツールの不足を原稿の問題や、納品の成功として扱わないでください。
• 引用の真正性確認、図の科学的な品質確認、論文の執筆をやり直さないでください。
• 中核となる手順で、有料の Overleaf、秘密鍵、ブラウザープラグイン、大量の npm ツールに依存しないでください。

納品時のセルフチェック

• 入力元の来歴と SHA-256 の各行には、原稿、図、図のマニフェスト、引用の納品／BibTeX／監査／失敗／レビュー成果物、およびプロファイルが含まれています。
• 引用の納品ステータスは DELIVERED で、納品物のハッシュはステージング済みファイルと一致し、引用の失敗とクレームレビューの未処理項目はありません。
• 図のソースマニフェストには埋め込み出力ハッシュが宣言され、実証的な図には、結果分析の根拠を結び付ける確認済みの証拠が含まれています。
• エンジン／バックエンドの選択は、ソースおよびプロファイルと一致しています。
• コンパイルステータスは正規の4つの状態のいずれかで、PASS にはハッシュ付き PDF があります。
• コンパイラーが原因箇所を示す場合、根本原因にはファイル名と行番号が記載され、警告は別に記載されています。
• 引用キー、図、ラベル、相互参照に不整合はありません。
• デスクリジェクトに関わる重大な問題がゼロでない場合、納品済みとしてマークされていません。
• すべてのビジュアル／メタデータ／コンプライアンス／ユーザー承認の各行はコンパイル済み PDF のハッシュに紐付いています。すべての PDF ページには、レンダリングハッシュ、レンダリングツール、レビュー担当者／日付、および PASS のレビュー行があります。プロファイルは最新で、正確な記事タイプに紐付いています。
• 著者チームによる再現性を、独立した再現／追試と誤って分類していません。
• 投稿先との適合性判定には、実際の PDF／ページ／コンプライアンス情報が使用されています。
• ステージ 11 では compile と desk_reject のみを使用し、ルートや逆向きエッジは追加されていません。