ck-impactlisted

# Assess a change's impact Find the consequential effects outside the edited code and the evidence needed to judge them. Work from a concrete diff or proposed behavior change. Keep the review centered on that change; unrelated quality findings belong elsewhere. ## 1. Bound the change Resolve the baseline, changed behavior, affected artifact, and intended contract from the request and repository. Include relevant configuration, generated outputs, and installed entry points when the change reaches them. If the change is only proposed, distinguish the current implementation from the proposal. Identify which downstream result matters to the user. A rename, default change, or cleanup may alter behavior through a stored value or another consumer even when its direct callers compile. ## 2. Trace the contracts Follow direct callers, then the relevant boundaries a symbol search misses: serialized data, persisted state, configuration defaults, dependency behavior, lifecycle ordering, generated packages, or consumers in another language or repository. Inspect the dependency version and local patches when its behavior supports the conclusion. Follow only boundaries the change can plausibly reach. For each consequential path, state the failure mechanism and its preconditions. Identify the assumption that would make the path safe, such as an operation being idempotent or a consumer accepting both representations. Cite the contract and implementation that support it. Describe likelih