The U4 executor peel (#3317) rewrote executor.ts from a pre-change base and
dropped `isPrincipalHoldCoolingDown`, re-inlining the read inside
executeWorkflowGraph behind `!opts?.alreadyClaimed` — a flag its only caller,
executeCore, always sets. The ladder kept recording and clearing correctly, so
it read as working while never once deferring a dispatch.
Without it, an unroutable role pool re-enters the graph on every dispatch only
to re-fence and re-park: one graph run, two work-item writes and two audit rows
per pass, for a condition that clears only when an operator enables or adds an
agent. The `!repeated` log suppression keeps that flood invisible after the
first line.
Restore the guard in executeCore, ahead of the graphRouting claim. Position is
load-bearing in both directions: returning after the claim would strand it
(graphRunnerOwnsClaim stops the finally from cleaning up), which is also why
the inner check must keep its alreadyClaimed gate.
Make the ladder a primitive with one exported writer and one exported reader so
a lost reader is a lost reference the compiler can see, rather than a .get()
that quietly moved somewhere its guard could never be true. Its test-mode zero
is now read at record time; bound at module load it collapsed the cooldown to
until === now under VITEST, so no test could have caught this.
Regression test asserts the invariant on both entry surfaces plus the negatives
that keep the guard from becoming a permanent block. Mutation-checked: with the
guard disabled the two dispatch-deferral cases fail.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
08f8c26ec1