Choose evidence by asking what a plausible mistake could damage and which observation would expose it. A settings-page alignment change and a payment retry repair have different failure modes. Giving both the same “unit tests passed” sign-off leaves the important question unanswered: did anyone check the behavior that carries the risk?
Define that question before choosing commands, screenshots, or fixtures. The size of the diff helps you navigate the review; the consequences of the changed behavior determine the proof it needs.
Establish what actually changed
Consider two illustrative patches. The first moves a settings-page button by 6 px to align it with form labels. Its intended effect is visual, and no handler changes. The second repairs a provider retry path that can leave a payment pending after capture.
Inspect the diff to confirm those descriptions. A spacing change that also modifies a shared component or pointer handling has a wider scope than the summary suggests. A payment change may alter persistence, retry scheduling, and recovery even when its implementation is short.
Write one sentence describing the main risk of each patch. For the first, it might be clipped or misaligned controls in the affected layout. For the second, it might be a captured payment remaining unresolved or an unsafe retry repeating a financial operation.
Give the visual change a bounded proof requirement
For the stated visual-only patch, request a screenshot of the affected settings state at the relevant viewport. Identify the revision, page, and state so the reviewer can connect the image to the change.
Compare the button with its labels and surrounding controls. Check the spacing the patch intends to repair and whether the result creates clipping or overlap. If the layout depends on a narrow viewport or a longer label, select that state deliberately.
A screenshot can be sufficient proof for this narrowly established visual risk. Additional checks become appropriate when inspection reveals additional behavior. Changing focus handling, disabled-state behavior, or a shared layout expands the review question and may require interaction checks or representative dependent screens.
Keep that expansion explicit. Avoid turning every tiny style adjustment into an unrelated payment or database test run.
Define the payment states before designing the replay
For the retry repair, identify the states the system can observe: the provider's capture result, the local payment record, the order state, and any pending retry work. Confirm the agreed transitions with the payment owner.
Build a controlled case representing the reported mismatch. State the starting records, the event or response supplied to the handler, and the expected persisted state after processing. An assertion that a helper returned success leaves the underlying payment record unexamined.
Use a safe test environment and fixtures with no live financial effect. The reviewer should be able to tell which parts of the real flow the setup represents and which provider behavior it substitutes.
Exercise repeat delivery and the exact stuck-state case
A useful payment verification plan can separate several questions:
| Question | Proposed evidence |
|---|---|
| Does the reported captured-but-pending case recover? | Replay the relevant input and inspect the exact payment and order records afterward. |
| Does repeated processing preserve the intended result? | Process the same logical operation again and check the system's idempotency contract. |
| Could an unwanted additional financial request escape? | Inspect outbound requests and the durable operation identity used to prevent repetition. |
| What happens if processing stops between steps? | Exercise a relevant interrupted transition and check the documented recovery behavior. |
These are proposed checks to adapt to the actual architecture. Define the duplicate and interruption cases precisely. Replaying one successful event twice cannot establish every concurrency or remote-failure guarantee.
For an actual reproducible defect, retain a check that fails for the original stuck-state behavior and passes after the repair. Confirm that it reaches the relevant transition rather than failing during fixture setup.
Combine evidence where the risk crosses boundaries
A focused test can establish a transition rule. A database assertion establishes what the tested path persisted. Integration evidence can establish whether the real handler, persistence layer, and retry machinery agree in the tested environment.
Choose the combination that reaches the failure boundary. If the suspected problem occurs between handler completion and durable state, replacing persistence with a mock removes an important part of the question.
Keep provider assumptions visible. A locally simulated timeout cannot by itself establish what a remote service did. Identify how unknown outcomes are reconciled and who owns the remaining provider-facing check before treating the retry as safe.
Use an evidence ladder as a selection guide
Static reasoning, focused tests, integration or browser checks, data checks, and release observations answer different questions. Select the levels that address the patch's material risks.
The visual-only change may need a reviewed screenshot. The payment repair may require several complementary artifacts because its failure can affect durable money state. A migration check belongs in the plan when data transformation is actually involved.
More artifacts do not automatically provide stronger proof. Ten passing tests can all avoid the persistence boundary. One carefully chosen assertion can expose the exact stuck-state defect while still leaving other risks unresolved.
Make the review decision traceable
Return a short record tying each material risk to its evidence, result, and remaining gap. For an observed check, include the patch revision, fixture or input, environment, and actual outcome. For an unexecuted check, label it as proposed and name its next owner.
State the acceptance decision separately. A payment repair with a passing local replay can still need integration confirmation. If release proceeds with a known limit, identify the accountable owner, monitored condition, stop trigger, and recovery action.
For the small visual patch, record the inspected state and the bounded conclusion it supports. For the payment patch, name what remains unproved after replay and database checks. Evidence is sufficient when it addresses the agreed risk boundary and the remaining uncertainty has an explicit decision and owner.
The Agentic Developer Interview includes the Evidence Ladder card and a review checklist covering risk-appropriate visual and payment-state proof, residual risk, and evidence-backed review decisions.