Test count told you nothing about the merge gate; 17 attempts to beat it told you something

A developer publishing a merge-gate matching core went back and corrected his own metric: an earlier piece said the core had 56 tests, and he now calls that sentence close to meaningless ^[1]. That correction is worth more than the number, because test count is the usual way teams assert a protection gate works, and it says nothing about whether the gate can be walked around ^[2].

The stated design of the suite is the inversion: each test is a hypothesis that the gate can be beaten, and it passes only when the gate goes red ^[3]. The core is published at github.com/inviolable-dev/core under Apache-2.0, so the accounting is checkable ^[4].

The accounting is the interesting part. The evasion file holds 22 tests ^[5], but the author breaks them down rather than quoting the total: 2 for renames and moves, 2 for case-only changes, 2 for Unicode normalisation, 3 for path spelling, 3 for edits to the protection config itself, 5 for unverifiable states that must fail closed, plus 4 ordinary-case tests and 1 empty pull request that must stay green ^[6]. That is 17 attacks and 5 tests whose job is to prove the gate is not simply red always ^[7][8], reconciling to the file's 22 ^[26]. His reason for the split is operational: a gate that fails everything is not a gate, it is an outage ^[9]. He also notes that quietly rounding 17 up to 22 would undo the previous article's argument that every number had a source ^[25].

The gate answers one question deterministically: does this pull request's diff contain a path the author listed as protected ^[10]. It is path comparison with no model in the loop, and it returns a verdict only; the thing that actually holds a merge is your branch protection rule ^[10][11]. The narrowness is deliberate, because "is this change safe?" is open-ended and an agent can argue its way to yes, while "did anything in this list move?" has an answer ^[12].

The attacks read like a list of ways a naive matcher fails. Renaming a protected file away does not work, because a rename appears in the diff as both the old and new path, so the old path is still there to match ^[13]; moving a file into a protected directory is a violation too, since a glob such as src/billing/** protects the directory rather than the filenames that happened to be in it ^[14]. Case-only changes are the second attack: GitHub paths are case-sensitive, so a naive comparison lets Firestore.Rules through, and a case-only rename is an ordinary accident ^[15]. The gate falls back to case-folded comparison ^[16], and the author states the trade plainly: folding can produce a false red but not a false green ^[17]. The verdict carries kind 'case_insensitive' and a detail mentioning case folding, on the argument that an unexplained red gets ignored ^[18]; a repo deliberately keeping README.md and Readme.md gets a red it did not expect ^[19]. The third is the one he says he did not think of himself: cafe has two valid encodings, NFC with a single code point U+00E9 and NFD with e plus a combining acute U+0301, and macOS filesystems return NFD while most other tooling produces NFC ^[20][23]. A byte comparison matches one and sails past the other depending on whose laptop the branch came from ^[21]; the fix is normalising both sides to NFC ^[22].

Two things to watch. The 5 fail-closed tests are the load-bearing group, because unverifiable state is where a path matcher has to choose between an outage and a silent green ^[6]; whether that group grows as new unverifiable states appear is the real quality signal. The other is tolerance for the false reds case folding creates ^[17][19], since the design deliberately moves the enforcement decision into branch protection config you own ^[11].