impact-audit

# Impact Audit Scope a **planned** change before writing it. Answers "if I change this, what else has to change, and in which repositories" -- across a federation of repositories, not just the one you have open. Run this while the change is still a proposal. Once code is written, `review-delta` and `review-pr` review what actually changed. **Command surface:** run the local CLI through the coding harness shell. Examples use the installed `better-code-review-graph` command; from a source checkout, prefix it with `uv run`. No MCP mapping is required. Use `better-code-review-graph query --help` for the actions reference. ## Steps 1. **State the change under audit in one line** before querying anything -- for example "add a required `tenant_id` parameter to `create_session`". The audit is only meaningful against a specific proposed edit, because the risky part differs: adding a required parameter breaks callers, changing a return type breaks consumers, renaming breaks both plus anything resolving the name dynamically. 2. **Make sure every repository that could be affected is in the graph.** A blast radius is only as wide as the graph: - `better-code-review-graph graph stats --repo-root "<path-a>"` -- confirm the graph exists and note `files_count`. - `better-code-review-graph graph build --full-rebuild --repo-root "<path-a>" --roots "<path-b>"` -- federate the additional repositories into the same graph. Each root is registered and its files tagged with a `repo_id`. ...