ponytail-audit

リポジトリ全体を、引き継いだばかりで、障害時には呼び出されるシニア開発者の視点で監査してください。重要度の順は、正確性、安全性、高負荷への耐性、テスト済みであること、速度、簡潔さです。簡潔さも重要です。コードが1行増えるたびに、後で読み、テストし、修正しなければなりません。これはユーザーが依頼したレポートなので、すべて報告してください。

1. まず全体を把握する

• ユーザーが指定した対象を監査します。フォルダー、パッケージ、またはリポジトリ全体です。 指定がない場合は、リポジトリ全体を対象とします。
• README、デプロイとビルドの設定、依存関係の一覧、エントリーポイント（メイン、ルート、ハンドラー、ジョブ、CLI コマンド）、テストを読みます。
• 想定される負荷を確認します。スクリプトを1人で実行するのか、複数のユーザーやプロセスが同時に使うのかを確認します。その規模を基準に評価し、想定した負荷も明記します。
• 主要な処理の流れを端から端まで追います。データの入力元、保存先、出力先を確認します。ユーザー入力、金銭、認証、データの書き込み、バックグラウンドジョブ、プロセス間で共有されるものなど、該当する経路をすべて読みます。
• 大規模なリポジトリでは、ファイルごとではなく、誤りが起きたときの損失が最も大きい箇所を詳しく調べます。読まなかった部分を明記します。

2. 確認する項目

1. **バグ：**誤った結果、クラッシュ、見落とされた境界ケース（空、ゼロ、最後の項目、丸め、タイムゾーン）、関数の戻り値に対する呼び出し元の認識違い、同じルールが場所によって異なる方法で適用されていること。
2. **リスク：**セキュリティ上の穴（インジェクション、弱い乱数、コード内のシークレット、ユーザー入力へのチェック不足）、データ損失（エラーの握りつぶし、誤った順序での書き込み、トランザクションの欠如）。
3. **規模：**1人で使うには問題なくても、複数人では問題になる点を確認します。チェック後の書き込みの競合、全プロセスで同じ処理を行うこと、増え続けるメモリやリスト、項目ごとにクエリを実行すること、大きな入力に対する O(n^2)、プロセスごとの状態を共有する必要があることなどです。
4. **不足しているテスト：**テストが壊れたときに失敗する、リスクの高いロジック（分岐、パーサー、金銭、セキュリティ、データ書き込みなど）のテストがないこと。カバレッジではなく、適切なテストを1つ挙げます。
5. **速度：**大幅な速度低下は問題として報告します。小さな改善（頻繁に実行されるループ内で繰り返される処理）は提案として扱います。ソフトウェアによっては、ミリ秒単位の差も重要です。
6. **簡潔さ：**存在すべきでないコード、またはもっと小さくできるコード。
   • 削除：デッドコード、未使用のオプション、フラグ、設定、先を見越しすぎた機能
   • 再利用：同じ処理をするヘルパーが2つある場合（1つに統合し、どちらを使うかを明確にする）
   • 標準ライブラリ／ネイティブ機能：標準ライブラリやプラットフォームに既存の機能がある場合、少数のコード行やプラットフォームの機能で実現できる処理を依存関係が担っている場合
   • YAGNI：実装が1つしかないインターフェース、生成物が1つしかないファクトリー、呼び出しを中継するだけのラッパー
   • 統合：変更時に一緒に変更しなければならない、よく似たコード
   • 分割：複数の無関係な役割を担い、読みづらくテストしにくい関数やクラス。行数ではなく役割ごとに分割し、関数を短くするだけのヘルパーは作らないでください。

3. 報告前に確認する

• すべての指摘に具体的なケースが必要です。「この入力または状況では、こうした誤った結果になる」と説明してください。具体例がなければ、指摘として報告しません。
• コードが未使用だと判断する前に、テスト、フィクスチャ、設定、文字列参照や動的参照も含め、リポジトリ全体を grep で検索してください。
• 制限を明記した shortcut:（または旧形式の ponytail:）コメントがある近道は、想定される負荷がすでにその制限を超えていない限り、指摘ではなく意図的な判断として扱います。
• 有効な最小限の修正を提案します。コードを削除する修正を優先してください。問題の解決に不要なレイヤー、フレームワーク、設定を追加してはいけません。
• 好みの問題や「検討してください」といった提案、漠然とした懸念は報告しません。

4. 出力

ごく簡単な英語で書きます。短い文と、日常的な単語を使います。技術用語は、初めて使うときに説明します。読者はこのコードを見たことがないかもしれません。

最初に、What this repo does: に続けて2～3文で説明し、想定した負荷も記載します。

次に、重要度の高い順に3つのグループで指摘事項を示します。該当する指摘がないグループは省略します。

• 必ず修正: バグ、セキュリティ問題、データ損失、想定負荷での動作不良。
• 修正を推奨: テストのないリスクのあるコード、実際の遅さ、重複、複数の役割を担う関数、存在すべきでないコード。
• できれば修正: わずかな高速化、より短くできる記述。

ユーザーが「2と5を修正して」と言えるように、すべてのグループを通して指摘事項に番号を付けます。指摘事項は最大20件です。より軽微な指摘を省いた場合は、その件数を記載します。 各指摘事項には次の4項目をすべて含め、それぞれ1～2文で簡潔に説明します。

2. 注文日が誤った日になります（billing/close_day.py:L40-52）
   • これは何か: このジョブは午前0時にその日の処理を締め、当日の注文すべてを請求します。
   • 問題: UTCで動作するサーバーの時計から「今日」を取得しています。ベルリンで午前0時30分に行われた注文は、前日分として請求されます。
   • 修正: 店舗のタイムゾーンを使って日付を一度だけ計算します。 datetime.now(ZoneInfo("Europe/Berlin")).date()。1行の変更で、ほかは何も変わりません。
   • 修正しない場合: 遅い時間の注文の日付が誤り、経理担当者が手作業で修正することになります。

最後に、次の項目を記載します。

• Verdict: 1行で、健全であること、または最初に修正すべき内容を示します。
• Lean: -<N> lines, -<M> dependencies possible. 該当する削減項目がある場合に記載します。
• Not checked: 読んでいない、または実行できなかった箇所を記載します。

指摘事項がない場合は、What this repo does: に続けて Healthy. Nothing to fix. と記載し、確認した内容を1行で説明します。

1回限りのレポートとし、コードは変更しません。