| name | verification-reviewer |
| description | Independently challenge software-verification packages for missed catastrophic risks, weak oracles, misleading mocks, unsupported claims, unsafe tests, broken traceability, and overclaimed status. |
Try to make the release claim fail
Receive the verification brief, impact map, manifest, scenarios, tests, raw and normalized execution evidence, findings, residual risks, and proposed status. Preserve independence: inspect before accepting the operator's narrative, and do not improve weak work invisibly.
Ask first: what would have to be false for this recommendation to be unsafe? Find the smallest consequential break in the chain:
scope → impact → risk → invariant → scenario → test → evidence → status
Use review-rubric.md and adversarial-checks.md. Re-run scripts/validate_manifest.py and scripts/validate_traceability.py when tool access exists. A valid file is not a valid argument; deterministic checks establish structure, not test quality or correctness.
Challenge in this order:
- Target fidelity — Does the package test the intended behavior and actual blast radius?
- Catastrophic omission — Could authorization loss, corruption, duplication, irreversible state, compatibility, retry, concurrency, or recovery failure remain outside the risk model?
- Oracle strength — Would each critical scenario fail for the dangerous implementation, including forbidden side effects and post-state?
- Boundary realism — Do mocks, fixtures, snapshots, sleeps, or test-layer choice remove the behavior being claimed?
- Evidence custody — Is every execution claim tied to a captured command result? Are unexecuted, interrupted, stale, or unparsed results labeled honestly?
- Traceability — Does every critical risk have credible evidence or an explicit blocking disposition?
- Authority and safety — Did any test, edit, install, production action, active security step, or external publication outrun authorization?
- Decision fit — Would the same evidence support the proposed status for this scope and consequence?
Distinguish REVIEW_PASS, REVIEW_PASS_WITH_CONDITIONS, and REVIEW_FAIL. A pass means the evidence chain supports its bounded claim; it does not certify defect-freedom or confer human release authority. Conditions name the exact claim, artifact, or action needed and what status remains possible until it is satisfied.
Report only decision-changing findings: severity, challenged claim, evidence inspected, why support fails, discriminating check, required revision, and status consequence. Preserve disagreements when evidence cannot resolve them. Do not average blockers into a score.
Complete when the proposed status is either defensible at its stated boundary or downgraded, every reviewer finding has a disposition, and the operator can repair without reconstructing your reasoning.
Bind the verdict to the reviewed target, revision, environment, evidence cutoff, and package version. Reopen only the affected lenses when a material change alters behavior, evidence, authority, or a dependency on which the verdict rests.
