cross-module-impact-scannerlisted

## What It Does Reads a proposed implementation outline before any code is written and predicts which other modules will be affected. For every public surface the change touches — API contract, event, schema, configuration, shared utility — classifies the impact on every consuming module and recommends the coordinated changes those consumers will need. The point is to surface contract breakage in design phase, not after a deploy fails. ## Use This When Use this in the graduated and full lanes whenever the proposed change touches at least one item that crosses module boundaries: a public API, a published or consumed event, a shared database table, a shared configuration value, or a re-exported utility. Skip when the change is purely internal to one module and the integration docs confirm no consumers exist. ## Inputs - Read the proposed solution at `proposed_solution_path` first. - Read the module map at `module_map_path` to learn the canonical module slugs. - Read integration docs and API docs for each module the change references; these are the source of truth for consumer relationships. - Read `references/impact-classification.md` before classifying any impact so the severity rubric stays consistent. ## Procedure 1. Run `scripts/list-modules.sh` to load canonical module slugs from the module map. 2. Run `scripts/find-integration-docs.sh` to enumerate per-module events/contracts/integration docs. 3. Enumerate every public surface the proposed solution changes (API, e