change-impactlisted

# change-impact ## 役割 提案された変更について、14ステップの変更フローを走らせる。依存をたどり、影響する文書・実装・テストを列挙する。更新の順序を守る。満たす要求は §2 の `R3`・`R4`（要求番号は §2 の登録簿で定める）。 ## 委ねる先（決定論は scripts へ） - `${CLAUDE_PLUGIN_ROOT}/scripts/dep-graph.py` — 依存の有向グラフ。前向きに波及先（`impacts`）を、逆向きに依存元（逆参照）を列挙する。ドメイン跨ぎの境界を分類する。逆向きで逆孤児を出す。 - `doc-author`（順序どおりの編集を作る）・`regression-guard`（廃止の段で突き合わせる）・`llm-context-pack`（LLM（大規模言語モデル）へ渡す情報の更新の段で使う）。 ## 経路を選ぶ（最初にここで分ける。ADR-051） 段数は変更の規模ではなく、**決定を含むか否か**で分ける。 - **決定を含む** → 下の14ステップを全て回す。規模は問わない。選べる案が複数あり、その一つを選んだなら決定である。既定値・上限・順序・型・境界の変更は、一行でも決定を含む。 - **決定を含まない**（誤字・言い回し・書式・リンクの張り替え・投影の描き直し・`updated` の更新）→ 軽い経���を通る。ステップ 2・3（影響の列挙）と、更新の順序（現行 `SPEC` → 実装 → テスト → 投影）だけを守る。`CHANGE`・`IMPACT`・`ADR` は要らない。 - 途中で決定を含むと分かったら、その場で14ステップへ戻す。軽い経路を通ったこと自体は記録しない。 どちらの経路でも、不変条件の強制は変わらない（削除安全ガード・ICD 依存ガード・全件監査はフックと CI の層にあり、経路を見ていない）。軽い経路が省くのは記録の段であって、強制ではない。 ## 更新の順序（§3.8、必ず守る） `ADR` → 現行 `SPEC` → 実装（`IMPL`）→ テスト（`TEST`）→ LLM へ渡す情報 → 廃止整理。順序を守る。「何を変えたか」（`CHANGE`／git）と「なぜ決めたか」（`ADR`）を分ける。 ## 14ステップ 1. 変更を `CHANGE`（`status: proposed`）として捕まえる。変更内容・理由・要求元・影響の初期見積（§3.2）。 2. `dep-graph.py` を対象から前向きに走らせ、波及する文書・実装・テストを列挙する。 3. `dep-graph.py` を逆向きに走らせ、逆参照（その対象に依存する文書）を列挙する。後の安全な廃止に要る。 4. `IMPACT`（`status: current`）を作る。影響��る文書・実装・テスト・工数見積（§3.2）。感想は書かない。 5. ドメイン跨ぎの境界を分類する。境界を越える影響は、相手ドメインの ICD を通す（`R7`）。ICD が変わるなら、依存する全ドメインの合意が要ると示す（§3.5）。 6. `ADR` を先に作る（§3.8）。決定を捕まえる（背景・却下した選択肢・決定・帰結、1文書1決定）。これが根拠である。 7. 次に現行 `SPEC` を更新し、決定に合わせる。必須の4節を保つ。 8. データ契約や接点が変わったら、`DATA`・`API` を更新する。 9. 実装。`IMPL` の注記を更新し、影響する部品を指す。