ELD Predict Impact

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

目的

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

因果タイプ分類

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

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

リスクマトリクス

code

            影響範囲
         狭い     広い
発   低  [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経由の呼び出し
•設定ファイルからの参照
•コード生成による参照
•リフレクションによる呼び出し
•動的インポート

段階化戦略

危険度に応じた段階化

code

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

段階化の原則

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

段階化計画テンプレート

markdown

## 段階化計画

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

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

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

品質優先原則（Superpowers統合）

核心原則

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

「速さより質」の実践

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

完了条件

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

停止条件

標準停止条件

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

1. 予測と現実の継続的乖離

•想定外のテスト失敗が3回以上
•想定外の依存関係が発見された
•影響範囲が当初の予測を50%以上超過

2. 観測不能な変更の増加

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

3. ロールバック線の崩壊

•戻せない変更が発生
•依存関係が複雑化して部分的な戻しが困難
•データマイグレーションが不可逆に

カスタム停止条件

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

yaml

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

反射の選択

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

機械反射（自動対応）

即座に修正可能な問題：

•型エラー → 型を修正
•lint警告 → フォーマット修正
•未使用変数 → 削除

設計反射（判断が必要）

方針決定が必要な問題：

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

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

停止条件に達した問題：

•セキュリティ脆弱性発見
•重大な設計変更が必要
•スコープ外の影響が判明

code

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

出力形式

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（未確認）を明示的にマークしたか
• 危険度に応じた段階化計画を立てたか
• 各ステップでロールバック可能か確認したか
• 停止条件を明確に定義したか
• 失敗パターンに該当していないか確認したか

使用例

code

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-predict-impact

ELD Predict Impact

目的

因果タイプ分類

リスクマトリクス

影響予測プロセス

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

Step 2: 直接影響の分析

Step 3: 間接影響の分析

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

段階化戦略

危険度に応じた段階化

段階化の原則

段階化計画テンプレート

品質優先原則（Superpowers統合）

核心原則

「速さより質」の実践

完了条件

停止条件

標準停止条件

1. 予測と現実の継続的乖離

2. 観測不能な変更の増加

3. ロールバック線の崩壊

カスタム停止条件

反射の選択

機械反射（自動対応）

設計反射（判断が必要）

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

出力形式

Impact Prediction Report

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

静的整合だけで完了扱い

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

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

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

チェックリスト

使用例

関連スキル