Check reference
Connect generated scenarios to verifying tests
Generated scenarios can sit unused beside a green test suite. flip_test_alignment looks for source-native verifying test evidence for requirements backed by legacy FLIP fixtures.
The check follows declared fixture scope
The component must appear in project.verification.fixture_evidence.components. With no tests directory or no applicable FLIP fixtures, the check reports alignment as not applicable. The check then compares fixture-backed requirements with source-native Verifies: test evidence. When tests are missing, findings can include the scenario names and signal combinations from the fixture rows. These are concrete starting points for test design, not a guarantee that an annotation truthfully describes what a test does.
Illustrative example: a denied request
A generated authorization scenario has token_valid=false and expects denial. A source test annotated for the same requirement only supplies a valid token. The annotation connects a file to a requirement, but the negative behavior still needs an assertion and a real execution path.
Scenario: invalid token
Arrange: a request with a rejected credential
Act: call the public authorization entry point
Assert: access denied and no protected operation performed
This test outline is illustrative. Replace the inputs and observable effect with those of the real system. Checking only that no exception occurred would miss an unintended allow.
Review the requirement's evidence
Inspect the requirement and its scenario table. For each relevant case, find the source test that creates the condition and asserts its outcome. Add missing tests, repair incorrect annotations, or correct a fixture that encodes the wrong requirement. Use the project's real test runner to execute the resulting tests and retain the run evidence.
proof mcdc show AUTH-REQ-001
proof audit --check flip_test_alignment --verbose
Alignment is weaker than observed coverage
This warning is about the connection between fixture scenarios and source-native evidence in the configured scope. It is not a substitute for observed code decisions, condition independence, or test-run provenance. A fixture-level independence witness belongs to the formal requirement; code-level MC/DC needs execution evidence for the implementation's decisions. Keep those reports named separately when presenting coverage.
Follow the evidence
Use one uncovered scenario to write a test whose failure would contradict the requirement.
Review one uncovered scenario. Bring its generated signals and source tests so we can identify the execution and assertion needed to support the requirement.