Repair formal proofs while preserving reviewed specifications

Why use this

1. A proof repair can make a checker accept changed code while altering a definition, strengthening a precondition or weakening the theorem the team intended to preserve. The visible completion of proof obligations does not by itself show that the reviewed specification survived.

2. A premise-and-change review packet could distinguish proof-script adjustments from changes to the mathematical contract. Formal-methods reviewers could inspect every proposed assumption and boundary change before deciding whether an authorized checker run and merge are appropriate.

Why an agent / simpler alternative

Useful judgment

Trace proposed proof changes to affected definitions and assumptions while flagging shifts in the statement being established.

Simpler alternative

Repair a localized tactic script manually when the specification and dependency boundary are clear.

Unsuitable when

No qualified reviewer can assess changed invariants, premises or theorem statements.

Proposed inputs

1. Name

   Proof-change description

   Owner

   Formal-methods maintainer

   Minimum scope

   Fictional theorem statements, invariant summaries and proposed edit categories

   Quality check

   Separate proof steps from specification changes.

2. Name

   Reviewed contract

   Owner

   Specification owner

   Minimum scope

   Preserved definitions, allowed assumptions and discussion requirements

   Quality check

   Identify premises requiring concrete justification.

Access and setup — proposed or unknown

Proposed minimum

1. Offline symbolic descriptions and a premise-difference manifest without a proof assistant.

Compatibility unknowns

1. Unknown: current runtime, proof-library versions, checker configuration and assumption-audit tooling.

External actions requiring approval

1. Definition, invariant, theorem or precondition changes; separately authorize builds, repository writes and merge.

Expected deliverable and review checks

Proposed artifact

Proof-change classification with premise differences, specification impacts and reviewer questions.

Critical checks

1. Every added assumption or altered statement is highlighted explicitly.

2. A proposed checker pass is not treated as evidence that the original contract is preserved.

Missing output evidence

No new workflow run or output inspection was performed for this overlay; use the canonical source-outcome references.

Failure signals and proposed responses

1. Signal

   A repair adds a stronger precondition without justification.

   Why it matters

   The theorem may apply to fewer cases than intended.

   Proposed response

   Hold the change for specification-owner review and require a concrete rationale.

2. Signal

   A theorem statement changes inside a supposedly proof-only patch.

   Why it matters

   The scope of the established claim may shift unnoticed.

   Proposed response

   Reclassify the patch and require explicit formal-methods review of the new boundary.

Effort and cost — unknown

Setup work

1. Record reviewed statements and premise-audit requirements.

Ongoing review

1. Inspect semantic changes and later authorized checker evidence.

Unknowns

1. Unknown: build cost, library compatibility and expert review effort.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

A fictional proof-change manifest labels an added precondition and altered theorem conclusion as tactic-only edits.

Acceptance checks

1. Reclassify both as contract changes.

2. Require reviewer justification without claiming a proof has been checked.

Stop conditions

1. Proof execution, real theorem editing or correctness certification is required.

Limits

1. This proposed premise checklist proves nothing; it cannot establish logical soundness, checker acceptance or specification preservation.