verify-completionlisted

# /verify-completion ## Goal Re-check a **completion claim** from a context that did **not** build the work (the hooks-mastery builder-validator pattern), so "the builder says it's done" is never the last word. It answers one question with evidence: *does the claim match reality?* — and defaults to **REFUTED** on any doubt. Two layers, and you run **both**: 1. **Deterministic** — `core/infra/completion-verify.py` mechanically checks that every cited file exists (and contains its declared substring), every cited test exits 0, and every cited assertion holds. This catches the common failure ("claimed file X" when X does not exist; "tests pass" when they fail) and cannot be argued with. 2. **Semantic** — a refute-by-default judgment that scripts cannot make: does the code actually *do* what the claim says, are the tests *meaningful* (not trivially-green), does the artifact match the stated intent? This is the LLM-judge layer of the eval harness. Both emit the **same verdict schema** (`docs/scoring-convention.md`). ## The claim A claim is a JSON/YAML file (by convention `.agent/claims/<slug>.yml`) the builder writes, or that you reconstruct from the builder's report: ```yaml claim: summary: "what the task asserts it accomplished" files: # each must exist; optional substring must be present - { path: "core/hooks/x.py", contains: "def new_guard" } tests: # each command must exit 0 - "bash core/te