review-change

変更のレビュー

実装者として作業を擁護するのではなく、独立したレビュアーとして差分をレビューします。

プロセス

1. レビュー範囲を確定する

レビュー対象となる固定点または差分を特定します。

• ユーザーが指定したブランチ、コミット、タグ、またはマージベース。
• 固定点が指定されていない場合は、現在の作業ツリー。
• パッチファイルまたは貼り付けられた差分。

範囲が曖昧な場合は、レビューを始める前に固定点を確認してください。

2. レビューに必要な情報を集める

レビュアーが必要とするコンテキストだけを集めます。

• 差分。
• タスクの概要、計画、Issue、PRD、またはユーザーの依頼（入手可能な場合）。
• 関連するテストと検証結果。
• 必要に応じて、プロジェクトの規約や周辺の実装パターン。

実装者の説明を証拠として扱わないでください。差分とソースコードに基づいて確認してください。

3. 観点を選ぶ

各観点は、別々のレビュアーが担当します。各観点の確認事項、入力情報、対象外事項、必要な証拠については、lenses.md を読んでください。

• 単一スライス： 正確性とテスト品質。
• 高リスクのスライス（公開される契約、永続化データ、共有モジュール、本番環境の処理経路）、または完成した機能： 設計適合性とシンプルさを追加します。完成した機能の場合は、各スライスが個別には適合していても、組み合わせると方向性がずれる可能性があるため、ブランチ全体を対象に設計適合性を確認してください。
• セキュリティ： 差分が認証、認可、信頼できない入力、またはシークレットに関わる場合は必ず確認します。

ユーザーまたは計画で別の観点が指定されている場合は、それに従ってください。

4. 新しいコンテキストでレビュアーを実行する

観点ごとに 1 つのサブエージェントを並列で起動し、実装者の説明や他の観点の影響を受けないようにします。各ブリーフには、差分の範囲、計画または依頼、lenses.md に記載された観点の定義、以下の評価ルールを含めます。安心させる回答ではなく、指摘事項を求めてください。

Review this change through the <lens> lens only. Report findings inside that lens, each with file and line, the concrete trigger, and the evidence the lens requires. Mark anything you could not back with that evidence as unconfirmed. Rate each finding with the supplied "Rate Blocker or Hardening" rules. Do not summarize the change.

TDD が必須だった場合、テスト品質レビュアーは、利用可能な RED（実装前に失敗するテスト）の証拠も確認します。証拠がない場合、最終的な差分から推測するのではなく、不明として報告してください。

サブエージェントを利用できない場合は、各観点について、その都度差分を最初から読み直して順番にレビューします。

5. 報告前に確認する

観点間で重複する指摘をまとめます。その後、Blocker の候補をすべて /verification-evidence で自分自身が確認します。可能であれば再現し、難しい場合は処理の流れを行ごとに追跡してください。確認しても成立しない指摘は報告せず、その件数を 1 行で「未確認の指摘を N 件省略」と記載します。ユーザーは必要に応じて、それらの指摘を求めることができます。

検証または CI が失敗している場合は、差分が原因の失敗と、環境またはインフラに起因する失敗を区別してください。

6. Blocker または Hardening の評価

レベルは 2 つのみです。Blocker（マージ前に修正）と Hardening（残存リスクに記録し、修正は要求しない）です。Hardening の項目には、具体的なトリガーも必要です。つまり、実際のどのような条件下で、誰が何をするのかを示します。「理論上は競合する可能性がある」や「誰かが後で何かをした場合」はトリガーではありません。その項目は削除してください。

トリガーは 1 文で記述し、製品がサポートするアクションのみを使ってください。その経路が実行されるたびに発生する欠陥は、以下の影響度の基準を満たす限り、到達可能性をこれ以上分析せずに Blocker とします。何も到達しない経路は、経路とはいえません。このセクションの残りは、トリガーが実行順序、偶然の一致、または特定の入力に依存する場合にのみ適用されます。

そのようなケースで、Blocker のトリガーは誰かが仕組まなくても発生するものでなければなりません。また、その主張の根拠となる証拠、つまり依拠するトラフィックパターン、デプロイモデル、または操作と、それをリポジトリ、設定、ドキュメントのどこで確認したかを明記してください。一般的にサポートされている操作を挙げるだけでは、証拠になりません。ほとんどすべての製品はデプロイ、再起動、再試行、キャッシュの破棄を行います。デプロイに関する前提に依存する場合は Hardening とし、未解決の疑問を「未解決の質問」に記載してください。

影響度は両端の判定に関わります。トリガーが自然に発生しても、最悪の結果が見た目上の問題、または回復可能な問題にとどまる場合は Hardening です。仕組まれたトリガーであっても、権限境界を越えるか、データが回復不能な形で失われる場合は Blocker です。

リポジトリ、設定、またはドキュメントで、信頼できない相手が脅威モデルに含まれている場合（公開されたルート、認証境界、文書化されたテナント分離など）、その相手は通常のアクターです。細工した入力は通常の操作であり、問うべきなのは、実際に取得可能な権限でその経路に到達できるかどうかだけです。そのような公開状態を示すものがなければ、Hardening とし、疑問を「未解決の質問」に記載してください。

テスト可能性は判定基準ではありません。決意のあるレビュー担当者なら、誰も実際には遭遇しないようなシナリオも含め、ほぼあらゆるシナリオをモックして失敗するテストを作れます。

各指摘を、到達可能性、影響度、証拠に照らして個別に評価してください。すべての指摘が同じ評価になることもあります。評価の分布を調整するために、項目を格上げしたり格下げしたりしないでください。

7. まず指摘事項を報告する

「指摘事項」には Blocker のみを記載し、Hardening は「残存リスク」に記載します。各 Blocker には以下を含めてください。

• ファイルと行番号（分かる場合）。
• 問題点。
• 具体的なトリガー（誰が何をすると発生するか）。
• 推奨する修正または検証方法。

Blocker がない場合は、変更に問題がないことを明記し、トリガーのある Hardening 項目のみを「残存リスク」に記載してください。レビューを正当化するために Blocker を作り出してはいけません。

出力

次の構成を使用してください。

## Findings

## Open Questions

## Residual Risk (triggered Hardening only; end with the omitted-unconfirmed count)

## Validation Notes

空のセクションは省略してください。ただし、「Blocker なし」が主な結果である場合を除きます。

完了条件

選択したすべての観点から報告があり、報告されたすべての Blocker が再実行または再追跡によって確認済みで、具体的なトリガーと観点ごとの根拠が示され、すべての Hardening 項目に具体的なトリガーが記載され、未確認の指摘が省略件数としてのみ示されている場合、レビューは完了です。

Blocker がなければ、変更に問題はありません。そこで終了し、レビュー済みのコードを再度確認するために新たなレビューを始めないでください。