`merge-confirmed-finalize` carves out one case: a no-op merge confirmation with no landed
commit is not proof the work was done, so when the steps are still unfinished the run must
fall through to stale-merge cleanup and reverification instead of being consumed there.
It selected that case by comparing the blocker reason with `===` against the exact string
"task has incomplete steps". The merge-authority work then made refusals more informative, so
a card in an error state reports `task is marked 'failed': … task has incomplete steps`. Same
meaning, different sentence — and the comparison stopped matching, silently. A filter pinned
to "subject is exactly Invoice" once invoices began arriving as "Invoice — March 2026".
Nothing in the merge gate said so, because the test guarding this case lives in a file the
gate does not run. It has been red on main since that lane landed.
`hasNonTerminalSteps` states the rule the message describes and is defined from the same
`NON_TERMINAL_STEP_STATUSES` set as `getTaskMergeBlocker`, so the two cannot drift. A blocker
message is written for an operator and will be reworded again; the condition underneath it is
what callers actually mean.
The new core test pins them apart deliberately: it asserts the sentences DIFFER between a
plain card and a failed one while the rule answers the same, and that the rule agrees with the
door for every step status. A future prefix cannot re-break this quietly.
pnpm lint 0 errors, test:gate green, core + engine typecheck clean, pipeline-smoke 93/93,
ce-workflow-step-executor 53/53 (was 52/53 on main).
cdef6ad7e8