Continue with evidence
Required checks passed and deterministic risk is low or medium. Preserve the report and hand the patch to review.
For coding agents
Give agents a verification loop they cannot hand-wave past.
PatchProof turns repository policy and changed-file risk into a structured outcome. The agent can read what failed, fix the patch, rerun the same checks, and preserve the proof a reviewer needs.
- 01PatchMake a bounded change
- 02VerifyRun policy + risk analysis
- 03ReadUse verdict + concerns
- 04RefineFix and prove again
A machine-readable stopping condition
The verdict becomes part of the agent’s contract.
Local verification prints a concise decision for people and writes a redacted JSON report for tools. Risky, blocked, and unknown verdicts return a nonzero exit code.
Continue deliberately
Checks passed, but high static risk needs review. The agent should surface the finding rather than silently treating green execution as approval.
Stop and refine
A required check failed or timed out, or critical risk is blocked by policy. The next action comes from the top concerns.
A practical local loop
Verify the actual working tree, not an idealized commit.
When the head is omitted or set to HEAD, PatchProof includes committed diff, staged changes, unstaged tracked changes, and untracked files. That keeps the proof aligned with what the coding agent really changed.
- Load the repository-owned
.patchproof.yml. - Scan changed files with deterministic risk rules.
- Run required commands, URL checks, and optional evidence.
- Write the redacted proof under
.patchproof/reports. - Read the verdict and fix the smallest useful concern first.
Agent verification loop
shell
# Run from an authorized project checkout
node /path/to/authorized/patchproof-source/apps/runner/dist/cli/index.js run \
--base origin/main \
--head HEAD
# Inspect the latest durable proof
node /path/to/authorized/patchproof-source/apps/runner/dist/cli/index.js \
report --latestEvidence an agent can act on
Concrete signals instead of “looks good.”
Structured concerns
Failed steps, timeouts, risk categories, and lifecycle interruptions have typed context and a bounded recommendation.
Changed-file status
Added, modified, deleted, renamed, copied, staged, and untracked evidence keeps the proof tied to the real patch.
Policy integrity
Deterministic rules flag weakened test, CI, authorization, dependency, Docker, environment, and PatchProof configuration.
Redacted output
Runner and cloud presentation boundaries reduce the chance that a credential value appears in logs or report metadata.
Reproducible commands
The verification contract lives in the repository rather than in a prompt that disappears when the agent session ends.
Durable provenance
Local proofs record the configuration path, working directory, timestamps, duration, and evidence counts. Shared cloud proofs also add commit, branch, and runner context.
Keep authority explicit
PatchProof verifies code; it does not grant repository access.
The CLI must run from a project checkout the operator is already authorized to use. A self-hosted runner needs its own legitimate Git access. PatchProof does not make a private repository public or bypass its access controls.
Use bounded runner credentials, environment access, network policy, and operating-system isolation appropriate for untrusted project commands. Never share an operator API token with code executing on a runner.
Read the security boundary01
Source authority
Only verify repositories and patches you are authorized to process.
02
Execution authority
The customer controls runner machines, secrets, network access, and package registries.
03
Merge authority
A proof informs the decision; it does not replace human review or production safeguards.
Start from source
Give the next patch a stopping condition.
Use an authorized PatchProof source checkout with Node.js 22 or newer, then run deterministic verification inside the repository your agent is changing.