Proof and evidence

What counts as proof

• Test output showing all relevant tests pass (e.g., cargo test, pytest).
• A diff showing the exact change, with test results confirming behavior.
• Operator notes with attached trace or log file confirming resolution.
• PR merge confirmation (auto-linked when a PR merges).

What does not count as proof

• A comment saying “I think it’s fixed.”
• A screenshot without test backing.
• An unattached PR draft.

Evidence types

Zero accepts any file as proof. The type label classifies what the evidence is — it does not restrict what you can attach.

How to attach proof

1. Open the case in VERIFYING state.
2. Navigate to the Proof tab.
3. Click Attach proof — paste test output, upload a log file, or link a PR.
4. Mark the proof as verified.
5. Once 1+ proofs are verified, the RESOLVED button becomes active.

Proof and outcomes

• ConfirmedCodeBug — code changed, proof shows tests pass.
• IntendedBehavior — no code change, proof shows behavior is correct by design.
• Unreproducible — proof shows issue cannot be reproduced.

After proof is verified

1. RESOLVED becomes available. The state-transition button for RESOLVED is now active.
2. Outcome can be set. You classify the outcome (ConfirmedCodeBug, IntendedBehavior, etc.) before marking RESOLVED.
3. Regression memory is written. Zero writes regression-memory/{case-id}.md with root cause, outcome, and proof references.
4. PR ready-check is unblocked. If a PR is linked, the gh pr ready status is updated.
5. Proof comment posted to PR. If a PR is linked, Zero posts a proof summary comment. Issue auto-close is operator-controlled and disabled by default.

PR proof commenting and issue close are operator-controlled. Neither is enabled by default.

Proof checklist

Each Work item can have a proof checklist — a list of evidence items that must be attached before RESOLVED. When all checklist items are satisfied, the proof gate opens.

• When importing from GitHub, acceptance criteria automatically generate proof checklist items.
• Manual checklist: add items via the Proof tab or via POST /cases/:id/proof/checklist.
• Each item has a description and an expected evidence type: test log, diff, trace, screenshot, or operator note.
• RESOLVED is blocked until all required checklist items have verified proof attached.

{
  "checklist": [
    { "id": "ac-1", "description": "Auth timeout reproduces under load", "type": "test-log", "required": true },
    { "id": "ac-2", "description": "Fix does not regress existing auth tests", "type": "test-log", "required": true }
  ]
}

Proof for new Work (greenfield)

For greenfield projects — new features, new modules, or new services with no prior state to test against — proof works differently than for bugs. There is no “passing test that was previously failing.” Instead, proof is the verified evidence that acceptance criteria were met.

Accepted proof for greenfield Work:

• Initial test suite passing — new test coverage counts. Zero does not require tests against pre-existing state.
• Specification or acceptance criteria document attached as a markdown file.
• Operator-written acceptance note confirming each acceptance criterion was verified.
• Test log output showing new tests passing, alongside a diff of the code introduced.

Example of valid greenfield proof:

"Added auth module with 23 unit tests, all passing. Acceptance: JWT issuance,
refresh, and revocation verified. See attached test log."

Common pattern for greenfield Work:

1. Write acceptance criteria in the Work item before starting.
2. Run a verifying session — confirm each criterion is met.
3. Attach test output as the primary proof item.
4. Attach the diff as a second proof item.
5. Mark verified. RESOLVED becomes available.

Related: Case states, Outcomes explained, Work types.