sync-submission

投稿パッケージの同期

正規原稿と各ジャーナル固有の投稿パッケージが乖離しないようにします。 submission/{journal}/ は派生出力として扱い、最新、古い、または凍結済みのいずれかを記録します。

入力

1. project.yaml を含むプロジェクトルート、または正規原稿の直接パス。
2. ジャーナルの短縮名（例：chest、ryai、academic_radiology）。
3. 任意のモード：
   • audit：既存の投稿パッケージを正規ソースと比較します。
   • build：正規ソースと、任意で宣言された最終成果物をバイト単位で保持してコピーし、メタデータを書き込みます。
   • freeze：利用可能なチェックコンテキストとともに、選択したバイトスナップショットを凍結します（投稿の承認を意味するものではありません）。

決定論的スクリプト

python "${CLAUDE_SKILL_DIR}/scripts/sync_submission.py" audit --project-root . --journal chest
python "${CLAUDE_SKILL_DIR}/scripts/sync_submission.py" build --project-root . --journal chest
python "${CLAUDE_SKILL_DIR}/scripts/sync_submission.py" freeze --project-root . --journal chest --status submitted

二重盲検ジャーナルの場合は、すべてのアップロード成果物から著者識別情報を網羅的に確認します。

python "${CLAUDE_SKILL_DIR}/scripts/blind_sweep.py" \
  --registry _shared/authors/author_registry.yaml \
  --files submission/{journal}/supplementary/*.md submission/{journal}/cover_letter.md \
  --backup-dir .cache/blind_sweep_backup

レジストリはプロジェクト内の YAML マッピングで、著者識別情報（氏名、原語表記、ピリオドの有無を問わないイニシャル、メールアドレス、ORCID）を役割ラベル（例：「Reviewer 1」）に対応付けます。スキーマは scripts/author_registry_example.yaml にあります。著者の身元が記載されているため、値を入力したレジストリを公開リポジトリにコミットしないでください。原稿の隣に保管してください。

出力仕様

成果物	パス	目的
投稿メタデータ	submission/{journal}/.journal_meta.json	ソースハッシュ、ステータス、正規パス
同期監査	qc/submission_sync_{journal}.json	オーケストレーターが使用する乖離結果
マニフェストの更新	artifact_manifest.json	投稿パッケージのレジストリ
プリフライトゲート	qc/preflight_gate_report.json	失敗時に停止する集約マニフェスト（下記「プリフライトゲート」を参照）
補足資料の構造	qc/supplement_structure.json	ゲート 14：索引とファイルの 1 対 1 対応、小節の欠落、コールアウトの網羅性

バンドル全体を作成するには、まず既存のレンダラーを実行し、その後 build --bundle-spec bundle.json を実行します。 宣言により、レンダリング入力のハッシュを固定し、再利用権の記録を付けた最終版の Word／PDF、補足資料、カバーレター、表／図、通知ファイルが追加されます。コピーではファイルのバイト列が保持されます。内容と視覚的な忠実性は、別途レビューされるまで not_assessed のままです。ビルドは、編集済みまたは凍結済みの出力と、破壊的なパスの衝突を拒否します。スキーマ、実行可能な合成例、記録される各チェックの限界については、バンドルのワークフローを参照してください。

事前チェックゲート（単一コマンド — 凍結前の最終ステップ）

freeze／提出の直前に、一度だけ実行します。

python "${CLAUDE_SKILL_DIR}/scripts/preflight_gate.py" --project-root . --journal chest
# add --strict to also halt on the heuristic/conditional (P1) checks
# add --online to make fabricated / author-mismatched references halt (PubMed/CrossRef)
# add --double-blind to make the asset-anonymization scan halt

チェックごとのスクリプトを呼び出し（再実装はしません）、qc/preflight_gate_report.json を書き出して、問題なしの場合は 0、停止が必要な場合（ブロッカーが1件以上）は 1、ゲート設定エラーの場合は 2 で終了します （例：--require で必須にしたチェックを実行できなかった場合）。終了コードがゼロ以外の場合、凍結はブロックされます。

• P0 — デフォルトで停止します（明確で決定論的なエラー）：未処理のプレースホルダー／マーカー（check_placeholders.py）、未定義の [@key] 引用（check_citation_keys.py）、重複した参考文献（verify_refs.py、オフラインで決定論的に判定）、正規版と提出版のハッシュ不一致（sync_submission.py audit）、および査読者向けファイルに含まれる内部監査ダンプ（check_checklist_dump_leak.py）。
• P1 — 実行して warn を報告し、--strict または --require ID の場合のみ停止します： check_xref、detect_copy_divergence、scope_drift_check、cover_letter_drift_check、cross_document_n_check、check_cross_artifact_stale。check_asset_anonymization は --double-blind を指定しない限り P1 です。
• 入力が存在しないチェック（レンダリング済みの docx、カバーレター、コピー、ジャーナルがない場合）は skipped として記録され、ブロッカーにはなりません。実行されて失敗したチェック（トレースバック、想定外の終了コード、または入力が存在するにもかかわらず「入力なし」で終了した場合。例：不正な .journal_meta.json、デコードできないカバーレター、存在しない --copy の指定、N 件のスキャンで読み取れないファイル）は error として記録されます。この場合、submission_safe は false となり、--strict の有無にかかわらずゲートは 2 で終了します。

このレポートを承認と解釈しないでください。従来の submission_safe フィールドが意味するのは、「設定されたブロッカー／エラーがない」ことだけです。readiness は not_assessed のままであり、任意のバンドルハッシュの紐付けが示すのは実行時に存在したパッケージであって、ファイルごとの目視確認やすべての外部チェック入力ではありません。事前チェック後にもう一度 audit を実行し、現在の証拠、古い証拠、または紐付けのない証拠を明らかにしてください。凍結ではバイト単位のスナップショットと利用可能なチェックコンテキストを記録しますが、事前チェックを実行したり、原文への忠実性や再利用の許可を承認したりすることはありません。

監査ダンプの漏えいチェック（P0）。 /check-reporting または /self-review のレポートは、内部作業用の監査です。自動修正の注釈、生の JSON ブロック（compliance_pct、fixable_by_ai、check_reporting_version）、パイプラインログのパス、「Action Items」が含まれます。これはジャーナルが求める正式な報告チェックリストではなく、ファイル名が正式なものに見えても、決して査読者に渡してはいけません（例：STROBE_checklist_v4.pdf を後のパッケージに再利用する場合）。scripts/check_checklist_dump_leak.py --dir submission/ は、パッケージ内のすべての .md／.docx／.pdf をスキャンし、これらのトークンを検出します。該当があれば、P0 の leak になります。事前チェックではジャーナルのアセットディレクトリを対象に実行します。凍結前に submission_safe: true であることを確認してください。qc/checklist_dump_leak.json に書き出します。

開示・利用可能性チェック（単独実行）。 医学系 AI の主要ジャーナルでは、査読前に、4つのトークン（バージョン＋アクセス方法＋日付／期間＋責任者。ツール名はチェックの起動条件にすぎません）を含む AI 利用の開示と、データ／コードの利用可能性に関する記述が求められます。python3 ${CLAUDE_SKILL_DIR}/scripts/check_disclosure_availability.py --manuscript <file> --journal <stem> [--ai-study] [--require data_availability ...] [--strict] を実行してください（references/journal_availability_policy.json を読み込みます）。必須の記述がない場合、または AI 開示があるもののトークンが不足している／プレースホルダーを含む場合はブロックします。ジャーナルがリポジトリを求めている場合の「合理的な要請に応じて提供」は P1 の警告です。qc/disclosure_availability_report.json に書き出します。

ワークフロー

1. project.yaml または明示的な入力から、正規の原稿を特定します。
2. 指定されたモードでスクリプトを実行します。
3. audit が DRIFT を報告した場合、ユーザーが正規の原稿にパッチを適用するか、その差分をジャーナルのみとして記録するまで、リターゲットや凍結を行わないでください。提出物の編集内容を SSOT に黙ってマージしたり、ジャーナルのみの差分を隠したりしてはなりません。ドリフトまたは明示的な例外として記録してください。
4. build が成功した場合は、最終提出の前に /verify-refs を実行します。
5. ソースハッシュが一致する場合にのみパッケージを最新とみなし、.journal_meta.json を書き込む freeze を通じてのみ提出済みとします。

品質ゲート

• Gate 0（事前確認、凍結前の最終ステップ）：上記の「事前確認ゲート」に従って scripts/preflight_gate.py を実行します。終了コードが 0 以外の場合、凍結はできません。このスクリプトは Gate 1～3、5b、5c、5d、8、9、11、11b、Phase 3b/3c のチェック、およびプレースホルダーと引用キーのチェックを実行します。各ゲートは個別にも実行できます。

• Gate 1：正本の原稿がない場合、凍結をブロックします。

• Gate 2：前回の投稿に未解決の差異がある場合、投稿先の変更をブロックします。

• Gate 3：パッケージを投稿可能とマークする前に、/verify-refs による監査を必須にします。事前確認で行うオフラインの参考文献チェックは、重複とページネーションのプレースホルダーのみを対象とします。PubMed/CrossRef に対してオンラインで実行する /verify-refs --strict が、捏造と著者名を確認するための正式なチェックです。

• Gate 4（docx の再帰的な走査）：docx の古い文字列を監査する際は、段落、表、ネストされた表のセルをすべて再帰的に走査する必要があります。document.paragraphs は表のセルをスキップし、document.tables は再帰的に走査しません。また、paragraph.runs では <w:hyperlink> 内の run が見えません。図、キャプション、報告用チェックリストは、1×1 の表やネストされた表に配置されていることがよくあります。ハイパーリンクやフィールド付近の run レベルの編集では、.runs ではなく段落の XML を確認してください。隠れたインライン要素が空の () のように見え、修正によって実際の不具合になることがあります。

• Gate 5（投稿ポータルの自由記述フィールド）：カバーレター、データ利用可能性、謝辞、抄録、著者貢献は、ポータルに直接入力されることが多く、このスキルが監査する docx の外にあります。凍結前に、ポータルの最終確認ページを原稿本文と 1 対 1 で照合し、各フィールドを個別の差異チェック対象として扱ってください。

• Gate 5c（ポータルフィールドに残る Markdown）：ポータルにそのまま貼り付ける .txt フィールド（abstract.txt、keywords.txt、…）は、Markdown から切り出されますが、Markdown 記法は除去されません。そのため、末尾の ---、**bold**、上付き文字の cm^2^ がそのまま公開されます。事前確認では scripts/check_portal_field_residue.py --dir portal_fields/（P1、--strict への昇格が可能）を実行します。スキャン対象は .txt のみです（.md は Markdown を含むことが前提です）。Minor の char_expansion 警告は ≥/≤ を検出します。ScholarOne ではこれらが「{greater than or equal to}」（5 語）に展開され、語数が増えるため、事前に >=/<= に置き換えてください（対象は ≥/≤ のみです。× と en ダッシュは問題なく貼り付けられます）。

• Gate 5d（図のポータル対応状況）：ファイル上で判定できる理由により、アップロードボタンで図のアップロードが拒否されることがあります。たとえば、ファイルサイズ（JACC: Asia では図の上限は 25 MB）や拡張子（SNAPP が受け付けるのは .tiff/.jpeg/.eps のみで、.png は拒否されます）です。事前確認では scripts/figure_portal_readiness_check.py --figures-dir <dir>（P1）を submission/<journal>/figures（または ./figures）に対して実行し、FIGURE_OVERSIZE と、ポータルが受け付ける形式を指定した場合（例：--figure-accept tiff --figure-accept jpeg --figure-accept eps）は FIGURE_FORMAT_REJECTED を出力します。/make-figures export_portal_tiff.py で再生成して修正してください（LZW + RGBA→RGB flatten）。図のディレクトリがない場合はスキップされ、エラーにはなりません。

• Gate 6（二重盲検ジャーナル）：原稿の匿名化が適切でも、ポータル上の匿名化が適切とは限りません。凍結前に、ポータルから査読用の匿名化 PDF をエクスポートしてください（これが正式な差異検出手段です）。そのうえで、アップロード対象全体から著者を特定できる情報を grep で検索します。対象には、原稿、補足資料（特に方法のログ、合意度の指標、修正ログ）、カバーレター（別途アップロードしたファイルは、「Don't show in review PDF」を切り替えない限り査読者に表示されます）、登録・承認の PDF（PROSPERO、ClinicalTrials.gov、IRB）、署名を貼り付けた場合のポータルの Letter フィールドのテキスト、改訂時の査読者への回答書が含まれます。ピリオドあり・なしのイニシャル（G.S. と GS）、ローマ字表記と各言語の文字表記による氏名、所属機関名、ORCID ID、投稿時のメールドメインを確認してください。

• Gate 7（テキストのみの docx の再構築）：回答書、カバー、補足資料などのテキストのみの docx に pandoc --reference-doc=manuscript.docx を使用しないでください。参照 docx に埋め込まれたメディア（図ファイル）が新しい docx にも引き継がれ、ファイルサイズが 50～100 倍に膨らむためです。pandoc input.md -o output.docx をそのまま使用してください。このようなファイルが 100 KB を超えた場合は、unzip -l output.docx | grep word/media/ の結果が空であることを確認してください。

• Gate 5b（カバーレターの自由記述における差異）：凍結前に Phase 4 を参照してください。

• Gate 8（文書間での N の整合性）：凍結前に Phase 5 を参照してください。

• Gate 9（原稿内の対象範囲の差異）：Phase 6 を参照してください。

• Gate 10（v_(N+1) docx の再生成）：凍結済みの前バージョンから作成する場合は、Phase 7 を参照してください。

• Gate 11（複数コピー間の不一致）：凍結または回覧の前に Phase 8 を参照してください。

• Gate 11b（再構成・見出し変更後の残存箇所のスキャン）：主張の分類を再構成する改訂（例：「地域別ベンチマーク」から「全体の統合結果」への変更）または見出しの数値を変更する改訂の後には、変更を「全体に」適用したと回答書に記載されていても、変更前の用語や値が未編集の段落、凡例、補足資料、回答書に残っていることがあります。再構成時の差分から、廃止する用語と置き換え後の値をクロスアーティファクトゲートに渡してください。本文とすべての補助ファイルをスキャンします。

  python3 "${CLAUDE_SKILL_DIR}/scripts/check_cross_artifact_stale.py" \
      --manuscript manuscript.md --aux supplement/ --aux figures/legends.md --aux revision/response_to_reviewers.md \
      --retired-term "location-stratified benchmark" --old-value 1.72
  

  retired_framing_survivor / stale_old_value の検出結果は、P1 に該当する古い主張の残存箇所です。--aux にはファイルまたはフォルダーを指定できます。.docx のサイドカーファイルは読み込まれ、図のスクリプト（.py/.R）は古いリテラルのみを対象に走査されます。--aux に読み取り可能なファイルが含まれていない場合は、合格ではなく終了コード 2 で終了します。読み取れない文書（.pdf、.pptx、…）は未チェックとして一覧表示されます。文言や数値を変更する場合は、SSOT ツリー全体で旧文字列も grep してください。対象を一部に限定してはいけません。また、部分一致による見落としにも注意してください。expertise-dependent patterns の完全一致検索では問題がなくても、expertise-dependent evaluation patterns は古い表現のまま残ります。

• Gate 12（投稿先ジャーナルのメタデータの差異）：build / 投稿先変更時には、原稿が投稿先としているジャーナル（project.yaml の target と、原稿のヘッダーまたはフッターにある「X へ投稿」の文字列）と、パッケージの作成先ジャーナルを比較し、投稿先が指定する構造上のメタデータ（抄録の見出し構成（4 見出しか 5 見出しか）、本文の語数制限、引用スタイル（Vancouver / AMA）、必須要素（Highlights / Central Illustration / Key Points））を確認してください。不一致（連鎖的な投稿先変更後もヘッダーに以前のジャーナル名が残っている場合や、見出しが 4 つの抄録を見出しが 5 つ必要な投稿先に提出する場合など）は、投稿先に合わせた構成変更のトリガーです。v_(N+1) へ分岐し、すべてのサイドカーファイル（カバーレター、タイトルページ、ICMJE COI リスト）を同期してください。黙ってビルドを進めてはいけません。

  # header target vs project.yaml target
  TGT=$(python3 -c "import yaml;print(yaml.safe_load(open('project.yaml')).get('target',''))" 2>/dev/null)
  grep -niE 'for submission to|submitted to|prepared for' manuscript/manuscript.md   # compare against "$TGT"
  

• Gate 13（本文の語数とジャーナルの上限 — 改訂による膨張の落とし穴）：査読者からの重大な指摘に対応すると語数が増えるため、改訂後の本文が気付かないうちにジャーナルの上限を超えてしまいます。最終確定前と、/revise を実行するたびに、対象ジャーナルのプロファイルで指定された本文上限に対して scripts/check_wordcount_cap.py を実行してください。WORDCOUNT_OVER_CAP は P0 です（方法や感度分析の詳細を補足資料に移してください）。WORDCOUNT_NEAR_CAP（上限の 0.95 倍超）は、次の改訂で上限を超えるおそれがあることを警告します。基準となる数値はレンダリング後の語数です（citeproc が [@key] を「(Author Year)」に展開します）。そのため、--rendered-words N を指定して、ビルド済み DOCX の語数を使うのが望ましいです。指定しない場合、スクリプトは Markdown の本文とインライン引用の展開から語数を推定します。

  python3 "${CLAUDE_SKILL_DIR}/scripts/check_wordcount_cap.py" \
    --manuscript manuscript/manuscript.md \
    --journal-profile "${CLAUDE_SKILL_DIR}/../find-journal/references/journal_profiles/<Journal>.md" \
    --article-type "Original Article" --out qc/wordcount_cap.json --strict
  # or, deterministic: --limit <the journal's body cap>   (and --rendered-words N from the built DOCX when available)
  

  プロファイルの上限は、構造化されたフィールドからのみ読み取られます。具体的には、論文種別の表（| Type | Body Word Limit | Abstract | ... |）の本文語数上限の列、または、論文種別を含む表がない場合は、その種別で始まるリスト項目（- Original Article (4,000 words, ...)）です。論文種別に言及しているだけの文章（多くの場合、要旨の上限）は読み取りません。数値が 1 つに定まらない場合、またはセルに複数の数値が含まれる場合、スクリプトは終了コード 2 で終了し、--limit を指定するよう求めます。

• Gate 14（補足資料の構成 — 番号のロック）：S{N}_*.md セクションと索引から成る補足資料を _combined.md に手作業で連結すると、改訂を重ねるうちに内容が食い違います。索引にファイルがない行、索引に記載されていないファイル、同じ S{N} を名乗る 2 つのファイル、挿入後のサブセクション番号の欠落（S6.3 の次が S6.5）などが生じ、「Supplementary Table S9」が誤った内容を開いてしまいます。最終確定前に scripts/assemble_supplement.py を実行して、索引とファイルの 1 対 1 対応を検証し、_combined.md を索引順に再構築してください（手作業で維持するのではなく、再現可能な方法で行います）。さらに --manuscript を指定すると、本文中にあるのに対応するセクションファイルがない参照（CALLOUT_WITHOUT_SECTION）と、本文から参照されていないセクションファイル（SECTION_UNCITED）が報告されます。4 種類の構造上の問題は --strict で P0 となり、網羅性に関する指摘は参考情報です。

  python3 "${CLAUDE_SKILL_DIR}/scripts/assemble_supplement.py" \
    --dir submission/{journal}/supplementary --index 00_index.md \
    --manuscript manuscript/manuscript.md \
    --out submission/{journal}/supplementary/_combined.md \
    --json qc/supplement_structure.json --strict
  

フェーズ 3b — 原稿を置き換えるポータルのフィールド

一部のポータルでは、公開されるのは原稿ではなく入力欄の内容です。SNAPP では、著者の貢献、利益相反、データの利用可能性、謝辞の各欄に、「これは原稿内に記載されたあらゆる声明に置き換わり、公開されるのはこの内容です」と明記されています。原稿にしかない宣言は公開記録から消えてしまい、警告も出ません。危うくそうなりかけた例が 2 つあります。

• 共同筆頭著者。 タイトルページの脚注にある †。貢献が同等であることを示すチェックボックスはありません — 著者の貢献欄に「X と Y は本研究に等しく貢献した」と入力しない限り、公開論文には共同筆頭著者が記載されません。
• 「資金提供者は研究デザインに関与していない……」 構造化された 研究資金 フィールドでは、資金提供者と助成金 ID を入力しますが、役割に関する免責事項を記載する欄はありません。そのため、謝辞欄に AI の使用に関する注記だけを貼り付けると、免責事項が抜け落ちます。

各欄を手作業で作成しないでください。 原稿から生成して、次の点を確認してください。

SS="${CLAUDE_SKILL_DIR}/scripts"
# scaffold every replacing field straight from the manuscript (lifts the equal-contribution
# sentence in from the title page, which is the one place --emit cannot copy it from)
python3 "$SS/check_portal_mirror.py" --manuscript manuscript/manuscript.md \
  --profile "<...>/journal_profiles/npj_Digital_Medicine.md" --emit portal_fields/

# then verify nothing was lost on the way to the box
python3 "$SS/check_portal_mirror.py" --manuscript manuscript/manuscript.md \
  --portal-dir portal_fields/ --profile "<...>/npj_Digital_Medicine.md" \
  --out qc/portal_mirror.json

判定	発生条件
PORTAL_FIELD_NOT_MIRRORED	置き換え対象の原稿セクションにある文が、そのフィールドの貼り付け用成果物に含まれていません。
PORTAL_FIELD_MISSING	原稿にセクションがあり、ジャーナルがそのセクションを置き換える設定なのに、成果物がありません — フィールドは空で公開されるか、ポータルの自動抽出による推測結果で公開されます。
EQUAL_CONTRIBUTION_NOT_IN_PORTAL	原稿では貢献が同等、または共同筆頭であると述べられているのに、著者の貢献のテキストにはその記載がありません。

3 つとも重大な問題で、終了コード 1 を返します。事前チェックでは P1 として実行されます（--strict で昇格可能）。

どのフィールドが置き換え対象かは、推測ではなくジャーナルの情報です。 ジャーナルプロファイルの ## Portal Mechanics ブロック（Fields that REPLACE the manuscript: …）から読み取ります。ポータルの仕様が記録されていないジャーナルでは、チェックは終了コード 2 で終了し、何も断定しません。仕様を作り上げるのではなく、初回投稿時にブロックを記録してください。照合には _quote_match.py を使用するため、貼り付け時に文の折り返しが変わっても、欠落として報告されません。

フェーズ 3c — CRediT の整合性（著者順ではありません）

貢献分類は公開される事実の主張ですが、用語が示す作業の痕跡がリポジトリに残らないこともよくあります（正当な「Conceptualization」がメールにしか残っていない場合など）。そのため、分類はゲート対象とし、裏付けの確認はプロンプトにとどめます。

python3 "${CLAUDE_SKILL_DIR}/scripts/check_credit_integrity.py" \
  --manuscript manuscript/manuscript.md --out qc/credit_integrity.json

判定	重大度	発生条件
CREDIT_TERM_INVALID	重大	CRediT と記載されたセクションで、公式の 14 項目にない用語が使われています — 「統計解析」「原稿執筆」「研究デザイン」は CRediT の用語として解釈されますが、該当しません。メッセージには意図された用語が示されます。
CREDIT_INITIALS_UNRESOLVED	重大	著者に一致しない、または複数の著者に一致するイニシャルがあります — 著者欄を編集した際に残った不整合です。
CREDIT_AUTHOR_UNLISTED	重大	著者欄に記載された著者に、帰属する貢献がありません（ICMJE に照らすと、著者資格に関する問題、または文節の脱落が疑われます）。
CREDIT_UNCORROBORATED	確認プロンプト	用語を裏付ける痕跡がありません — 図のない論文での Visualization、Code Availability の記載がない論文での Software、または（--contribution-record を指定した場合に限り）記録にない貢献者です。

著者順や貢献が同等である旨の指定をゲート対象にしてはいけません — これらは合意に基づいて決めるものであり、交渉すること自体は正当です。裏付け確認のプロンプトには証明書で回答してください。リポジトリ外の貢献を理由にビルドを失敗させないでください。解決可能な著者名が著者欄に 2 名未満しかない場合、著者とイニシャルの照合はスキップされ、その旨が表示されます。貢献のセクションがない場合、スクリプトは終了コード 2 で終了し、何も断定しません。

フェーズ 4 — カバーレターの自由記述のずれ

カバーレターの ## Article details ブロック（本文の単語数、抄録の単語数、参考文献数、表／図の数）は、原稿が v_N → v_(N+1) に分岐すると古くなるサイドカー情報です（語数制限の再設定、抄録の再構成、参考文献の追加など）。また、docx レベルでこれを監査する仕組みはありません。scripts/cover_letter_drift_check.py は原稿を計測し、レターに記載された数値と比較します。

python "${CLAUDE_SKILL_DIR}/scripts/cover_letter_drift_check.py" \
    --manuscript manuscript.md \
    --cover-letter cover_letter.md \
    --refs refs.bib \
    --out qc/cover_letter_drift.json

参考文献／表／図の数は完全一致する必要があります。抄録の単語数は ±5、本文の単語数は 5% の差まで許容されますが、レターに上限に対する語数（「3,998/4,000 words」）が記載されている場合は、その余裕の範囲内に狭められます。ずれがある場合は、v_(N+1) のビルド時に原稿からカバーレターを再生成して解消してください。このスクリプトはカバーレターを編集しません。カバーレターは意図的に作成された成果物のまま保持されます。

フェーズ 5 — 文書間の N の整合性

抄録、本文、PROSPERO レコード、カバーレター、補足抽出シート、INDEX、PRISMA フローのキャプションには、同じ k included／k excluded／N patients の合計が繰り返し記載されます。これらに不一致があると、レビュー担当者にはデータの完全性に関する問題、または編集漏れとして受け取られます。 scripts/cross_document_n_check.py はカテゴリ（patients、cases、included、excluded、nodules、tumors、studies_total）ごとに、すべての「N 」という記述を抽出します。カテゴリ内に異なる整数値が複数ある場合は、P0 のずれとなります。--root を指定すると、原稿、抄録、PROSPERO、ルートとジャーナルごと（submission/<journal>/）のカバーレター、supplement/、supplementary/ をスキャンします。該当ファイルを UTF-8 として読み込めない場合、そのファイルは files_scanned ではなく unreadable_files に記載され、スクリプトは 2 で終了します。そのため、対象範囲が不完全なまま合格と判定されることはありません。

python "${CLAUDE_SKILL_DIR}/scripts/cross_document_n_check.py" \
    --root . \
    --out qc/cross_document_n.json

プロジェクトで /meta-analysis フェーズ 3f.5 から 2_Data/FINAL_POOL_LOCK.yaml を確定している場合は、それを権威ある基準として渡してください。

python "${CLAUDE_SKILL_DIR}/scripts/cross_document_n_check.py" \
    --root . \
    --pool-lock 2_Data/FINAL_POOL_LOCK.yaml \
    --out qc/cross_document_n.json

qc/cross_document_n.json の submission_safe: false は作業停止の指示として扱ってください。各記載箇所をデータ成果物（抽出シート、PRISMA カスケード TSV）までたどり、ロックされた数と一致しない文書を修正して、ずれを解消してください。

フェーズ 6 — 原稿内のスコープのずれ

scripts/scope_drift_check.py は、次の 2 つの P0 パターンを検出します。

• SCOPE_DRIFT — 限界／考察には数値上の基準値（AUC、OR/HR/RR、感度／特異度）があるものの、方法＋結果にはない状態です。通常は、主要な報告が存在しないまま、感度分析が後から追加されたケースです。
• PROSPERO_DRIFT — PROSPERO レコードでは特定の統合手法（Freeman-Tukey、ランダム効果 DerSimonian-Laird、二変量、HSROC、ベイズなど）を確約している一方、方法では別の手法が使われている状態です。または、レコードが更新されたのに方法が更新されていない状態です。方法に「amendment lodged なし」と記載されている場合、これは記録された、気付かれないプロトコル逸脱です。

python "${CLAUDE_SKILL_DIR}/scripts/scope_drift_check.py" \
    --manuscript manuscript.md \
    --prospero prospero/prospero_v2.md \
    --out qc/scope_drift.json

解決方法は、(a) 基準値を主要な報告として方法＋結果に反映するか、(b) 限界／考察から削除するかのどちらかです。統合手法のずれについては、PROSPERO の修正届を提出し、方法もそれに合わせて更新してください。投稿前に両者が一致している必要があります。

PROSPERO の公開レコードの「Print/PDF」エクスポートには、現在の修正内容のみが反映されます。以前のバージョンは、バージョン履歴のドロップダウンからのみ閲覧できます。PROSPERO のバージョン状態を引用する際は、単一の PDF エクスポートだけに頼らないでください。公開済みの各バージョンの PDF を個別に保存し、どのバージョンが方法論の根拠となり、どのバージョンが文書上のみの正誤表を反映しているかをカバーレター／補足資料に記載してください。このような正誤表（方法／適格基準／統合に変更のない、叙述上の事実の修正）については、新たな構造化された修正届ではなく、単一の Revision-Note 追記を推奨します。

フェーズ 7 — v_(N+1) docx 再生成ゲート

凍結済みの v_N パッケージから v_(N+1) を作成した場合（Markdown 本文の編集、査読者とのやり取り、またはカスケード却下の再ターゲット後）、v_(N+1) の docx は v_N の docx と必ず異なっていなければなりません。よくある暗黙の差し戻しは、pandoc／Zotero CWYW による再生成を省略する cp v_N/manuscript.docx v_(N+1)/manuscript.docx の手順です。Markdown は編集されているのに、ポータルには凍結済みの v_N の docx が送られます。上流のパイプラインで docx が再生成されたように見える場合でも、v_(N+1) の提出ゲートの最初にバイト同一性のアサーションを実行してください。

python3 "${CLAUDE_SKILL_DIR}/scripts/verify_package_integrity.py" \
    --assert-vN-docx-changed \
    --vN-docx SUBMISSION/<journal>/v<N>/manuscript.docx \
    --new-docx SUBMISSION/<journal>/v<N+1>/manuscript.docx

MD5 が同一なら終了コード 1 になります。再生成手順が修正されるまで提出をブロックしてください。

フェーズ 8 — 複数の原稿コピーの乖離

プロジェクトで複数の原稿コピーを手作業で管理している場合（作業用 SSOT の manuscript.md、共著者のフィードバック用 manuscript_circulation.md、ポータル用の submission/<journal>/manuscript.md）、SSOT の編集内容は一部のコピーにしか反映されないことがよくあります。パッケージを凍結する前、または回覧ラウンドを送る前に、方向性検出ツール（SSOT → 各コピー）を実行してください。

python3 ${CLAUDE_SKILL_DIR}/scripts/detect_copy_divergence.py \
  --ssot manuscript.md \
  --copy manuscript_circulation.md \
  --copy submission/<journal>/manuscript.md \
  --out qc/copy_divergence.json --strict

コピーごとに、反映されていない SSOT の 主張（数値の記述 — n = N、割合、p、OR/HR/RR、95% CI — およびセクション見出し）が報告されます。STALE_COPY（全体の判定が DIVERGENT）は P0 ブロッカーです。主張を再反映するか、より望ましくは、並行するコピーの手作業による管理をやめ、ビルド手順（pandoc 変換）を通じて単一の SSOT から回覧用／提出用のバージョンを生成してください。検出されるのは、数値や見出しが変更された場合または存在しない場合のみで、文言の違いは対象外です。コピーにのみ存在する数値の主張（stale_in_copy。例：反映済みの n = 120 の横に古い n = 118 が残っている場合）も、そのコピーを STALE_COPY にします。一方、コピーにのみ存在する見出し（回覧用の送付状など）は copy_only に記載されますが、STALE_COPY にはなりません。存在しないパスを指定した --copy は、終了コード 2 で終了します。

フェーズ 9 — Springer Editorial Manager のパッケージ化（タイトルページ欄なし）

Springer Editorial Manager のジャーナルが、Manuscript／Figure／Table／Supplementary／LaTeX のアップロード項目のみを提供し（Title Page または Cover Letter の欄がない）場合は、${CLAUDE_SKILL_DIR}/references/springer_em_packaging.md を読んでください。

フェーズ 10 — 改訂ラウンド用の変更履歴付き原稿

すべての改訂ラウンドでは、変更履歴付きの原稿が求められます。これは、査読者が見たバージョンと比較して変更履歴を記録した改訂論文です。

比較元は前回のラウンドではなく R0 です。 差分の基点は常に最初に査読された投稿原稿です。更新するのは比較先だけです。編集者は査読対象のバージョン以降に行われたすべての変更を求めているため、v7 と v8 を比較しないでください。

安全に作成できるのは Word の比較機能だけですが、スクリプトから実行できます。 pandiff と LibreOffice の --compare は実際の原稿の OOXML を破損します（表が崩れ、所属先の上付き文字が失われます）。使用しないでください。Word for Mac では AppleScript 経由で author name を指定して compare を実行できるため、ビルドに GUI の操作や、後から w:author を書き換える処理は不要です。

python3 "${CLAUDE_SKILL_DIR}/scripts/build_marked_manuscript.py" \
  --original submission/{journal}/R0/manuscript.docx \
  --revised  submission/{journal}/R1/manuscript_clean.docx \
  --out      submission/{journal}/R1/manuscript_marked.docx \
  --author   "Submitting Author" --line-numbers

（macOS と Word のみ。他のプラットフォームでは Word で手作業により変更履歴付きファイルを作成し、その後、以下のゲートを実行してください。）

ゲート：grep ではなく、往復検証

「変更履歴付きファイルに文 X が含まれている」という確認は、比較機能によって段落が欠落したり、重複したり、変更箇所が 2 人の作成者に分散されたりしていても通ってしまいます。構築によって検証してください。すべての変更を承諾すると改訂原稿が完全に再現され、すべての変更を却下すると元の原稿が完全に再現されなければなりません。

python3 "${CLAUDE_SKILL_DIR}/scripts/check_marked_manuscript.py" \
  --marked   submission/{journal}/R1/manuscript_marked.docx \
  --original submission/{journal}/R0/manuscript.docx \
  --revised  submission/{journal}/R1/manuscript_clean.docx \
  --author   "Submitting Author" --strict

このゲートは移動を考慮します。Word は移動した内容を w:ins／w:del ではなく w:moveFrom／w:moveTo としてエンコードします。挿入／削除だけを認識する検証ツールでは、移動した段落が二重に見え、正常なファイルを破損と判定してしまいます。ゲートが判定結果を報告した場合、他の docx プローブを書く前、または変更履歴付きファイルのサイズが大きすぎてアップロードできない場合は、${CLAUDE_SKILL_DIR}/references/marked_manuscript.md を読んでください。