Skip to content

/prove

Audience: coding agents and integration operators. CLI commands and schemas below are system reference, not a user checklist. Users can follow Quickstart.

In plain words: Prove checks that the work really does what the agreement promised. The harness runs the project’s own tools (the providers), records each result as a receipt, and has a review read the diff. You only step in for a decision that is yours, such as acceptance or a waiver. You get proven when every promise has fresh evidence. proven is not delivered: nothing has reached your project yet. Only /land reaching archived means done.

/prove <change>

Run:

Terminal window
claude-foundation advance <change> --through proven

The coordinator validates the current agreement and workspace, reuses receipts whose inputs are still current, executes eligible independent providers once, routes review before acceptance, finalizes the proof bundle, and audits it. It returns DONE only when the requested proven target is reached.

Failed evidence returns one REPAIR or EDIT batch with the invalidated claim closure. After a fix, only invalidated/downstream checks rerun. A configured review that the harness can run starts in parallel with the tests for the same workspace hash, reads only the diff and the agreement’s requirements, and uses the fast model tier for low risk and a faster standard tier for medium risk (high risk and security triggers keep the configured model; review.modelByTier overrides it). When Build checks are reused, review still overlaps the asynchronous base-source test check without rerunning those Build checks; its findings and failed tests return as one REPAIR. Other configured reviews are RUN_EXTERNAL; a named external owner is WAIT without a question; a material contract or acceptance decision is ASK_USER. A control-plane, CI, or secret path (such as .claude/, .github/, foundation.json, .env) or a deletion outside the task paths does not stop Prove: it is recorded and listed for you at Land. Each boundary preserves state and gives one exact resume route. Repeating an unchanged wait does not poll, rerun evidence, or spend another model request.

Recovery observations survive process restarts. The first unchanged repair handoff belongs to its owner; the second asks the agent for one materially different approach inside the agreement; the third goes back to the same owner, agent or harness, with the output that kept repeating, the strategies already tried, and a set of different approaches. It does not ask you: a gate that keeps returning the same findings is still the agent’s repair. Only a choice that is yours (approval, product meaning, Land, a side effect, budget) becomes a question. For those, the agent records your answer with advance --decision, the returned fingerprint, a decision reference and reason. The harness resumes the original target and reuses the answer while its scope is unchanged. Waiting names the owner and condition; pausing does not run setup or providers. A retry grants no waiver, extra budget, or Land authority.

On the rapid lane, a clean test run whose count cannot be parsed passes when its output shows an executed test; the receipt records countMeasurement: "exit-code" rather than a count. Standard lanes still require a counted result.

The harness never fabricates evidence, converts unavailable measurements to zero/pass, or lets review prose replace a missing behavioral result. Prototype artifacts are rejected as proof. Integration claims can require security, compatibility, resilience, and signed external evidence as declared by the agreement.

proof readiness, proof advance, provider, receipt, and authority commands remain compatible advanced surfaces under help --all; normal agents do not compose them manually. DONE at proven does not supply Land authority.