The two numbers answer different questions, and both are honest. "36/36 biting mutants" reads as: for every mutant in the corpus, something went red [3]. It does not say which guard line bit, and it says nothing about the lines no mutant ever reached. Deletion is the only probe that separates those cases [1].
Arithmetic closes some of the gap before you run anything. Thirty-six mutants cannot be paired one-to-one with 61 guard lines, so at least 25 lines have no mutant of their own [4]. The measured result was worse than the pigeonhole floor: 40 unmeasured, leaving 21 lines whose presence any test can distinguish from their absence [2][2].
For 66% to transfer to your repository, the ratio would have to be a property of guards in general rather than of this guard set against this mutant corpus, and it is not: both come from one author's engine, measured in one release he already suspected [2][5]. Widen the operator set your mutants are generated from and the rate moves. Write guards for input classes your fixtures never produce and it moves the other way. That second case is the Blind Gate in the post's own taxonomy, alongside the gate that fell out of CI and the gate whose internal errors are swallowed by a soft error flag: it runs, it exits 0, and the input required to trigger its logic is never produced [6]. So the careful carry into review is narrower than the author's line about a comment pretending to be a guard [15]. Forty lines are unverified. That is not the same as wrong, and it is still not evidence.
The harness is linear in guard count. Sixty-one lines means 61 sabotage runs plus the baseline, so 62 full suite executions [3].
Two design rules keep it survivable. Each sabotage works on a temporary copy, so the working source file hafiza.py is never edited in place [13]. And the finder is an AST parse rather than a regex, because a regex silently misses multi-line calls, which would make the measurement tool blind in exactly the way it is trying to detect [12].
The detail I would steal is the encoding one. The hukum_kapisi.py gate matches explicit ASCII character patterns instead of UTF-8 dashes, because when Python's errors="replace" handler fires, a dash can print as "?", and a gate matching unicode dashes would be broken by the same encoding failure it exists to catch [14]. The other half of the proof is easier and gets skipped anyway: a gate also has to stay silent on clean input, or you have kept a false-positive generator with good manners [9].
