Check reference
Regenerate fixtures when their model changes
A generated scenario belongs to the model that produced it. fixture_staleness_clean warns when controlled fixture evidence no longer matches its formalization inputs.
An optional evidence policy
This check is disabled by default. Enable project.checks.fixture_staleness_clean.enabled and list the relevant components under project.verification.fixture_evidence.components when generated fixtures are controlled project evidence. Components outside that list may keep fixtures as optional design aids. Retired, superseded and rejected requirements are excluded from the active fixture set.
Illustrative example: a changed timeout
A retry requirement changes from responding within three model ticks to responding within five. Its old fixture still encodes the three-tick model. Even if an implementation test accepts that old scenario, it does not demonstrate that the current scenario set has been regenerated.
Model before: response within 3 ticks
Model now: response within 5 ticks
Old fixture: generated from the earlier formalization
Action: regenerate and review the changed scenarios
Changing the intended timeout also needs normal requirement review. A fresh fixture cannot approve the requirement change.
Refresh only the affected evidence
Inspect whether the finding concerns FLIP scenario fixtures or Z3 property examples. Regenerate the named component using the matching producer. Review added, removed and changed cases, including cases for requirements that were superseded. Do not hand-edit stored fingerprints to imply regeneration.
proof testgen specs/system retry --engine heuristic
proof proptest specs/system retry --source z3 --output tests/retry/
proof audit --check fixture_staleness_clean --verbose
Freshness does not mean execution
Formalization text, strategy and variable definitions can change the generated evidence. Pure trace or review metadata should not itself change the formalization fingerprint. If it does, investigate the dependency rather than regenerating the whole repository blindly. The check establishes correspondence between fixtures and model inputs; it does not run production tests or demonstrate code-level MC/DC. Run and retain the actual tests that consume those scenarios separately.
Follow the evidence
Use the fixture type and component in the finding to choose the smallest useful regeneration run.
Review one stale fixture set. Bring the model change and generated cases so we can identify which evidence needs regeneration and which tests need a rerun.