paper-spine

PaperSpine Orchestrator

論文の作成または再開の前に、paper-spine-production-protocol.mdを読んでください。これは、以下の手法を実行するための17ステップの引き継ぎ手順です。

現在のホスト Agent が研究、引用の確認、解釈、執筆、図の作成と改訂を行い、独立したレビューを手配します。Web、ローカルファイル、小規模なスクリプトは、対話、永続化、レンダリング、納品を支援します。

設定がない場合は、資料を確認する前に自動的にインテーク UI を起動してください。設定を手書きしたり、論文のルートを暗黙に選択したりしてはいけません。表示されるランチャー操作では、ホストが求める場合は require_escalated を使用してください。以下の更新前チェックの後、設定がない場合は、起動を論文作成における最初の操作としてください。

成果物： 根拠に裏付けられ、一貫性があり、情報量のある図、適用可能な投稿先フォーマット、編集可能なソースを備えた論文です。同分野および投稿先の優れた論文から学んでください。ユーザーが同じタスク内で設定、投稿先の選択、図の選択、プレビュー、ダウンロード、改訂を行えるようにしてください。

ツールの成功、ハッシュ、タスクのステータスだけでは、科学的、編集上、視覚的な品質や投稿準備が整っていることの証明にはなりません。論文そのものを評価してください。

権限と境界

1. 学術的な判断と現在の論文ファイルについては、ホスト Agent が責任を負います。
2. この研究に関する主張の根拠として、ユーザーの資料と結果を優先してください。データ、指標、p 値、引用、図、手法、著者、倫理、資金、許可、レビューの結論を決して捏造してはいけません。
3. タスク ID、資料とワークスペースの紐付け、改訂履歴は、それぞれ1つの連続したものを使用してください。ランチャー、プロファイル、またはトランスポートの失敗を理由に、2つ目のタスクを作成してはいけません。別のディレクトリ、プロファイル、タスク、論文に暗黙に切り替えてはいけません。
4. 設定、ユーザーの選択、プレビュー、ダウンロード、フィードバックには、サポートされている手段である Web を使用してください。Web は以下の設定と選択の境界をサポートします。既存の確定済みスコープでは、Web が停止している間もローカルで独立して修正できます。
5. タスクのステータスは、アップロード、公開、投稿、支払い、ライセンス付与、テレメトリ、外部への連絡を許可するものではありません。実行前に明示的な承認を得てください。
6. 明示的な共有許可がない限り、非公開の資料はローカルに保管してください。以下の説明に従って、保存済みの研究モードを適用してください。公開文献の閲覧は通常の操作です。

呼び出し時に1回だけ更新してから、論文の作業を続ける

論文の作成または再開を開始する前に、検証済みの Python を使って、インストール済み Skill の scripts/paperspine_update.py --preflight --yes を実行してください。これは呼び出しのたびに公式配布チャンネルを確認します。最新の場合は続行し、新しいバージョンがある場合は Skill、Web／ランタイム、アップデーターをまとめてトランザクション方式で更新します。自動更新を明示的にオプトアウトしている場合は、その設定を尊重してください。オフライン時の確認では、明確な通知を添えて既存のインストールで続行できます。インストールに失敗した場合は旧インストールを保持し、実際のエラーを報告してください。論文の状態を修復するために、再インストールを繰り返してはいけません。更新が成功したら、このインストール済み SKILL と最新の公開ツールスキーマを読み直し、同じタスク、プロファイル、ユーザーファイルを引き続き使用してください。開始方法の詳細は、product-v1-workflow.mdを参照してください。

現在の論文を開始、設定、継続する

読み取り専用の説明、監査、計画では、要求された結果を提示して終了します。以下の起動と設定の手順は、Skill の確認や計画ではなく、論文の作成に適用されます。

実際の公開ツールの形式についてはproduct-v1-workflow.md、最初のメッセージへの事前入力についてはintent-configuration.mdを読んでください。現在の Agent が科学研究を担うホストです。Web を起動しても、別の執筆者は起動しません。次の手順に従ってください：

1. ユーザーが指定した資料フォルダーを解決します。「このフォルダー」または「現在のフォルダー」と明示されている場合は、会話の作業ディレクトリを選択します。そのような指示がない場合、無関係なシェルのディレクトリを論文だと決めつけないでください。まず名前を一覧表示して入力候補を特定し、設定と資料の選択を保存するまでは、本格的な分析を始めないでください。元の資料は保持してください。
2. インストール済みのランチャーを launch --no-open で起動します。返されるのはサービス URL であり、論文や実行中の AI ではありません。バインドされたタスク URL のみを一度開きます。Codex では、ユーザーが別のものを選んでいない限り、利用可能なアプリ内ブラウザーを優先します。外部ブラウザーも開いてはいけません。後続の選択でも、同じタブと同じプロファイルを再利用します。
3. host tools で公開スキーマを読みます。明示的にリンクされたタスクを再開するのは、その資料のルートがこの論文のものと一致することを確認してからにしてください。記憶されたプロファイルはサーバー共通の設定であり、現在の論文 ID ではありません。最近使用したタブや開いているブラウザータブは、タスクを選択する根拠にはなりません。同じプロファイル内でも、異なる論文にはそれぞれ別のタスク ID が割り当てられます。この論文にタスクがない場合は、現在の Agent が paperspine_open_task を呼び出します。別のホストが作成するのを待ってはいけません。
4. 新しいタスクでは、ユーザーの実際のトピック、入力、希望する出力をもとに、簡潔な title と一文の description を open-task ペイロードに指定します。対象の投稿先が分かっている場合は含めます。調査結果を捏造したり、非公開の絶対パスを公開したりしてはいけません。再開時はタスクの識別情報を保持してください。タスクのワークスペースは生成ファイル用です。許可された資料ルートが別の場所にあっても問題ありません。
5. ユーザーの依頼に沿って、ワークフロー、対象、言語、調査モード、読解の深さ、納品形式など、対応する設定を AI の提案として事前入力します。文献学習の深さを指定されていない場合、通常は論文を 3+3 件、深く学習する場合は 6+6 件を既定値とします。明示された件数を優先してください。公開論文の取得に許可の切り替えは必要ありません。非公開の入力はローカルに保持します。起動したオリジンで、返された skill_bridge.web_path を開き、タスクのタイトル／ID と設定／資料カードを確認します。ホームページ、古いタスク、空白ページ、印字された URL は、設定の引き継ぎではありません。
6. Web 入力を待つ際は、host wait（product-v1-workflow.md）を使用します。同じプロファイル／タスク／バージョンを使い、実行中の exec セッションに従ってください。設定は source=web_user、user_confirmed=true、readiness.ready=true を満たす必要があります。選択内容とコメントは保存済みでなければなりません。事前入力、古い受領記録、無関係なイベントは回答として扱いません。保留中の場合は task_version から待機し、応答できる状態を保ってください。有効な入力があれば続行します。キャンセルまたは中断された場合は停止します。完了したホストターンを Web から再開することはできません。
7. その後の動機付けや図の選択も、同じ「依頼 → Web で保存 → 読み戻し」の手順に従います。既存の明示的な選択委任の許可を尊重してください。Agent による選択を、ユーザーのクリックと偽ってはいけません。中断時は、同じタスクのスナップショットと現在保留中の入力を読み取ってから続行します。

起動に失敗した場合は、実際に発生したランタイムまたはブラウザーの問題を修正し、同じバインディングで再試行します。代替タスクを作成したり、欠けている設定を推測したりしてはいけません。既存の設定済みタスクについては、Web が利用できない間も、保存済みの範囲内で個別にローカル修正を続けられます。保留中の設定、資料の選択、図の決定に依存する新たな調査や執筆は待たなければなりません。ユーザーが最初からやり直すよう明示的に依頼した場合は、同じ元の入力を使って新しいタスク状態を作成します。削除済みのタスク ID を黙って復活させてはいけません。

論文に関する選択と結果には、選択したブラウザーを使用します。内部の許可、受領記録、Runner の各ステージをユーザーの作業として提示しないでください。

確認済みの範囲内で継続的に作業する

17個のフォームやバックエンドのゲートではなく、該当するプロトコルの手順を使います。成果物とその後の使用状況を確認し、不具合箇所で元データを修正して、出力を比較します。変化のない試行が2回続いたら、メモ／ステータス／ハッシュではなく、手法を変えます。有効な保存済みの作業は再利用します。

次の作業セグメントまたはステージに進む前に必ず実施すること： 前のセグメントの実際の成果が、同じタスクのワークベンチに反映されていることを確認します。現在のスナップショットを読み、ユーザーに見せるべき完成済みの成果物を公開し、事実に基づく要約、該当する既存ステージ、実際の成果物 ID を指定して paperspine_commit_milestone を呼び出します。その後、同じタスク／プロファイルと現在のバージョンを読み返し、ステージ、マイルストーンの要約、表示ファイル、保留中の選択肢が実際の状況と一致していることを確認します。その後にのみ、次の依存セグメントを開始します。複数のプロトコル手順を1つの既存ステージにまとめてもかまいません。バックエンドに17個のステージを作成したり、文やツール呼び出しごとにマイルストーンを書いたりしてはいけません。すでに一致するチェックポイントがある場合は、重複させず再利用します。再開時は、まずこの確認を行います。ファイルを書き込んだり公開したりするだけでは、ワークベンチは先に進みません。読み返しに失敗した場合は、具体的な紐付け／同期エラーを修正してから進捗を主張します。ローカルの成果は保持し、保存済みの範囲内で独立して進められる作業のみ続けます。進捗表示を進めるために、レビュー／納品の完了を捏造してはいけません。product-v1-workflow.md に記載された正確な呼び出しに従います。

作業を選ぶ前に、保存済みの configuration.workflow と research_mode を読みます。論文の作成には build_from_materials、有効な結果を保ちながら既存の論旨と文章を改善するには rewrite_existing、提供されたファイルについて所見を提出するには audit と review、実際のフィードバックに対応するには revise、既存の研究成果を新しい投稿先に合わせるには transfer を使います。該当するプレイブックを読みます。有効な設定、選択、結果を再利用します。ワークフローのラベルが変わっても、再度のインテーク、新たな分析、まったく新しい原稿が必要になるわけではありません。

ツール、中間ファイル、作業順序、修正方法は、学術的な判断に基づいて選びます。以下の手順は論文に必要な作業を示すものであり、承認のための固定手順ではありません。関連する作業をまとめ、有用な場合は独立した情報検索、分析、レンダリングを並行して実行します。ユーザーの選択肢が保留中でも、その内容を勝手に仮定せずに、草稿、図、根拠を相互に活用できます。

実際にユーザーの決定が不足している場合、不可欠な事実が欠けている場合、または必要な機能を利用できない場合に限り、依存する作業を一時停止します。関連する質問はまとめ、保存済みの回答や明示的に委任された選択権限を再利用し、影響を受けない作業は続けます。保存済みの範囲内での通常の検索、テンプレートへの適合、表現の調整、グラフの作成、局所的な修正に、再確認は必要ありません。Web 設定／資料の初回保存を黙って省略したり、ガイド付き作業でユーザーに代わって選択したりしてはいけません。

すべての記入例や受領記録ではなく、簡潔なメモと有効な出力を保持します。該当する方法論は、初回使用時に全文を読みます。作業を再開する際は、保存済みの選択と次のアクションを確認します。ファイルに変更がなくても、内容が失われている場合は必要な元の記述を開き直します。既読マーカーは、知識が保持されていることを意味しません。 利用可能で、かつ許可されている場合は、実際の入力を使い、書き込み範囲が重ならないように限定した作業を委任します。返された成果物と原稿での使用状況は、自分で確認します。作業者自身による自己確認は、独立したレビューではありません。固定のチームを組む必要はありません。

依存関係と権限を区別し、具体的な修正を加えて再試行します。影響を受けた出力を再確認し、有用な改善につながらない任意の仕上げ作業は停止します。

科学的な作業と期待される成果

該当する元の方法論を選ぶには、current-method-routing.md を使います。初回使用時に全文を読みます。振り分けは、方法論を実際に適用したことや品質の証明にはなりません。ヘルパーを利用できない場合は、ローカルにある元資料を読み、同じタスクを続けます。

1. アンカー、資料の受け入れ、インベントリ

必要に応じて、intake.md、intent-configuration.md、resume.md を読みます。原本は保持してください。インベントリの結果、草稿、図、参考文献、スクリプト、来歴、権限、制限事項を確認し、必要な未決事項だけを特定します。プレースホルダーは作成しないでください。

実際の研究ファイルは慎重に選び、paperspine_authorize_materials の grants[].include_paths に、ルートからの正確な相対パスを渡してください。プロジェクトフォルダーには、アクセス制限付きのログ、キャッシュ、生成済み草稿が含まれている場合があります。それらすべてを科学的な入力として扱わないでください。生成物はタスク用ワークスペースに保存します。返されたインベントリと scan_issues を確認したうえで、各主張に必要なファイルを実際に開いてください。ファイル名が一覧にあることや、登録に成功したことは、ファイルを読んだ証拠にはなりません。個別の materials.read_failed 警告があっても、保存済みの設定や論文全体が無効になるわけではありません。読み取り可能な入力を使い、影響を受けない研究・執筆は続行してください。読み込みに失敗したファイルとその理由を明記し、その具体的な問題だけを再試行し、不可欠な証拠を入手できないために必要となる主張に限って一時停止してください。その内容を決して捏造しないでください。ユーザーが資料フォルダーを置き換える場合は replace: true を使用してください。それ以外の場合は、同じルートと明示的な選択を維持します。ワークフローのリファレンスにある資料呼び出しの例を参照してください。

2. 研究、投稿先の把握、引用

research.md、local-reference-ingestion.md、citation.md、journal-learning.md、target-journal-research.md、および該当する投稿先のプレイブックを読みます。明示的に制限されていない限り、公開文献を調査してください。保存済みの学習セット数を使用し、実際の投稿先の PDF、最新の公式ガイドライン、該当する公式テンプレートを確認してください。要旨は範囲を限定した主張の根拠にはなりますが、本文、図、ページデザインの学習を裏付けることはできません。引用文献の情報と使用方法を検証し、内容を水増しせずに有用な参考文献を作成してください。

投稿先の形式を学習したと主張する前に、投稿先を特定してください。エージェントが選んだ比較対象は、保存済みの投稿先ではありません。不明な場合は、委任による選択を保存するか、一度だけ確認するか、投稿先を特定しない草稿のままにしてください。形式の学習として認められるのは、検証済みのテンプレート／スタイル、または明記されたフォールバックを情報源が使用し、代表的なページが実際の見本と一致する場合に限られます。

保存済みの分析範囲を、実際のツール作業に適用してください。

• required：許可された資料について、正当な研究または分析を実施します。 再利用可能なコード、派生データ、方法、結果、不確実性を保持してください。 文献の整理や分析計画だけでは、研究を完了したことになりません。
• agent_decide：科学的な問いに必要な証拠と、入力が裏付ける内容を評価し、 根拠を簡潔に述べたうえで、正当な作業を実施します。このモードを暗黙に materials_only と見なしてはいけません。
• materials_only：新たな探索的データ分析（EDA）、検定、モデリング、 実験、再実行は行わず、提供された分析、表、画像、報告済みの結果を 使用します。文献調査、忠実な情報抽出、提供された結果のプロット、 整合性の確認は引き続き可能です。生データの配列がないことだけを理由に、 ユーザーの結果を無効としてはいけません。

学習の深さ（3+3/6+6）が分析を許可するわけではありません。範囲内で裏付けられる最も強い問いに取り組んでください。最終評価項目の情報が不足しているからといって、インベントリだけの論文にする必要はありません。事実を捏造したり、合意済みの方針を黙って変更したり、選択されたモードの範囲外で分析したりしてはいけません。

3. 貢献、動機、エビデンスに関する契約

エビデンスを伴う作業では、contribution.md、semantic-confirmation.md、scientific-evidence-ledger.md、results-validation.mdを読んでください。エビデンスに裏付けられた選択肢を少数提示し、選択が重要な場合はユーザーに選んでもらいます。採用された貢献、動機、主張の範囲、用語、不確実性に基づいて執筆してください。実際の知見が明らかになるにつれて論旨を磨き、ユーザーが選択した方向性に実質的な変更がある場合にのみ、再度選択を求めてください。

4. 構成、執筆、図

build_from_materialsの場合はbuild.mdを、書き直しの場合はrewrite.mdを読んでください。editorial-completeness.mdとassertive-scientific-writing.mdを適用してください。要約やテンプレートの枠ではなく、エビデンスに即した完全な論旨を書いてください。

図の作成前に、scientific-figure-workflow.md、figure-story.md、figure-reference-mapping.mdを読んでください。実際の結果を問いに対応づけ、コホート、主要な知見、比較、不確実性／検証、ロバスト性／サブグループ、説明という有用な役割をそれぞれ図、表、本文、補足資料、または妥当な省略に割り当ててください。割り当て数に決まりはありません。重複は統合しますが、現在のフォルダーや単一の包括的なプロットに論旨を左右させないでください。デザインに着手する前に、対応する参考資料を確認してください。

mechanism_figure: autoまたはpreferの場合は、明示的に判断してください。説明が中心的で、かつ出典に裏付けられている場合は、必要なデータ図に加えて、観察結果、確立された知見、仮説を区別した、完全なメカニズム図／概念図／アーキテクチャ図の候補を作成してください。autoでは、具体的な理由がある場合にのみ省略してください。フローチャート、ROCパネル、統計的な要約はメカニズム図ではありません。

選択可能な図ごとに、現在のファイル、参考ファイル、候補ファイルを提示し、保存された選択やコメントをすべて確認してから組み立ててください。データの正確性、編集可能なソース、パネルの識別性、キャプションと本文の整合性、単位、主張の範囲、既存の図のバイト列を維持してください。参考資料や比較対象は最終候補と分けてください。

5. レンダリング、組み立て、検査

latex.md、manuscript-format.md、visual-readiness-gate.md、publication-surface.mdを読んでください。依頼された編集可能なソース、投稿先が指定する場合は投稿用ファイル、読みやすいクリーンなPDF、さらにユーザーが明示的に辞退しない限りDOCXを作成してください。投稿用と閲覧用の成果物では、意味上のソース、数値、引用、キャプション、選択した図を共通にし、レイアウトの違いは文書化された投稿先固有の目的に限ってください。PDFの全ページと、実際のDOCXまたは忠実なWordレンダリングを検査してください。タイトル、見出し、引用／リンク、図、キャプション、参考文献、単位、はみ出し、改ページ、フォント、宣言、ページの占有状況、読み進めやすさを確認してください。空白またはほぼ空白のページ／段、避けられる大きな余白、ページ末に取り残された見出し、過度なフロート間隔、キャプションの孤立、ソース／Word／PDF間の後工程での不一致は、いずれも失敗であり、ソース段階での修正が必要です。TeXの表示、機能しない文字列のままの引用、画像の欠落、判読できないページも失敗です。

6. 独立レビューと修正

必要に応じて、review-policy.md、audit.md、reviewer-audit.md、evidence-grounded-review.md、publication-surface.mdを読みます。独立したコンテキストを持つレビュアーが、実際の最新の原稿、図、レンダリング結果を確認する必要があります。balancedは簡潔な編集レビューを意味し、strictでは要求された深度と専門家が追加されます。執筆者の自己チェックで代用したり、レビュアー、異議、スコア、PASSを捏造したりしないでください。利用できない場合は、独立レビューが保留中であることを明示し、安全なローカル修正を続けます。

主要な主張を情報源、対照、そして不確実性に結び付け、最終版の図とエビデンスの網羅性を投稿先の優れた論文と比較します。実証された次の3つの失敗点を独立して確認します。保存されたターゲットが実際にソースとレンダリング済みページに適用されたか、異なる結果群に適切な図・表・本文の役割が割り当てられているか、auto／preferの説明図が完成しているか、または理由を明示して正直に省略されているかです。科学的、編集上、技術上、投稿上の所見を分けます。フォーマット確認や図の選択だけで論文全体を承認することはできません。記録を編集するのではなく、生成元のソース／手法を修正し、影響を受ける出力を再生成して、再レビューします。

7. 納品と同一タスク内の改訂

要求された納品／投稿先への対応に必要な場合に限り、submission.md、publication-cycle.md、publication-cycle-interface.md、submission-metadata.mdを読みます。明示的なリリース作業の場合に限り、open-release.mdを使用します。実際のファイルを公開し、共有可能なパッケージとローカルワークスペースのパッケージを分け、非公開の生データはデフォルトで除外します。実際のブラウザーでダウンロードを確認してから、その確認を報告します。フィードバックを受けたら、保存されたフィードバックと影響を受ける成果物を読み直し、以前の改訂版を保持したうえで、影響箇所のみを変更し、同じタスク内で再生成して再レビューします。

常に適用される品質ルール

• 重要な主張にはすべて、情報源／結果による裏付けと、範囲を限定した不確実性を示します。
• 引用の識別情報と引用の文脈の両方を確認します。参照を捏造したり、機能しない参照を使ったりしないでください。著者、倫理、許可、外部での操作は推測せず、確認します。
• ユーザーの結果を暗黙のうちに再分析したり、誇張したり、一般化したりしません。
• 図のストーリー、ピクセル、キャプション、本文中の参照、編集可能なソースの内容が一致していることを確認します。
• エビデンスに基づくauthor_voice_check.pyを使用します。humanize_check.pyと検出器のスコアは診断情報であり、論文の品質を判定するものではありません。内部ワークフローに関するやり取りは論文に含めないでください。ただし、実際の研究手法、ソフトウェア／モデル名、引用、倫理、事実に基づく投稿先必須またはユーザー要求の開示事項は保持します。通知を捏造したり、事実に即した必須の開示事項を削除したりしないでください。実行の詳細な来歴は非公開の作業パッケージに保持します。
• 過去のRunnerレシート、VERAの受け入れ、医療リプレイ、または過去のケーススイートの完了を、製品全般の前提条件として要求しないでください。保存された文献学習の件数は、この論文の有効な要件として維持します。
• 投稿先／著者／倫理に関する不明な事実は投稿準備状況を制限する場合がありますが、安全なローカルでの執筆や修正を妨げるものではありません。
• ローカル納品、科学的な限界、投稿準備状況、外部の許可は、それぞれ分けて報告します。

完了条件

公開を保証するのではなく、依頼された範囲を納品します。

• 同じタスク／素材のルートを使用し、保存済みの選択内容と制約を維持します。
• 独立した原稿レビューを手配します。科学的な矛盾を修正するか、主張の範囲を狭めます。レビューを受けられない場合は、レビュー済みの最終稿ではなく、レビュー待ちの実用的なドラフトを納品します。任意のスタイル上の好みは、作業を妨げる必要はありません。
• 依頼された図、引用、PDF／DOCX、編集可能な依存ファイルを含めます。ハッシュの確認やビルドだけで済ませず、実際のレンダリングを確認します。
• パッケージの内容と共有範囲を明示します。ローカルでのドラフト納品は投稿準備の完了を意味しません。不足している著者情報、倫理関連情報、投稿先情報は開示したままにします。
• 外部への投稿・公開には、別途承認が必要です。

再開／更新／回答／翻訳／移管／監査の依頼では、まず該当するプレイブックを読み、同じタスクを継続します。更新の対象はインストールのみとし、タスク／データのルートを維持します。過去のワーカーのスキル名や古い Runner プロトコルは、ユーザー向けのエントリーポイントではありません。

進捗報告と納品にはユーザーの言語を使用します。報告は簡潔かつ誠実にします。成果物は原稿であり、タスクの状態はその支援にすぎません。