You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#776 gates the behavioral UI suite to push on dev, so a release commit no
longer earns its own UI run — it inherits dev's. That is the intended
trade-off and it is recorded in the ci.yml comment above the step.
The inheritance is a convention, not a guarantee.
Problem
concurrency.cancel-in-progress: true cancels a dev run when the next dev
push lands. So this sequence leaves a shipped commit with no green UI run
anywhere:
Version-bump commit lands on dev; its CI run starts.
Another merge lands on dev before that run finishes; cancel-in-progress
kills it.
Nothing surfaces this. The release proceeds and looks normal.
Frequency
Checked the last 8 releases. It happened once — run 31319081463, superseded
after 4m36s.
The other 6 non-green dev runs in that window were all the #775 90-minute
wedge, which is now fixed, so the forward-looking rate should be lower than
that history suggests. This is a real gap, not an urgent one.
Current enforcement
docs/release.md step 2 ("make sure dev is green") — a human step, and the
failure mode above is one where devis green at HEAD while the specific
commit being released is not.
Possible directions
Not yet decided; whichever is cheapest that actually closes the loop.
Have scripts/build-release.sh (or a pre-tag check) query the Actions API
for a successful run on the exact commit SHA being released, and refuse to
proceed otherwise.
Run the UI suite on main pushes only when no successful run exists for that
SHA — recovers the coverage without paying for it on the normal path.
Drop cancel-in-progress for version-bump commits specifically.
Acceptance criteria
Releasing a commit whose dev UI run was cancelled or never ran either
fails loudly or triggers the missing coverage.
The normal path — a release whose dev run went green — costs no extra
runner time.
Context
#776 gates the behavioral UI suite to
pushondev, so a release commit nolonger earns its own UI run — it inherits
dev's. That is the intendedtrade-off and it is recorded in the
ci.ymlcomment above the step.The inheritance is a convention, not a guarantee.
Problem
concurrency.cancel-in-progress: truecancels adevrun when the nextdevpush lands. So this sequence leaves a shipped commit with no green UI run
anywhere:
dev; its CI run starts.devbefore that run finishes;cancel-in-progresskills it.
mainand tagged. Itsmainrunskips the UI step (ci: dev-to-main fast-forward runs the identical commit twice, serially #776). Its
devrun was cancelled.Nothing surfaces this. The release proceeds and looks normal.
Frequency
Checked the last 8 releases. It happened once — run 31319081463, superseded
after 4m36s.
The other 6 non-green
devruns in that window were all the #775 90-minutewedge, which is now fixed, so the forward-looking rate should be lower than
that history suggests. This is a real gap, not an urgent one.
Current enforcement
docs/release.mdstep 2 ("make sure dev is green") — a human step, and thefailure mode above is one where
devis green at HEAD while the specificcommit being released is not.
Possible directions
Not yet decided; whichever is cheapest that actually closes the loop.
scripts/build-release.sh(or a pre-tag check) query the Actions APIfor a successful run on the exact commit SHA being released, and refuse to
proceed otherwise.
mainpushes only when no successful run exists for thatSHA — recovers the coverage without paying for it on the normal path.
cancel-in-progressfor version-bump commits specifically.Acceptance criteria
devUI run was cancelled or never ran eitherfails loudly or triggers the missing coverage.
devrun went green — costs no extrarunner time.
docs/release.mdreflects whatever mechanism lands.Spec
docs/superpowers/specs/2026-08-26-ci-ui-test-watchdog-design.md— the #776half. Follow-up to #776.