BLOG / / 2 MIN READ / THE ELISHA TEAM
Between cloning the repository and touching a single file, every task passes through one step we call the gate. It runs exactly once per task, and it has three possible outcomes: accept the work, ask one question that sharpens it, or hand it back to a human.
Research is not optional
The gate never judges a bare ticket. Research always runs first, so the decision is made about the ticket next to what is actually in the repo — the file that the card says doesn't exist, the helper that already does what is being asked for, the three call sites the description forgot.
A card that reads "fix the coupon bug" is unanswerable in the abstract and perfectly answerable once you have grepped the checkout directory.
A question is the product; a stop sign is not
The gate's job is to help define the task. Early on we let a risk hit escalate a task into a state no reply could release — a keyword in a ticket could freeze work indefinitely. That was wrong on the facts. A run edits files in an ephemeral sandbox, pushes a branch, and opens a pull request. It cannot delete your data or touch production config.
So risk categories now produce a heads-up that rides along on the pull request and the message announcing it, rather than a block. The review that matters already exists one step later, at the diff — where you can see what the change actually touched instead of guessing from a keyword.
Flags have a budget
A rule that fires on the word "delete" in "the delete button should say Discard" will flag every card on the board, and a flag that appears on everything gets read as decoration. So the rules name the risky thing specifically: deleting records, not the word delete. Deploying to production, not the word prod.