w-review

指定された diff、ブランチ、PR、または作業ツリーと、そこで意図されている動作を使用してください。修正も依頼されていない限り、読み取り専用で作業してください。

1. 実装を評価する前に、トリガーと期待される結果を把握してください。テストを読んで、どの主張が実際に検証されているかを確認してください。
2. 対象範囲内のレビュー観点を確認してください。動作が変更された場合は、ドキュメントや README も対象に含めます。担当範囲を分けた読み取り専用の調査担当を 2～3 人起動してください。変更された動作、呼び出し元、失敗経路に注目してください。対象範囲外の観点は確認せず、その旨を記載してください。
3. 疑わしい不具合は、具体的な実行経路、失敗するケース、またはソースコード上の証拠で検証してください。見た目だけを根拠に、タイミングや脆弱性をでっち上げないでください。
4. 検証済みという主張を鵜呑みにせず、批判的に検討してください。影響の大きい順に、ファイル／行、発生条件、結果、最小限の有効な修正案を添えて指摘事項を並べてください。コードを確認しただけでは、テストの合格もマージの承認も証明できません。