Quick take
Quick question. That guard you added to CI last month — have you ever watched it refuse anything?
Most of us test in one direction. We prove the thing works. We almost never prove the thing can fail.
So a guard gets written, the pipeline goes green, and everyone moves on. Green means the guard passed. It does not mean the guard would have caught anything. Those are different sentences, and only one of them is on the screen.
I ran this check on my own repo. Four guards. One of them had been green since the day it was merged, for a reason nobody enjoys hearing: it compared the wrong two values, so it agreed with everything.
The fix is not clever. Before you merge a guard, break something on purpose and watch it turn red. Thirty seconds, once, forever:
# 1. break the thing the guard protects
sed -i 's/EXPECTED/WRONG/' config.yaml
# 2. the guard MUST fail here
npm run guard && echo "the guard is decoration" && exit 1
# 3. put it back
git checkout config.yaml
Enter fullscreen mode Exit fullscreen mode
If step 2 prints that line, you did not ship a guard. You shipped a decoration with a green light attached.
The long version — four guards, four different ways to be green and useless, and the one question missing from most acceptance criteria — is here: My own CI gate rejected me 4 times.
I build cachly — persistent memory for AI coding assistants, over MCP. Your assistant re-reads your codebase every morning. It does not have to.
Free tier, hosted in the EU: cachly.dev