Deterministic gate on node entry in a team run

Today a team node's guardrails live entirely in stepInstructions and in the skills it loads. That makes every guardrail advisory: it holds only for as long as the LLM reads the text and complies. We run an operational kill-switch (a repo variable that must halt all automation instantly) and we had to implement it as "first line of every node's instructions" — which means a node that simply doesn't follow the instruction runs anyway, and nothing notices. checkCommand doesn't cover this. It's an exit gate: it runs in the handoff path, after the agent has already completed the step. By then the work is done. There is no hook between entering a node and the agent acting. Proposal — entryCheckCommand + entryCheckPolicy on the node, symmetric with the existing checkCommand/checkFlag, but executed by the runner before spawning the agent. Exit 0 proceeds; any other exit, a timeout, or a spawn error blocks the run. entryCheckPolicy chooses between blocking the run and skipping to a designated node. Acceptance criteria 1. With the check command returning non-zero, the run blocks at the first node having consumed zero LLM turns — verifiable in the run's token accounting. 2. The block is visible in the UI with the command's stderr, not a silent skip. 3. A node without entryCheckCommand behaves exactly as today. 4. Command timeout and spawn failure are treated as failure (fail-closed), never as success.

This gathers what several people told us separately. Their original messages stay private: only this rewording is public, and nobody sees who wrote what.

Discussion0

You will be told by email and in the app on every reply. Every message carries a link to stop them.