classifying-review-findings

レビュー指摘の分類

重大度カテゴリ

絵文字	カテゴリ	基準
❌	CRITICAL	動作停止、クラッシュ、データの漏えい、または要件違反につながるもの
⚠️	IMPORTANT	エラーハンドリングの欠如、未処理のエッジケース、バグを引き起こす可能性があるもの
♻️	DEBT	パターンの重複、規約違反、6 か月以内の再作業が必要なもの
🎨	SUGGESTED	セキュリティを測定可能な形で向上させる、複雑さを 3 以上削減する、バグのクラスを排除するもの
❓	QUESTION	人間の知識が必要なもの。不明確な要件、意図、またはシステム間の競合

各指摘には必ず絵文字とテキストを組み合わせた形式を使用してください（重大度が複数該当する場合は、最も高いものを使用します：❌ > ⚠️ > ♻️ > 🎨 > ❓）。

分類する前に

次の 3 点をすべて確認してください。

1. 誤った動作につながる実行経路をたどれますか？
2. これは別の場所（エラーバウンダリ、ミドルウェア、バリデーター）で処理されていますか？
3. フレームワークの動作とプログラミング言語のセマンティクスを確実に理解していますか？

いずれかの答えが「いいえ」または「不明」なら、指摘として分類しないでください。

有効な指摘ではないもの（却下）

• 称賛（「優れた実装です」）
• 曖昧な提案（「もっと簡潔にできるかもしれません」）
• 適用されている標準に基づかないスタイルの好み
• 実際に誤解を招く場合を除く、命名に関する細かな指摘
• PR のメタデータに関する問題（タイトル、説明、テスト計画）。これらはサマリースキルで扱い、ここでは分類しません
• CI が成功している既存依存関係に対する Renovate/Dependabot のマイナー／パッチ更新。これらは通常の Stage 5 モニタリングであり、レビュー対象の指摘ではありません

改善提案（🎨）の基準

測定可能な価値をもたらす改善だけを提案してください。

1. セキュリティの向上 - 脆弱性のクラス全体（SQL インジェクション、XSS など）を排除する
2. 複雑さの削減 - 循環的複雑度を 3 以上削減する、またはネストレベルを 1 段階減らす
3. バグの予防 - バグのカテゴリ全体を発生不能にする（型安全性、null 安全性）
4. パフォーマンスの向上 - O(n²) を O(n) にする、または N+1 クエリを排除する（根拠を提示する）

具体的な指標を示してください。

• ❌ 「もっと簡潔にできるかもしれません」
• ✅ 「循環的複雑度は 12 です。検証ロジックを切り出せば 6 に削減できます」

改善を測定できない場合は、提案しないでください。