The gate is separate from the review

A review and a gate sound similar until a branch protection rule has to make a decision. The review is the explanatory surface: findings, inline comments, summaries, and context for a human. The gate is the control surface: one required status check that either lets the head commit merge or blocks it. Postil exposes those as two GitHub check-runs, postil/review and postil/gate, because those jobs should not share one status.

One check cannot do both jobs cleanly

The gate documentation defines the split directly. postil/gate is the blocking verdict and the check teams require in branch protection. It fails when a finding reaches the configured threshold, whose default is error, or when the review cannot complete and the repository uses the default fail-closed behavior. postil/review carries advisory output and inline comments. The docs say not to require it.

That separation matters because advisory output is allowed to be more expressive than a merge rule. A warning can be useful without being a blocker. A clean review can leave no visible comment while the passing check-run remains the record. An operational error can be visible in the advisory check without quietly turning an unreviewed head into a passing gate.

The required check is the product behavior

GitHub branch protection works on named status checks. If a team wants an AI reviewer to block merges, the enforceable artifact is the check that branch protection requires, not the presence of a comment. In Postil, that artifact is postil/gate. The homepage describes the same split, and the setup path in the docs tells teams to add postil/gate to required checks while leaving postil/review advisory.

The evidence page shows the distinction in public examples. Each case is labeled by what the gate did: blocking, advising, or passing silently. The review content explains the finding when there is one. The gate state is the merge verdict. Those are related, but they are not the same artifact.

Why public evidence has to show the split

A product claim like "blocks merges" is only meaningful when the example shows which check carried the block and what source state it reviewed. The evidence-truthfulness work merged in postil-dev/postil#321 tightened the public examples around that rule: evidence cards now link to the source repository and to the pull request files at the reviewed commit. The evidence data also retains the reviewed head SHA and the review and gate check-run URLs as verification records.

The standard is simple: advisory text can help a reviewer understand the issue, but the merge decision must be visible as its own required check. Postil keeps that boundary explicit so a team can require the gate without turning every advisory note into a blocker.