Review the diagnosis
Choose security and code-review methods before seeing their results, then run workbench review to test whether the diagnosed risks are supported by the diff and requirements.
Review YAML
From a diagnosed risk to a bounded review finding
Every review result traces to a diagnosed risk and states its evidence limit.
Sibling repository../payments-validation-fixture836a75dThe preparation guide explains how to verify a newer revision before using it.
Why this stage exists
Selection happens before results are shown. A method is useful only when it can answer the question raised by the diagnosed failure mode.
Review challenges the diagnosis; it does not approve the change or decide whether refund idempotency is required.
What you start from
Work from these inputs only. Anything not on this list is either a later stage’s concern or a decision you do not own.
- Risk surface YAML
- The plausible risks from Stage 1.
- Review methods
- Security, fresh-context and adversarial review methods.
- Requirements
- Payments product and technical specs, without later eval results.
Choose the method before seeing the result
One worked pass, so the shape of the work is visible before you do it on your own.
- Choose a security or code-review method for each named risk.
- Run workbench review and write the review YAML.
- Check whether the provider request can reach a log sink and whether the timeout path is covered.
- Record provenance, scope and what the review could not establish.
What this turns onA card-data concern may be supported by review while refund idempotency remains a human-owned policy question.
Do the work
- Choose review methods for card-data leakage, weak retry testing and regression risk before viewing results.
- Run the review/security pass on the refund-retry diff.
- Separate supported risks from signals the review could not establish.
- Do not treat a review opinion as deterministic proof.
You produce
Review YAML
- Risk reviewed
- Method and reviewer context
- Finding or no finding
- Evidence type
- Known limit
Challenge your own result
The review says the retry looks safe. Does that prove refund idempotency?
Show how this resolves
No. A review opinion about the retry path does not create a requirement for repeated refunds or prove every downstream behavior.
Ready to continue when
- Every review finding traces to a diagnosis risk.
- Every review result states its scope and evidence limit.
What transfersReview is strongest when it challenges a named risk rather than searching the whole diff without a question.