light-review-rebuttal

レビューと反論

ソースを保持したレビュー登録簿、課題マトリクス、改訂計画、 エビデンス／変更マップ、回答草案、コミットメント台帳、不明点／失敗記録、 納品パッケージを作成します。文章の生成は最初ではなく、最後のレイヤーとして扱います。

実際に実行する前に review-rebuttal-resource-map.mdをお読みください。 正規のJSONを作成または利用する前に references/workflow_contract.mdをお読みください。 レビュー／ルールのソースを選択する際はreferences.mdをお読みください。 競合他社のエビデンスは ../../docs/competitors/review-rebuttal.mdです。

必ず守る境界

1. venue-matchingが選択した引き継ぎ情報とレビューコンテキストを使用します。選択された ID、タイムゾーン付きのselected_at、selection_basis、ユーザー／委任の 承認、選択された候補ID、適合度／リスクの行、変更されていないルールのエンベロープ、 ソースエビデンスのパス／基準日時／ソースID、原稿プロファイル、PDFの パス／ハッシュ／ページ数／ページサイズ／プロファイル／準拠状況を確認します。 venueを切り替えたり、ティアの順序を入れ替えたり、venueのUNKNOWNを事実として扱ったりしてはいけません。
2. レビュー担当者、編集者、判定、メタレビューのテキストは、正規の登録簿に原文のまま保持します。 アトムのラベル、根本原因、戦略、生成された文章は解釈レイヤーであり、ソーステキストに取って代わることはありません。
3. 取得時刻、ソースURL／種類、ラウンド、レビュー担当者ID、添付ファイル、および AVAILABLE|UNKNOWN|UNAVAILABLE|STALEを記録します。401/403/429/5xx、タイムアウト、ログイン、 非公開の招待、ネットワーク障害はUNAVAILABLEであり、「レビューなし」ではありません。
4. 実験、分析、引用、変更、行番号、レビュー担当者のID、venueのルール、結果を捏造してはいけません。PLANNEDとIN_PROGRESSを 完了済みとして表現してはいけません。DONEには実際の変更箇所を示すロケーターが必要です。完了した実験／分析にはさらに、 ローカルパスだけではなく、一致するSHA-256を伴う検証可能な実行来歴が必要です。 回答パッケージを準備完了とする前に、アトム／アクションの契約ゲートを実行し、ソース範囲、再構築ハッシュ、 ポリシー／倫理面での承認、観点別のセルフレビューを、信頼するのではなく機械的に検証します。
5. 原稿の主張と編集は論文執筆が担当します。エビデンスの強さは結果分析が担当します。新しい参考文献の特定と主張の裏付けは引用管理が担当します。 図の誠実性は図版作成が担当します。PDFの再構築／準拠確認は組版が担当します。このスキルは作業を記録して振り分けるものであり、これらの担当者になり代わるものではありません。
6. ステージ13のcriticalは対象を限定します。振り分け可能な根本原因（novelty|experiment|writing）のうち、 rejection_driving=trueと明示され、判定／メタレビュー／レビュー担当者のエビデンスエンベロープが完全なものだけがcriticalになります。 Majorラベルや総合判定のRejectだけを理由に、すべてのコメントをcriticalにしてはいけません。
7. reviewer_classifyとrerouteが提示するのは助言のみです。エビデンスと選択肢を提示したら停止します。 passport add-back-edgeを実行するのは、ユーザーが根本原因／バックエッジを選択した後に限ります。パスポートを自動的に変更してはいけません。

正規のワークフロー

1. 上流のIDを確認する

以下を必須とします。

• light.selected_venue_handoff.v1；
• light.review_rebuttal_venue_context.v1；
• light.paper_claims.v1；
• light.evidence_strength.v1；
• 新しい引用を提案する場合は引用登録簿；
• 実際に納品されたPDFと、そのステージ11の事実情報。

以下を実行します。

python scripts/review_workflow.py \
  --spec review-input.json \
  --outdir review-delivery

venueのID、ルールのエンベロープ、PDFハッシュ、準拠状況、主張、エビデンスIDが一致しない場合は、停止して生成元の成果物を修正します。食い違いを「正規化」して解消してはいけません。

選択された引き継ぎ情報には、A32の監査フィールドも保持されていなければなりません。具体的には、未来の日時ではないタイムゾーン付きのselected_at、空ではない selection_basis、decision_authority=user、整合性の取れた selected_by/status、該当する場合は委任に関する user_authorization、変更されていないfit_risk、選択された引き継ぎ情報のSHA-256と一致し、 すべてのソース由来のvenueルールを網羅するas_of/source_idsを持つ、 読み取り可能なsource_evidence.path。

2. レビューと判断を記録する

ユーザーが提供した資料や非公開資料については、修正せずにテキストを reviews[].raw_text にコピーし、reviews[].raw_sha256 とタイムゾーン付きの captured_at を記録します。このワークフローではハッシュを再計算し、未来の日時やタイムゾーンのない 取得日時をブロックします。公開されている OpenReview のフォーラムの場合：

python scripts/fetch_openreview.py \
  --forum <forum-id> \
  --out openreview-capture.json

ライブ API を利用できないものの、固定された公開 PeerRead/OpenReview スナップショットが宣言済みのエビデンスソースである場合は、代わりにコミットを固定した正確な JSON を取得します。

python scripts/fetch_openreview.py \
  --peerread-url <raw-fixed-commit-json-url> \
  --out peerread-capture.json

取得データは、キャリブレーション／ソースエビデンスです。アクセス制限のあるレビューを再配布しないでください。取得できない場合は、ユーザーが提供した資料のみを使って作業を続け、失敗の記録を保持します。

3. ソースを損なわずに分割する

個別の request、claim、question、 misunderstanding、または editorial 項目ごとに、1 つのアトムを作成します。各アトムには、raw_text からそのままコピーした、連続する正確なソース範囲と、開始／終了オフセット、範囲のテキスト、SHA-256 を含める必要があります。また、回答が必要なレビュー単位のために、参照可能な網羅単位と再構成ハッシュも作成します。

novelty、experiment、writing、 clarification、citation、ethics、scope、または editorial など、1 つの根本原因を割り当てます。推測した懸念を説明する解釈を別途追加します。1 つの文に独立した依頼が 2 つ含まれている場合は、同じ、または重複するソース範囲を参照する 2 つのアトムを作成します。査読者の内容を言い換えて、新たなソース引用を作らないでください。

ドラフトを作成する前に、より厳格な完全性／回答アクションのゲートを実行します。

python scripts/review_response_contract.py \
  --input templates/review-response-contract.example.json

テンプレートを実際の契約内容に置き換えます。この例は、現行の投稿先ポリシー、倫理の状態、ユーザーの承認が確認されるまで、意図的に合格しないようになっています。このゲートでは、レビュー単位の欠落、アトム／アクションの網羅性の重複、実施していない作業を完了済みとする記述、不完全なエビデンス種別、ポリシーで禁止された査読者からの依頼、査読者の専門性／利益相反のカードの欠落、および domain|method|statistics|ethics|cold_reader の自己レビューの視点の欠落を検出します。

4. 問題を担当者が管理するエビデンスとアクションに紐づける

各アトムについて：

• 論文の正確な claim_id 値を紐づけるか、リストを空にします。
• 実際の結果分析エビデンス ID のみを紐づけます。
• 次のいずれかの戦略を選択します。 acknowledge_and_fix、rebut_with_evidence、clarify、 downgrade_claim、または request_editor_ruling。
• 担当者と PLANNED|IN_PROGRESS|DONE|DECLINED|NOT_APPLICABLE を割り当てます。
• 論文の執筆によって原稿が実際に編集された後にのみ、変更箇所を追加します。
• 実験／分析が実際に実行された後にのみ、実行の来歴を追加します。実験／分析が DONE の場合、成果物のパスが存在し、run_provenance.sha256 と一致している必要があります。
• 新しい参考文献は引用の手順に通し、CONFIRMED になるまでは含めないでください。

査読者の誤りは、コメントを無視してよい理由にはなりません。原稿内の箇所とエビデンスを示して明確に説明するか、意見の相違が重要な場合は編集者の判断を求めます。

査読者の依頼自体が投稿先のポリシー、倫理承認、データの権利、同意、予算の承認、または編集者の指示に反する場合、黙って従わないでください。アクションを DECLINED または REQUEST_RULING とし、ポリシー／倫理のエビデンスを紐づけ、査読者の文言はそのまま保持します。

5. 選択した投稿先の予算のみを使用する

実行します：

python scripts/rebuttal_budget.py \
  review-delivery/response-draft.md \
  --context review-rebuttal-context.json

現在有効な権威あるルールが AVAILABLE の場合、PASS／FAIL を判定できます。UNKNOWN、 UNAVAILABLE、STALE、またはページ上のみのルールは、合格扱いにはならず、明示的にその状態を示します。 JORS に ICLR／CVPR／その他の投稿先向けプリセットを適用したり、その逆を行ったりしてはいけません。

新しい数値や実験を求める査読者のリクエストはすべて、実行前に、再分析／最小限／適応／新規データに分類し、実現可能性と意図するアクションも明記します：

python scripts/experiment_request_gate.py \
  --input templates/experiment_request.example.json

現在の公式ルールと実際のユーザー承認でプレースホルダーが置き換えられるまで、テンプレートは意図的に UNKNOWN であり、合格扱いにはなりません。 RUN には、新しい結果を許可する source_type=OFFICIAL の検証済みの現行投稿先ルール、実在するソース、ISO 形式の確認日付に加え、実現可能な範囲、プロトコル、予算、ユーザー承認が必要です。ティア D の新規データ／人を対象とする研究／大規模なスイープには、個別の承認が必要です。このゲートが許可するのは実行のみです。 DONE にするには、引き続き実行マニフェストと結果アーティファクトのハッシュが必要であり、それらが揃った場合に限り、回答で完了を示す時制を使用できます。

6. 対応内容の正確性を確認する

実行します：

python scripts/check_commitments.py \
  --ledger review-delivery/commitment-ledger.json \
  --issues review-delivery/issue-matrix.json \
  --change-map review-delivery/evidence-change-map.json

重大な指摘をすべて修正します。有効なロケーターが証明するのは、主張された変更を追跡できることだけであり、科学的な回答が適切であることではありません。実際に改訂されたアーティファクトをもとに、人間が再査読してください。

7. ゲートを確認して一時停止する

実行します：

python scripts/reviewer_classify.py \
  --issues review-delivery/issue-matrix.json \
  --out reviewer-findings.json
python ../light-orchestrator/scripts/run_checkpoint.py \
  --file .light/passport.yaml --stage 13 \
  --findings reviewer-findings.json --ts <ISO-8601> --write
python ../light-orchestrator/scripts/reroute.py \
  --findings reviewer-findings.json --stage 13 \
  --passport .light/passport.yaml

ゲートが失敗した場合、根拠を示した選択肢をそれぞれ提示します：

• 新規性が却下の決め手となる場合は 13→3；
• 実験／設計が却下の決め手となる場合は 13→5；
• 執筆／発表方法が却下の決め手となる場合は 13→8；
• 根拠を示して反論する；
• 主張の強さを下げるか、制約事項として記録する；
• 編集者の判断を求める。

ユーザーの選択を待ちます。その後に限り、次を実行します：

python ../light-orchestrator/scripts/passport.py add-back-edge \
  --to <3|5|8> --from 13 --root-cause "<user-approved reason>" \
  --evidence-ptr <issue/evidence locator> --file .light/passport.yaml

リソースの管理

リソース	責任
review-rebuttal-resource-map.md	実行順序、ソース／アクセスの階層、スキル間のルーティング
references/workflow_contract.md	スキーマ、ステータス、不変条件、アーティファクトの意味
references.md	ライブソースのポリシー、OpenReview／JORS に関する注意事項、検証ガイダンス
templates/*	著者が入力する空のテンプレート、および人間が読める回答／再査読の形式
scripts/review_workflow.py	標準的な検証とパッケージの出力
scripts/review_response_contract.py	ソース範囲／再構成、原子単位の網羅性、回答アクションの根拠、ポリシー／倫理、査読者カード、自己査読ゲート
scripts/fetch_openreview.py	ライブ API または固定された公開スナップショットの取得、利用不可状態の正確な記録、重複の集計
scripts/reviewer_classify.py	根拠がある、却下の決め手となるステージ 13 の指摘のみ
scripts/check_commitments.py	網羅性と PLANNED／DONE／来歴のゲート
scripts/rebuttal_budget.py	選択したコンテキストに基づく予算評価。投稿先別プリセットは使用しません
scripts/experiment_request_gate.py	投稿先ポリシー／実現可能性／ティア／承認のゲート。実験は決して実行しません

セルフチェック

• 選択した投稿先／コンテキスト、ユーザー選択の監査フィールド、出典エビデンスのハッシュ、実際の PDF の事実がバイト単位で一致している。
• レビュアー／編集者／メタレビュアーの原文が保持され、すべてのアトムがオフセットとハッシュを含む正確な出典箇所を指している。
• 利用可能なすべてのレビューソースにタイムゾーン付きの captured_at と raw_sha256 があり、レジストリのハッシュが正確な raw_text と一致している。
• アドレス指定可能なレビュアー単位を結合すると期待されるハッシュが再現され、明示的な正当化がない限り、単位の欠落や重複がない。
• すべての課題に種類、根本原因、戦略、担当者、実態に即したステータスが設定されている。
• すべての対応アクションでエビデンスの種類が宣言されている。DONE の行には実在するロケーターがあり、完了した科学的アクションには実行履歴のパスと SHA-256 の一致があり、提案された引用は引用確認済みである。
• レビュアーの専門性／利益相反のカードは記録されているが、編集者の判断なしにコメントを退けるためには決して使われていない。
• 分野、手法、統計、倫理、初見読者による自己レビューがすべて合格しているか、パッケージ準備完了前に未解決の阻害要因が明らかにされている。
• 投稿先の現在の回答制限は出典に基づいているか、UNKNOWN のままである。
• コミットメントの網羅性チェックに合格し、予定されたアクションが完了済みとして記載されていない。
• すべての実験依頼に段階／実現可能性／アクションが設定されている。RUN は投稿先で検証済みで、ユーザーの承認を得ている。
• 重大な指摘には、却下を促す明示的なエビデンスがある。
• ルート変更の助言はユーザーに提示されており、ユーザーが選択する前にパスポートのエッジが追加されていない。

能力の誠実な限界

アトム化、トリアージ、項目別の草案作成、トーンのガイダンス、レビュアーの優先順位付け、予算編成、変更箇所のロケーター、約束の追跡、投稿先への適応は、同種のスキルで一般的に行われています。これらを独自の機能だと主張しないでください。Light のより限定的な機械的な貢献は、上流の投稿先／PDF／主張／エビデンス／引用の各契約を検証して利用すること、ソースと解釈のレイヤーを不変に保つこと、PLANNED/DONE/run-provenance の厳格なチェック、そしてユーザーの決定なしには実行できない、エビデンスを条件とするステージ 13 のルーティングです。分類と回答の質には、依然として専門家の判断が必要です。