パイプライン全体で参照されるエスカレーション判断基準。Findingを3段階に分類し、自律対応かユーザー確認かを決定する。
パイプラインの全フェーズ（設計・実装・テスト・レビュー）で発見された問題（Finding）を分類し、対応方針を決定する。
/escalation classify <finding の説明>
指定された Finding を以下の3段階に分類し、分類理由と推奨アクションを出力する。
以下に該当する場合、作業を停止してユーザーに確認する。自律的に修正してはならない。
| 基準 | 理由 |
|---|---|
| 外部API / DBスキーマの選定・変更 | ドメイン知識とビジネス要件に依存 |
| 認証・認可フローの設計判断 | セキュリティポリシーに直結 |
| 公開インターフェースの破壊的変更 | 下流の利用者に影響 |
| 設計書に記載のない新規要件の発見 | スコープ外の判断はユーザーが行う |
| 同一問題の修正が3回連続失敗 | アプローチ自体の見直しが必要 |
| 検証ゲートが最大リトライ後もパスしない | 根本原因がスキルの範囲外の可能性 |
| ライセンス・法的制約に関わる変更 | 法務判断が必要 |
| パフォーマンス特性を大きく変える設計変更 | ユーザーのトレードオフ判断が必要 |
以下に該当する場合、自律的に修正し、完了後にユーザーに報告する。
| 基準 | 例 |
|---|---|
| S-Critical / S-High の定型修正パターン | unwrap() → ? 変換、SQL injection → .bind() |
| 設計書の軽微な矛盾修正 | 型名の揺れ、引数順の不一致、フィールド名の統一 |
| テストで発見されたバグの修正 | テスト失敗の原因となるロジックバグ |
| エッジケーステストの追加 | 境界値・空入力・NaN 等のテスト補強 |
| Missing（仕様にあるが未実装）の実装 | spec-check で検出された未実装項目 |
| Constraint 違反の修正 | アーキテクチャ制約違反、データ形式順序違反 等 |
報告フォーマット:
[自律対応] {分類} | {対象ファイル:行番号}
内容: {何を修正したか}
理由: {なぜ自律対応が妥当か}
検証: {修正後の検証結果（テスト通過等）}
以下に該当する場合、自律的に修正し、報告は不要。
| 基準 |
|---|
| S-Medium / S-Low / Info レベルの修正 |
| フォーマット修正、import 整理 |
| ドキュメントコメントの追加・修正 |
| 既存テストの軽微なリファクタリング（振る舞い変更なし） |
| lint / clippy 警告の解消 |
CLAUDE.md に ## Escalation Overrides セクションがある場合、そのルールを優先適用する。
## Escalation Overrides
- promote: S-High の修正でも DB 関連は必ずエスカレーション
- demote: ドキュメント修正は全て Tier 3（報告不要）
╔══════════════════════════════════════╗
║ エスカレーション分類結果 ║
╚══════════════════════════════════════╝
Finding: {入力された Finding の要約}
分類: Tier {1|2|3} — {必ずエスカレーション|自律対応+事後報告|自律対応(報告不要)}
該当基準: {マッチした基準}
推奨アクション:
Tier 1 → ユーザーに以下を提示して判断を仰ぐ: {具体的な質問}
Tier 2 → 以下の修正を実行し事後報告: {修正内容}
Tier 3 → 以下の修正を実行: {修正内容}
Override 適用: {あり — ルール名 / なし}
パイプライン実行中、Tier 1 の Finding は PIPELINE-STATE.md のエスカレーションキューに蓄積される。
蓄積タイミング:
ユーザーの回答後:
resolved に更新dismissed に更新