Constraints Registry

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

Policy-as-code guardrails for AI coding agents, validated via OPA, Conftest, Checkov & Semgrep.

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

概览

AI 生成的概览

一个本地 MCP 服务器,向编码代理提供工程约束,并用 OPA、Conftest、Checkov 和 Semgrep 校验候选产物。

可以做什么
通过 describe_scope 发现可用的选择器词汇与约束类别,通过 get_constraints 获取与当前构建内容相关的规则,该工具采用失败开放策略,不会阻塞代理。通过 validate 用已绑定的执行引擎校验候选产物:OPA 和 Conftest 处理 Rego 策略,Checkov 扫描基础设施即代码,Semgrep 检查源代码。约束从多个源仓库聚合为不可变、带版本的捆绑包,并带有命名空间与优先级规则,可按间隔重新导入而无需重启服务器。
适用场景
适用于希望 Claude Code、Cursor、Codex 等编码代理在生成代码前查阅组织、基础设施或架构规则的场景,也适用于需要用现有策略引擎检查生成产物的场景。它提供指导并委托校验,本身不是执行引擎。
运行要求
以 PyPI 包形式在本地通过 stdio 运行(也可选用共享 HTTP 端点)。需要 Python 3.11 或更高版本以及 uv;Semgrep 由 uv sync 安装。Rego 校验和夹具交叉检查需要 OPA;Conftest 和 Checkov 为可选,缺失时相关检查会被跳过。约束源和引擎在注册表配置文件中配置,也可通过 CREGISTRY_CONFIG 变量指定。
安装前请注意
服务器从配置的本地路径读取约束源并提供给连接的代理,应持续审查这些仓库和配置文件。validate 工具会在候选产物上运行外部引擎二进制文件,只应对愿意处理的内容使用。热重载会自动拾取约束变更,因此修改源后无需重启就会影响代理收到的指导。

安装

在 SourceWeft 中

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

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

其他 MCP 客户端

参照 仓库 中的启动说明。

README

Constraint Registry

[License: Apache 2.0] [Python] [CI] [PRs Welcome]

Policy-as-code guardrails for AI-generated code. An MCP server that serves engineering constraints to coding agents (Claude Code, Cursor, Codex) at generation time and validates artifacts with OPA, Conftest, Checkov, and Semgrep.

A single, queryable source of engineering constraints (infrastructure, organizational, architectural) that coding agents (Claude Code, Cursor, Codex, …) consult at code-generation time, exposed over an MCP server. It does not enforce constraints itself — it provides guidance to agents and delegates deterministic validation to existing enforcement engines (OPA, Conftest, Checkov, Semgrep).

Constraints are authored in source repos, aggregated into an immutable, versioned bundle, and served over MCP so an agent can:

  1. describe_scope — discover the valid selector vocabulary,
  2. get_constraints — fetch the rules relevant to what it's building, and
  3. validate — check a candidate artifact against the bound enforcement engines.

Authoritative requirements: constraint-registry-v0-spec.md. Requirement → component → test mapping: TRACEABILITY.md.


Contents


Features

  • Three constraint categories — infrastructure, organizational, architectural, including relationship-style selectors (e.g. "no synchronous calls across domain boundaries") and advisory (no-enforcement) constraints.
  • Multi-source aggregation — import from many source repos; ids are namespaced per source; deterministic, content-hashed, immutable versioned bundles.
  • Precedence & anti-drift — a configurable default policy (hard outranks weaker; a downstream source may not relax a higher-precedence rule on the same scope); fixture cross-checks keep guidance and enforcement from drifting.
  • Pluggable engines — a stable adapter interface with four real adapters: OPA and Conftest (Rego policies), Checkov (IaC scanning), and Semgrep (application source code). SARIF-emitting engines share one normalization seam (adapters/sarif/), so adding a new SARIF engine is mostly wiring. Adding an engine = one adapter + one config line (see Adding an enforcement engine).
  • Catalog importers — Checkov and Semgrep ship importers that turn an engine's rule catalog/ruleset into draft constraint stubs (with license/source provenance) for a human to enrich — a fast path to bootstrapping a source.
  • MCP server — three tools (describe_scope, get_constraints, validate) over stdio or a shared HTTP endpoint. get_constraints fails open so an agent is never blocked.
  • Hot reload — the server can periodically re-import so constraint changes are picked up without a restart.
  • Validation harness — proves the registry and constraint set are internally consistent; machine-readable JSON, non-zero exit on failure.

Prerequisites

ToolRequired?Notes
Python ≥ 3.11yesthe package targets 3.11+
uvyesmanages the venv and runs entry points
OPA (opa)for Rego validate / fixture cross-checksthe reference enforcement engine
Conftest (conftest)optionalsecond Rego engine; its checks SKIP if absent
Checkov (checkov)optionalIaC scanning engine; its checks SKIP if absent
Semgrep (semgrep)bundledsource-code engine; installed automatically by uv sync

Install the external engines on macOS:

bash
brew install opa conftest checkov   # semgrep is installed by `uv sync`

Each engine is optional and independent: any test or harness check whose engine binary is not on PATH is skipped, not failed. The registry and the get_constraints/describe_scope guidance work without any engine at all — an engine is only needed to run validate and the fixture cross-checks for constraints bound to it.


Quick start

bash
git clone https://github.com/SureshKhemka/constraints-registry.gitcd constraints-registry
uv sync                      # create the venv + install deps (incl. semgrep)
uv run cregistry-harness     # run the validation harness against the bundled samples

The harness emits machine-readable JSON and exits non-zero on any failure. A green run looks like:

json
{ "passed": true, "summary": { "pass": 21, "fail": 0, "skip": 0, "total": 21 }, "checks": [ ... ] }

(skip is used only when an optional engine like conftest is not installed.)


Running the MCP server

Two transports — pick based on how you want tools to connect.

bash
# stdio (default): each tool launches its own copy; nothing to manageuv run cregistry-mcp
# one shared HTTP server every tool connects to (recommended for multiple tools)uv run cregistry-mcp --http --port 8765 --reload-interval 60

Flags: --transport {stdio,http,sse}, --http (shorthand), --host (default 127.0.0.1), --port (default 8765), --config (or $CREGISTRY_CONFIG), --reload-interval SECONDS (0 = off).

Manage the shared HTTP server:

bash
lsof -ti tcp:8765 | xargs kill     # stop# restart = stop + start

Full operational guide (stop/restart, macOS launchd auto-start, the repo-sync/decoupling pattern): docs/RUNNING.md. Tool input/output contracts: docs/MCP_CONTRACT.md.


Integrating with coding agents

The server exposes three tools: describe_scope, get_constraints, validate.

Claude Code

bash
# shared HTTP server (start it first, see above), available in every project:claude mcp add --scope user --transport http constraint-registry http://127.0.0.1:8765/mcp
# OR stdio (no separate server to run; Claude launches it):claude mcp add constraint-registry -- uv run --directory "$(pwd)" cregistry-mcp
claude mcp list   # should show: constraint-registry ... ✔ Connected

Cursor (~/.cursor/mcp.json)

json
{ "mcpServers": { "constraint-registry": { "url": "http://127.0.0.1:8765/mcp" } } }

Codex / other stdio-only tools

Configure an MCP server with command: uv, args: ["run","--directory","/abs/path/to/repo","cregistry-mcp"].

Make the agent actually consult it

Agents auto-discover the tools, but to get them to consult the registry before generating code, add an instruction to your project (or ~/.claude/CLAUDE.md):

Before writing AWS/infra code, call the constraint-registry MCP: describe_scope to learn valid selector values, then get_constraints with the right scope, and comply with every hard constraint as a non-negotiable downstream gate. Optionally validate the result.


Authoring constraints

A source is a directory with constraints/*.yaml (one constraint per file) and, optionally, policies/ (engine policies) and fixtures/ (sample artifacts). Register sources and engines in registry.config.yaml:

yaml
sources:  - { name: platform-security, path: sources/platform-security, precedence: 100 }  - { name: data-platform,     path: sources/data-platform,     precedence: 50  }engines:  - { name: opa,      adapter: "cregistry.engine.adapters.opa:OpaAdapter" }  - { name: conftest, adapter: "cregistry.engine.adapters.conftest:ConftestAdapter" }  - { name: checkov,  adapter: "cregistry.engine.adapters.checkov:CheckovAdapter", options: { min_level: warning } }  - { name: semgrep,  adapter: "cregistry.engine.adapters.semgrep:SemgrepAdapter", options: { min_level: warning } }precedence_policy: default

A constraint (see sources/platform-security/constraints/aws-s3-no-public-access.yaml):

yaml
id: aws.s3.no-public-accesstitle: "S3 buckets must not be publicly accessible"intent: "Public buckets are the top source of data-exposure incidents."category: infrastructure          # infrastructure | organizational | architecturalscope:  providers: [aws]  resource_types: [aws_s3_bucket] # Terraform resource ids (NOT "s3_bucket")  environments: [all]  repos: ["tag:data-plane"]severity: hard                    # hard | soft | advisoryenforcement:                      # omit for an advisory (guidance-only) constraint  - { engine: opa, policy: policies/s3_public.rego }guidance:  do:   ["Attach an aws_s3_bucket_public_access_block with all four flags true"]  dont: ["Never set acl = 'public-read' or 'public-read-write'"]  example_compliant: |    {"resources": {"aws_s3_bucket": {"data": {"acl": "private", "public_access_block": true}}}}owner: platform-securityversion: 1.0.0fixtures:                         # optional; cross-checked against the engine  pass: fixtures/s3_private.json  fail: fixtures/s3_public.json

Scoping notes (matters when agents query):

  • resource_types use the target tooling's identifiers (Terraform: aws_s3_bucket). Call describe_scope to discover the exact vocabulary present.
  • A query that omits a dimension matches broadly; a value that contradicts a constraint's selector excludes it. Relationship-scoped constraints are only returned for queries that supply a matching relationship.
  • After authoring, run uv run cregistry-harness to validate schema, precedence, and fixtures.

Hot reload (no restart on constraint changes)

Run the server with --reload-interval N and it re-imports from disk every N seconds, publishing a new immutable bundle when content changes:

bash
uv run cregistry-mcp --http --port 8765 --reload-interval 60
  • No-op when nothing changed; previous bundle versions stay pinnable by id.
  • A failed re-import (e.g. an unresolvable precedence conflict) keeps the last-good bundle serving and logs the reason — the server never goes dark.
  • The server reads from the configured source paths, so wire your teams' constraint repos to sync/pull into those paths (a separate ops job, e.g. a cron git pull or CI publish). Code/dependency changes still need a restart.

Validation harness

uv run cregistry-harness runs end-to-end against the bundled, self-contained sample sources and proves: schema conformance, deterministic import, malformed- constraint isolation, namespacing & precedence, versioning & deprecation, engine- interface conformance (incl. a reusable suite any adapter can be run against), fixture cross-checks / broken-binding detection, the MCP contract / scoping / fail-open, and hot-reload behavior. It prints structured JSON and returns a non-zero exit on any failure — suitable for CI.

bash
uv run cregistry-harness            # human-readable JSON to stdout, exit 0/1uv run cregistry-harness --config path/to/registry.config.yaml

Adding an enforcement engine

Implement the EngineAdapter interface in a new module under src/cregistry/engine/adapters/, add one line under engines: in registry.config.yaml, and validate it against the existing conformance suite — no changes to the schema, importer, MCP server, or harness. Full walkthrough: docs/ADDING_AN_ENGINE.md.


Repository layout

src/cregistry/  model.py            constraint schema (Pydantic)  loader.py           load + per-field schema validation  config.py           registry config (sources, engines)  importer.py         import → aggregate → bundle  precedence.py       namespacing precedence / conflict resolution  scope.py            scope matching (query + conflict)  bundle.py store.py  immutable versioned bundles + store  query.py validate.py  scoped queries + artifact validation  integrity.py        fixture cross-check / anti-drift  service.py          transport-independent service (+ hot reload)  mcp_server.py       MCP server (stdio / http) + CLI  engine/             stable engine interface, registry, and adapters:    adapters/opa, adapters/conftest, adapters/checkov, adapters/semgrep    adapters/sarif    shared SARIF normalization seam (used by checkov + semgrep)  harness/            the validation harness (checks/*)sources/              bundled sample source repos (constraints, policies, fixtures)scenarios/            self-contained fixtures for harness edge casestests/                pytest suite: adapter conformance, fixtures, import, e2edocs/                 RUNNING.md, MCP_CONTRACT.md, ADDING_AN_ENGINE.mddeploy/               launchd template for auto-starting the HTTP serverCONTRACTS.md          the frozen engine-adapter seam new adapters code against

Run the adapter test suite directly with uv run pytest.


Contributing

Contributions are very welcome — bug reports, new engine adapters, constraint sources, and docs. Adding an engine is intentionally small: one adapter module plus one config line, with no changes to the schema, importer, MCP server, or harness.

Before opening a PR, make sure uv run pytest and uv run cregistry-harness are green; CI runs both on every pull request.


License

Licensed under the Apache License 2.0. See NOTICE for attribution and the licenses of the external engines this project integrates with.

来源:README.md,提交 20888cb

工具

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

版本历史

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

评分

已满足适用检查项的 50%

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

  • 近 30 天内可连通25 分

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

  • 已声明认证方式10 分

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

  • 已列出工具15 分

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

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