The Review Gate Is A Named Step

Version 1.0.0 shipped on 2026-04-02 with 1 gate. Version 2.0.0 shipped on 2026-04-03 with 2. The second version did not replace the adversarial pass. It put a cheaper check in front of it, because a review that runs before a change and a review that runs after it fail on different things. Tier 1 is a pre-apply review: the delegate works in an isolated git worktree and the diff is read inline by the executor, with no external model call and no cost beyond the read. Tier 2 is the adversarial pass on code that is already in the working tree. Both tiers draw on 1 shared delegation slot, so they run serial, never concurrent. That constraint is not housekeeping. 2 reviews racing each other return 2 opinions, and an opinion is not a gate. The order is Tier 1, then apply, then Tier 2, and the order is the mechanism.

Tier 1 exists because the cheapest place to reject a bad change is before the change is applied. The delegate runs inside a throwaway worktree, so the working tree stays untouched while the work happens, and the output is 2 things: a message and a diff. The executor reads the diff inline and lands on 1 of 4 decisions. Clean, and the patch is applied with git apply or copied across by hand. Minor concerns, and it is applied with inline fixes noted in the summary. Significant concerns, and the change is rejected, the prompt is refined and the delegate is retried. Non-zero exit, and the failure is logged while the task is implemented directly. Note the last 1: a Tier 1 failure never blocks a task. It degrades to direct implementation, and the summary says so in writing. A rejected suggestion costs 1 prompt rewrite. A rejected commit costs a rollback, a rebuild and a lost wave. The probability that a defect is caught rises with every step it is moved earlier, and Tier 1 moves it to the earliest step that still has enough information to judge.

Tier 2 asks a different question: not should this land, but does what landed hold. It is invoked after the code is in the working tree and its brief is adversarial by construction. Correctness. Error handling. Edge cases. Security. Not a summary of what was done, and not applause. The pass is read-only, which is why it needs no isolation: it reads existing code and writes no files, so a worktree would add nothing. Findings are integrated by the executor rather than auto-applied, which keeps 1 readable step between a review comment and a commit. Failure handling here is deliberately soft. An auth error is logged and the run proceeds. A timeout past 300 seconds is logged and the run proceeds. An empty output file is logged and the run proceeds. The gate never blocks completion, which is exactly why it can be mandatory without being feared. A gate that can halt a plan gets argued with. A gate that logs and proceeds gets run.

A review that returns a paragraph has returned a conversation. A review that returns ranked findings has returned work. The ranks are simple and 3 of them matter in practice: P1 and P2 are fixed inline before the summary is written, P3 and below are logged under review findings and carried, with a follow-up task created when a finding warrants 1. Every summary that ran the gate carries exactly 1 line about it, either PASS with no findings or FINDINGS with a short summary. That line is the audit trail. A reader can open any completed plan from the last 12 months and know whether the gate ran, what it found and what was done about it, without reading the review itself. Ranking also settles the argument about perfection. A P4 that would take 2 days to fix is not a reason to hold a wave that is otherwise green. It is a row in the next planning pass. Fixed, logged or carried: 3 outcomes, all of them recorded.

Version 2.0.0 arrived 1 day after 1.0.0 and added the first tier. It did not replace the second.

The trigger table is 6 rows and it removes judgement from the question. A plan with code files in files_modified is mandatory. A plan with a requirements field is mandatory. Auth, API and integration work is mandatory. A plan that delegates through the isolated wrapper is mandatory, because Tier 1 is automatic on that route and Tier 2 follows the implementation. A documentation-only plan, markdown files and nothing else, skips the gate entirely. And an auth error or a timeout on invocation is a skip with a log line, never a hard stop. 1 table, 6 rows, 2 outcomes, 0 judgement calls. The value is not that the table is clever. The value is that nobody has to decide on a Thursday afternoon whether this particular change is the kind that deserves a review. It either matches a row or it does not. Rules that require interpretation get interpreted in the direction of the deadline.

Placement is the whole discipline. The gate sits after the last code task in a wave completes and before the summary is written, and it never shares a wave with a delegation task, because the slot is shared and serial is the rule. So the flow is flat and readable: the wave completes, Tier 1 reviews the proposed diffs, the changes land, Tier 2 argues with the result, findings are ranked and either fixed or carried, and the summary is written with 1 line about the gate. 5 movements, same order on every wave. EX Venture runs the same shape across its studio: 35 staff and 200 plus interns a year, work built across 12 countries, 450 plus generated articles and films behind the pipeline, and every render order passing a named check before it ships. The reason is identical in both places. A step that is named can be audited, skipped visibly and improved. A step that lives in someone's habit lasts exactly until the week they are busy. Name the step, give it 2 tiers and 1 slot, rank the findings, write the line. That is the gate.