You asked why I could not prove it. Because I kept trying to prove it THROUGH S05,
which asserts a different property — no merge without a current approval — and
reaches it by racing the background auto-merge. That race is the source of its
intermittency, and it has nothing to do with remediation.
The behaviour itself does not need that race. `pipeline-remediation.pipeline.test.ts`
drives it explicitly, turn by turn, and asserts three things in order:
1. a Code Review REVISE appends a step carrying `remediation` metadata — named
work derived from the reviewer's findings, not a bare bounce;
2. no step is left pending — the appended work is actually executed, which is the
failure mode that previously left it `pending` forever;
3. `mergeDetails.mergeConfirmed` — the loop terminates instead of merely looking
alive.
Five consecutive runs, five passes.
REVERTED in the same change: the `workflow-graph-foreach` relaxation that let a
sequential region grow past its pinned step count. I justified it with a measured
failure, but that measurement came from a configuration since fixed elsewhere and no
longer reproduces — with the growth removed the full lane passes 89/89, including
this new drive. An engine change to a core execution primitive that no failing test
requires is dead weight on a hot path, so it goes rather than staying "just in case".
A future case that genuinely needs growth must arrive with a test that fails without it.
pnpm lint 0 errors, test:gate, verify:fast, and three consecutive full runs:
133.1s, 136.0s, 134.2s of the 150s budget.
bf147d6ade