レビュー規範チェックリスト

code-reviewer(レビュー時)と techlead(設計時の事前つぶし)が必ず参照するチェックリスト。

運用ルール(自己成長):

• /review で新しい不具合パターン(一般化可能で再発しうるもの)を見つけたら、末尾の「追記ログ」に1行追記する。
• /retro が定期的に追記ログを整理し、セクションへの昇格・重複統合・古い項目の削除を行う。
• プロジェクト固有すぎる項目は各プロジェクトの CLAUDE.md へ移す。

軽量モデル製コードの頻出欠陥(最優先で確認)

• [ ] 存在しないAPI・メソッドの捏造(シグネチャを実際のSDK・コードベースと照合したか)
• [ ] 設計書スコープ外の変更(無関係ファイルの修正・余計なリファクタ・依存の追加)
• [ ] 既存の類似実装・ユーティリティの無視(車輪の再発明・重複実装)
• [ ] テスト・ビルドを実際に実行した形跡があるか(「動くはず」の宣言を信用しない)
• [ ] ハードコードされたパス・値・ダミーデータの残置
• [ ] エラー処理の極端(全省略 or 過剰なtry/catch)。検証はシステム境界のみの方針に合っているか

正しさ(一般)

• [ ] null/optional・空配列・空文字の境界
• [ ] 非同期処理の競合・キャンセル・再入(連打、画面離脱、二重実行)
• [ ] 状態の単一情報源(同じ状態を2箇所で保持していないか)
• [ ] 冪等性(リトライ・再実行で壊れないか)
• [ ] 時刻・タイムゾーン・ロケール依存の暗黙前提

Swift / iOS

• [ ] メインスレッド外でのUI更新(@MainActor / DispatchQueue.main)
• [ ] CloudKit・ネットワークエラーの分類(リトライ可能/不可能の区別)とオフライン時挙動
• [ ] クロージャの [weak self]、Task/Combine 購読の保持とキャンセル
• [ ] Info.plist / entitlements / capability の変更が設計書に明記されているか

セキュリティ

• [ ] 機密情報(APIキー・トークン)のコード・ログ・KBへの混入
• [ ] 外部入力の検証がシステム境界で行われているか
• [ ] 危険なシェル実行・パス結合(トラバーサル)

追記ログ