verification-reviewerlisted

# 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. Before scoring any other lens, enforce custody after failure: a product defect or newly exposed requirement must end that candidate's verification cycle. Treat product patching or retesting inside the same cycle as a review failure. 1. **Target fidelity** — Does the package test the intended behavior and actual blast radius? 2. **Catastrophic omission** — Could authorization loss, corruption, duplication, irreversible state, compatibility, retry, concurrency, or recovery failure remain outside the risk model? 3. **Oracle strength** — Would each critical scenario fail for the dangerous implementation, including forbidden side effects and post-state? 4. **Boundary realism** — Do