self-reviewlisted

現在の diff の自己レビューを実施し、レポートを `docs/reports/` に書く。 ## レビュースコープ — diff 品質のみ diff そのものだけにフォーカスする。スペック適合性・テストカバレッジ・ドキュメントドリフトは評価しない（それぞれ `/verify` と `/test` の担当）。 テスト・静的解析・フォーマッター・リンター・型チェック・スペック適合検証・ドキュメントドリフト���ェック・広範な無関係のリポジトリ監査は実行しない。`git diff` とターゲットを絞ったファイル読み込みのみを使用する。 diff を以下の観点で評価する： 1. **不要な変更** — 無関係な変更、フォーマットのみの diff、意図しない追加 2. **命名** — 明確さ、周辺コードとの一貫性、grep しやすさ 3. **可読性** — 関数の長さ、ネストの深さ、コメントの質 4. **タイポとコピペミス** 5. **null 安全性と防御的チェック** — 境界での欠落したガード 6. **デバッグコード** — 残ったログ出力、print、TODOマーカー、コメントアウトコード 7. **シークレットと認証情報** — ハードコードされたキー・トークン・パスワード 8. **例外処理** — 握りつぶされたエラー、汎用 catch、欠落したエラーパス 9. **セキュリティ** — インジェクションリスク、XSS、CSRF、安全でないデシリアライゼーション、パストラバーサル 10. **保守性** — 密結合、隠れた副作用、マジックナンバー ## レビュー手順 1. アクティブプランと変更ファイルを `git diff` で確認する。 2. 直感よりも diff とリポジトリ契約からのエビデンスを優先する。 3. [template.md](template.md) を使ってレポートに所見を記録する。 4. ブロッキングな問題とフォローアップ提案を分ける。 5. 所見が技術的負債や既知のショートカットを表す場合、`docs/tech-debt/` に追記する。 6. 所見がない場合は、何を確認したか・どのエビデンスがその結論を支持するかを述べる。 ## 出力 - `docs/reports/self-review-<date>-<slug>.md` - 深刻度タグ付きの所見 - マージ/非マージの推奨 - 技術的負債エントリ（必要な場合）