意図的な設計判断をレビュアーが誤検知(FP)しないよう、全 review-*.md に
{report:coder-decisions.md} の参照セクションを追加。ただし設計判断自体の
妥当性も評価する指示を含め、盲目的な通過を防ぐ。
28 lines
1.5 KiB
Markdown
28 lines
1.5 KiB
Markdown
要件充足の観点から変更をレビューしてください。
|
||
|
||
**レビュー観点:**
|
||
- 要求された各要件が実装されているか
|
||
- 暗黙の要求(当然期待される動作)が満たされているか
|
||
- 要求にない変更(スコープクリープ)が紛れていないか
|
||
- 部分実装や未実装がないか
|
||
|
||
|
||
**設計判断の参照:**
|
||
{report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
|
||
- 記録された意図的な判断は FP として指摘しない
|
||
- ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
|
||
|
||
**前回指摘の追跡(必須):**
|
||
- まず「Previous Response」から前回の open findings を抽出する
|
||
- 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved` で判定する
|
||
- `persists` と判定する場合は、未解決である根拠(ファイル/行)を必ず示す
|
||
|
||
## 判定手順
|
||
|
||
1. レビュー対象レポート・タスクから要件を1つずつ抽出する
|
||
2. 各要件について、実装されたコード(ファイル:行)を特定する
|
||
3. コードが要件を満たしていることを確認する
|
||
4. 要求にない変更がないかチェックする
|
||
5. 検出した問題ごとに、Policy のスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
|
||
6. ブロッキング問題(`new` または `persists`)が1件でもあれば REJECT と判定する
|