Engineering guide

Gate an AI code change on its requirements

A useful gate asks whether the proposed revision still satisfies its governing promises. It needs current evidence and protected review policy, not only a test command that exits successfully.

Choose the change boundary

For a retry change, identify the approved retry policy, affected implementation, callers, timeout assumptions, and regression cases. Include the old guarantees that the task did not mention. A trace graph helps locate recorded relationships; review missing relationships and shared state explicitly.

Illustrative candidate. The agent extracts a retry helper. Required behavior includes a maximum attempt count, the original deadline, and no repeated side effect. The gate must not accept a simultaneous edit that removes the deadline assertion merely because the remaining tests pass.

Use a fast loop and a final gate

proof review req SYS-REQ-042 --gate
proof review req SYS-REQ-042 --gate --run
proof review req SYS-REQ-042 --gate --run --full

The first plans the requirement gate. The second executes the focused loop, including affected tests and audit checks. The third includes the full audit for final evidence. Inspect execution failures, skips, cache or fallback notes, and unavailable measurements alongside the verdict.

The audit CLI defaults to --fail-level warn, unless project configuration overrides it. Choosing a different threshold changes acceptance policy; document that decision rather than describing all warnings as harmless.

Protect the criteria as well as the code

Requirement edits, test deletion, weakened assertions, new waivers, and verification-scope changes alter what the gate accepts. Review them under the applicable authority policy. Agents may operate within delegated authority, but a request to implement a feature does not silently authorize weakening an older requirement.

Keep the approval and evidence tied to the candidate revision and relevant requirement state. If either changes after review, reassess the affected evidence. A report generated from yesterday's code is not a verdict on today's patch.

Connect the command to repository enforcement

To prevent merging, configure CI to run the applicable gate and require its result for the candidate commit. Protect the policy and verification configuration, and define who can bypass a required check. Proof's CLI does not establish those repository rules merely by running.

Keep a failed observation visible. If the change fixes a defect, preserve the reproducer, add a regression, review related cases, and record the closure scope. Passing a focused test closes neither an unexamined bug class nor every requirement in the project.

Continue from here

Preserve intent across agent tasks. Check change record backing.

Bring one pull request and the requirement you want its merge decision to protect. Bring a change to Proof.