verify-plan

name	verify-plan
description	Falsify a plan's factual claims before implementing against them. Use before executing any plan written in another session (/ck:cook --from-plan), via /ck:plan verify <path>, or whenever a plan asserts existing-behaviour facts (a root cause, "X currently does Y", affected row counts, "already done"). Produces a claim → verdict → evidence table; no code until it is approved.
metadata	{"version":"1.0.0"}

Verify-Plan — Falsify Before You Build

Why

Implementing against unverified plan claims is the top measured source of first-pass defects (buggy_code 12 + wrong_approach 7 in one dataset; a wrong root cause shipped in 3 merged PRs in another, then cost corrective + cleanup PRs). A plan is not evidence — it is a set of falsifiable hypotheses written by someone (often a past session) who could be wrong.

Method

1. Extract every factual claim. The claim classes that fail in practice:

   • root cause ("the bug is caused by X")
   • current behaviour ("X currently does Y", "the legacy path handles Z")
   • data claims (affected row counts, "only N records match")
   • code-path claims ("this handler runs on every request")
   • status claims ("already done", "phase 2 is complete", "this migration ran")

2. Prove or disprove each with evidence, never with plausibility:

   • git log / git blame / git show — did the change actually land? when? what did legacy behaviour look like?
   • direct file reads — does the cited code do what the plan says at that file:line?
   • read-only queries (SELECT, EXPLAIN) — do the row counts / data shapes hold?
   • run the cited command and paste its output.

3. Fill the fixed table → plans/<plan>/reports/plan-verification.md:

   | # | Claim | Verdict (CONFIRMED / REFUTED / UNVERIFIABLE) | Evidence (file:line, git ref, or verbatim output) | Impact if wrong |

4. Verdict discipline:

   • CONFIRMED requires evidence in the row — a citation-free CONFIRMED is a guess and gets downgraded to UNVERIFIABLE.
   • UNVERIFIABLE names the check that would settle it and why it wasn't run.
   • REFUTED quotes the disproving evidence verbatim.

Hard rules

• No code until the table is approved.
• Any REFUTED load-bearing claim (the plan's approach depends on it) → back to planner; do not patch around it.
• All-REFUTED is a legitimate outcome. One verified migration plan proved to be a complete no-op — finding that before implementation is the gate's biggest win, not a failure of the gate.
• Verification is read-only: no edits, no writes, no mutating queries.
• Append the gate result to plans/<plan>/STATE.md ([[run-state]]): phase 0: gate verify-plan → PASS|FAIL (evidence: <K> claims, <c>/<r>/<u>).

When it triggers

• Mandatory: /ck:cook --from-plan — a plan authored in another session is exactly the case that failed.
• Auto-trigger elsewhere: the plan asserts ≥1 falsifiable claim about existing behaviour. A greenfield feature plan has nothing to falsify — running the gate there is pure cost.
• Standalone: /ck:plan verify <path>.
• Also runs inside /ck:fix after its root-cause gate, on the diagnosis itself (the root cause is a claim like any other).

Cross-links

[[planning]] (executable exit gates make claims checkable), [[cook]] (Stage 0.5), [[run-state]], [[code-review]] (same Iron Law: evidence or it didn't happen), [[debugging]] (root-cause tracing supplies the evidence for cause claims)