blast-radius-audit ยท diff
git:20260908.e500868 to git:20260930.5312cda
37 added, 36 removed. Audit A to A.
---
name: blast-radius-audit
description: Find downstream breakage a code change could cause beyond the files it directly touches.
---
# Blast Radius Audit
- Find how a change could break behavior outside the edited files. Identify the facts that must be true for the change to be safe and check them against code, documentation, or execution.
+ Find how a change could break behavior outside the edited files, and check the facts its safety depends on.
- Audit only. Do not edit repository files, add permanent tests, apply fixes, commit, publish, or change production or external systems unless separately authorized. Read-only inspection and reversible local diagnostics are allowed. Keep temporary probes outside the working tree and remove them when finished.
+ This is an audit. Do not edit repository files, add permanent tests, apply fixes, commit, or touch production or external systems unless the user separately asks. Read-only inspection and reversible local commands are fine. Put temporary probes outside the working tree and delete them when done.
- ## Identify the change
+ ## 1. List the changed contracts
- Resolve the pull request, branch, commit, diff, or working changes named by the user. Record exact commits when available. Ask only when the target remains unclear and choosing incorrectly would change the audit.
+ Audit the pull request, branch, commit, or working changes the user names. If none is named, audit the current branch against the default branch plus uncommitted changes. Record the exact commits.
- Read the complete diff and commits, added or removed symbols, relevant tests, callers, and repository instructions. Identify what behavior changes, including effects not obvious from the edited lines. Follow dependencies beyond direct callers when the change could affect them.
+ Read the full diff, the commit messages, the related tests, and the repository instructions. Then list every contract the change alters, including ones not obvious from the edited lines:
- ## Look for downstream effects
+ - function and type signatures, return shapes, thrown errors, and error messages that callers match on
+ - stored data: database columns, serialized formats, cache keys, events, files, and exports
+ - external interfaces: HTTP or RPC responses, CLI output and flags, and public package exports
+ - configuration keys, environment variables, feature flags, and defaults
+ - timing: order of operations, retries, transactions, startup and shutdown, and work that runs later or more than once
+ - permission checks, validation, and other checks that were moved, loosened, or removed
+ - cost on hot paths: query counts, payload sizes, and loops over large collections
- Investigate only paths the change could affect:
+ ## 2. Find the consumers
- - **Data:** stored records, database columns, serialized values, events, cache keys, exports, and consumers in other languages or repositories.
- - **Timing:** startup, cleanup, retries, ordering, concurrency, transactions, partial failures, and work that runs later or more than once.
- - **Runtime selection:** configuration, environment variables, feature flags, dependency injection, plugins, reflection, generated code, and dynamically loaded paths.
- - **Dependency behavior:** the installed library or runtime version, local patches, platform differences, and what the called code actually does.
- - **Deployment and recovery:** rollout order, compatibility with older versions, how failures would be detected, and how to recover or roll back.
+ For each changed contract, find what depends on it. Search by symbol name and by literal value, such as a column name, event name, config key, or route path, because many consumers reference a contract by string. Look beyond direct callers: generated code, dependency injection, plugins, reflection, migrations, fixtures, scripts, documentation, other services and repositories, and older versions still running during a rollout.
- Verify versions, schemas, and documentation when a conclusion depends on them. Finding no references in a code search does not prove that a function or format is unused; configuration, generated code, or external systems may select or consume it.
+ A search with no results does not prove a contract is unused. Say where you looked.
- ## Check the facts that safety depends on
+ When a conclusion depends on how a library or runtime behaves, check the installed version and its code or documentation.
- For each possible failure, state what must be true to prevent it. Keep unrelated failures separate. Do not list hypothetical concerns without a plausible path from the change to an affected caller or system.
+ ## 3. Check each risk
- Describe what you checked and what it establishes: exact code or documentation, a traced path that rules out the failure, an executed test or command, or an observed application workflow. Distinguish these observations from assumptions. Code or a documented contract may be enough; do not run a test merely to repeat proof already obtained.
+ A risk needs a plausible path from the change to a consumer. Do not list concerns without one.
- Prefer existing tests and commands. A temporary probe must use the application's actual code and dependency version, exercise the behavior in question, and fail clearly if the safety assumption is false. Testing a mock or substitute path does not prove the shipped path works.
+ For each risk, state what must be true for the change to be safe, and check it the cheapest reliable way: read the code or documented contract, trace the path, run an existing test, or run a temporary probe. A probe must use the real code and dependency version and fail clearly if the assumption is false. A probe against a mock proves nothing about the shipped path. Do not rerun checks to repeat proof you already have.
- If a necessary fact cannot be checked, state what is missing and how it could be established. Do not describe an assumption as verified.
+ Give each risk one status:
- ## Classify each risk
+ - **Confirmed:** the failure can happen. State the conditions, and whether you reproduced it or established it by reading.
+ - **Unresolved:** a specific missing fact prevents confirming or ruling it out. Name the fact and the check that would settle it.
+ - **Ruled out:** evidence shows it cannot happen in the audited scenario.
- Use one status per investigated risk:
+ ## 4. Report
- - **Confirmed:** code, documentation, or execution establishes a failure under conditions that can occur. State those conditions and whether the failure was reproduced or established by inspection.
- - **Unresolved:** there is a plausible failure path, but a specific missing fact prevents confirming or ruling it out. Name that fact and the check needed.
- - **Ruled out:** the suspected failure cannot occur in the audited scenario, with supporting evidence.
+ Choose the verdict:
- For confirmed or unresolved risks, explain the affected behavior, cause, impact, and evidence about how likely the conditions are. Include detection, recovery, and rollback when they affect the recommendation. Name the simplest check that would resolve any remaining uncertainty.
+ - **Material risk** if any confirmed risk affects correctness, data, compatibility, or operation.
+ - **Unverified** if nothing is confirmed but an unresolved risk could change the verdict.
+ - **Contained** if every risk is ruled out. This covers only what you inspected.
- Mention ruled-out risks only when they explain the verdict or answer a likely concern. Keep them separate from open problems. Do not add minor or hypothetical risks to fill a report.
+ Use this format and omit sections with nothing to report:
- ## Report
+ ```markdown
+ **Verdict:** Material risk | Unverified | Contained, with one sentence on why.
- Choose the overall verdict in this order:
+ **Changed contracts:** the contracts from step 1 that have consumers outside the diff.
- 1. **Material risk found:** at least one confirmed failure would affect correctness, data, compatibility, or operation enough to require attention. Report any unresolved risks alongside it.
- 2. **Unverified:** no confirmed failure determines the verdict, but an unresolved risk or unchecked safety requirement could change it.
- 3. **Contained:** the relevant safety requirements have been checked and no material risk remains. State the scope covered; this is not a guarantee about uninspected parts of the system.
+ **Risks**, confirmed and unresolved, most severe first:
- Lead with the verdict and use only the detail needed to support it:
+ - **Status: what breaks.** The conditions, who is affected, and the evidence. The next check or fix direction, plus detection and rollback when they matter.
- - what behavior changes beyond the edited files
- - confirmed or unresolved risks, with their evidence and next checks
- - facts checked that explain why a likely concern was ruled out
- - any verification needed before merge
+ **Ruled out:** only concerns a reviewer would likely raise, each with its evidence in one line.
- Stop when each safety requirement has been checked or identified as unverified, each investigated risk has a status, and the report explains any remaining work.
+ **Before merge:** checks or decisions still needed.
+ ```