adversarial-reviewer

敵対的コードレビュー

通常のレビューでは見逃される不具合を探します。実装の前提を検証すべき主張として扱い、すべての指摘を証拠に結び付けてください。

レビュー範囲を確定する

1. レビュー対象の差分、ブランチ、プルリクエストのヘッド、またはファイルを特定します。
2. データフローと不変条件を理解するために必要な周辺コードを読みます。
3. リポジトリの指示と、期待される動作を定義するテストを確認します。
4. 変更を、その明示された目的と照らし合わせます。課題、議論、または採用された設計で扱うシナリオと設定を、実際のコードに沿って追跡し、説明や変更セットに記載された各主張を検証対象として扱います。
5. レビュー対象の変更によって生じた不具合と、無関係な指摘を区別します。範囲外の問題は、変更の安全性に重大な影響を与える場合に限って報告します。

ユーザーから依頼がない限り、コードを変更したり、レビューを投稿したり、レビュー対象を拡大したりしないでください。

不具合を探す

すべてのカテゴリを機械的に適用するのではなく、変更内容に合った確認を選びます。

• ロジックと境界条件： 空および単一要素の入力、ページネーションの境界、無効な状態遷移、ロケール処理、Unicode、最大値、繰り返し呼び出し。
• エラーとクリーンアップ： 握りつぶされた失敗、一部だけのクリーンアップ、誤解を招くステータスコード、内部情報の露出、タイムアウトの欠如、上限のない再試行。
• 状態と並行処理： 古い読み取り、更新の消失、検査と使用の間に発生する競合状態、重複配信、冪等でない再試行、リスナーのリーク、共有された可変状態。
• 認可と信頼： 権限チェックの欠如、呼び出し元 ID の混同、CSRF、安全でないリダイレクト、インジェクション、パストラバーサル、シークレットの露出、検証せずに境界を越えて引き継がれる信頼。
• データ整合性： 部分書き込み、マイグレーションの再開動作、方言の違い、一意性に関する前提、破壊的なカスケード、旧バージョンと新バージョンの互換性。
• リソースとパフォーマンス： 上限のないコレクション、繰り返されるラウンドトリップ、保持されたままのリソース、ログアウト時のホットパスにおける性能低下、攻撃者が制御する入力に応じて増大する処理。
• 範囲： 他の場所に残された同じ不具合（兄弟関係にある呼び出し箇所、別のストレージバックエンドや描画経路、旧形式のまま保存されているデータなど）。
• インターフェース： エクスポートされた型、生成スキーマ、生成型、新しい動作と一致しなくなったドキュメント。

具体的な入力とイベントの順序を、実際の実装に沿って追跡します。主張の根拠を確かめるのに最も手早い方法であれば、対象を絞ったテストや最小限の再現コードを実行します。見慣れないパターンだけを根拠に、不具合と推測してはいけません。

指摘の基準

指摘には、次のすべてが必要です。

• 違反されている動作または不変条件。
• 正確なコード上の位置。
• 具体的なトリガーまたは実行経路。
• 観測可能な結果。
• 影響に見合った修正の方向性。

適切な確度の表現を使います。確認済みの不具合は明確に述べます。未解決の懸念には不確実であることを示し、不足している証拠を説明します。命名、書式、任意の堅牢化、個人的な設計の好みを、正確性に関する指摘として扱ってはいけません。

影響度と発生可能性に基づいて優先順位を付けます。

• Critical： 悪用可能なセキュリティ問題、回復不能なデータ損失、または広範な本番環境の停止。
• High： ユーザーに見える誤動作、認可の回避、または回復可能なデータ破損が起こる可能性が高い。
• Medium： 起こり得る境界条件、競合状態、または継続的な負荷のもとで実際に発生する障害。
• Low： 影響が小さい、限定的な正確性の問題。見た目だけの指摘は省きます。

報告

重大度の高い順に指摘から始めます。指摘ごとに、短いタイトル、ファイルと行番号、失敗するシナリオ、影響、修正の方向性を記載します。行範囲は必要最小限にしてください。

証拠に裏付けられた対処可能な不具合がなければ、その旨を伝えます。意味のある残存リスクや未テストの境界条件には触れてかまいませんが、レビューを徹底しているように見せるために指摘を捏造してはいけません。