change-impact
Change Impact
Turn “this change is safe because…” into a checkable claim. Use this assessment independently or within the existing Developer/Reviewer task. Reuse valid evidence; the assessment itself adds no merge gate.
Bound the Candidate
Identify the task, authoritative contracts, baseline, and complete task-owned candidate. Inspect committed changes, staged/unstaged edits, and new files; separate unrelated user work. A branch-to-branch diff alone can omit the proposed change. When ownership or the base is unclear, investigate it before claiming complete coverage.
Use existing repository terminology and architectural decisions. Keep the investigation proportional to the changed boundary.
Trace and Prove
- Find the actual callers/readers/writers and entrypoints across the changed contract: exports, schemas, adapters, generated registrations, examples, tests, and external consumers supported by available evidence. Follow relevant references and runtime registration; a text-search miss alone cannot prove no consumers exist.
- For each materially affected boundary, state what behavior changes, which consumer relies on it, and the fact required to preserve acceptance or compatibility. Include shared ports, quotas, data, creating processes, and cleanup consumers for ownership changes.
- Choose the smallest evidence that distinguishes a safe change from the concrete failure. Reuse public behavior tests, independent expected values, contract checks, representative consumer execution, or current runtime receipts. Static inspection can support static claims; runtime claims need runtime evidence. Label consumers outside available access as unknown.
- Report uncovered assumptions and the next discriminating check. A missing proof can motivate a narrower change or additional focused verification within the authorized scope.
Example: renaming an event field is safe only if supported producers and readers agree. Trace serialization, browser decoding, retained fixtures, and any compatibility promise; exercise a representative producer-to-reader path. A green producer unit test alone leaves decoding unproved.