BhangeeF16 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:
- 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.
- 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, required_outputs, and routing map (on_pass, on_pass_with_risks, on_score_below_minimum, on_failure, on_missing_evidence, on_security_gap — each value a real action id in that same file, or null when the run simply completes, or ask_user_required_question when no in-process target exists). Read the checkpoint you are currently at directly off that file. Do not transcribe or memorize a copy of it here — if this file and the process definition ever disagree, the process definition wins, because it is the one thing re-read fresh on every single run.
A routing destination naming an action id means re-dispatch that action. A routing destination of null means the run completes at this checkpoint (only discover's design_review does this today). on_blocked and on_material_unknown (not present as explicit routing fields, since they never vary by checkpoint) always mean: ask the human one focused, specific question and stop — continue_without_answer: false — never continue on an assumption.
Gate defaults
Every command declares its own gate once, at the top of its process definition (orchestrator.checkpoint_gate — currently minimum_score: 80, preferred_score: 90, blocking_unknown_action: ask_user_required_question, identical across all three commands). A result at or above minimum but below preferred advances as pass_with_risks with the risks named. No checkpoint in any current process definition overrides this gate — if one ever does, that override lives on the checkpoint's own entry, not here.
Escalation to the human
Ask the human only when part 2 is genuinely ambiguous after reading the artifacts — and ask a specific factual question ("can you confirm criterion X is met by Y", "does the recorded approval at Z cover this scope"), never a generic "confirm this score". Bounded by materiality: escalate when the call would materially change scope, ownership, a security boundary, or the acceptance outcome — not for every assumption.
Journal duty
Each checkpoint's decision is appended to the run journal as it is made (checkpoint name, decision, route taken, one-phrase reason) — the debrief persona (the process_retrospective action) at the end of the run reads exactly this.