test_completion_order_is_alpha_then_beta
test_R08_gather_order_assumption.py · failed in 10% of captured runs
Forcing finish_beta to start before finish_alpha reproduced the failure on every attempt, so that ordering is a sufficient condition for the failure.
Both operations have 'access: "write"' and neither reads what the other produced. Their relative order is not established by the code under test, so the assertion demands an ordering nothing promises.
Where the two runs diverge
The same test, twice, on a shared time axis. The outlined pair is the ordering that differs.
Outlined: finish_beta#0 starts before finish_alpha#0 in the failing run, and after it when the test passes.
Evidence
Suspicion comes from comparing runs. The decision comes from forcing the ordering and seeing what happens.
| Ordering | Suspiciousness | When forced | Verdict |
|---|---|---|---|
| finish_beta#0 → finish_alpha#0the assertion depends on this | 1.00 | fails 100% | reproduces the failure every time it is forced |
One scheduling constraint is enough to reproduce this failure.
Policy gate
Every check the proposed patch had to pass before it was allowed to run.
No patch was proposed, so there was nothing for the policy gate to review.
Verification
What was established, and at which strength. A weaker check is never presented as proof.
Verification did not run: no patch reached it.