change-impact-scanlisted

## Purpose 「直したら別の箇所が壊れた」を防ぐ。 変更の実行範囲と影響範囲を分けて整理し、波及リスクのある箇所を実装前に明示する。 ## Use When - 既存コード・DB・API の変更を行う前 - リファクタリングや型変更など、波及が広い変更の前 - 「どこを直せばいいか」がわかった後、「どこに影響するか」を確認したい場合 - implementation-gate でゲートチェック後、影響範囲の詳細が必要な場合 ## Inputs 以下を準備すること。不足している場合は推測せず、不足を明示する。 - **変更内容**: 何を変更するか（ファイル・関数・型・DB カラム等） - **変更理由**: なぜその変更が必要か - **現在の利用箇所**: 変更対象が使われている場所の既知情報 - **技術スタック**: 言語・フレームワーク・ORM・テストツール - **テスト状況**: 既存テストのカバレッジ・実行方法 ## Output Contract 以下の順で出力すること。順序を変えない。 1. **論点**: この変更の影響範囲を左右する核心的な判断軸 2. **根拠**: その論点をそう判断した理由 3. **影響範囲マップ**: 変更が波及する箇所の一覧 4. **含意**: 影響範囲の広さが示す設計上の意味 5. **改善案**: 影響範囲を最小化するための変更戦略 6. **代替案**: 影響範囲を避けつつ目的を達成する別アプローチ 7. **判断材料**: 「実装に進む / 段階的に進む / 設計を見直す」を選ぶための情報 ### 影響範囲マップ フォーマット | 影響箇所 | 種別 | 重篤度 | 対処方針 | |---|---|---|---| | （ファイル/関数/テーブル名） | 直接変更 / 依存 / 副作用 | 高/中/低 | 合わせて修正 / テスト追加 / 監視 / 無視可 | 種別: - **直接変更**: 実装の主要対象 - **依存**: 変更対象を import / call している箇所 - **副作用**: 変更によって間接的に影響を受ける箇所（型推論・テスト等） ## Review Lens - **目的妥当性**: 影響範囲の洗い出し基準が変更リスクに対して適切か - **範囲の過不足**: 依存が深いところまで追えているか（過剰に広くなっていないか） - **中長期リスク**: 今後の機能追加で影響が拡大しそうな箇所を見落としていないか - **LAB全体との整合性**: Supabase スキーマ・NextAuth・Stripe との依存が含まれているか - **非エンジニア理解可能性**: 重篤度と対処方針が非技術者に説明できるか - **他LLM移植耐性**: 影響種別の定義が Claude 固有の解釈に依存していないか ## Instructions 1. 変更対象を「ファイル / 関数 / 型 / DB カラム / API レスポンス」に分類する 2. 各変更対象について依存元（呼び出し元・参照元）を列挙する 3. 依存元の依存元（2次波及）まで追う（3次以降は概要のみ） 4. 重篤度を「高（動作不能）/ 中（劣化・警告）/ 低（影響軽微）」で評価する 5. 各影響箇所に対処方針（修正 / テスト追加 / 監視 / 無視可）を付ける 6. 「ここは変更前に必ずテストを書くべき」な箇所を明示する 7. 最終判断（実装に進む / 段階的に進