Cejel

cejel

任何人都能重新运行的仓库证据。 Cejel 会读取仓库自身的证据 （确实断言了某些内容的测试、已提交的密钥、CI 门禁），并生成一份固定到某个提交的证书。 无论收到证书的是客户、买家还是收购方，都可以离线在同一提交上运行相同版本的 Cejel， 并得到相同结果。无需大模型，无需注册。

将它添加到工作流中；结果会发布到作业摘要中：

on: [pull_request]
jobs:
  cejel:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0 # full history: A2 and B2 read commit history
      - uses: BargLabs/cejel/action@v1

也可以从 Shell 中运行一次：npx @cejel/cejel@latest . 关于此 Action 的更多信息，请参阅 GitHub Action。

Cejel（发音为 “SEH-jel”）——为代码库提供的信任证书。

免费的离线免注册 CLI，可对表明是否应信任某个仓库的工程信号进行评分——测试、密钥、隔离、 声明与现实是否相符、CI／审计规范——并生成信任证书和徽章。当代码大部分由 AI 编写时， 它尤其有价值：这正是你无法靠肉眼判断是否可信的时候。它基于确定性的非大模型评分核心构建—— 免费使用时不会发起任何网络请求，也无需账户。

声明边界： Cejel 对工程信任信号进行评分；它不声称能检测软件缺陷，也不证明代码安全。 缺陷和漏洞扫描器仍是证据生成工具，Cejel 可将其结果汇总到信任证书中。

Cejel 并非另一个与你现有扫描器竞争的单点扫描器，而是一种开放、可移植、离线的信任证书， 可将多个扫描器的结果汇总起来。输入兼容 SARIF 的输出（MunaTrust、Snyk、Semgrep、CodeQL、Codex） 以及 OpenSSF Scorecard，即可获得一份可分享的证书和徽章，涵盖所有这些结果。请参阅下方的“汇总扫描器结果”。

Cejel 用于 Barg Labs 自身的代码。公开榜单 会将发布者自有快照与排名中的公开仓库分开标注。

评分规则校准政策

公开 CLI 的默认评分规则为 witan-rubric-v17-2026-07-24，这是最后一套通过 Cejel 预注册的、 未触碰的 200 个仓库留出集验证的评分规则。已发布的校准数据仅适用于这套确切的评分规则和冻结的评估群体。 后续评分规则——包括当前的 v18 至 v23 前瞻性系列——仅供明确指定的评估框架使用。前瞻性评分规则 不继承 v17 的任何校准数据；有界配对修复或语料库差异结果可以验证其所述的构建方法，但不能据此转移 精确率、召回率或假阳性率声明。要将前瞻性评分规则提升为公开默认规则，必须进行新的、经过身份验证的 未触碰留出集评估，通过所有预注册门槛，并另行记录提升决定。

有界实测召回率

有界实测召回率。 Cejel 在 docs/calibration/v22-detection-recall/ 中发布了一个队列级、适用范围内的检测召回率数据，针对前瞻性 v22 规则集；不存在通用数据，且 cejel.dev/methodology 并列列出了三个称为召回率的量。在一组冻结、预注册、适用范围内的留出测试样例中，包含 30 个已命名缺陷，已发布的公共默认版本（v17，树 a857f0b3）检出了 16/30，双侧 95% Wilson 区间为 [36.1%, 69.8%]；前瞻性 v22 检测器（提交 8a289ea，树 10960a03）检出了 24/30，双侧 95% Wilson 区间为 [62.7%, 90.5%]。两次运行使用相同测试样例、相同划分和相同控制项。v22 是前瞻性版本，并非已发布的默认版本。完整的预注册方案和结果见： docs/experiments/in-scope-detection-recall-v3-result-2026-08-09.md 和 docs/experiments/in-scope-detection-recall-v4-result-2026-08-11.md。

缺陷类别普查公布了覆盖广度边界——已发布规则针对哪些缺陷类别——并明确指出这并非召回率声明。

安装

无需账户、密钥或注册。

单文件二进制文件。 一个文件。无需 Node、npm、node_modules，也无需安装任何内容。

set -eu
asset="cejel-$(uname -s)-$(uname -m)"
curl -fsSL "https://github.com/BargLabs/cejel/releases/latest/download/$asset" -o "$asset"
curl -fsSL https://github.com/BargLabs/cejel/releases/latest/download/SHA256SUMS -o SHA256SUMS
checksum_entry_count="$(awk -v asset="$asset" '$2 == asset { count++ } END { print count + 0 }' SHA256SUMS)"
if [ "$checksum_entry_count" -ne 1 ]; then
  echo "Expected exactly one SHA256SUMS entry for $asset; found $checksum_entry_count" >&2
  exit 1
fi
if command -v sha256sum >/dev/null; then
  grep "  $asset$" SHA256SUMS | sha256sum -c -
else
  grep "  $asset$" SHA256SUMS | shasum -a 256 -c -
fi
mv "$asset" cejel
chmod +x cejel
./cejel .

Windows x86_64（PowerShell）。

$asset = "cejel-Windows-x86_64.exe"
Invoke-WebRequest "https://github.com/BargLabs/cejel/releases/latest/download/$asset" -OutFile $asset
Invoke-WebRequest "https://github.com/BargLabs/cejel/releases/latest/download/SHA256SUMS" -OutFile SHA256SUMS
$expected = ((Select-String -Path SHA256SUMS -Pattern "  $([regex]::Escape($asset))$").Line -split "\s+")[0]
$actual = (Get-FileHash -Algorithm SHA256 $asset).Hash.ToLowerInvariant()
if (-not $expected -or $actual -ne $expected.ToLowerInvariant()) {
  throw "SHA-256 verification failed for $asset"
}
.\cejel-Windows-x86_64.exe .

Windows 签名状态： cejel-Windows-x86_64.exe 在 0.6.8 中有意不签名，可能触发 Microsoft SmartScreen。发布构建会在 SEA 注入前移除 Node 继承的签名，并确保 Windows 报告结果为 NotSigned，否则构建失败；它不会发布无效签名。运行前，请验证 SHA256SUMS 和 GitHub 构建来源证明。每个二进制文件还附带一份 SPDX SBOM（列出构建中打包的依赖包，以及其中嵌入的 Node.js 运行时；从 0.6.0 之后的版本起，该 SBOM 已对二进制文件进行证明）和一份本平台验证回执，涵盖 --version、--help、实际扫描、源代码与二进制文件的一致性，以及网络禁用时的扫描。如果你的策略要求 Authenticode，请在获得人工批准的签名流程前使用 npm 包或 OCI 镜像。

别轻信离线声明——亲自验证。 关闭网络，然后运行二进制文件。它仍会为你的代码库评分并生成证书。这就是整个产品，你可以在十秒内验证这一点：

# with Wi-Fi off, or:
docker run --rm --network=none -v "$PWD:/w" -w /w -v "$PWD/cejel:/cejel:ro" debian:stable-slim /cejel .

npm。

npx @cejel/cejel@latest .

分发说明： Cejel 0.6.8 是 npm、独立二进制文件、Docker/OCI、GitHub Action、Homebrew 和 MCP Registry 的协调发布版本。GitLab CI 模板和 Code Quality 导出见 docs/gitlab-ci.md。

npx 可能会复用过期的缓存包。请使用上方的 @latest 指定符强制获取当前 npm 发布版本，并在比较证书前检查将要运行的版本：

npx @cejel/cejel@latest --version

如果根目录下的 package.json 仍包含模板名称，只覆盖证书显示名称，同时保留根据代码库生成的稳定 slug：

npx @cejel/cejel@latest . --name "Customer Portal"

从 0.4.5 起，当两个检出目录需要生成相同的身份字段时，请使用 --product-name。提供的值会同时设置显示名称和经 slug 化处理的稳定 ID：

npx @cejel/cejel@latest . --product-name "Customer Portal"

产品身份是调用方上下文，并非评分的代码库证据，因此不纳入证书字节比较声明。

npm 包的作用域为 @cejel/cejel；其可执行文件仍使用简短命令 cejel。

GitHub Action — 为每个 PR 评分并发布徽章：

- uses: actions/checkout@v4
  with:
    fetch-depth: 0     # full history: A2 and B2 read commit history
- uses: BargLabs/cejel/action@v1
  with:
    min-score: "2.5"   # optional: fail the build below this

actions/checkout 默认只获取一个提交。在浅克隆中，A2 和 B2 只能看到该提交，证书会在“History limitations”下说明这一点。 在前瞻性 v27 评分标准（--rubric-pin witan-rubric-v27-prospective-2026-10-19）下，浅克隆的限制更大。除非存在已确认的严重机密信息发现，否则 A2 会弃权；即使该发现原本会被标记为不适用，也同样如此，因为该判断也依赖更早的提交。如果读取更早提交的操作有任何一次失败，A2 也会以同样方式弃权：例如使用 --filter 创建的部分克隆，而 fetch-depth: 0 且不使用 filter 可以避免这种情况；或者读取触及 Cejel 自身的任一限制：输出限制，或历史机密信息扫描最多检查 5,000 个历史文件的限制。这些情况会出现在某些大型完整历史记录中，重新扫描同一仓库也无法解除限制（#567）；还有 30 秒超时，重新扫描有时可以解除。此外，如果历史记录中有凭据样式的路径因名称包含控制字符而未被读取，或者扫描主机上无法运行 git，A2 也会弃权。如果评分涉及 B2，而可见提交少于 12 个，B2 也会弃权。每种弃权在综合评分中都计为 0，因此可能拉低 v27 得分。

如需查看实际运行的公开示例，了解如何将发布工件绑定到 Cejel 证书中指定的同一提交，请参阅 使用 GitHub 构建来源证明进行认证发布。

从源代码构建 — 本项目采用 AGPL 许可，且可离线运行，因此阅读源代码正是重点：

git clone https://github.com/BargLabs/cejel && cd cejel
pnpm install && pnpm build
node dist/index.js .

已发布的二进制文件：cejel-Darwin-arm64、cejel-Darwin-x86_64、cejel-Linux-aarch64、cejel-Linux-x86_64 和 cejel-Windows-x86_64.exe。发布内容还包括 SHA256SUMS、每个二进制文件对应的 SPDX SBOM，以及一份针对其自身平台的验证回执。SBOM 会列出打包到二进制文件中的软件包，以及嵌入其中的 Node.js 运行时。0.6.0 版的 SBOM 不包含这些内容：它们只列出扫描目录和二进制文件。请参阅 docs/release-process.md。附加之前，每个二进制文件都会与源代码构建产物进行比对执行，并在禁用网络的情况下运行。从 v0.1.6 起的发布还附带 Sigstore 捆绑包，其中包含 GitHub 为该发布集签署的构建来源证明。下载二进制文件后，可使用以下命令进行验证：

gh attestation verify ./cejel-Windows-x86_64.exe -R BargLabs/cejel

这是经密码学签名的来源证明，与 Apple Developer ID 或 Microsoft Authenticode 代码签名不同。

Docker / OCI。 当前容器版本为 0.6.8：

docker run --rm -i -v "$PWD:/workspace:ro" ghcr.io/barglabs/cejel:0.6.8

该镜像默认通过标准输入/输出运行 cejel-mcp。如需改用 CLI：

docker run --rm -v "$PWD:/workspace:ro" --entrypoint cejel ghcr.io/barglabs/cejel:0.6.8 .

OCI 镜像附带基础镜像软件包的 SBOM、最大模式构建来源证明，以及签名的注册表证明。自 0.6.0 之后的版本还附带第二份 SPDX 证明，其中列出了 Cejel 打包的软件包。0.6.0 镜像的 SBOM 不包含这些内容。

排行榜

Cejel 开源软件信任排行榜托管于 cejel.dev，这是目前唯一的排行榜。本仓库不再分发另一份评分或证书副本。排行榜会记录生成它的软件包版本、评分标准、运行日期、固定的公开修订版本，以及该次运行的复现说明。排行榜中 Barg Labs 自有私有代码库对应的条目是透明度快照，无法独立复现。

网站的“History”部分保留了2026-08-18 撤回声明：此前关于密封式公开评分器可复现性的声明并不属实。之前链接于此的过时前瞻性评分标准副本已移除；不得将其视为当前证据。

脱敏策略

只有当读者能够核查路径时，才会准确公布该路径。榜单上的每个公开仓库都会在所有产物的所有位置引用完整的证据路径和行号——无法打开证据的证书不算证据。私有仓库条目（工作室单体仓库的透明度快照）在任何位置、任何字段或格式中都不会引用源路径——但发现结果本身、维度、状态、分数和内容哈希始终保留；只有位置会被隐去，并统一标记为“路径已隐去——私有仓库”。脱敏移除的是位置，而非事实：私有仓库即使未通过自身检查，仍会按名称显示在证书上。v3 仓库扫描器会将 B1 和 B5 标记为不适用，适用于所有仓库，包括我们自己的；它不接受这两个维度的结构化基底证据。它们仍为其他评分标准输入项所定义，但仓库排名会以失败关闭的方式将其排除。不会根据公共扫描器无法收集的证据给任何仓库评分。

已知误报（发布前已修复）

针对真实的顶尖仓库校准评分标准会暴露问题；这份记录是信任声明的一部分，不会被掩盖。有两个维度因缺少可评分的表面而非真实弱点给出了惩罚性分数，这两项问题都已修复： Django 因使用版本范围而非精确锁定版本，被标记为依赖项卫生状况严重不佳——对于库而非应用来说，这是正常且有意为之的做法；现在，评分标准会根据适合相应类型的规范评估依赖项卫生状况。OSSF Scorecard——Google 自家的供应链安全审计工具——因通过 GitHub Releases 而非已提交的 CHANGELOG.md 发布发行说明，被标记为审计轨迹完整性严重不足；对于没有可评分审计表面的仓库，现在会返回“数据不足”（不纳入综合评分），而不是给出惩罚性分数。榜单还会为每一行公布实测覆盖率指标：分数仅反映其已实测的维度；如果某一行的适用维度中得分维度不足一半，则会显示为未排名，而不会与证据更充分的行进行排序比较。

使用方法

./cejel scan .

scan 会采用合理的默认设置为当前目录评分：无需注册，完全离线。原有的 ./cejel . 形式仍作为兼容性简写受到支持。 它会打印简明的终端证书，并将文件写入 .cejel/：

• report.json — 完整的结构化报告；已评分的运行会包含数值型总分和分数段 verdict，而弃权的运行会包含 null 分数和 verdict: "insufficient_source"
• attestation.json — 未签名的 in-toto 声明，将报告摘要、仓库修订版本、评分标准以及已评分或弃权的结果绑定在一起；可交由外部签名者签名
• certificate.html — 独立的 HTML 证书（无外部资源）
• badge.json — shields.io endpoint 载荷
• badge.svg — 静态、独立的信任评分徽章
• summary.json — 精简摘要（分数、结论、主要发现）

该声明会明确说明其保证级别：Cejel 会创建声明，但不会假称自己是独立签名者。在客户、审核者或来源证明系统为其签名之前，assurance.status 为 unsigned，而 issuer 为 self-generated。弃权的扫描只会附带拒绝原因，不会包含数值分数。

验证生成的报告是否仍与其声明相符：

./cejel verify .cejel/report.json .cejel/attestation.json

此命令会验证报告架构，以及报告与声明之间的摘要、仓库、评分标准、时间戳和结果绑定。它不会验证签名或签名者身份；每次验证成功时，命令都会打印这一界限。

标志

• <path> — 要评分的仓库（默认：当前目录）
• --out <dir> — 报告、证书和徽章文件的写入位置（默认：.cejel； --out-dir 仍可作为兼容别名使用）
• --min-score <n> — 如果总分低于 n（0–4）、Cejel 弃权，或任何分数所依据的适用维度中，测量的维度少于一半，则以非零状态码退出；用于 GitHub Action 的可选阈值门控
• --product-name <name> — 同时设置调用方上下文显示名称和 slug 化的产品 ID，让名称不同的检出副本生成完全相同的证书。
• --name <display> — 仅覆盖显示的项目名称，保留派生的 slug 不变；为兼容性而保留
• --ingest <file|glob> — 将其他扫描器的输出纳入评分（可重复指定）。接受 SARIF、OpenSSF Scorecard JSON 或通用 Cejel 外部信号格式——自动检测格式。请参阅下文“聚合扫描器结果”。
• --subject-repository <repo> — 指定被扫描的仓库名称（github.com/owner/repo 或克隆 URL），以便将声明了其他仓库的导入输入记录为不匹配。Cejel 不会根据克隆状态推断仓库名称。
• --strict-ingest — 评分前拒绝声明了其他仓库或提交、观测时间早于被扫描提交存在时间，或与其他输入重复的导入输入。不启用此选项时，会记录绑定状态，但评分不变。请参阅输入绑定。
• --rubric-pin <version> — 仅显式选择时使用：固定到其他评分标准，而非经过校准的公开默认版本。 它接受经过校准的版本或任何已发布的前瞻性评分标准（从 witan-rubric-v18-prospective-* 到 v26），其他版本会导致程序安全失败，并指出可接受的版本。v26（witan-rubric-v26-prospective-2026-10-14）是前瞻性且未经校准的版本：它是下一个校准候选版本，继承 v25 的全部内容，不继承 v23 或 v24，并且目前的评分结果与 v25 完全相同。v25 是前瞻性且未经校准的版本：它继承 v22，仅增加对应用文件中内联声明的健康或就绪路由的评分（请参阅下文“什么算作健康或就绪信号”）。v23 是前瞻性且未经校准的版本，与 v17 之后的所有评分标准一样：公开默认版本（WITAN_LAST_CALIBRATED_RUBRIC_VERSION）仍为 witan-rubric-v17-2026-07-24，且 v23 不继承 v17 的精确率、召回率或假阳性率数据。它继承 v22 的检测器和评分行为，并增加有限的 A1 覆盖标志识别（#276），以及针对 A1 的 coverage_percent/non_hollow_test_share 指标按信号（而非按标准）弃权（#278）；在 v23 中，所有其他标准仍按整个标准弃权，与 v17/v22 相同。若要获得每次默认扫描都会生成的经过校准的结果，请省略此标志——前瞻性版本不附带精确率/召回率声明；每当使用此标志时，终端证书、HTML 证书和 Markdown 报告都会明确说明这一点。
• --run-attempt <n> — 记录生成此证书的 CI 运行尝试次数，并将其显示在人类可读的证书中，同时作为可选附加字段 predicate.githubRunAttempt 写入 attestation.json。GitHub Action 会自动从 GITHUB_RUN_ATTEMPT 设置此项；本地扫描或其他 CI 请省略该选项——Cejel 不会伪造或默认设置运行尝试次数。
• --quiet — 不显示终端证书（仍会写入文件）
• -h、--help — 打印用法并成功退出
• -v、--version — 打印从软件包清单中获取的版本并成功退出

支持的语言

Cejel 读取的是仓库的文件树，而不是字节码——它需要识别文件的源代码扩展名，才能对文件作出判断。它并不支持所有语言，也会如实说明，而不是猜测：

• 深度建模 — JS/TS、Python：测试检测、覆盖率和声明与实际情况的核验，均针对这些生态系统进行了专门调优。
• 部分建模 — Go、Rust、Java、Ruby、PHP、C#、C/C++、Swift、Kotlin、Dart、Elixir、Scala：识别为源代码，并根据与语言无关的维度（CI 规范、依赖管理、审计跟踪、密钥）评分，但未针对特定生态系统的测试框架进行调优。
• 已识别但未建模 — shell、R、Lua、Julia、Haskell、Terraform、SQL、Perl、OCaml、Clojure、Erlang、Nim、Zig、F#、Groovy、Fortran、CUDA/HIP、Web 模板/样式：计作源代码，以免将仓库误判为空，但在这三个层级中，其针对特定生态系统的调优程度最低。
• 尚未识别 — 其他生态系统，包括 COBOL 和 MATLAB。Cejel 完全不会将这些语言计作“源代码”：如果仓库中没有任何扩展名可识别的文件，就会被归为 unrecognised_ecosystem 类型，相关标准状态明确标记为 insufficient_data，主要评分为 null，机器判定明确为 insufficient_source——绝不会给出数值评分区间判定，也绝不会仅仅因为 cejel 无法读取该语言，就使用“未经验证”一词。证书会明确说明 11 个维度中哪些已测量、哪些未测量。

这份清单会不断扩展，但永远不会涵盖“任何代码库”——解析器无法兑现这种承诺；与其用代码第一次面对不支持的仓库时就自相矛盾的营销说辞，不如提供诚实的支持矩阵。

汇总你的扫描器

Cejel 不会与 AI 代码扫描器（MunaTrust、Snyk、Semgrep、CodeQL、Codex，以及 CI 中运行的任何工具）竞争，而是构建在它们之上。使用 --ingest 输入扫描器的输出，Cejel 会将这些发现纳入同一份按评分标准打分的离线信任证书，并在证书和报告中将提供发现的工具列为来源：

./cejel . --ingest munatrust.sarif --ingest scorecard.json

或者将文件放入 .cejel/inputs/，系统会自动读取，无需任何标志：

mkdir -p .cejel/inputs
cp munatrust-results.sarif .cejel/inputs/
./cejel .

外部发现只会以有限幅度向下调整维度得分，并且始终如此——它们会补充原生仓库扫描结果，而不会取代它。每个输入文件都会在 certificate.html、report.json（consumedSignals）和终端输出（“纳入了以下工具的发现：...”）中按名称标明来源，因此证书呈现的是清晰可见的汇总，而非黑箱。

扫描器输出有三种纳入方式：

1. SARIF — 任何输出 SARIF 2.1.0 的工具（Semgrep、CodeQL，以及大多数商业 SAST/AI 代码扫描器）都无需配置即可使用；--ingest 会自动检测 runs 数组。

2. OpenSSF Scorecard — 运行 scorecard --repo=... --format=json > scorecard.json，然后使用 --ingest scorecard.json；系统会根据 checks 数组自动检测。

3. 通用 JSON — 对于输出格式不属于上述两种的工具，可将其输出映射为以下最简格式（如果需要实际解析格式，也可以编写一个小型适配器，参照 scorecard-adapter.ts）：

   {
     "version": "1.0",
     "tool": "my-scanner",
     "signals": [
       {
         "dimension": "A2",
         "weight": 0.7,
         "findings": [
           {
             "ruleId": "hardcoded-secret",
             "severity": "critical",
             "message": "Hardcoded API key detected.",
             "location": "src/config.ts:10"
           }
         ]
       }
     ]
   }
   

   dimension 是评分标准中的一个准则 ID（A1-A5、B1-B6）；weight（0–1，默认值为0.5）限定此信号对该维度的影响幅度；severity可为critical|warning|info；location` 为可选项。

   必须提供版本字段。Cejel 会拒绝未注明版本的通用文档以及主版本未知的文档，而不会猜测。请参阅通用输入契约、其已发布的 JSON Schema，以及合成 CI heal-log 映射。输出字段的稳定性和版本路由规则详见格式稳定性。契约 1.1 新增了可选的 subject、producer 和 observedAt 字段，以便将输入与某个修订版本绑定。

每份输入文档也会记录在 report.json 的 inputBinding 下：包括其字节内容的 sha256、该文档自身格式声明的生产者和主题（Scorecard 的 repo.name/repo.commit/date、SARIF 的 versionControlProvenance 和 invocations、通用格式的 subject/observedAt），以及该主题是否与已扫描的 HEAD 匹配（matched、mismatched-repository、mismatched-commit、stale、unbound、unverifiable）。默认情况下，这些信息只会被记录，不会作为门槛，也不会改变得分。使用 --strict-ingest 可拒绝不匹配、过期和重复的输入。cejel verify ... --input <file> 会根据记录的摘要校验一组输入文件，从而检测输入是否被替换。请参阅输入绑定，其中包含测试所用的一致性表。

显示信任徽章

终端 JSON（将 badge.json 托管在任意静态位置——仓库文件、gist、GitHub Pages 均可，然后将 shields.io 指向它）：

![Cejel trust score](https://img.shields.io/endpoint?url=<url-to-your-hosted-badge.json>)

或者直接提交/链接静态 SVG：

![Cejel trust score](./.cejel/badge.svg)

GitHub Action

请参阅 action/action.yml — 在 push/pull_request 时运行 Cejel，将得分和重要发现发布到作业摘要中，还可以选择在得分低于可配置的 min-score 阈值时让检查失败。评分步骤不会进行网络调用，也不需要密钥。

- uses: actions/checkout@v4
  with:
    fetch-depth: 0 # full history: A2 and B2 read commit history
- uses: BargLabs/cejel/action@v1
  with:
    min-score: '2.5' # optional; omit to never fail the check

请使用 fetch-depth: 0 检出仓库：默认深度为 1，会截断 A2 和 B2 读取的历史记录，证书随后会列出历史记录受限这一情况。

与 Claude 配合使用

Cejel 以 Claude Code 插件的形式发布于 plugins/cejel/。该插件为 Claude 提供下方的 scan 工具，该工具通过 npx 启动，并固定为此版本；此外还提供 cejel-scan 技能。该技能会告诉 Claude 何时扫描能回答问题，以及如何读取证书。它还会告诉 Claude，应将评分作为你自行判断的依据，而绝不能视为审计结果或保证。

在 Claude Code 中，从此仓库的市场安装：

/plugin marketplace add BargLabs/cejel
/plugin install cejel@cejel

在 shell 中，对应的两个步骤是 claude plugin marketplace add BargLabs/cejel 和 claude plugin install cejel@cejel。

扫描全程离线：scan 工具不会发起网络请求，也不会写入任何文件。服务器首次启动时，npx 会从 npm 获取固定版本的 @cejel/cejel 包。如果你指定的仓库不在本机上，Claude 会在使用你的 git 克隆之前征求许可。这两项获取操作都不属于扫描过程。

可用于公开仓库的示例提示词：

• “将 https://github.com/BargLabs/cejel 克隆到一个临时文件夹，并给出它的 Cejel 信任评分。”
• “用 Cejel 扫描 https://github.com/BargLabs/cejel，并说明主要发现以及对应的评估标准。”
• “对 https://github.com/BargLabs/cejel 运行 Cejel，并将其信任徽章保存到 ./cejel-badge.svg。”

支持：GitHub 问题。隐私政策： https://barglabs.ai/privacy。条款：https://barglabs.ai/terms。

MCP 服务（供 Agent 使用）

同一个包还提供第二个二进制程序 cejel-mcp——一个通过 stdio 运行的轻量 MCP（Model Context Protocol）服务，因此任何 MCP 客户端（Claude Code、Cowork、Cursor、Codex）都能通过工具调用请求信任证书。它封装了与 CLI 完全相同的扫描流程——评分和结论也完全相同——并通过仓库中的 smithery.yaml 列在 Smithery 上。

将其添加到 MCP 客户端配置中：

{
  "mcpServers": {
    "cejel": {
      "command": "npx",
      "args": ["-y", "--package=@cejel/cejel@latest", "cejel-mcp"]
    }
  }
}

该服务公开一个工具和两个资源：

• scan — 输入 { path, format? }；对 path 指定的仓库评分，并以 JSON 格式返回信任证书（format: "summary" 是默认值，返回精简摘要；format: "json" 返回完整报告，与 CLI 的 report.json 相同）。
• cejel://last-scan/certificate.html 和 cejel://last-scan/badge.svg — 最近一次扫描的 HTML 证书和 SVG 徽章（URI 方案源自 npm 包名称）。

与 CLI 一样，通过 MCP 评分完全离线：不发起网络请求、不收集遥测数据、不需要注册，且服务不会写入任何文件。

通过 Smithery 安装

Cejel 通过仓库中的 smithery.yaml 列于 Smithery MCP 注册表中。发现服务无需账户：

npx -y @smithery/cli@latest mcp search cejel

通过 Smithery 自带的 CLI 连接是单独的步骤，需要 Smithery 账户：对每个调用者而言，smithery mcp add 都会在创建连接前提示执行 smithery login，而不仅仅是首次使用时才会提示。

npx -y @smithery/cli@latest mcp add cejel

如果你不想创建 Smithery 账户，上方的通用 MCP 客户端配置无需登录，也完全不需要第三方 CLI——它会直接与同一个 cejel-mcp 二进制程序通信。

在 OpenClaw 上安装

OpenClaw 将出站 MCP 服务存储在 mcp.servers 下。使用 npm 包自带的 cejel-mcp 二进制文件添加 Cejel：

{
  "mcp": {
    "servers": {
      "cejel": {
        "command": "npx",
        "args": ["-y", "--package=@cejel/cejel@latest", "cejel-mcp"]
      }
    }
  }
}

对应的 OpenClaw 命令如下：

npx -y openclaw@latest mcp add cejel --command npx --arg -y --arg --package=@cejel/cejel@latest --arg cejel-mcp
npx -y openclaw@latest mcp doctor cejel --probe

请明确固定使用 openclaw@latest，而不要直接运行 openclaw。mcp add/mcp doctor 子命令需要 OpenClaw ≥2026.7.1-2，而 OpenClaw 本身需要 Node ≥22.22.3（也 需要 ≥24.15 或 ≥25.9）——如果使用的是较旧但仍受支持的 Node 22 补丁版本，npm 自带的兼容引擎 解析会悄然提供一个缺少这些子命令的旧版 OpenClaw，导致上述命令报错 error: unknown option '--command'，而不是显示版本信息。

当 Docker 是首选的执行边界时，也可以使用 OCI 镜像。将主机路径替换为 OpenClaw 应允许 Cejel 读取的仓库路径：

npx -y openclaw@latest mcp set cejel-oci '{"command":"docker","args":["run","--rm","-i","-v","/absolute/path/to/repo:/workspace:ro","ghcr.io/barglabs/cejel:0.6.8"]}'
npx -y openclaw@latest mcp doctor cejel-oci --probe

Cejel 已作为 io.github.BargLabs/cejel 收录于 Official MCP Registry。上述 OpenClaw 显式配置不受目录索引影响，仍可独立使用。

Cejel 会扫描你指定的代码库。这一免费的采用入口不会监视、拦截或治理 Agent 的运行时操作。运行时操作治理是未来付费 Agent Pack 的独立边界。

这里的“离线”是什么意思

为代码库评分——包括 cejel scan . 本身和 Action 的评分步骤——不会发起任何网络调用：没有遥测、无需注册，也不会调用模型。扫描器会通过一个经过加固的子进程唯一入口调用本地 git 二进制文件：仅使用固定的 argv（绝不使用 shell）、明确的超时和输出上限、禁用提示和网络传输、移除代理变量，并中和由仓库控制的文件系统监视。静态 CI 防护规则只允许在该模块中使用 node:child_process，并在其他所有位置禁止直接使用网络原语；此外，每个发布二进制文件也都会在禁用出站网络的条件下接受扫描。

首次获取 @cejel/cejel 包（与任何通过 npm 分发的 CLI 一样，包括此 Action 自身的依赖安装）确实需要网络；这是一次性的安装开销，不属于评分保证的范围。如果跟踪文件清单意外生成失败，JSON、HTML 和 markdown 证书会注明扫描器改用了有界目录回退方案，而不会在不作说明的情况下将两种清单当作等效结果。

证书范围的含义

证书会对某个固定版本的仓库树进行评分，也只会评估该树。这个边界是有意设定的：如果证书涉及固定版本仓库树之外的内容，接收者就无法复现结果，而可复现性正是本产品的全部意义所在。只对固定版本的仓库树评分是正确的——问题在于，证书本身没有告诉读者他们看到的是哪一类陈述。如果某个仓库的回归测试套件位于单独的仓库中，由其自己的 CI 检出并运行，那么报告其源文件对应的测试文件数为零是正确的。这个结论对于仓库树而言属实，对于整个系统而言却不属实；没有其他背景信息的读者无法分辨两者。

现在，每份证书都会附带一条固定的范围说明，无论评估结果如何，这条说明都会出现在所有形式（HTML、Markdown、终端）的“如何阅读本证书”部分中：证书描述的是固定版本的仓库树，而不是该仓库树所属的系统；仓库树之外的证据既不会被检测，也不会被声称不存在。这是补充说明，并非回避责任——关于未在该仓库树中发现证据的结论，仍会原样保留。

以下四种情况可能导致仓库树本身的结论无法准确反映其所属系统：

• 测试套件存放在单独的仓库中。 无法从固定版本的仓库树内部检测到这一情况——没有可靠信号可以表明存在关联仓库。此情况由上述固定范围说明涵盖，而非有条件地披露。
• CI 配置在运行检查前切换到其他工作目录。 同样无法检测到这一情况，除非实际执行 CI 任务，而离线扫描器不会这样做。此情况由上述固定范围说明涵盖。
• 大型实现文件超出读取上限。 这种情况可以检测到，发生时会有条件地披露：如果超过大小上限的文件导致某项特定信号没有可供评估的内容，证书的扫描限制部分就会列出该文件——“因实现文件过大、超出仓库内容大小限制而跳过”——而不是将其归入用于扩展名排除或非常规文件的通用覆盖限制说明。目前，这会影响两个 A3 信号（健康状态／就绪状态路由检测和可观测性标记计数）；随着更多信号采用相同的逐信号归因方式，此披露也会扩展到更多信号。
• **已识别但无实际作用的包脚本，**例如 npm 自动生成的 "test": "echo \"Error: no test specified\" && exit 1" 占位脚本，却被当作真正的测试运行器计入。这属于检测器缺陷，而非范围披露方面的遗漏——Cejel 现在会检查 test 脚本的内容，并与已知的测试运行器调用进行比对，而不再仅根据键是否存在来计入，因此无需为此另加披露说明。

哪些内容算作健康或就绪信号

按照校准版评分规则（以及 v25 之前的所有候选评分规则），“健康或就绪信号”组件的判定有意基于文件名。只有以下形式才会计分：

• 专门的健康或就绪文件，例如 health.ts、healthcheck.js、readiness.py（文件必须提及健康或就绪）；
• 根目录 Dockerfile 中的 HEALTHCHECK 指令；
• k8s/、kubernetes/ 或 helm/ 清单中的 Kubernetes 存活或就绪探针。

在应用文件中内联声明的路由不计入校准版评分规则，无论其内容如何：server.ts 或 app.ts 中的 app.get("/health", ...) 都不会在此得分，因为该组件不会读取路由文本。证书会在该组件旁注明这一点。候选规则 witan-rubric-v25-prospective-2026-10-12 及继承该规则的 witan-rubric-v26-prospective-2026-10-14，是唯一也会为内联路由计分的规则；它们仅检查独立的信息级“无健康或就绪路由”问题已读取的文件（位于 src/、app/、lib/、packages/、functions/ 下，仓库根目录中的 server/index/app/main 文件，或 server/、backend/、api/ 目录树中的文件），并会剥除注释、排除测试、文档、示例和脚本。这两项规则都必须显式选择（--rubric-pin），不声称精确率或召回率，也从未进行过公开的配对重评。

帮助验证 Cejel

Cejel 不会收集遥测数据。因此，外部验证需要选择加入，且过程可供检查：

• 如果评分、发现项、证据指针或拒绝结果有误，请报告校准结果。表单会先征求许可，然后才将更正加入公开错误记录。
• 如果想参与 Quant 或 Healthcare Pack 的设计合作伙伴试点，请加入试点。在通过各自领域的校准门槛之前，两者都仍处于试点阶段。

请仅提交公开或已脱敏的证据。切勿在 GitHub 问题中提供凭据、专有策略代码、患者数据或受保护的健康信息。

公开排行榜：脱敏内容、排除项，以及我们的错误

我们发布了一个信任榜单，对包含知名开源仓库及我们自有仓库的语料进行评分。对他人的代码运行排行榜，就必须准确说明其运作方式，因此我们在此完整说明。

我们会脱敏哪些内容，以及依据是什么。 规则只有一条：只有可供核查的路径才会公开。 对于公开仓库，我们会完整列出每个证据路径和行号——无法打开证据的证书就不是证据。对于私有仓库（我们的仓库），任何字段或格式中都不会引用源文件路径；无法核实的路径无法提供任何可供你核查的信息，却会免费泄露我们的文件树。脱敏只会移除位置，绝不会移除事实：发现项、所属维度、状态、评分和内容哈希都会保留。任何被隐去的路径都会明确标出。这一机制由结构保障——公开产物由筛选后的数据构建，而不是先渲染再清理——如果构建过程将输出私有路径，就会失败而不会发布。

我们会从排名中排除什么。 对于仓库输入，v5 仓库扫描器不会评估 B1（调度追踪完整性）或 B5（已验证的学习追踪），包括我们自己的仓库：在仓库证书中，这两项始终为不适用。它们仍在评分规则中定义，用于结构化基底证据，但此扫描器不接受此类证据。排名采用失败即关闭策略排除这两个维度，包括读取旧版报告或单独生成的结构化报告时也是如此。我们既不会依据公开扫描器无法收集的证据给你评分，也不会因为你无法质疑的证据给自己加分。 我们哪里做错了。 用真实代码仓库校准这套评分标准，并像陌生用户一样运行看板本身，暴露了我们自己的工具中以下错误，每一个都是我们发现并修复的。这份列表本身就是错误计数；我们不在这句话里手动填写数字，因为在不断增长的列表旁手动输入数字，正是这款工具旨在发现的那类未经核实的说法。我们公开这些错误，因为从未出错的评分工具，就是从未经过检查的评分工具：

• Django 在依赖卫生方面被误判为严重问题。 我们把适用于应用的预期套用到了库上。现在由原型类型决定是否评估这一维度。
• OpenSSF Scorecard 在审计跟踪方面被误判为严重问题。 我们把 Google 自己的审计工具标记为审计不足。该维度此前缺少“是否有可供评级的内容？”这一道关卡，直接跳到了“做得怎么样？”。现在已补上这道关卡。
• 早期版本的看板静默丢弃了 17 个仓库中的 12 个，尽管如此却仍报告成功。 生成器此前可能丢失行而不发出提示。现在它会断言语料库中的每个仓库都已得到处理——已排名、未排名或出错——否则就会明确失败。
• 低覆盖率仓库被当作已完成全面测量来排名。 现在设有置信度下限：低覆盖率仓库会照常发布，但不参与排名，而不是让人误以为我们拥有实际并不具备的精确度。
• A1 的定时工作流检查把我们自己的内部 QA Agent 文件名硬编码为定义，而不是检查它实际衡量的概念。 按照这种设计，它对所有外部仓库都不起作用——这是一条伪装成通用规则的主场规则。现在它会检测模式（由 cron 定时安排、运行验证套件的工作流，以及其结果是持久发布还是仅交给临时 CI 工件）；我们自己的内部夜间 QA 工作流只是这种模式的一个已识别实例，而非其定义。
• 我们的看板与自有证书在 4 个仓库的总体分数上相差 0.1——存在两套自洽的计算依据（看板用于跨仓库公平排名的依据，以及各证书自身维度的依据），却在两处都印了同一个词：“Overall”。我们在上线当天发现并修复了这个问题：“Overall”现在在所有出现之处——看板、证书、徽章、报告和 JSON——都逐字节一致；而在排名依据确实不同的地方，它现在有单独且明确标注的列，不再借用同一个名称。
• 我们自己的行使用了一条其他人无法运行的评分路径。 看板生成器可以在公开扫描后添加内部采集器，因此它那份看似可靠的采集器黑名单并非其声称的约束条件。Rubric v3 移除了这条额外路径：语料库中的每一行现在都经过同一个封装的公开评分器，每个外部来源都固定到一个提交，并且必需的防护检查会重新评估每一行，并比较分数、判定、覆盖率和证据。坦诚修正后，我们自己的私有代码库 Code 分数从 2.5 降至 2.4，A5 从 2.9 降至 2.4。虽然没那么好看，但更值得信赖。
• 已跟踪的符号链接可能会让证据依赖检出目录之外的文件。 仓库发现过程使用了会跟随符号链接的常规文件检查，因此已跟踪的链接可能逃出不可变的源代码快照。Rubric v4 现在只接受已跟踪的常规文件。在固定的语料库中，这移除了 Zod 的一个重复声明来源：A5 从 2.2 降至 2.0，而四舍五入后的 Code 分数、Overall、判定和排名保持不变。完整的 24 行差异见 rubric 更新日志。
• 同一个固定提交可能因克隆中的无关 Git 引用不同而得到不同分数。 历史证据遍历了所有本地引用和远程跟踪引用，包括并非待认证修订祖先的分支。必需的干净克隆复现任务发现了这一不一致。Rubric v5 现在只扫描 HEAD 的祖先，因此环境中的分支状态不再能增加证据或改变覆盖率。完整的 v4 至 v5 差异已发布在 rubric 更新日志中。
• 版本 0.1.1 将 --help 和 --version 当作未知标志拒绝，并把 -h 识别为目录路径。 版本 0.1.2 会在解析位置路径前处理这两个别名，并从软件包清单读取所打印的版本号。
• 我们报告了自己测试夹具中的定时侧信道。 将 Cejel 指向它自己的仓库时，其秘密处理维度标记出“非恒定时间的秘密比较”——实际上这段内容位于测试文件的字符串字面量中，是用于证明检测器会触发的故意不安全示例代码。它读取的是一个文件，而非比较操作，却报告了一个旨在捕获该漏洞的测试中存在漏洞。同一维度的两条子规则各自对“生产代码”有不同的私下定义，而没有定义的那条反而发出了更响亮的警报。版本 0.1.3 让每条规则都使用同一个派生出的答案，并且只报告真实匹配项所在的实际行，否则就什么也不报告。
• 我们修复了 COBOL 的误判，发布了版本，但问题依然存在。 更早的一个版本修正了某个用我们无法阅读的语言编写、却仍被评分的仓库。用于证明修复有效的夹具只包含 COBOL。我们实际指向的第一个 COBOL 仓库——AWS 的大型机信用卡演示项目——在 329 个文件中夹带了 9 个无关的 shell 脚本，而这 9 个脚本就足以完全绕过弃权路径：一个 99% 为 COBOL 的代码库仅凭部署脚本就被评分，并得到一个看似确定的 0.0、“Unverified”。每个真实的旧式仓库都有部署脚本，因此这个通过所有测试的修复实际上对几乎所有此类仓库都不起作用。现在，已识别的源码必须占据主导地位，而不能只是存在。比现实更干净的夹具证明不了任何事。
• 版本 0.1.7 漏掉了 AVA 在仓库根目录使用 test.js 的约定。 针对 sindresorhus/slugify 的冒烟测试报告称已配置测试运行器，但未检测到具体的测试文件，尽管仓库根目录中存在 test.js。这是 Cejel 的检测缺口，并非关于该仓库的证据。Rubric v6 现在能识别 AVA 的 test.js 和 test-*.js 约定；回归夹具也保留了这一修正。
• 版本 0.1.9 声称 Express 没有覆盖率配置，但它的 package 脚本使用了 nyc。 检测器此前只查找独立的覆盖率文件和框架配置。版本 0.1.10 还会识别 package.json 中实际使用的 nyc、c8 和 Istanbul 命令或配置。未使用的依赖不会被当作覆盖率证据。这消除了一个误报，同时不改变测得的覆盖率分数。
• 仅显示指标的维度等级会告诉用户问题由“combined metric weighting”导致，然后就没了下文。 完整证书中包含底层指标，但终端结果中没有；而 info 级别的发现可能与 critical 维度等级并列显示，却没有说明二者是不同的概念。版本 0.1.10 会明确列出贡献最低的两项测量结果、具体的后续操作、finding severity 和 dimension band。此外，当请求扫描的目标被 gitignore 忽略时，它会作出说明，而不会把该目标说成一个普通的空仓库。 每一次都源于我们造成的信任失误——对他人代码的误报、悄无声息的遗漏、前后不一致的呈现，或只适用于自家项目的评分路径——我们宁愿让你提前知道，也不愿你事后才发现。如果你认为榜单对你的仓库评分有误，请提交 issue——无法公开修正的评分标准，就不该公开发布。

评分标准的任何变更都不会悄悄重新评分。 每次评分行为变更都必须提升 WITAN_RUBRIC_VERSION，并在 leaderboard/RUBRIC_CHANGELOG.md 中公布全语料库的变更前后对比——列出每个仓库的分数、判定和排名；若结果是“没有仓库发生变动”，也必须明确说明。未同时满足这两项要求的构建将失败；有关上述主场优势修正，请参阅该文件中的 v2 条目，这是首次以这种方式记录的评分标准变更。

许可证

cejel 是免费软件，采用 AGPL-3.0-only 许可证，遵循 copyleft 要求：你分发的任何修改版本，或作为网络服务运行的任何修改版本，都必须按照相同条款提供其源代码。对于需要在不承担这些 copyleft 义务的情况下使用或修改 cejel 的团队，我们也提供商业许可证。