What Is a CI Gate and Why Does It Block Bad Code From Merging?

I am the CI gate. In one sentence: I stand between a proposed change and the branch everyone depends on, and I refuse to let that change land until a defined set of checks -- tests, builds, reviews, scans -- all come back green against the exact code being merged, not code that used to be there or code someone promises will pass later. I don't write the checks. I enforce that they ran, and that they passed, before anything moves.

What I actually do, in order

Left ungated, a branch that everyone builds on will eventually break, because someone will merge something that looks fine, compiles on their machine, and quietly breaks a test they didn't run. That's not malice, it's just what happens without a gate: local confidence is not the same thing as verified confidence, and nothing forces the difference to matter until I exist.

My job runs the same way on every proposed change:

1. Pin to an exact snapshot. I don't evaluate "the branch" in the abstract. I evaluate one specific commit -- the exact head of the change at the moment it's proposed. 2. Run the required checks against that exact snapshot. Tests, build, lint, security scan, whatever the required set is for this branch -- all of it runs against that one commit, not a summary of it, not a promise about it. 3. Refuse to move on anything less than all-green. One failing required check blocks the merge. Not "merge and fix it after" -- blocked, full stop, until the check passes against a real re-run. 4. Re-check if the snapshot changes. If new commits land on the change after I already evaluated it, my prior green result no longer applies to the new head. I re-run against the new snapshot before I'll allow a merge, every time. 5. Let the merge through atomically against the exact head I approved. When I do allow a merge, I match it to the specific commit I evaluated. If the head moved between my approval and the merge attempt, that merge fails closed rather than merging code I never actually checked.

How I actually work here

In this operation, I'm the reason a pull request review isn't just a human or an agent reading a diff and having an opinion -- it's that opinion plus a real, reproducible, machine-run verification that the exact proposed code builds, passes its tests, and clears its security and quality checks. I'm the reason "looks good to me" is necessary but not sufficient: a reviewer can approve the intent, but I'm the one who confirms the mechanism actually works. I'm also the reason a review can't be quietly invalidated -- if someone pushes a new commit after a reviewer approved the old one, I know the head changed, and I don't let a stale approval cover code nobody actually re-checked.

I don't care who authored the change or how senior they are. I check the same required set against everyone's commits, because the failure I exist to prevent -- a broken build reaching the shared branch -- doesn't care about authorship either.

Where I fail

This is the part that matters more than the part above, so I'm not going to bury it.

I only enforce the checks someone configured me to require. If a check that matters -- a security scan, an integration test, a migration dry-run -- was never added to my required set, I have no opinion about it. A change can sail through me with a gap nobody told me to look for, and my green checkmark will say nothing about that gap.

A green result answers a point-in-time question, not a standing one. I can be green at the moment of merge and something else can be red twenty minutes later -- a dependency updated, a flaky external service recovered just long enough to pass, a race condition that only shows up one run in twenty. Looking at my current status and concluding "it must have been green when this merged" is exactly backwards from how to use me: the merge-time snapshot is the only one that matters, and it has to be checked at that moment, not inferred later from my current state.

I can be gamed by suppression instead of correctness. A check that's made to pass by disabling the assertion that would have failed, or by routing its output to somewhere nobody reads, looks identical to me as a check that passed because the code is actually correct. I see an exit code. I don't see whether the exit code means what everyone assumes it means.

Flaky checks train people to ignore me. If a required check fails intermittently for reasons unrelated to the change being tested, the predictable human response is to re-run until it's green, or to stop trusting a red result at all. Once that habit sets in, I stop functioning as a gate and start functioning as a formality people route around.

I can't tell a distinct reviewer requirement from an availability problem. If my rules require approval from someone who structurally cannot give it -- wrong role, no access, not actually authorized to review this class of change -- I don't know that. I just see an unmet requirement and block forever, indistinguishable to me from a legitimate pending review.

Tech-Tips

- Require checks against the exact head commit, and re-check on every new push. A gate that evaluates a branch instead of a pinned commit, or that doesn't re-run after new commits land, is not actually gating the code that ends up merged. - Treat a flaky required check as an incident, not an inconvenience. Every flake that gets "fixed" by re-running instead of root-caused erodes trust in every future green result the same check produces. - Audit what's NOT required, on a schedule. A gate only catches what it was told to catch. Periodically ask what class of failure could still reach the shared branch today, and add the check that would have caught it. - Never let a human or agent bypass the gate as a matter of routine. An override that exists for genuine emergencies becomes the default path the moment it's used casually, and a gate with a casual bypass isn't a gate. - Match merge authority to a specific evaluated commit, not a branch name. If the head can move between approval and merge without re-triggering me, the approval and the merged code can silently diverge.

Evidence: This piece describes the required-checks and merge-gate pattern as used throughout our internal continuous-integration operation (exact-head evaluation, all-required-checks-green enforcement, re-check on new commits, and atomic head-matched merge) -- no vendor or specific product is named, per the moat-protection and STORY-FORMAT conventions. Evidence class: internal operating record and Owner attestation, 2026-08-25.