feat: Implement two-sided verification check with check modes

[MikaelMayer]

Summary

Replaces the single-sided reachCheck flag with a two-sided verification framework using orthogonal check mode and check amount flags. Each proof obligation now produces a VCOutcome with independent satisfiability and validity properties, enabling richer diagnostic feedback.

Problem

We want to perform richer checks on assert statements beyond simple validity. Covers are existential checks where forking into two means the results are linked by an OR, so they are not suitable for detecting assertions that surely fail along a path. To find such failures, checks must be encoded as assertions, and we need extended diagnostics for them.

A previous PR opened the way by adding a reachability check, demonstrating that two checks per command are feasible. However, the reachability check missed an important case for bug-finding mode: from reachability + validity alone, we cannot derive the result of reachability + satisfiability. By testing both P ∧ Q (satisfiability) and P ∧ ¬Q (validity) where P is the path condition and Q is the property, we get two checks that together determine the validity and satisfiability of Q given P, and also derive reachability.

Solution

Two orthogonal flags replace reachCheck:

• Check Mode (--check-mode): deductive (default) or bugFinding
• Check Amount (--check-amount): minimal (default) or full

A per-statement @[fullCheck] annotation can override the global check amount.

Possible outcomes by mode

Default mode (deductive, minimal): validity check only for asserts, satisfiability check only for covers.

For assert statements (validity only, satisfiability masked to unknown):

Emoji	Label	Meaning
✔️	always true if reachable	Validity passed, property always true if reachable
➖	can be false and is reachable	Validity failed, solver found a reachable counterexample (with model)
❓	unknown	Solver could not determine validity

For cover statements (satisfiability only, validity masked to unknown):

Emoji	Label	Meaning
➕	can be true and is reachable	Satisfiability passed, property can be true and is reachable from declaration entry
✖️	refuted if reachable	Satisfiability failed, property always false if reachable
❓	unknown	Solver could not determine satisfiability

Bug-finding mode (bugFinding, minimal): satisfiability check only for all statement types. Same as the cover table above.

Full mode (full): both checks run, all 9 outcomes possible. The last two columns show the error reporting level in SARIF output for each mode (✅ = pass, 🔴 = error, 🟡 = warning, 🔵 = note).

Emoji	Label	P ∧ Q	P ∧ ¬Q	Inferred reachability	Meaning	Deductive mode error level	Bug finding mode error level
✅	always true and is reachable	sat	unsat	✅	Property always true, reachable from declaration entry	✅	✅
❌	always false and is reachable	unsat	sat	✅	Property always false, reachable from declaration entry	🔴	🔴
🔶	indecisive and reachable	sat	sat	✅	Reachable from declaration entry, solver found models for both the property and its negation	🔴	🔵
⛔/❌	unreachable	unsat	unsat	❌	Dead code, path unreachable (⛔ warning for assert, ❌ error for cover)	🟡/🔴	🟡/🔴
➕	can be true and is reachable	sat	unknown	✅	Property can be true and is reachable from declaration entry, validity unknown	🔴	🔵
✖️	refuted if reachable	unsat	unknown	❓	Property always false if reachable, reachability unknown	🔴	🔴
➖	can be false and is reachable	unknown	sat	✅	Solver found a model for P ∧ ¬Q: path is reachable from declaration entry and Q can be false, but satisfiability of Q is unknown	🔴	🔵
✔️	always true if reachable	unknown	unsat	❓	Property always true if reachable, reachability unknown	✅	✅
❓	unknown	unknown	unknown	❓	Both checks inconclusive	🔴	🔵

Testing

All existing tests updated. New tests cover the full outcome matrix including per-statement @[fullCheck] annotations. BoogieToStrata integration tests, Python analysis tests, and SARIF output all updated.

[MikaelMayer]

incomplete, then indeed you don't care about that case.

However, if we think providing complete preconditions is simpler than providing a correctness proof, then I think "test for all proven bugs assuming that the preconditions are complete" could be useful. There are many bugs that only trigger on some inputs, so we could find a lot more bugs with this mode than with the bug finding mode that you're describing.

I understand better now, thank you very much for the explanation. It seems rational to have an intermediate between bug finding (where preconditions are typically absent) and deductive (where complete preconditions are expected), where we want bug checking in full mode to report (sat, sat) as a failure.

I thought about it a lot and decided to make it a mode (not an additional flag), but that mode forces the check level to be full, as we can't report negative counter examples if we don't check validity.