Your Verification step completed in 46ms and reported PASS without executing
anything. It had never run.
`GateNodeRunner` recognised exactly two executable shapes, `prompt` and
`scriptName`. A gate carrying `workflowAction: "deterministic-verification"`
matched neither and fell through to the method's closing `return success`. The
code that runs testCommand/buildCommand was never reached — so the strictest gate
in the review lane was decorative, and it was supplying the merge evidence a task
is allowed to rely on.
The existing unit tests were green throughout, because every one of them called
`runDeterministicVerificationGate` directly. Testing a function proves the
function; it does not prove the graph calls it. The new wiring suite asserts the
routing itself and fails when the fix is removed — verified by removing it.
DRY: `verification-gate.ts` re-derived the command list and re-ran the loop, a
second implementation of a rule that `runExecutorDeterministicVerification`
(FN-3345, run-implementation.ts) already owned. The two had already drifted — the
copy treated "no command configured" as a hard failure while the original treats it
as not-applicable. The gate now delegates, so timeouts, per-command logging, and
settings precedence can only be fixed in one place.
NOT in this change, and deliberately so: recording an unrunnable gate as `skipped`
rather than `passed`. It is the right model and it was implemented end-to-end, but
`pre-merge-approval` clears a `skipped` step only for an audited operator bypass,
so it made every task on a project without a test command unmergeable — 25 of 90
smoke tests. Narrowing the acceptance left one unexplained failure (S09 sentinel,
120s timeout). Shipping that half-understood would trade a visible false green for
an invisible merge deadlock. FN-189 owns it with the full evidence.
pnpm lint 0 errors, test:gate, engine-pipeline-smoke 90/90, and three consecutive
full runs: 150.9s, 152.8s, 154.5s of the 175s budget.
28a8205645