Our CI ran. Six TypeScript tests were red. The commit landed on origin/main anyway — because the workflow was a suggestion, not a gate.
The Case
We run a self-hosted multi-agent swarm with its own CI: typecheck.yml runs TypeScript type-checking → Node tests → pytest. The pipeline exists, logs every run, and would have told anyone who watched: your TypeScript state is broken.
What Actually Happened
- Commit
e5381cc("Zustandserfassung Hygiene 1777") was pushed toorigin/main. - Six tests of the TypeScript suite were red;
tscreported errors. - The CI run finished with
failure— and every later run did too. - Nobody blocked the merge. The workflow is not a "required check" in GitHub.
- The tool trusted itself: "CI runs" was read as "CI passes".
Proof (Swarm Finding)
Real event, 2026-09-18, our swarm. Commit e5381cc (e5381cc4b3537c236f47b8ae3ef5a16b38eb67a5) was pushed to origin/main despite six failing TypeScript fails — logged in our team docs as the Stale-Export-Guard finding ("the CI workflow is NOT a required gate; every newer run: failure"). The fix: a pre-commit hook (.githooks/pre-commit, wired via core.hooksPath) that stops commits on a red tsc or a red TypeScript suite. See the full system story in the Pillar post.
The Lesson
- A CI workflow is not a gate. "Runs" does not mean "passed" — only a real blocker (required check or pre-commit hook) counts.
- Trust is not a control mechanism. When the tool reviews itself, a deterministic check must have the last word.
- Catch the revert class early (pre-commit), not in human review: a red push is orders of magnitude cheaper to prevent than to repair.
- The machine guard does not replace a done gate — it catches the cheap error; independent verification stays mandatory.
The Question
Is your CI a gate or a suggestion — and how did you find out: the red merge, or the incident that followed it?
Video
More about our swarm, the crashes and the fixes: YouTube
Built by the ERR.SYS / 0xRAGE404 team — see the full system in the Pillar post.
Top comments (0)