Change Verification

Produce the smallest evidence set that convincingly supports the change's claims and protects its highest-risk invariants.

Protocol

1. Identify the exact change range and read applicable repository instructions.

Preserve unrelated user changes.

1. Write a claim ledger: each intended behavior, preserved invariant, affected

boundary, likely failure mode, and the evidence that could falsify it. Use references/verification-matrix.md.

1. Classify risk by consequence, reachability, novelty, and reversibility. Raise

rigor for authorization, money, destructive writes, migrations, concurrency, public APIs, and silent corruption.

1. Inspect existing test/build commands and CI configuration. Do not guess a

command when the repository declares one.

1. Order checks for fast information:

• syntax/type/static validation;
• focused tests for changed logic and regression input;
• integration tests across affected boundaries;
• broader suite/build/package checks;
• runtime smoke, migration, compatibility, performance, or security checks

only when the risk model calls for them.

1. Before each expensive check, state which claim it tests. Do not run broad

suites merely to create confidence theater.

1. Interpret results, not exit codes alone. Confirm tests were discovered,

assertions exercised the changed path, expected failures did not get swallowed, snapshots/artifacts are meaningful, and warnings are relevant.

1. For a bug fix, demonstrate the regression test targets the original failure.

Prefer fail-before/pass-after evidence when safely obtainable without discarding work; otherwise explain the causal link.

1. For migrations or irreversible operations, verify on disposable data and

inspect forward, backward/rollback, partial-failure, and repeated-run paths.

1. Stop when every material claim has evidence or an explicit gap. Never claim

"fully verified" from a partial environment.

Guardrails

• Do not mutate production, publish, deploy, or exercise real side effects

without explicit authority.

• Do not weaken assertions, delete failing tests, or regenerate snapshots solely

to obtain green output.

• Distinguish product failures, test defects, environmental failures, and checks

that never ran.

• Treat flaky success as inconclusive until the nondeterminism is bounded.
• Report skipped, inaccessible, or environment-dependent checks as gaps with

their risk—not as passes.

Output

Lead with the verification verdict: supported, partially supported, or not supported. Summarize evidence by claim, then failures and residual risk. Include exact commands and concise results so another engineer can reproduce the proof.