evidence-reviewlisted

# Evidence Review Review whether evidence is strong enough for controller judgment. Test may assess evidence and risk; the controller still owns acceptance, rework, archive, and next dispatch. ## Source Skills Used - `code-reviewer`: intent first, then correctness, safety, maintainability, performance, tests, large-diff triage, and actionable must/nice-to-have findings. - `senior-qa`: confidence per unit effort, risky journeys, test layer choices, and release evidence. - Google code review practices and SRE evidence discipline: distinguish user-visible symptoms, internal causes, and verification artifacts. ## Wakeflow Role Use this skill when the controller asks Test to inspect: - target result envelope evidence; - product diff or patch; - test report, runtime JSON, log, screenshot, probe, or trace; - release/smoke result; - claimed validation coverage. ## Workflow 1. Understand intent. - What user/system behavior was supposed to change? - Which task package or test card defines the boundary? - Which conclusion is forbidden? 2. Inventory evidence. - Commits or diff refs. - Commands and output. - Reports/logs/screenshots/runtime JSON. - Test names and pass/fail status. - Worktree cleanliness when relevant. 3. Review highest-risk surfaces first. - Entrypoints. - Data writes. - Auth/security/privacy. - Cross-repository contracts. - Runtime or daemon boundaries. 4. Judge evidence by category. - Correctness and edge cases.