evidence-verificationlisted

# Evidence Verification The delivery-lead's in-session gate check, run at each checkpoint position with no subagent dispatch. It has exactly two parts, in order: 1. **Mechanical check** — do the stretch's required outputs exist as real files/content, per each action's own reported locations? This part is scriptable and involves no judgment: an output is present or it is not. A missing output ends the check — route on missing evidence; do not proceed to part 2 to argue the gap away. 2. **Factual read** — does that evidence, read plainly, actually satisfy the accepted acceptance criteria or user story? This is a judgment call, but a factual one: "criterion X asks for a denied-path test; the evidence contains one / does not." It is NOT a quality re-score — quality independence is already provided by the distinct reviewer roles in the flow (the code reviewer is not the implementer; the security reviewer implemented nothing; QA judges evidence it did not produce). Two rules apply to every checkpoint: a claim with no evidence entry behind it is not passing-shaped, regardless of the result field attached to it; and residual risks are recorded explicitly even when the list is empty. ## Where the contract and routing live There is exactly one copy of this data, and it is already in your context: the current command's own `commands/<name>.process.yaml`, live-injected at the start of every run. Each `- checkpoint:` entry in its `sequence:` carries its own `required_inputs`, `requir