denizaslan36 Verification Gate
Match every important completion claim to fresh, proportionate evidence.
Gate
- Extract the claims the final answer would make. Include explicit acceptance criteria and important implied promises.
- For each claim, identify the cheapest check that could disprove it. Prefer direct checks over proxies.
- Run safe checks that are available and authorized. Read the exit status and relevant output; do not infer success from a command merely starting.
- Map each claim internally to one status:
- verified — direct current evidence supports it;
- partially verified — evidence covers only part of it;
- not verified — no adequate check was run;
- failed — evidence contradicts it.
- Resolve failed claims when the task authorizes implementation. Re-run the affected checks after any change.
- Report the actual state. Never turn partial evidence into a complete-success claim.
Evidence Rules
- Use the narrowest check that proves the claim, expanding only when risk or dependencies justify it.
- A linter does not prove a build; a build does not prove behavior; a passing unrelated test does not prove the reported bug is fixed.
- Old output, expected output, and another agent's assertion are leads, not fresh evidence.
- When a check cannot be run because of missing access, time, hardware, or credentials, name the limitation without assigning work to the user unless asked.
- Preserve exact failure details needed to diagnose the result, but never expose secrets.
Final Form
Keep the report compact: outcome, evidence run, unresolved limitations. Show per-claim statuses only when they clarify multiple claims or mixed results. For a single straightforward claim, give the conclusion and decisive evidence in plain prose; omit a checklist when a short sentence is clearer.