inspect-perf

inspect-perf — セマンティックなパフォーマンスとリソース効率の監査

ドメイン評価基準

1. スコープと許容範囲のガードレール（無視する対象）

• 必須の対象スコープ：ユーザーは、明示的な対象パス（file、directory、またはsubsystem）を必ず指定する必要があります。対象スコープが指定されていない場合は、ただちにターンを終了してスコープを尋ね、推測に基づくリポジトリ全体のスキャンを禁止してください。
• セマンティックな負債とマイクロベンチマークの区別：分析対象は、構造的なアルゴリズム上のリスク、I/Oの増幅、リソースの保持に厳密に限定してください。サブマイクロ秒単位の命令最適化、コンパイラーのインライン化に関する細かな指摘、コールドパスでの時期尚早なキャッシュは無視してください。
• 判断の基準：パフォーマンスパターンは、references/performance-rubric.md のみに照らして評価してください。

2. 判断の分岐：[LOCAL-FIX] と [ARCHITECTURAL-REFACTOR]

• [LOCAL-FIX]（関数内での局所的な最適化）：アルゴリズム上の検索インデックス化（$O(1)$ の set/map）、ループ不変条件のループ外への移動、または単一のメソッド／ファイル内での文字列ビルダーへの置き換えです。振る舞いを保ったまま対応できる候補は /simplify-audit に振り分けてください。新たなクエリ制限の導入や結果の意味の変更には /changeset が必要です。
• [ARCHITECTURAL-REFACTOR]（システム全体に関わる構造的な改善）：直積結合を分割クエリ／DataLoader に分解すること、ネットワークI/Oをデータベーストランザクションから切り離すために Transactional Outbox を抽出すること、ワーカースレッドへのオフロード、または上限のある分散キャッシュの導入です。改善は /changeset に振り分けてください。

正式な出力形式

# Performance Audit Dossier: <Target Scope>

## 1. Executive Summary
- **Target Inspected**: `<directory_or_file_path>`
- **Health Rating**: <OPTIMAL | LOCALIZED_BOTTLENECK | CRITICAL_DEGRADATION>
- **Primary Bottleneck**: <Single-sentence summary of highest-latency or highest-risk resource hazard>

## 2. Load-Bearing Defect Catalog
### [<CRITICAL | MAJOR>] [<LOCAL-FIX | ARCHITECTURAL-REFACTOR>] <Dimension>: `<Target Symbol / Query>`
- **Offending Code**: [<file>#L<N>](file:///path/to/file#L<N>)
- **Violated Rubric**: [<spec_or_dimension>](references/performance-rubric.md#anchor)
- **Smell**: <Observable bottleneck, complexity multiplier, or resource leak description>
- **Action**: <[LOCAL-FIX] Local optimization OR [ARCHITECTURAL-REFACTOR] Separation / batching path>

*(Emit 'No load-bearing performance defects observed across rubric dimensions' if clean)*

振り分け

• 動作の等価性を監査できる、ローカルなインデックス化またはビルダーの変更 →（/simplify-audit 経由）。
• 結果の意味の変更、またはシステム全体に関わる分割クエリ、アウトボックス、コネクションプール、スレッドプールのリファクタリング →（/changeset 経由）。

実行プロトコル

1. 受付とスコープ確認：

   • 対象スコープ（file、directory、またはsubsystem）を受け取ります。
   • スコープ確認を徹底：明示的なスコープが指定されていない場合は、ただちにターンを終了し、ユーザーに次のように尋ねてください："「/inspect-perf を使用する際は、確認対象の範囲（ファイル、ディレクトリ、またはサブシステム）を明示してください。」"
   • references/performance-rubric.md を読み、評価の基準とします。

2. 規模に応じた実践的な監査：

   • ターン内で実行（10ファイル未満、またはまとまりのあるモジュール）：評価基準の各項目に照らして、そのターン内でコードを直接監査します。
   • サブエージェントへの分割委任（複数パッケージにまたがる広範なサブシステム）：スライスの座標、特定したアンカー、ドメイン評価基準、出力形式を設定して、research サブエージェントを2～3個起動します（役割：Performance Inspector (<Slice>)）。
   • セクション1のガードレールを徹底：ホットパス以外でのマイクロベンチマークのノイズは無視し、すべての指摘を [LOCAL-FIX] または [ARCHITECTURAL-REFACTOR] のいずれかに明確に分類します。

3. 統合とターン終了の確認：

   • 指摘事項を正式な出力形式にまとめます。
   • 確定的な健全性評価（OPTIMAL、LOCALIZED_BOTTLENECK、CRITICAL_DEGRADATION）を割り当てます。
   • 完成した報告書を会話に提示し、ただちにターンを終了します。