Cejel

cejel

Cejel（「SEH-jel」）— コードベースの信頼証明書です。

無料、オフライン、登録不要の CLI で、リポジトリを信頼できるかどうかを判断するエンジニアリング上のシグナル（テスト、シークレット、隔離性、申告内容と実態、CI／監査の規律）を評価し、信頼証明書とバッジを出力します。AI がコードの多くを書いた場合に特に役立ちます。まさにそういうときこそ、コードを目視しただけでは信頼性を判断できません。決定論的な、LLM を使わない評価コアを基盤としており、無料の利用ではネットワークへの呼び出しは一切なく、アカウントも不要です。

主張の範囲： Cejel が評価するのはエンジニアリング上の信頼性を示すシグナルです。ソフトウェアの欠陥を検出したり、コードの安全性を証明したりするものではありません。欠陥や脆弱性のスキャナーは引き続き証拠を生成するものであり、Cejel はその証拠を集約して信頼証明書にまとめることができます。

Cejel は、すでに利用しているスキャナーと競合する新たな単機能スキャナーではありません。複数のスキャナーを集約する、オープンで移植可能なオフラインの信頼証明書です。SARIF 互換の出力（MunaTrust、Snyk、Semgrep、CodeQL、Codex）と OpenSSF Scorecard を入力すると、それらすべてをまとめた共有可能な証明書とバッジが得られます。詳しくは以下の「スキャナーを集約する」をご覧ください。

Cejel は Barg Labs 自身のコードにも使用されています。公開ボードでは、公開リポジトリのランキングとは別に、公開者が所有するスナップショットを明示しています。

評価基準の較正ポリシー

公開 CLI のデフォルトは witan-rubric-v17-2026-07-24 です。これは、事前登録された200リポジトリの未使用ホールドアウトで Cejel の基準を最後にクリアした評価基準です。公開されている較正値は、この正確な評価基準と固定された評価対象にのみ適用されます。以降の評価基準（現在の v18 から v23 までの前向き評価シリーズを含む）は、明示的な評価ハーネスでのみ利用できます。前向き評価基準は v17 の較正値を一切引き継ぎません。範囲を限定したペア修正またはコーパス差分の結果によって、その構築内容を検証することはできますが、適合率、再現率、偽陽性率の主張を引き継ぐことはできません。前向き評価基準を公開デフォルトに昇格させるには、新たに認証された未使用ホールドアウトを用意し、事前登録されたすべてのゲートを通過したうえで、昇格の判断を別途記録する必要があります。

測定済み再現率（限定的）

測定済み再現率（限定的）。 Cejel が公開しているコホートレベルの対象範囲内の検出再現率は、前向き評価の v22 評価基準についての1つの数値で、docs/calibration/v22-detection-recall/ に記載されています。一般的な再現率の数値は存在しません。また、再現率と呼ばれる3つの量は 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。

欠陥クラスの調査では、リリース済みの各ルールが対象とする欠陥クラスというカバレッジの範囲を公開しており、再現率の主張ではないことを明示しています。

インストール

アカウントも、キーも、登録も不要です。

単一ファイルのバイナリ。 ファイルは1つだけです。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.7 では意図的に署名されておらず、Microsoft SmartScreen が警告を表示する場合があります。リリースビルドでは、SEA 注入の前に Node が継承した署名を削除し、Windows が結果を NotSigned と報告しない場合は失敗します。無効な署名を同梱することはありません。実行する前に、SHA256SUMS と GitHub のビルド来歴の証明を確認してください。各バイナリには、SPDX SBOM（バイナリに同梱されるパッケージ、ビルド時に一覧化されたもの、および埋め込まれた Node.js ランタイムを記載。0.6.0 以降のリリースでは、バイナリに対する証明付き）と、--version、--help、実際のスキャン、ソースとバイナリの同等性、ネットワークを遮断したスキャンを対象とする、そのプラットフォーム上での検証レシートも添付されています。ポリシーで Authenticode が必須の場合は、人による承認済みの署名手段が利用可能になるまで、npm パッケージまたは OCI イメージを使用してください。

オフラインで使えるという主張を鵜呑みにせず、確かめてください。 ネットワークをオフにしてから、バイナリを実行してください。それでもリポジトリを評価し、証明書を書き出します。それがこの製品のすべてです。10 秒で反証できます。

# 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.7 は、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 にテンプレート名が残っている場合は、リポジトリから導出される安定したスラッグを維持したまま、証明書の表示名だけを上書きしてください。

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

0.4.5 以降、2 つのチェックアウトディレクトリで同じ識別フィールドを出力する必要がある場合は、--product-name を使用してください。指定した値は、表示名とスラッグ化された安定 ID の両方に設定されます。

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

製品 ID は呼び出し元のコンテキストであり、スコア対象のリポジトリ証拠ではないため、証明書のバイト単位比較に関する主張の対象外です。

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 は既定で 1 つのコミットだけを取得します。シャロークローンでは、A2 と B2 はそのコミットしか確認できず、証明書の「History limitations」にその旨が記載されます。

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 以降のリリースには、リリース一式に対する GitHub の署名済みビルド来歴の証明を含む Sigstore バンドルも含まれています。ダウンロードしたバイナリは、次の方法で検証してください。

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

これは暗号学的に署名された来歴です。Apple Developer ID や Microsoft Authenticode によるコード署名とは異なります。

Docker / OCI。 現在のコンテナーリリースは 0.6.7 です。

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

イメージは、既定で stdio 経由の cejel-mcp を実行します。代わりに CLI を使うには、次のようにします。

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

OCI イメージには、ベースイメージのパッケージの SBOM、最大モードのビルド来歴、および署名済みのレジストリ証明が含まれています。0.6.0 以降のリリースでは、Cejel が同梱するパッケージを一覧にした 2 つ目の SPDX 証明も含まれています。0.6.0 のイメージの SBOM には、これらのパッケージは記載されていません。

リーダーボード

Cejel OSS トラストリーダーボードはcejel.devで公開されており、現在の唯一のリーダーボードです。このリポジトリでは、スコアや証明書の別コピーを配布しなくなりました。リーダーボードには、その実行に関する生成元のパッケージバージョン、評価基準、実行日、固定された公開リビジョン、再現手順が記録されています。非公開のAlfred透明性スナップショットは、単独では再現できません。

サイトの「履歴」セクションには、2026-08-18の撤回が記録されています。それ以前にあった、非公開のスコアラーの再現性に関する主張は誤りでした。以前ここからリンクされていた、古くなった将来適用予定の評価基準のコピーは削除済みであり、現在の根拠として扱ってはなりません。

マスキングポリシー

読者が確認できる場合に限り、パスをそのまま公開します。リーダーボードに掲載されているすべての公開リポジトリでは、すべての成果物のあらゆる箇所に、完全な証拠パスと行番号を記載しています。開けない証拠が記載された証明書は、証拠ではありません。非公開リポジトリの項目（スタジオのモノレポの透明性スナップショット）では、どの箇所にも、どのフィールドや形式にもソースパスを記載しません。ただし、指摘事項そのもの、そのディメンション、ステータス、スコア、コンテンツハッシュは常に保持され、非公開となるのは場所だけです。場所の表示は一律に「パスを非公開 — 非公開リポジトリ」とします。マスキングによって削除されるのは場所であり、事実ではありません。非公開リポジトリが独自のチェックに失敗した場合も、その名前とともに証明書に記載されます。v3リポジトリスキャナーは、当方のリポジトリを含むすべてのリポジトリでB1とB5を該当なしとし、これらについて構造化された基盤の証拠を受け付けません。ほかの評価基準入力では引き続き定義されていますが、リポジトリのランキングではフェイルクローズ方式で除外されます。公開スキャナーが収集できない証拠で評価されることはありません。

既知の偽陽性（公開前に修正済み）

実際の優れたリポジトリを使って評価基準を調整すると、誤りが明らかになります。その記録は信頼性の主張の一部であり、隠すべきものではありません。2つのディメンションでは、実際の弱点ではなく、評価対象となる仕組みが「存在しない」ことに対して過度に厳しいスコアが付いていましたが、どちらも修正済みです。Djangoは、依存関係の衛生状態に関して、正確に固定されたバージョンではなくバージョン範囲を使用しているため、重大と判定されました。これはアプリではなくライブラリでは一般的で意図的な慣行です。現在の評価基準では、依存関係の衛生状態を、用途に応じた規範に照らして評価します。OSSF Scorecard（Google独自のサプライチェーンセキュリティ監査ツール）は、コミット済みのCHANGELOG.mdではなくGitHub Releasesを使ってリリースノートを公開していたため、監査証跡の完全性に関して重大と判定されました。評価可能な監査対象がないリポジトリは、過度に厳しいスコアではなく「データ不足」となり、複合スコアから除外されます。また、リーダーボードでは各行に測定対象のカバレッジ指標も公開します。スコアに反映されるのは測定済みのディメンションのみです。該当するディメンションの半数未満に基づいてスコアが付けられた行は、より多くの証拠がある行と順位付けせず、未ランクとして表示されます。

使用方法

./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> — 呼び出し元コンテキストの表示名とスラッグ化された製品 ID の両方を設定し、名前の異なるチェックアウトでも同一の証明書を生成できるようにします。
• --name <display> — 派生したスラッグは変更せず、表示されるプロジェクト名のみを上書きします。互換性のために維持されています。
• --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 実行の試行回数を記録します。人間が読める証明書と、attestation.json の省略可能な追加フィールド predicate.githubRunAttempt に表示されます。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 テンプレート／スタイル：ソースとしてカウントされるため、リポジトリが空だと誤認されることはありませんが、3 つの段階の中でエコシステム固有の調整が最も少ないカテゴリです。
• 未対応 — COBOL や MATLAB など、その他のエコシステム。Cejel はこれらを「ソース」として評価しません。認識可能な拡張子を持つファイルが 1 つもないリポジトリは、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）、およびターミナル出力（「Incorporates findings from: ...」）に名前が記録されるため、証明書はブラックボックスではなく、集約内容が見える形になります。

スキャナーの出力を取り込む方法は次の 3 つです。

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 は Witan ルーブリックの基準 ID（A1～A5、B1～B6）のいずれかです。weight（0～1、既定値は 0.5）は、このシグナルがそのディメンションに与える変動幅の上限を定めます。severity は critical | warning | info のいずれかで、location は任意です。

   version フィールドは必須です。Cejel は、バージョンのない汎用ドキュメントや不明なメジャーバージョンを、推測で処理せず拒否します。汎用取り込みコントラクト、公開済み JSON Schema、および合成 CI ヒールログのマッピングを参照してください。出力フィールドの安定性とバージョンの振り分けについては、形式の安定性に記載されています。コントラクト 1.1 では、入力をリビジョンに紐付けられるよう、任意の subject、producer、observedAt フィールドが追加されています。

取り込まれた各ドキュメントは、report.json の inputBinding にも記録されます。記録内容は、ファイルのバイト列の sha256、形式で宣言されている producer と subject（Scorecard の repo.name／repo.commit／date、SARIF の versionControlProvenance と invocations、汎用形式の subject／observedAt）、およびその subject がスキャン対象の 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 を参照してください。Cejel を push／pull_request で実行し、スコアと上位の検出結果をジョブサマリーに投稿します。また、設定可能な 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 は plugins/cejel/ に Claude Code プラグインとして同梱されています。このプラグインは、npx 経由で起動し、このリリースに固定された以下の scan ツールと、cejel-scan スキルを Claude に提供します。このスキルは、スキャンで質問に答えられる場合と証明書の読み方を Claude に伝えます。また、スコアはご自身の判断材料として提示し、監査や保証として扱わないよう Claude に指示します。

Claude Code 内で、このリポジトリのマーケットプレイスからインストールします。

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

シェルからは、同じ 2 つの手順を claude plugin marketplace add BargLabs/cejel と claude plugin install cejel@cejel で実行できます。

スキャンはオフラインで実行されます。scan ツールはネットワークへの接続を行わず、ファイルも書き込みません。サーバーの初回起動時に、npx が固定された @cejel/cejel パッケージを npm から取得します。お使いのマシンにないリポジトリを指定すると、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 サーバー（エージェント向け）

同じパッケージには、2 つ目の実行ファイル 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"]
    }
  }
}

サーバーは 1 つのツールと 2 つのリソースを公開します。

• 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 を実行するのではなく、openclaw@latest を明示的に指定してください。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' で失敗します。

OCI イメージは、Docker を優先的な実行境界として使う場合の代替手段です。ホストパスは、Cejel に読み取りを許可するよう OpenClaw が設定されているリポジトリのパスに置き換えてください。

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.7"]}'
npx -y openclaw@latest mcp doctor cejel-oci --probe

Cejel は Official MCP Registry で io.github.BargLabs/cejel として有効になっています。上記の明示的な OpenClaw 設定は、カタログのインデックス化とは独立して機能します。

Cejel は、指定したコードをスキャンします。この無料の導入形態では、エージェントのランタイムアクションを監視、傍受、または管理しません。ランタイムアクションの管理は、将来提供予定の有料 Agent Pack における別の境界です。

ここでいう「オフライン」の意味

リポジトリのスコアリング、つまり cejel scan . の実行と Action のスコアリングステップでは、ネットワーク呼び出しは一切行われません。テレメトリー、サインアップ、モデル呼び出しはありません。スキャナーは、強化された単一のサブプロセス境界を通じて、ローカルの git バイナリを呼び出します。引数は固定（シェルは使用しません）、タイムアウトと出力上限を明示的に設定し、プロンプトとネットワークトランスポートを無効にし、プロキシ変数を削除し、リポジトリによって制御されるファイルシステムの監視を無効化します。静的 CI ガードは、この単一モジュールでのみ node:child_process を許可し、それ以外のすべての場所で直接的なネットワークプリミティブを拒否します。また、各リリースバイナリも送信ネットワークを遮断した状態でスキャンされます。

@cejel/cejel パッケージを初めて取得する場合（この Action 自体の依存関係のインストールを含む、npm で配布される他の CLI と同様）には、ネットワークが必要です。これは初回のインストール時に限られるもので、スコアリングの保証には含まれません。追跡対象ファイルの一覧取得が予期せず失敗した場合、JSON、HTML、Markdown の証明書には、2 つの一覧が同等であるかのように黙って表示するのではなく、スキャナーが上限付きのディレクトリフォールバックを使用したことが明記されます。

証明書の対象範囲とは

証明書は、ピン留めされた特定のリビジョンにおけるリポジトリツリーを評価します。対象はそのツリーだけです。この境界は意図的に設けられています。ピン留めされたツリーの外部にまで及ぶ証明書は、受け取った人が再現できず、再現性こそがこの製品のすべてだからです。ピン留めされたツリーだけを評価するのは正しいことです。問題は、証明書自体に、読み手がどの種類の記述を受け取っているのかが示されていなかった点です。回帰テストスイートが別のリポジトリにあり、そこでチェックアウトされ、そのリポジトリ独自の CI で実行される場合、ソースファイルに対してテストファイルがゼロであると報告されるのは正しいことです。その記述はツリーについては真実ですが、システムについては真実ではありません。他に何の情報も持たない読み手には、その違いを見分けられません。

現在、すべての証明書のあらゆる表示形式（HTML、Markdown、ターミナル）で、判定結果にかかわらず、「この証明書の読み方」セクションに常時表示される対象範囲の説明が記載されています。証明書が示すのは、ピン留めされたリビジョンのリポジトリツリーについてであり、そのツリーが属するシステムについてではありません。また、そのツリーの外部にある証拠は確認されず、存在しないとも主張されません。これは補足であり、断定を避けるためのものではありません。「このツリー内では証拠が見つからなかった」という指摘は、そのままの内容です。

次の4つの状況では、ツリー自体に基づく結論が、実際に属するシステムについて誤解を招くおそれがあります。

• 別のリポジトリに置かれているテストスイート。 ピン留めされたツリーの内部からは検出できません。兄弟リポジトリの存在を示す信頼できるシグナルがないためです。条件付きの開示ではなく、上記の常時表示される対象範囲の説明で対応します。
• チェックを実行する前に、作業ディレクトリを別の場所に変更する CI 設定。 CI ジョブ自体を実行しなければ検出できませんが、オフラインスキャナーは実行しません。上記の常時表示される対象範囲の説明で対応します。
• 読み取り上限を超える大きな実装ファイル。 これは検出可能で、発生した場合は条件付きで開示します。サイズ上限を超えるファイルが、特定のシグナルで測定できるものがない理由となる場合、証明書のスキャン制限セクションでは、拡張子の除外や通常ファイルではない場合に使う一般的なカバレッジ制限の文言に含めるのではなく、そのファイルを明記します。具体的には、「リポジトリコンテンツのサイズ上限を超えた大きな実装ファイルを読み取り対象から除外しました」と記載します。現在、これは2つの A3 シグナル（ヘルス／レディネスルートの検出とオブザーバビリティマーカーのカウント）で発生します。同じシグナルごとの帰属方式を採用するシグナルが増えれば、対象も広がります。
• 認識はされるものの、機能しないパッケージスクリプト。 たとえば npm が自動生成する "test": "echo \"Error: no test specified\" && exit 1" というプレースホルダーが、実際のテストランナーと同じように評価される場合です。これは対象範囲の開示不足ではなく、検出器の欠陥でした。Cejel は現在、test スクリプトの内容を既知のテストランナー呼び出しと照合して確認するため、キーが存在するだけで評価することはありません。そのため、これについて個別の開示行は必要ありません。

ヘルスまたはレディネスのシグナルとして認められるもの

A3 の本番環境対応チェックにおける「ヘルスまたはレディネスのシグナル」コンポーネントは、調整済みルーブリック（および v25 より前のすべての暫定ルーブリック）において、意図的にファイル名ベースになっています。次の形式のみが評価対象です。

• health.ts、healthcheck.js、readiness.py などの専用ヘルスファイルまたはレディネスファイル（ファイル内に health または readiness の記述が必要です）。
• ルートの 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 Pack または Healthcare Pack のパック設計パートナーパイロットに参加してください。どちらも、ドメイン固有の調整ゲートを通過するまではパイロット段階です。

公開情報または機密情報を伏せた証拠のみを提出してください。GitHub の Issue に認証情報、専有の戦略コード、患者データ、または保護対象の医療情報を記載しないでください。

公開リーダーボード：伏せる情報、除外する情報、そして誤りがあった箇所

よく知られたオープンソースリポジトリのコーパスを自分たちのリポジトリと並べて採点し、信頼性ボードとして公開しています。他者のコードでリーダーボードを運用する以上、その仕組みを正確に説明する必要があります。以下にすべてを記します。

伏せる情報とその根拠。 ルールは一つです。確認できる場合に限り、パスをそのまま公開します。 公開リポジトリについては、すべての証拠パスと行番号を省略せずに記載します。証拠を開けない証明書は証拠とは言えません。非公開リポジトリ（自分たちのリポジトリ）については、どのフィールドや形式であっても、ソースパスは一切記載しません。検証できないパスは確認可能な情報を何も伝えず、代わりにファイルツリーを無償で開示することになります。伏せるのは場所であり、事実ではありません。検出結果、そのディメンション、ステータス、スコア、コンテンツハッシュはすべて残ります。パスを伏せた場合は、その旨を明記します。これは構造的に徹底されています。公開用アーティファクトは、データをレンダリングした後に情報を削除するのではなく、フィルタリング済みデータから作成されます。非公開パスを出力するビルドは、公開せずに失敗します。

ランキングから除外するもの。 v5 リポジトリスキャナーは、リポジトリ入力について B1（ディスパッチトレースの完全性）と B5（検証済み学習トレース）を評価しません。自分たちのリポジトリも例外ではありません。この2つはリポジトリ証明書では常に該当なしとなります。構造化された基盤証拠向けにルーブリック上の定義は残っていますが、このスキャナーはその証拠を受け付けません。ランキングでは、レガシー形式または別途作成された構造化レポートを読み取る場合も含め、両方のディメンションをフェイルクローズで除外します。公開スキャナーで収集できない証拠によって皆さんを採点することも、異議を唱えられない証拠によって自分たちに得点を与えることもありません。 私たちの誤り。 この評価基準を実際のリポジトリで調整し、見知らぬ人の立場でボード自体を動かしてみたところ、以下の誤りが自分たちのツールで見つかりました。いずれも私たちが発見し、修正したものです。リスト自体が件数を示しているため、この文では数を数えていません。増え続けるリストの横に手入力した数字を置くことこそ、このツールが見つけるために存在する、未検証の主張そのものだからです。誤りを一度も犯したことがない評価ツールは、検証されていない評価ツールです。私たちがこれらを公開するのはそのためです。

• Django は、依存関係の衛生状態について誤って重大と評価されました。 ライブラリにアプリケーション向けの基準を適用していました。現在は、アーキタイプによってこの評価軸を適用するかどうかを判定します。
• OpenSSF Scorecard は、監査証跡について誤って重大と評価されました。 Google 自身の監査ツールを、監査が不十分だと指摘してしまいました。「どの程度優れているか」を問う前に、「評価対象となるものがあるか」を確認するゲートがこの評価軸にはありませんでしたが、現在は追加されています。
• 初期版のボードでは、17 件中 12 件のリポジトリが何も告げずに除外されていたにもかかわらず、生成処理は成功を報告していました。 ジェネレーターは、行を失っても常に何も告げませんでした。現在は、コーパス内のすべてのリポジトリが、ランク付け済み、ランクなし、またはエラーのいずれかとして処理されていることを検証し、そうでなければ明確に失敗します。
• カバレッジの低いリポジトリが、十分に測定済みであるかのようにランク付けされていました。 現在は、信頼度の下限を設け、それを下回るリポジトリはランク付けせずに公開します。これにより、実際には得られていない精度があるかのような印象を与えません。
• A1 のスケジュール済みワークフローのチェックは、測定対象の概念ではなく、自社の内部 QA エージェントのファイル名を定義としてハードコードしていました。 そのため、外部リポジトリでは必ず機能しない、一般的なルールを装った身内びいきのルールでした。現在は、構造（検証スイートを実行する cron スケジュールのワークフローと、その結果が永続的に公開されるか、一時的な CI アーティファクトに渡されるだけかどうか）を検出します。自社の内部 nightly QA ワークフローは、その構造に該当する一例として認識されますが、定義そのものではありません。
• ボードと自社の証明書で、4 件のリポジトリの総合スコアに 0.1 の食い違いがありました。 2 つの基準（ボードでリポジトリ間を公平に比較する基準と、各証明書独自の評価軸に基づく基準）があり、どちらにも「総合」という同じ名前が表示されていました。公開初日にこの問題を見つけて修正しました。現在、「総合」の値は、ボード、証明書、バッジ、レポート、JSON のどこに表示されてもバイト単位で同一です。実際に異なるランキング基準は、同じ名前を使い回さず、明示的なラベルを付けた専用の列に表示されます。
• 自社の行だけ、他の誰も実行できない採点経路を使っていました。 ボードのジェネレーターは、公開スキャン後に内部コレクターを追加できたため、コレクターのブラックリストは、謳っていた不変条件を保証していませんでした。Rubric v3 では、この二重経路をなくしました。コーパスのすべての行が、同じ封印済みの公開スコアラーを通り、外部ソースはすべてコミットに固定されます。また、必須のガード処理がすべての行を再採点し、スコア、判定、カバレッジ、証拠を比較します。正直な修正の結果、Alfred の Code スコアは 2.5 から 2.4 に、A5 は 2.9 から 2.4 に下がりました。見栄えは劣りますが、信頼性は高まりました。
• 追跡対象のシンボリックリンクによって、証拠がチェックアウト外のファイルに依存する可能性がありました。 リポジトリの検出では、シンボリックリンクをたどる通常ファイルのチェックを使っていたため、追跡対象のリンクが不変のソーススナップショットから外に出る可能性がありました。Rubric v4 では、追跡対象の通常ファイルのみを受け付けます。固定されたコーパスでは、これにより Zod の重複した主張ソースが除外されます。A5 は 2.2 から 2.0 に下がりますが、丸め後の Code スコア、総合スコア、判定、順位は変わりません。24 行すべての差分は、ルーブリックの変更履歴に記載されています。
• 固定されたコミットのスコアが、クローン内の無関係な Git ref によって変わる可能性がありました。 履歴の証拠は、認定対象のリビジョンの祖先ではないブランチも含め、すべてのローカル ref とリモート追跡 ref をたどっていました。必須のクリーンクローン再現ジョブが、この不一致を検出しました。Rubric v5 では HEAD の祖先のみをスキャンするため、周辺のブランチ状態が証拠を追加したりカバレッジを変えたりすることはありません。v4 から v5 への完全な差分は、ルーブリックの変更履歴に公開されています。
• バージョン 0.1.1 は --help と --version を不明なフラグとして拒否し、-h をディレクトリパスとして読み取っていました。 バージョン 0.1.2 では、位置引数のパスを解析する前に両方のエイリアスを処理し、表示するバージョンをパッケージマニフェストから取得します。
• 自分たちのテスト用フィクスチャで、タイミングサイドチャネルを報告していました。 Cejel の秘密情報の取り扱いに関する評価軸を自分自身のリポジトリに適用すると、「一定時間でない秘密情報の比較」が検出されました。テストファイル内の文字列リテラルに含まれる、検出器が作動することを証明するための意図的に安全でないサンプルコードです。比較ではなくファイルを読み取り、その脆弱性を検出するために書かれたテストで脆弱性を報告していました。同じ評価軸の 2 つのサブルールが、「本番コード」の意味について異なる独自の定義を持っており、その定義がない方が、より大きな警告を出していました。バージョン 0.1.3 では、すべてのルールが、この問いに対する共通の導出済みの答えを使い、実際の一致箇所があればその行を、なければ何も報告しません。
• COBOL の誤判定を修正してリリースしたのに、まだ壊れていました。 以前のリリースでは、読み取れない言語で書かれたリポジトリが採点されてしまう問題を修正しました。その修正を証明するフィクスチャには、COBOL しか含まれていませんでした。最初に対象にした実際の COBOL リポジトリ、AWS のメインフレーム向けクレジットカードデモには、329 ファイル中 9 個の付随的なシェルスクリプトが含まれていました。その 9 個だけで棄権処理が完全に迂回され、99％が COBOL のコードベースがデプロイスクリプトを基に採点され、自信ありげに 0.0、「未検証」と判定されました。実際のレガシーリポジトリには必ずデプロイスクリプトがあるため、すべてのテストに合格した修正は、実質的にどのリポジトリでも適用されませんでした。現在は、認識されたソースが存在するだけでなく、大半を占める必要があります。現実よりも整ったフィクスチャでは、何も証明できません。
• バージョン 0.1.7 は、AVA のルートレベルの test.js という慣例を見落としていました。 sindresorhus/slugify に対するスモークテストでは、ルートに test.js が存在するにもかかわらず、テストランナーは設定済みだが具体的なテストファイルは検出されなかったと報告されました。これは Cejel の検出漏れであり、リポジトリについての証拠ではありませんでした。Rubric v6 は AVA の test.js と test-*.js の慣例を認識します。この修正は回帰フィクスチャで保持されます。
• バージョン 0.1.9 は、Express のパッケージスクリプトで nyc が使われているにもかかわらず、カバレッジ設定がないと報告していました。 検出器は、単独のカバレッジファイルとフレームワーク設定だけを確認していました。バージョン 0.1.10 では、package.json 内の実際の nyc、c8、Istanbul のコマンドや設定も認識します。使われていない依存関係は、カバレッジの証拠として扱いません。これにより、測定されたカバレッジスコアを変えずに、誤検出をなくします。
• 測定値だけの評価軸のバンドは、「指標の複合的な重み付け」が原因だとユーザーに伝えた後、説明を打ち切っていました。 元となる指標は完全版の証明書には含まれていましたが、ターミナルの指摘には表示されていませんでした。また、info の指摘の重大度が、2 つの異なる概念であることを明示しないまま、critical の評価軸バンドと並んで表示されることがありました。バージョン 0.1.10 では、寄与度の低い測定値を 2 つ、具体的な次のアクション、「指摘の重大度」、「評価軸のバンド」を明示的に表示します。また、要求されたスキャン対象が Git の無視対象になっている場合は、その対象を一般的な空のリポジトリとして扱わず、その旨を説明します。 いずれも、私たちが引き起こした信頼性の問題でした。他者のコードに対する誤検知、ひそかな見落とし、一貫性のない表示、あるいはホーム限定のスコアリング経路です。それを皆さんが自ら発見するよりも、先にお知らせしたいと考えています。ボードがリポジトリを誤って採点していると思われる場合は、issue を作成してください。公開の場で修正できない評価基準を、公開するべきではありません。

評価基準の変更によって、通知なく再採点することはありません。 スコアリング動作を変更するには、WITAN_RUBRIC_VERSION を更新し、全リポジトリを対象とした変更前後の差分を leaderboard/RUBRIC_CHANGELOG.md に公開する必要があります。そこには、すべてのリポジトリのスコア、判定、順位を記載し、変更がなかった場合は「no repository moved」と明記します。両方を満たさないビルドは失敗します。この方法で記録された最初の評価基準変更として、上記のホーム限定の問題を修正した v2 の項目をご覧ください。

ライセンス

cejel は無料で、コピーレフト条項を含む AGPL-3.0-only の下でライセンスされています。改変版を配布またはネットワークサービスとして実行する場合、同じ条件の下でソースコードも公開する必要があります。こうしたコピーレフト条項を適用せずに cejel を使用または改変する必要があるチーム向けに、商用ライセンスもご用意しています。