The Claim → Evidence Ledger

Separate each claim from the evidence that backs it, and grade the evidence honestly. This is the exact move that turns an over-claim into the truth — the transcript that motivated this pack did it as an A/B/C list.

The three grades

| Grade | Means | Earns "done"? | | --- | --- | --- | | ✅ executed | You ran the real path and observed the expected result | Yes | | ◐ code-path | You read the code / traced the logic; it should work — not run | No | | ○ assumed | Inferred from a related fact, a convention, or "looks right" | No |

Build it before you claim

For each Done criterion, write one line:

A. agent loads SOUL.md and runs as Principal Design Engineer   ◐ code-path — not run
B. agent, given "audit stripe.com", calls audit_site + reports ○ not run
C. design engine round-trips over MCP                          ✅ ran tools/call over stdio

Then add, for every ✅, what it does NOT establish:

• "C proves the engine is exposed over MCP. It does NOT exercise the agent loop or the persona — the MCP server calls the tool directly, with no system prompt and no agent deciding to call it."

The verdict rule

• Done only when every criterion is ✅.
• Any ◐ or ○ on a Done criterion → not done. Either go execute it (vd-run-the-real-path]]) or report the gap (vd-report-the-gap]]).
• A pile of ✅ on adjacent claims never sums to a ✅ on the real one (vd-plumbing-vs-behavior]]).

Why grade the good news too

The danger isn't the ○ you know is shaky — it's the ✅ you over-read. Stating what a green result does NOT prove is what catches "I verified the plumbing and called the feature done." Governed by vd-done-is-executed]].