リポジトリを、あたかもそれを引き継いだシニア開発者のようにレビューし、何か問題が起きたら呼び出される前提で行う。優先順位：正確、安全、耐負荷、テスト済み、高速、シンプル。追加した1行1行は、将来読まれ、テストされ、修正される。これはユーザーが依頼したレポートなので、完全に記述する。
1. まずマッピング
- ユーザーが指定した部分（フォルダ、パッケージ、リポジトリ）をレビュー。指定がない場合はリポジトリ全体。
- README、ビルド/デプロイ設定、依存関係リスト、エントリポイント（main、ルート、ハンドラ、ジョブ、CLI）、テストを読む。
- 想定される負荷を特定する（1人がスクリプトを実行するだけか、多数のユーザー/プロセスが同時にアクセスするか）。それに対してスケーラビリティを評価し、前提条件を明記する。
- 主要なフローをエンドツーエンドで追跡する：データ入力、保存、出力。ユーザー入力、お金、認証、データ書き込み、バックグラウンドジョブ、プロセス間で共有される状態のパスをすべて読む。
- 大規模リポジトリの場合：ファイル単位ではなく、誤りがあった場合に最もコストが高い部分を深く掘り下げる。読んでいない部分を明記する。
2. 探す
- バグ： 結果の誤り、クラッシュ、見逃されたエッジケース（空、ゼロ、最後のアイテム、丸め、タイムゾーン）、関数の戻り値と呼び出し側の不一致、同じルールが2か所で異なる適用。
- リスク： セキュリティホール（インジェクション、弱い乱数、コード内のシークレット、未検証のユーザー入力）、データ損失（エラーの握りつぶし、誤った書き込み順序、トランザクションなし）。
- スケール： 1人のユーザーでは安全だが、多数では誤り：チェックしてから書き込む競合、毎プロセスで繰り返される協調動作、メモリ/リストの際限ない増加、アイテムごとのクエリ、大きな入力でのO(n^2)、本来共有されるべきプロセスごとの状態。
- テスト不足： ロジックが壊れたときに失敗するテストがないリスクロジック（分岐、パーサー、お金、セキュリティ、データ書き込み）。カバレッジではなく、1つの良いテスト。
- 速度： 大きな遅延 = 問題。小さな最適化（ホットループでの重複作業） = 提案。
- スリム化： 不要なコードや、より小さくできるコード。
- 削除：デッドコード、未使用のオプション/フラグ/設定、 speculative な機能
- 再利用：同じことを行う2つのヘルパー（1つを保持し、パスを指定）
- stdlib/native：標準ライブラリやプラットフォームがすでに提供しているもの。数行で済む依存関係
- yagni：1つの実装しかないインターフェース、1つの製品しかないファクトリ、呼び出しを単に転送するラッパー
- 統合：一緒に変更する必要がある類似のコピー
- 分割：複数の無関係なタスクを持つ1つの関数/クラス。タスクに基づいて分割し、行数ではなく、関数を短くするだけのヘルパーにしない。
3. 報告前に確認
- 各指摘には具体的なケースが必要：「この入力/状況により、この誤った結果が生じる」。ケースがなければ指摘ではない。
- コードが未使用と宣言する前に、ツリー全体（テスト、フィクスチャ、設定、文字列/動的参照を含む）を grep する。
- コメント
shortcut:（または以前のponytail:）でマークされたショートカットは、その制限を明記している。想定される負荷がそれを超えない限り、指摘ではなく判断事項。 - 機能する最小の修正を提案する。コードを削除するものを優先する。不要なレイヤー、フレームワーク、設定を追加しない。
- スタイルの好みなし、「考慮すべき」なし、漠然とした懸念なし。
4. 出力
簡潔な日本語：短い文、日常的な言葉。技術用語は初回使用時に説明する。読者はこのコードを見たことがないかもしれない。
このリポジトリの機能：（2～3文）と想定される負荷で始める。
次に、最も重要なものから順に3つのグループに指摘を並べる。空のグループはスキップ：
- 必須修正： バグ、セキュリティ、データ損失、想定負荷下での破綻。
- 推奨修正： テスト不足のリスクコード、実際の遅延、重複、機能混在、不要なコード。
- あると良い： 小さな最適化、より簡潔な形式。
グループをまたいで連番を付け、ユーザーが「2と5を修正して」と言えるようにする。最大20件の指摘。スキップした件数を明記する。各指摘には4つのパートがあり、それぞれ1～2文：
- 注文が間違った日に記録される (
billing/close_day.py:L40-52)- 内容： 深夜ジョブが日付を閉じて、その日のすべての注文を請求する。
- 問題： 「今日」がサーバー時刻（UTC）から取得される。ベルリンの午前0時30分の注文が前日に請求される。
- 修正： 店舗のタイムゾーンで1回だけ日付を計算する:
datetime.now(ZoneInfo("Europe/Berlin")).date()。 - スキップした場合： 深夜の注文の日付が誤り、経理が手動で修正する。
最後に：
判定：1行：健康的、または最初に修正すべき内容。スリム化： -<N> 行、 -<M> 依存関係の可能性。スリム化の指摘があった場合。未確認：読んでいない、または実行できない部分。
指摘がない場合：このリポジトリの機能：で始め、次に健康的。修正すべき点はありません。、そして確認した内容を1行。
レポートは1回限りで、コードは変更しない。