Verification planning

Before changing a non-trivial system, build an evidence path: a route from the claim to evidence that can establish, limit, or refute it.

Purpose is not picking a familiar technique. Purpose is deciding how this system can reveal the truth of this change.

Stack defaults (Bossmann Cursor):

• Explore via codebase-memory (search_graph / trace_path / get_code_snippet)
• Compress large logs via token-engine
• Record the plan in .claude/state/checkpoint.json (tests, next_action)
• Prefer measure-only quality gates; do not autofix unless the user asks
• After the path runs, optional /blindspot-pass for missed edges

When to skip

Small mechanical edits with an obvious existing check (one-liner, rename with types green). Follow ordinary project commands directly.

Process

0. Prior-art check (reuse before build)

If the plan introduces a new component, tool, integration or workflow, run /prior-art-check first: look for an existing open-source or already-installed solution and record adopt | adapt | build with the reason. Skip for edits inside code that already exists.

Done when: the plan says what is reused and what is genuinely new.

1. Frame the claim

State the behavior that must become true and what could make a confident conclusion wrong.

Name:

• what must change
• what must remain true
• which boundary the behavior crosses
• which failure would matter most

Done when: claim, uncertainty, and important failure modes are concrete.

2. Design the evidence path

Derive paths from the system itself: controllable inputs, observable effects, state transitions, invariants, boundaries, artifacts, repeat/reverse ability.

Generate alternatives before choosing. Prefer the path that yields a trustworthy conclusion with proportionate cost and safety.

Done when: preferred path + known limits + a weaker/stronger fallback exist.

3. Set a verification budget

List distinct claims. Assign one owner (agent step or command) per claim. Choose the minimum non-duplicative evidence. Reuse evidence only while code, inputs, environment, and state stay valid. Required repo/CI checks still apply.

4. Create a verification affordance when needed

If the decisive truth is too indirect, add the smallest capability that makes the relevant state controllable, observable, repeatable, and diagnosable for an agent (fixture, demo script, assert, narrow probe).

Treat the affordance as part of the evidence path, not an automatic product feature. Decide temporary vs durable before building. Ask before new dependencies or persistent diagnostic surfaces.

5. Make the path runnable

Prepare only narrow, repeatable support. Prefer commands already in PROJECT.md. Write the chosen commands into checkpoint tests.

Done when: the path can be followed without guessing setup or interpretation.

6. Close the evidence path

After implementation, follow the planned path. Report whether each claim was established, limited, or refuted. Separate known facts from remaining uncertainty. No completion claims without fresh evidence (same spirit as superpowers verification-before-completion).

Output (compact)

Claim: <behavior>
Uncertainty: <what could make confidence wrong>
Evidence path: <commands / checks / affordance>
Budget: <min checks; what skipped and why>
Status: established | limited | refuted | not-run-yet

Compose with