Eld Predict Impact

---
name: eld-predict-impact
description: |
  ELD（Evidence-Loop Development）のPredict（予測）フェーズスキル。
  変更の影響を因果タイプで分類し、段階化戦略と停止条件を確定する。
  「賢く動く」よりも「壊さずに収束する」を優先。
  使用タイミング: (1) 実装前の影響分析、(2) 「影響予測して」「段階化計画を立てて」、
  (3) Phase 2: Designで変更計画を策定する時、(4) 複雑な変更前のリスク評価
---

# ELD Predict Impact

変更の影響を事前に分類・評価し、安全な変更計画を策定する。

## 目的

- **「壊さずに収束する」を最優先**: 賢く動くよりも安全に進める
- 変更の影響を事前に分類・評価
- 安全上限を持った自律編集の設計
- 停止条件の明確化

## 因果タイプ分類

変更の影響を5つのタイプで分類する：

| タイプ | 説明 | リスク | 対策 |
|--------|------|--------|------|
| **互換性** | API/スキーマの破壊 | High | 段階リリース、deprecation |
| **性能** | レスポンスタイム、スループット | Medium | ベンチマーク、負荷テスト |
| **信頼性** | 障害耐性、復旧時間 | High | フェイルセーフ、Circuit Breaker |
| **セキュリティ** | 認証/認可、データ保護 | Critical | セキュリティレビュー |
| **可観測性** | ログ、メトリクス、トレース | Low | 監視設定の確認 |

### リスクマトリクス

```
            影響範囲
         狭い     広い
発   低  [Low]   [Medium]
生
確   高  [Medium] [High/Critical]
率
```

## 影響予測プロセス

### Step 1: 変更スコープの特定

変更対象を明確化する：

```yaml
change_scope:
  target_files:
    - path: <変更対象ファイル>
      change_type: modify | add | delete
      symbols: [<変更するシンボル>]

  related_laws:
    - <関連するLaw ID>

  related_terms:
    - <関連するTerm ID>
```

### Step 2: 直接影響の分析

このファイル・モジュールの変更による直接的な影響：

```yaml
direct_impact:
  - change: <変更内容>
    causal_type: 互換性 | 性能 | 信頼性 | セキュリティ | 可観測性
    risk: Low | Medium | High | Critical
    affected_components: [<影響を受けるコンポーネント>]
    mitigation: <リスク緩和策>
```

### Step 3: 間接影響の分析

依存先への伝播を追跡：

```yaml
indirect_impact:
  - dependent: <依存先ファイル/モジュール>
    impact_type: <影響内容>
    risk: Low | Medium | High | Critical
    verification: <確認方法（テスト名等）>
```

### Step 4: unknown（未確認）の特定

静的に追跡困難な影響を明示：

```yaml
unknown_impacts:
  - description: <追跡困難な理由>
    possible_risk: <潜在的リスク>
    investigation: <調査方法>
```

**よくあるunknown**:
- DI/IoC経由の呼び出し
- 設定ファイルからの参照
- コード生成による参照
- リフレクションによる呼び出し
- 動的インポート

## 段階化戦略

### 危険度に応じた段階化

```
危険度:    Low → Medium → High → Critical
段階数:     1      2-3      3-5     5+
```

### 段階化の原則

1. **最小単位で変更**: 1ステップ = 1概念の変更
2. **即時検証**: 各ステップ後に静的診断 + テスト
3. **ロールバック可能**: 各ステップで戻せる状態を維持
4. **観測可能**: 各ステップの成功/失敗が検証可能

### 段階化計画テンプレート

```markdown
## 段階化計画

### Step 1: <ステップ名>
- **変更内容**: <具体的な変更>
- **因果タイプ**: <互換性/性能/信頼性/セキュリティ/可観測性>
- **検証方法**: <静的診断/テスト名>
- **成功条件**: <このステップの完了条件>
- **ロールバック**: <戻し方>

### Step 2: <ステップ名>
...

### Step N: 統合検証
- **変更内容**: 全体の統合テスト
- **検証方法**: <統合テスト名>
- **成功条件**: <全体の完了条件>
```

---

## 品質優先原則（Superpowers統合）

### 核心原則

1. **Epistemic Humility**: 推測を事実として扱わない。`unknown`と言う勇気を持つ
2. **Evidence First**: 結論ではなく因果と証拠を中心にする
3. **Minimal Change**: 最小単位で変更し、即時検証する
4. **Grounded Laws**: Lawは検証可能・観測可能でなければならない
5. **Source of Truth**: 真実は常に現在のコード。要約はインデックス

### 「速さより質」の実践

- 要件の曖昧さによる手戻りを根本から排除
- テストなし実装を許さない
- 観測不能な変更を防ぐ

---

## 完了条件

- [ ] 因果タイプが正確に分類されている
- [ ] 段階化戦略が明確に定義されている
- [ ] 各ステップの停止条件が設定されている
- [ ] 影響範囲が予測されている
- [ ] Evidence収集計画が立案されている

---

## 停止条件

### 標準停止条件

以下が発生したら**即座に停止**し、追加計測またはスコープ縮小：

#### 1. 予測と現実の継続的乖離
- 想定外のテスト失敗が**3回以上**
- 想定外の依存関係が発見された
- 影響範囲が当初の予測を**50%以上**超過

#### 2. 観測不能な変更の増加
- 物差し（テスト/メトリクス）で検証できない変更が増える
- 「動いているはず」という推測が増える
- Evidence Ladderの低いレベル（L0のみ）が続く

#### 3. ロールバック線の崩壊
- 戻せない変更が発生
- 依存関係が複雑化して部分的な戻しが困難
- データマイグレーションが不可逆に

### カスタム停止条件

Issue Contractで定義した追加の停止条件：

```yaml
custom_stop_conditions:
  - condition: <条件>
    action: <停止時のアクション>
    owner: <責任者>
```

## 反射の選択

変更後の診断結果に応じて、適切な反射を選択：

### 機械反射（自動対応）

即座に修正可能な問題：
- 型エラー → 型を修正
- lint警告 → フォーマット修正
- 未使用変数 → 削除

### 設計反射（判断が必要）

方針決定が必要な問題：
- テスト失敗 → 原因分析と修正方針決定
- 依存関係の問題 → アーキテクチャ検討
- 性能劣化 → 最適化戦略の検討

### 停止反射（ユーザー確認）

停止条件に達した問題：
- セキュリティ脆弱性発見
- 重大な設計変更が必要
- スコープ外の影響が判明

```
軽微な問題 → 機械反射で即修正
中程度の問題 → 設計反射で方針決定
重大な問題 → 停止反射、ユーザーに確認
```

## 出力形式

### Impact Prediction Report

```markdown
# Impact Prediction Report

## Summary

| 項目 | 値 |
|------|-----|
| 変更対象 | <ファイル数> files, <シンボル数> symbols |
| 直接影響 | <件数> components |
| 間接影響 | <件数> dependents |
| 未確認(unknown) | <件数> items |
| リスクレベル | Low / Medium / High / Critical |
| 推奨段階数 | <N> steps |

---

## 変更スコープ

### 対象ファイル
| ファイル | 変更タイプ | 変更シンボル |
|----------|-----------|-------------|
| src/orders/service.ts | modify | `createOrder`, `validateOrder` |
| src/orders/types.ts | modify | `OrderInput` |

### 関連Law/Term
- **Laws**: LAW-pre-order-quantity, LAW-inv-stock-balance
- **Terms**: TERM-order-quantity, TERM-inventory-available

---

## 直接影響

| 変更 | 因果タイプ | リスク | 緩和策 |
|------|-----------|--------|--------|
| createOrder引数変更 | 互換性 | High | 段階リリース |
| バリデーション追加 | 信頼性 | Medium | テスト追加 |

---

## 間接影響

| 依存先 | 影響内容 | リスク | 検証方法 |
|--------|----------|--------|----------|
| src/api/orders.ts | 引数変更の伝播 | High | test_api_orders |
| src/batch/process.ts | 型変更の影響 | Medium | test_batch_process |

---

## 未確認(unknown)

| 説明 | 潜在リスク | 調査方法 |
|------|-----------|----------|
| DI経由の呼び出し | 実行時エラー | 実行時テスト |
| 設定ファイル参照 | 環境依存 | 設定レビュー |

---

## 段階化計画

### Step 1: 型定義の更新 (Low)
- **変更内容**: OrderInput型に新フィールド追加
- **因果タイプ**: 互換性
- **検証方法**: tsc --noEmit
- **成功条件**: 型エラーなし
- **ロールバック**: git checkout -- src/orders/types.ts

### Step 2: バリデーション追加 (Medium)
- **変更内容**: validateOrder関数の強化
- **因果タイプ**: 信頼性
- **検証方法**: npm test -- orders.validation
- **成功条件**: 全テストパス
- **ロールバック**: git checkout -- src/orders/validation.ts

### Step 3: サービス実装 (High)
- **変更内容**: createOrder関数の修正
- **因果タイプ**: 互換性 + 信頼性
- **検証方法**: npm test -- orders.service
- **成功条件**: 全テストパス + カバレッジ80%以上
- **ロールバック**: git checkout -- src/orders/service.ts

### Step 4: 統合検証 (High)
- **変更内容**: E2Eテスト実行
- **検証方法**: npm run test:e2e -- orders
- **成功条件**: 全E2Eテストパス
- **ロールバック**: git revert HEAD~3

---

## 停止条件

### 標準停止条件
- [ ] 想定外のテスト失敗が3回発生
- [ ] ロールバック不可能な状態になった
- [ ] 観測不能な変更が増加

### カスタム停止条件
- [ ] セキュリティ脆弱性が発見された場合
- [ ] 性能が20%以上劣化した場合

---

## 次のアクション

1. [ ] Step 1から順次実行
2. [ ] 各ステップで検証を実施
3. [ ] 停止条件をモニタリング
4. [ ] 完了後 `/eld-ground-check` で接地確認
```

## 失敗パターン（必ず回避）

### 静的整合だけで完了扱い

**NG**: 「型エラーが消えたので完了」
**OK**: 「型エラー解消 + テスト通過 + 影響範囲確認」

### 表層エラーを消すための無理な対応

**NG**:
- 無理なキャスト（`as any`）
- 例外の握り潰し（`catch {}`）
- 警告の無効化（`// @ts-ignore`）

**OK**: 根本原因の解決

### 参照がないから安全と判断

**NG**: 「grep で参照がないから安全」
**OK**: 以下も確認:
- DI/IoC経由の呼び出し
- 設定ファイルからの参照
- コード生成による参照
- リフレクションによる呼び出し

### 物差し不足なのに意味の正しさを断言

**NG**: 「テストはないけど正しく動くはず」
**OK**: 「テストがないため意味の正しさは検証未完了」

## チェックリスト

- [ ] 変更の影響を因果タイプで分類したか
- [ ] 直接影響と間接影響を分析したか
- [ ] unknown（未確認）を明示的にマークしたか
- [ ] 危険度に応じた段階化計画を立てたか
- [ ] 各ステップでロールバック可能か確認したか
- [ ] 停止条件を明確に定義したか
- [ ] 失敗パターンに該当していないか確認したか

## 使用例

```
User: 注文作成機能の変更について影響予測して

Claude:
## Impact Prediction実行中...

### Step 1: 変更スコープ特定
- 対象: src/orders/service.ts (createOrder)
- 関連Law: LAW-pre-order-quantity, LAW-inv-stock-balance
- 関連Term: TERM-order-quantity

### Step 2: 直接影響分析
- API引数変更 → 互換性リスク(High)
- バリデーション強化 → 信頼性向上

### Step 3: 間接影響分析
- src/api/orders.ts → 引数伝播(High)
- src/batch/process.ts → 型変更影響(Medium)

### Step 4: unknown特定
- DI経由呼び出し: 要実行時確認

---

## Impact Prediction Report

### Summary
| 項目 | 値 |
|------|-----|
| リスクレベル | High |
| 推奨段階数 | 4 steps |

### 段階化計画

**Step 1**: 型定義更新 (Low)
**Step 2**: バリデーション追加 (Medium)
**Step 3**: サービス実装 (High)
**Step 4**: 統合検証 (High)

### 停止条件
- 想定外テスト失敗3回
- セキュリティ脆弱性発見

この計画で進めますか？
```

## 関連スキル

- `/eld-model-law-card` - 関連Lawの確認
- `/eld-model-term-card` - 関連Termの確認
- `/eld-ground-check` - 変更後の接地検証
- `/eld-record-collection` - 変更履歴の記録