Gate

io.github.nugehs由 GitHub 账号 nugehs 发布v0.3.0更新于 Oct 24, 2026

One ship/no-ship verdict from aiglare, bouncer, tieline & repoctx — the unified merge gate.

已验证STDIO仅桌面开发者工具安全与监控

概览

AI 生成的概览

运行 aiglare、bouncer、tieline、repoctx 四项仓库检查,并把结果合并成一个规范化的“能否发布”结论交给助手。

可以做什么
  • 获取某个仓库统一的发布/不发布结论,可选用 only、skip、ci、strict 参数
  • 列出 gate 运行的四项检查,以及各自所属领域和回答的问题
  • 查看按 pass、warn、fail、unknown、skipped、error 归一化的各领域状态与阻断原因
  • 通过命令行、CI 或编辑器扩展运行同一套门禁
适用场景
当仓库已经使用 nugehs 工具链中的部分或全部工具,并希望助手用一次调用回答“这次改动能否发布”,而不必分别运行四个工具再自行比对不同格式的结果时使用。
运行要求
以本地 stdio 进程运行,通过 npx 从 npm 包 @nugehs/gate 启动(需要 Node.js)。四个底层工具并未打包在内,运行时依次从 GATE_ _BIN 环境变量、已安装的 @nugehs 包或同级目录检出中查找。未声明任何身份验证。
安装前请注意
gate 会对仓库执行四个底层工具,即运行第三方代码,并可能对被检查的仓库产生副作用。无法找到的工具会被记为 skipped 而非失败,而什么都没检查的运行会报告 NO CHECKS RAN,因此配置错误可能看起来像干净结果。本地运行时合并就绪度常显示为 warn,因为无法在本地核实评审状态。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Gate,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

gate

One ship/no-ship verdict from your whole nugehs toolchain.

[npm] [license: MIT] [node]

[gate demo]

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 reponpx @nugehs/gate ./service --ci       # fail the build on a blocking verdictnpx @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   ✓ PASS

What 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 skipped

Each tool's native result is normalized onto one status vocabulary:

StatusMeaning
passthe check ran and is clean
warnran, found something worth a look — not blocking
failran, found a blocking problem
unknownran, but couldn't determine — explicitly not a pass
skippednot applicable / not configured for this repo
errorthe 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

ToolNative signal→ gate
aiglarea red surface on a side-effectful sinkfail; any red/amber → warn
bouncera fail finding (missing required control)fail; any unknown control → unknown
tielinedrift > 0 (FE call with no BE route)fail; unverifiable > 0 → warn
repoctxFAIL/BLOCK merge verdictfail; WARN → warn

gate runs aiglare without --ci and derives the blocking verdict itself, so a tool that process.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:

  1. GATE_<TOOL>_BIN environment variable (explicit override)
  2. the installed @nugehs/<tool> package (from node_modules)
  3. 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

yaml
- run: npx @nugehs/gate . --ci

For 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 servernpx @nugehs/gate mcp

Tools:

ToolReturns
gate_checkthe unified verdict for a repo (path, optional only/skip/ci/strict)
list_checksthe 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 @gate chat participant, a gate_check tool 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 *-web sites.

License

MIT © Oluwasegun Olumbe

来源:README.md,提交 bb9ca33

工具

0
SourceWeft 尚未在沙箱中启动过该软件包,因此其工具未知。

版本历史

1
  1. v0.3.0最新Sep 16, 2026

评分

已满足适用检查项的 50%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通25 分

    请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。

  • 已声明认证方式10 分

    请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。

  • 已列出工具15 分

    请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。

  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分