change-impact-analyzerlisted

# Purpose Quantify who and what a change breaks or touches so planning and QG can size risk correctly. # When to Use / When NOT to Use **Use when:** cross-service changes, API/schema edits, shared library bumps, migrations, large refactors, “what will this break?”. **Do not use when:** typo/docs-only; pure local private helper with no exports (lite one-liner OK). # Preconditions Diff, PR, or proposed change description plus CONTEXT_PACK (or ability to search callers/contracts). # Inputs / Outputs **Inputs:** change set / plan, CONTEXT_PACK, OpenAPI/proto/schema if present, TASK_GRAPH optional. **Outputs:** `IMPACT_REPORT` # Upstream / Downstream **Upstream:** delivery-planner, feature-implementer, api-contract-guardian, engineering-os. **Downstream:** delivery-planner, test-strategy-designer, quality-gate, migration-surgeon, pr-generator. # Core Principles 1. Follow edges: imports, APIs, events, schemas, feature flags, config. 2. Name concrete consumers (services, packages, mobile/web). 3. Separate breaking vs compatible vs unknown. 4. Data/migration impact is first-class. 5. Unknown consumers → ProceedWithConditions or Block for public APIs. 6. Prefer evidence (grep, refs, contracts) over guessing. 7. Do not implement the change. # Process 1. Summarize the change intent. 2. Identify exported surfaces touched (HTTP, RPC, events, DB, packages). 3. Trace inbound/outbound dependents in-repo; note external unknowns. 4. Classify impact per consumer: None | Compatib