Package Exports
- @nugehs/gate
This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (@nugehs/gate) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.
Readme
gate
One ship/no-ship verdict from your whole nugehs toolchain.

gate runs aiglare,
bouncer,
tieline and
repoctx against a repo and
merges their four dialects into one normalized verdict. Each tool already
answers a different "can this ship?" question — gate is the place they finally
agree on the answer.
npx @nugehs/gate # audit the current repo
npx @nugehs/gate ./service --ci # fail the build on a blocking verdict
npx @nugehs/gate --json # the unified verdict, machine-readable ┌──────────────────────────────────────────────┐
│ gate │
│ one config · one verdict · one report │
└──────────────────────────────────────────────┘
│ │ │ │
aiglare bouncer tieline repoctx
red/amber/ pass/fail/ matched/ PASS/WARN/
green unknown drift FAIL
│ │ │ │
└──── normalize to pass · warn · fail ─────┘
│
✗ FAIL ⚠ WARN ✓ PASSWhat it reports
gate · /path/to/repo
✗ AI governance fail 2 red · 1 amber · 13 green · 1 blocking side-effect
· Compliance skipped not configured (run `bouncer init`)
· Contract drift skipped not configured (run `tieline init`)
⚠ Merge readiness warn 1 of 8 checks need attention
verdict: FAIL — 1 blocking · 1 warn · 2 skippedEach tool's native result is normalized onto one status vocabulary:
| Status | Meaning |
|---|---|
pass |
the check ran and is clean |
warn |
ran, found something worth a look — not blocking |
fail |
ran, found a blocking problem |
unknown |
ran, but couldn't determine — explicitly not a pass |
skipped |
not applicable / not configured for this repo |
error |
the tool couldn't be run, or returned garbage |
The top-level verdict is the worst across the domains that actually ran
(skipped never counts). unknown and error roll up to warn so nothing
slips through as a silent pass.
How each dialect maps
| Tool | Native signal | → gate |
|---|---|---|
| aiglare | a red surface on a side-effectful sink | fail; any red/amber → warn |
| bouncer | a fail finding (missing required control) |
fail; any unknown control → unknown |
| tieline | drift > 0 (FE call with no BE route) |
fail; unverifiable > 0 → warn |
| repoctx | FAIL/BLOCK merge verdict |
fail; WARN → warn |
gate runs aiglare without
--ciand derives the blocking verdict itself, so a tool thatprocess.exit()s before flushing its pipe can't truncate the report it feeds us.
A run that checked nothing is not a pass. If every domain is skipped or
deselected (e.g. --skip them all, or a typo'd --only), gate reports NO
CHECKS RAN (ok:false) and fails under --ci — a misconfiguration can't
silently turn the gate green.
On repoctx + local mode. repoctx's merge-readiness gate can only verify
review state (approvals, CODEOWNERS, required checks) against a host like
GitHub. Run locally it reports those as a WARN, so on a clean local repo gate
will often show merge readiness: warn. That's repoctx being honest about what
it can't see locally — not a problem with your change.
CLI
gate [path] [options]
--json Emit the unified verdict as JSON
--ci Exit non-zero when the gate fails (blocking by default)
--strict Treat WARN/UNKNOWN as blocking too
--only <list> Run only these tools (aiglare,bouncer,tieline,repoctx)
--skip <list> Skip these tools
-h, --help Show this help
gate mcp Start the MCP server (stdio)By default only a fail verdict blocks under --ci — safe to adopt without
drowning a team in warnings. Add --strict when you want warnings to gate too.
Tool resolution
gate doesn't bundle the four tools; it finds each one at runtime. Per tool, first hit wins:
GATE_<TOOL>_BINenvironment variable (explicit override)- the installed
@nugehs/<tool>package (fromnode_modules) - a sibling checkout at
../<tool>(local development)
A tool that can't be resolved is reported as skipped, never a hard failure —
so gate is safe to run in a repo that only uses some of the toolchain.
In CI
- run: npx @nugehs/gate . --ciFor a machine-readable record, --json emits the full verdict (schema version,
per-domain results, counts, and the blocking reasons) for dashboards or audit
evidence.
MCP
gate is also an MCP server, so an agent can ask "can this ship?" in one call — the unified verdict, not four separate tools.
gate mcp # stdio JSON-RPC server
npx @nugehs/gate mcpTools:
| Tool | Returns |
|---|---|
gate_check |
the unified verdict for a repo (path, optional only/skip/ci/strict) |
list_checks |
the four checks gate runs, each with its domain and what it answers |
Registry manifest: server.json (io.github.nugehs/gate).
Editor extension
The same normalized verdict drives a VS Code / Cursor extension
(clients/vscode) — the gates, shifted left from CI into the
editor:
- a verdict cockpit and a checks tree in gate's own Activity Bar container;
- inline diagnostics, hovers, Quick Fixes (mute / open docs) and CodeLens on located findings;
- AI-native gating — an
@gatechat participant, agate_checktool agent mode can call before it says "done", and an MCP server provider — so the assistant writing the code is checked by the same gate as CI; - debounced run-on-save with in-flight cancellation, and multi-root support.
Roadmap
gate is the shared spine. The same JSON already drives the CLI, the --ci gate,
the MCP server, and the editor extension above. Next client on the same JSON:
- Web cockpit — a repo/PR verdict board over the JSON, unifying the four
*-websites.
License
MIT © Oluwasegun Olumbe