Safe to install: read-only, no network, no credentials, zero dependencies
Anything you wire into a build pipeline runs with your build's permissions, and the tools ecosystem has learned to ask hard questions before granting that. no-fabricate gate is built for those questions. It reads local files, writes nothing, calls no network, touches no credentials, never runs unless you invoke it, and installs zero dependencies. You do not have to take any of that on trust: the whole gate is a handful of small source files you can read before you run them.
The properties, exactly as scoped
Read-only: the gate scans files and exits with a code. It writes nothing to your tree, so the worst a bug can do is a wrong exit code, not a changed file.
No auto-run: it is invoked explicitly, as a CLI or an imported function. There is no install hook, no session hook, no daemon, and no side effect at import time. If you did not run it, it did not run.
No network, no credentials: it is pure local regex over local files. It has no HTTP client to call and no key store to read, so your drafts and your figures never leave your machine.
Zero dependencies: it needs Node 18 or newer, or Bun, and nothing else. An empty dependency tree is a supply-chain property: there is no transitive package to compromise, because there are no packages.
Verifiable beats trusted
These are strong claims, and the right response to strong claims from an unfamiliar tool is to check. The gate is deliberately small enough to make checking practical: an extraction module, an engine, and a CLI. You can read every line that executes before granting it a place in your pipeline, which is a different trust model from auditing a plugin with a deep dependency tree.
The behavior is covered by the repo's own test suite, which you can run locally before first use. The tests pin the extraction shapes, the normalization, and the failure modes, so what the documentation claims and what the code does are checked against each other in the open.
Fail-closed is a safety property too
A gate that fails open is a decoration. no-fabricate gate treats its own misconfiguration as a failure: a missing manifest, a sources entry without a claim, value, or URL, or a malformed ignore list stops the build with a distinct error exit code instead of quietly passing everything. The distinction matters in CI, where a silently skipped check looks identical to a green one until something fabricated ships.
The same posture extends to what the gate refuses to guess about. It does not fetch your sources to judge them, does not rewrite your copy, and does not decide which numbers are yours; you declare that in the manifest, under version control, where the decision is visible in review.
Keep reading, then read the source.
- no-fabricate gate: what it is
- Why AI invents numbers, and how to catch it
- Source packs: the manifest that gates your build
- The same posture in the sister gate: de-AI gate
- View the source on GitHub
no-fabricate gate is open source under the MIT license. Read it first, then run it. That order is the point.
Read the source on GitHubFAQ
Does it phone home, collect telemetry, or send my content anywhere?
No. It makes no network calls of any kind. It reads the files you point it at, compares extracted statistics against your local manifest, and exits with a code. Nothing leaves your machine.
Can it modify or delete my files?
No. It is read-only by construction: it opens files to scan them and writes nothing back. Its only outputs are console text and an exit code.
What is the supply-chain surface?
The gate itself, and nothing else. It declares zero dependencies, so installing it adds no transitive packages. The source is small enough to review directly, which is the strongest supply-chain answer a build tool can offer.
What happens if I misconfigure it?
It fails the build with a distinct error exit code rather than passing silently. A malformed or missing manifest is treated as an error, never as permission, so a configuration mistake cannot quietly disable the check.