Lemma binding freshness

The check is lemma_binding_freshness. It is verify-stage. Severity of a drift is warning, not fail. The inspect command is proof bindings, plus proof verify-lemma --no-cache ./....

The hop joins every // reqproof:lemma ... binds-to ... entry in .proof/lemma-bindings.json against the live source. Two hashes are stored: target_func_hash over the gofmt-normalized bound function, and lemma_body_hash over the funclit. A change on either side is a finding. The kinds are target_drift, lemma_drift, both_drift, and unresolved when the directive is gone.

The help file teaches the silent binding first. The proofs package never imports the production package. Nothing in the suite asked whether the hashes still matched.

// proofs/abs_lemmas.go
// reqproof:lemma abs_positive_identity binds-to mathx.Abs

// mathx/abs.go  (body changed after last verify-lemma)
func Abs(x int) int {
    if x < 0 {
        return -x
    }
    return x
}

# .proof/lemma-bindings.json
# abs_positive_identity target_func_hash still the old SHA-256

# proof audit --check lemma_binding_freshness
# [VERIFICATION] lemma_binding_freshness
# abs_positive_identity target_drift binds-to mathx.Abs
# silent binding: last PROVE still on disk

Re-prove with proof verify-lemma --no-cache if the live function should still satisfy the claim. Re-read the funclit when the drift is lemma_drift or both_drift: a weaker lemma will PROVE and still refresh the hash. Restore the directive, or delete that one entry, only for unresolved. Then re-run the same check. Do not wipe .proof/lemma-bindings.json to make the warning disappear. With no bindings the check skips, and the trace that made the last PROVE trustworthy is gone.

proof bindings
proof bindings --binding-view per-function
proof verify-lemma --no-cache ./...
proof audit --check lemma_binding_freshness --verbose

The teaching graph is still one lemma whose last PROVE sat on disk after the bound function moved. Close it by re-running proof verify-lemma --no-cache until the solver decides the live body, by restoring a directive that was removed by accident, or by deleting one entry whose lemma is genuinely gone. Hand-editing target_func_hash or lemma_body_hash is the same as wiping the file with extra steps: it asserts a proof was re-run when it was not. Only proof verify-lemma should write those hashes. An absent or empty bindings file is a skip, not a pass that the Go is correct.

# after proof verify-lemma --no-cache ./...
# .proof/lemma-bindings.json
# abs_positive_identity target_func_hash = live Abs
# abs_positive_identity lemma_body_hash  = live funclit

# proof audit --check lemma_binding_freshness
# no drifted pair. this hop is quiet

The solver hop stays on Z3/Kind2 on one function. The status hop stays on formalization lemma verdict consistency. Jama still authors. Proof vs Jama.

Warning, not fail. Not blocking. No project loaded is a pass. No .proof/lemma-bindings.json, or an empty one, is a skip, not a fail. Projects that never used separate-file lemmas should not see this check warn. The hop looks at the persisted hash pair and the live source. It does not re-run Kind2. It does not re-run Z3. It does not write the hashes. It does not prove the Go. A matching hash is freshness, never correctness: a weaker funclit will hash-match after you accept it. Raising severity to error in proof.yaml is a strictness setting, not a remediation. We have not scored this floor against a frozen Jama pack or a ReqIF export. The loss is named, not scored.

The solver hop stays on Z3/Kind2 on one function. The engagement stays on software correctness audit. Jama still authors.

What is lemma binding freshness? Same question. Same URL.

Is this Z3 or Kind2 on one function? No. That hop runs the solver. This hop asks whether a last PROVE still describes the live function. See Z3/Kind2 on one function.

Is this formalization lemma verdict consistency? No. That hop is a SYS-REQ that still says valid while the lemma cache is timeout. This hop is the SHA-256 pair on a separate-file binding. See formalization lemma verdict consistency.

Is this assume contract consistency? No. That hop is a source // reqproof:assume whose callee lemma must exist. This hop is a binds-to hash. See assume contract consistency.

Is this lemma branch coverage? No. That hop is AST branches no lemma translation reached. This hop is whether a binding you already have is still the live code.

Does a tree with no separate-file lemmas pass? The check skips when the bindings file is missing or empty. That is not a proof that the Go is correct. It is a proof that this hop had nothing to join.

Does a green hop prove the code matches the shall? No. The hop observes hashes and source. It does not prove the Go.

Is Proof a Jama alternative for the shall? No. Jama still authors. Proof vs Jama.