proofline MCPサーバー
コミット 2026年10月27日機械的に検証可能なコントラクトに基づき、コーディングエージェントの成果物を検証・妥当性確認することで、パフォーマンスを保証し、根拠のない主張を防ぎます。
別名 Optitransfer/proofline, @optitransfer/proofline
- スター
- 0
- ツール
- —
- ダウンロード数(30日間)
- —
- 最新バージョン
- —
- 最終コミット
- 2026年10月27日
- ライセンス
- —
proofline MCPとは
prooflineはMCPサーバーです。 機械的に検証可能なコントラクトに基づき、コーディングエージェントの成果物を検証・妥当性確認することで、パフォーマンスを保証し、根拠のない主張を防ぎます。.
プロジェクトのREADMEから生成された概要
proofline MCP server について
コーディングエージェントを活用する開発者は、Prooflineを使用することで、自動化された作業が指定された要件を実際に満たしているかを確認できます。エージェントによる「タスク完了」の主張を鵜呑みにするのではなく、このツールは機械的に検証可能なコントラクトを使用してパフォーマンスを検証します。リポジトリ内のゲートキーパーとして機能し、git hooksを利用して、テストのスキップ、タイムアウトの延長、承認された範囲外での変更といった一般的なショートカットを防止します。
システムをセットアップするには、AGENTKEY_HOME ディレクトリを用意し、agentkey ユーティリティを使用してオーナーキーを管理する必要があります。ワークフローでは、まず proofline.json コントラクトを作成します。エージェントが自身のルールを書き換えるのを防ぐため、オーナーがこれを署名し承認する必要があります。その後、エージェントは proofline next などのコマンドを使用してタスクを受け取り、proofline verify を使用して進捗を確認します。高いセキュリティが求められる環境では、検証プロセスが改ざんされないよう、特定のイメージダイジェストを使用して、proofline verify および proofline gate コマンドを隔離されたコンテナ内で実行できます。
できること
- 1エージェントによる根拠のない主張の防止AIエージェントが、実際には必要なテストをスキップしたりタイムアウトを延長したりしているにもかかわらず、タスクが完了したと報告する可能性があります。
- 2厳格なタスクスコープの強制コーディングエージェントが、割り当てられたタスクに含まれないファイルを変更しないように制御できます。
- 3修正フィードバックの自動化エージェントが検証チェックに失敗した場合、システムはどのファイルのどの行を修正すべきかについて、具体的な指示を提供します。
プロジェクトの README から作成されています。すべてのユースケースは、その引用と照らし合わせて確認されています。
proofline MCPのインストール方法
フォーマット検証日 2026年11月10日Cursor に追加Gooseに追加Claude Codeにproofline MCPをインストール
$ claude mcp add proofline -- npx -y @optitransfer/prooflineCursorにproofline MCPをインストール
~/.cursor/mcp.json
{
"mcpServers": {
"proofline": {
"command": "npx",
"args": [
"-y",
"@optitransfer/proofline"
]
}
}
}VS Codeにproofline MCPをインストール
.vscode/mcp.json
{
"servers": {
"proofline": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@optitransfer/proofline"
]
}
}
}VS Code CLIにproofline MCPをインストール
$ code --add-mcp '{"name":"proofline","type":"stdio","command":"npx","args":["-y","@optitransfer/proofline"]}'Claude Desktopにproofline MCPをインストール
claude_desktop_config.json
{
"mcpServers": {
"proofline": {
"command": "npx",
"args": [
"-y",
"@optitransfer/proofline"
]
}
}
}Codexにproofline MCPをインストール
$ codex mcp add proofline -- npx -y @optitransfer/prooflineCodex config.tomlにproofline MCPをインストール
~/.codex/config.toml
[mcp_servers.proofline] command = "npx" args = ["-y", "@optitransfer/proofline"]
Gemini CLIにproofline MCPをインストール
$ gemini mcp add -s user proofline npx -- -y @optitransfer/prooflineGemini settings.jsonにproofline MCPをインストール
~/.gemini/settings.json
{
"mcpServers": {
"proofline": {
"command": "npx",
"args": [
"-y",
"@optitransfer/proofline"
]
}
}
}設定
AGENTKEY_HOME
| 名前 | 説明 | 種類 |
|---|---|---|
| AGENTKEY_HOME | — |
自動チェック
実行日 2026年11月15日完全なレポート →まだ検証されていません。サーバーには80点のスコア、重大な問題がないこと、および検証に必要な十分なデータが必要です。 チェックの仕組み · 点数を上げるための改善点
- ソースリポジトリがリンクされており、アクセス可能optitransfer/proofline is public and reachablegithub.com/optitransfer/proofline ↗合格
- パッケージがこのリポジトリをソースとして指定@optitransfer/proofline names optitransfer/proofline as sourcenpmjs.com/package/@optitransfer/proofline ↗合格
- ビルドの来歴 (Sigstore 証明)No build attestation published for this release未チェック
- オープンソースライセンス (OSI)No license検出事項
- 過去1年以内にコミットまたはリリースありLast commit or release 2026-10-27github.com/optitransfer/proofline ↗合格
- OpenSSF Scorecard未チェック
- パッケージ名が有名なパッケージに酷似していないNo popular package one edit away from @optitransfer/proofline合格
- パッケージおよびその依存関係に重大な勧告なし未チェック
- モデルへの隠れた指示がない0 tool descriptions and the README read; no override phrases, credential paths or hidden characters合格
- 破壊的なツールがラベル付けされている未チェック
- リモートエンドポイントが MCP ハンドシェイクに応答未チェック
README
GitHubで見るProofline
The agent says done. Proofline verifies and validates the work against a V&V contract, to assure agent performance.
A coding agent reports that a task is finished. Proofline does not take the report: it holds the definition of done as a contract a machine can check, hands the agent one task at a time, re-runs every check itself when the agent reports, and lets a commit through only when the evidence says PASS. The agent gets a corrective prompt that names the file and the line to fix next, never a verdict it can argue with. Zero dependencies, Node 22+, Apache-2.0.
proofline verify --isolated and proofline gate --isolated run command, red-green and metric checks in a container. Local use stays off unless that flag is passed. The image digest is env.image on the contract under test. Without it, --isolated refuses and names env.image.
flowchart LR
C["proofline.json<br/>tasks, criteria, scope,<br/>forbidden actions"] --> N["proofline next<br/>one task, its brief,<br/>the base revision pinned"]
N --> A["the agent<br/>failing test first,<br/>then the fix"]
A --> H1{"pre-commit hook<br/>forbidden actions,<br/>contract change without a marker"}
H1 -- "refused" --> A
H1 -- "clean" --> V["proofline verify<br/>every criterion re-run<br/>from the base revision"]
V -- "FAIL or BLOCKED:<br/>corrective prompt,<br/>file and line" --> A
V -- "PASS" --> G["proofline gate --claims<br/>the agent's report line<br/>against the evidence"]
G -- "a claim the evidence<br/>does not support" --> A
G -- "PASS, report written" --> H2{"pre-push hook<br/>does this HEAD gate PASS?"}
H2 -- "no" --> A
H2 -- "yes" --> M[("main")]
M --> N
O["owner marker<br/>sha256 of the approved<br/>proofline.json"] -. "approves a<br/>contract change" .-> H1
See it catch
node examples/demo/catch.mjs builds a throwaway repository with one task, then plays five ways an agent "finishes" without doing the work, and the real work last. Real output, shortened only where a line ran long:
proofline next -> TASK-1: Saves return a durable receipt on the default path
1. The lie: no work, reported "done | abc1234 | app.test.mjs" -> FAIL
claim rejected: claimed "done" but the independent gate says FAIL: ...
claim rejected: commit abc1234 does not exist
TASK-1-AC01 FAIL test file test/durable.test.mjs not found
TASK-1-AC02 FAIL durableReceipt is not referenced from the default path (src/app.mjs; 2 files reachable). Built but not wired in.
2. The gap: a "durable" test that asserts what already held -> FAIL
TASK-1-AC01 FAIL test PASSES on base 412bc3d9 without the change: it does not prove the change (tests how, not what?)
3. The shortcut: test.skip and a timeout raised 2000 -> 20000 -> FAIL
forbidden: test_skip_only in test/app.test.mjs: test.skip('handle returns ok', { timeout: 20000 }, () => { assert.equal(handle('x').ok, true); });
forbidden: timeout_raise in test/app.test.mjs: 2000 → 20000
TASK-1-AC03 FAIL 1 skipped/todo > allowed 0
4. The stray change: README.md edited, outside the task's scope -> FAIL
TASK-1-AC04 FAIL changes outside the approved scope: README.md
5. The weakening: proofline.json edited so "suite green" runs `true`, then git commit -> REFUSED by the pre-commit hook
contract weakened: TASK-1/TASK-1-AC03 command changed: "node --test" → "true"
marker (no approvals directory configured)
6. The work: failing test first, durableReceipt wired in, committed through the hooks, pushed -> PASS
TASK-1-AC01 PASS red on base (exit 1), green now
TASK-1-AC02 PASS durableReceipt used on the default path: src/app.mjs
TASK-1-AC03 PASS exit 0 in 234 ms
TASK-1-AC04 PASS 2 changed files, all in scope
TASK-1-AC05 PASS HEAD f6234c72 is origin/main
claim accepted: "TASK-1 | done | f6234c7 | save is durable, test/durable.test.mjs | - | -"
evidence: 9 entries in the hash-chained log; report .proofline/reports/TASK-1-latest.md
Caught five, passed one.
Sixty seconds
In the repository the agent works on:
npm install --save-dev @optitransfer/proofline@next && npx proofline init --approvals ~/.proofline/approved && cp node_modules/@optitransfer/proofline/AGENTS.md .
initialised /path/to/your-repo
proofline.json
.proofline/config.json
.gitignore
hooks/pre-commit
hooks/pre-push
That writes the contract skeleton, the local evidence log, the two git hooks, the directory where you (the owner) approve contract changes, and the loop the agent follows in AGENTS.md. Add one task and tell the agent to start:
cat > task.json <<'JSON'
{ "id": "TASK-1", "title": "Reject an empty body", "phase": "implement",
"scope": { "allow": ["src/**", "test/**", "CHANGELOG.md"] },
"criteria": [
{ "id": "TASK-1-AC01", "mandatory": true, "statement": "an empty body is refused",
"verifier": { "type": "test_red_green", "test_file": "test/empty_body.test.mjs", "cmd": "node --test {test}" } },
{ "id": "TASK-1-AC02", "mandatory": true, "statement": "suite green",
"verifier": { "type": "command", "cmd": "npm test" } },
{ "id": "TASK-1-AC03", "mandatory": true, "statement": "pushed", "verifier": { "type": "pushed" } } ] }
JSON
npx proofline contract create --from task.json # TASK-1: valid
npx proofline next # the agent's first command: the brief, with the base pinned
When the agent reports, Proofline checks. Before any work this is what it says, and the agent is told what to do next:
$ npx proofline verify TASK-1
== TASK-1: FAIL
base: 0a88576db5567f08c9f1cd9481c633001036d8e1 = 0a88576d (pinned at start)
FAIL TASK-1-AC01 [test_red_green] test file test/empty_body.test.mjs not found
PASS TASK-1-AC02 [command] exit 0 in 393 ms
FAIL TASK-1-AC03 [pushed] working tree not clean (3 paths); work held locally
report: .proofline/reports/TASK-1-latest.md
PROOFLINE CORRECTIVE INSTRUCTION for TASK-1 (Reject an empty body): gate FAIL
1. TASK-1-AC01 [test_red_green] FAIL: an empty body is refused
Next step: The test test/empty_body.test.mjs must FAIL on the base and PASS now.
2. TASK-1-AC03 [pushed] FAIL: pushed
Next step: Commit everything and `git push origin main` (hooks on; never --no-verify).
DECISION: FAIL
Exit codes: 0 PASS, 1 FAIL, 2 BLOCKED, 3 usage. Every command takes --json. The published package is @optitransfer/proofline at 0.2.0-next.1 on the next dist-tag: npx @optitransfer/proofline@next. npx proofline --version prints the version you have.
How you use it, start to finish
Short path
proofline setup then proofline task "<plain words>" then proofline contract approve then proofline watch.
That is the short path: four commands, in that order. The diagram and the table below are the manual path.
proofline setup needs two things from your shell, and stops before it writes anything when either is missing, naming the command that provides it:
AGENTKEY_HOME: the directory that holds your owner key. Proofline never picks one for you. For exampleexport AGENTKEY_HOME="$HOME/.proofline-owner", in your shell profile, becauseproofline contract signreads it too.agentkeyon PATH: the owner key is made with agentkey.npm install --save-dev @optitransfer/agentkeyand run Proofline throughnpx, ornpm install -g @optitransfer/agentkey.
export AGENTKEY_HOME="$HOME/.proofline-owner"
npm install --save-dev @optitransfer/proofline@next @optitransfer/agentkey
npx proofline setup
Once guard/owner.pub is pinned, proofline contract sign writes proofline.json.sig and proofline contract verify-sig checks it. proofline contract propose writes proposals/<sha256>.diff and prints the hash. An unsigned or altered contract is refused with contract not owner-signed.
Three parties: you (the owner of the repository), your agent (Claude Code, Cursor, a CI job), and Proofline (the hooks and the gate in your repository). The agent builds; Proofline checks; you decide twice, once on the rules and once on the result.
sequenceDiagram
participant You
participant Agent
participant Proofline
You->>Proofline: 1. npx proofline init
You->>Agent: 2. the task, in plain words
Agent->>Proofline: 3. proofline contract create (the task as checks)
Proofline-->>You: the contract and its hash
You->>Proofline: 4. approve the hash
Agent->>Proofline: 5. proofline next, build, proofline verify (repeat)
Agent->>Proofline: 6. git commit, git push (the hooks gate both)
Agent-->>You: 7. "done", commit, tests
Proofline-->>You: 8. gate report and signed receipt
You->>You: merge
| Step | Who | What happens | Command |
|---|---|---|---|
| 1 | You | Install Proofline in the repository once. It writes an empty proofline.json, installs the pre-commit and pre-push hooks and records where your approvals live. |
npm i -D @optitransfer/proofline@next then npx proofline init |
| 2 | You | Describe the task to your agent in plain words. "Add per-client rate limiting, 100 requests a minute, 429 with Retry-After, every existing test stays green." | your agent's chat |
| 3 | Agent | Turn the words into a contract: a title, the files it may touch, and acceptance criteria that are checks, not sentences (a test that fails before and passes after, a grep for Retry-After, the suite green, changes in scope, pushed). The result is the contract's new bytes and their hash. The agent cannot put it into force. |
proofline contract create |
| 4 | You | Read the contract (it is short and every line is checkable) and approve its hash. From now on the hooks accept only contract bytes you approved, so the agent cannot change the rules it is judged by. | approve the hash |
| 5 | Agent | Take the one active task with its brief, write the failing test first, then the code, and run the checks as often as it likes. Proofline re-runs every criterion itself and prints a corrective instruction for anything not yet true. | proofline next, proofline verify TASK |
| 6 | Agent | Commit and push. The pre-commit hook refuses the known shortcuts: skipped tests, raised timeouts, deleted assertions, a bypass flag. The pre-push hook runs the gate before anything leaves the machine; a FAIL stays local. | git commit, git push |
| 7 | Agent | Report: done, the commit, the tests. The report is a claim, not evidence. | one line |
| 8 | Proofline | The gate compares the claim with what it measured and writes the report: every criterion PASS or FAIL with the measured detail, and a signed receipt (through agentkey) saying which agent role produced the commit against which contract hash. A claim the evidence does not support is rejected. | proofline gate TASK |
| You | Read the one page, not the diff. Merge. |
What you never do: read the agent's prose for reassurance, trust a green checkmark the agent printed, or let the agent change the rules it is judged by.
Why
An agent's report is a claim. Left to itself it says "done" for a test it skipped, a timeout it raised, a target it lowered, a commit it never pushed, or a number it did not measure. Reviewing every claim by hand does not scale past one agent, and asking a second model whether the first one is right only adds a second opinion.
Proofline replaces the opinion with a contract and a re-run. The contract is yours: it names each task, the files it may touch, and the checks that prove it, and it cannot be weakened by the agent, because a changed criterion, threshold or forbidden rule is refused at commit time unless a marker with the hash of the new contract sits in the directory only you write to. The checks are the kind a machine can settle: a test that fails on the base revision and passes now, a command and its exit code, a metric against its target, changed files inside the allowed scope, a HEAD that is on the contract's branch. Every result is appended to a hash-chained evidence log, so a report can be checked later against what actually ran.
What it checks
Every criterion names a verifier. Each one is deterministic: no model reads the diff, no opinion decides.
| Type | Passes only when |
|---|---|
command |
exit code matches; no hung/cancelled tests; optional max_skipped, min_tests (catches deleted tests). A fail-then-pass is flaky, not a pass. Test counts and failing-test names are parsed from the Node test runner's output (TAP or spec reporter); for other runners use command criteria without min_tests |
test_red_green |
the test exists, fails on the base revision (replayed in a git worktree) and passes now; named test actually executed |
test_exists |
test file (and name) present |
metric |
bench command's JSON (key dotted path) meets op value; also fails on >20% regression vs baseline.metrics. One bench run feeds all its metrics. Missing rig → BLOCKED. The evidence and report line record the 1-minute load, the CPU count and the node --version the command resolves; with defaults.max_load_per_cpu set, a load per CPU above it before the run is BLOCKED (machine busy), never PASS or FAIL, and raising or removing that limit is a contract weakening |
grep |
pattern present/absent (e.g. the new code path is the default config) |
wiring |
the symbol is called in a file reachable by static imports from the default entry (catches "built but not wired in") |
scope |
every changed file matches the allowlist |
docs |
generator leaves no diff in the given paths |
pushed |
tree clean and HEAD == <remote>/<branch> (the criterion's remote/branch, else defaults.remote/defaults.branch, else origin/main) |
file_exists |
path exists (e.g. the bench rig is committed) |
Always on: forbidden-action scan of the diff (skip/only/todo, raised timeouts, net assertion loss, deleted tests, --no-verify, bypass env vars, lowered protected caps; proofline.json and .proofline/ are left out, because the contract declares the deny-list and would match it), contract-weakening check vs the base revision (loosened thresholds, removed criteria, changed commands → BLOCKED), hash-chained evidence log integrity, claim reconciliation.
How it decides
Owners
Two or more builders can share one contract. A task may carry an owner, and defaults.owners may list the names (contract validate then refuses an owner outside the list). next --owner <name> (MCP: task_next with owner) hands out only that owner's tasks and unowned ones, never another owner's; the phase gate applies to that lane, and depends_on still waits on any owner's task. status --owner <name> and brief <TASK> --owner <name> take the same filter, and brief refuses another owner's task. Without --owner, nothing changes.
Contract scaffold
proofline contract scaffold --title ... --scope a,b [--kind feature|docs|release] prints a task with the standard criteria and the default stop rules. It does not write the contract. A feature gets a red-then-green test and the suite; docs gets a grep; release gets one command. Scope and pushed are always there. contract validate refuses a task with no stop rules, a task with no scope criterion, a criterion whose file, path, test file or entry sits outside that scope, a double-quoted sh -c or bash -c command that contains $, and a red-then-green criterion with no test file. A grep whose pattern already matches on the base revision is a warning, and the warning names that revision. brief and steer still run when a loaded task has no stop rules.
proofline contract merge <fragment.json> [--owners a=b,c=d] appends the fragment's tasks and any owner rule that is not already there. A duplicate id is refused and the file is left untouched. Existing tasks and the bytes around them stay. The command prints the sha256 of the result. proofline contract coverage <REQUIREMENTS.md> [--contracts a.json,b.json] reads ids from lines of the form - ID: text and prints one line per id with the tasks that name it, or MISSING. A task that names an id the file does not list is unknown. The exit code is 1 when any id is missing or unknown.
Git hooks
init installs pre-commit (forbidden actions and contract weakening vs HEAD) and pre-push (the active task must gate PASS). If the repository already has one of these hooks and it is not proofline's, init keeps it as <hook>.proofline-prev and says so. The installed hook runs it first, with the same arguments and stdin; if it fails, its exit code stands and the gate does not run. Running init again changes nothing. If both <hook> and <hook>.proofline-prev exist and neither is proofline's, init stops rather than lose one.
A push is gated on the commit being pushed. The hook reads that commit's local sha from stdin, checks the commit out in a temporary worktree, and gates it there. It does not gate the checked-out HEAD. A commit already on a remote default branch is left out. That head is read with git ls-remote of the push URL at send time, never from a local remote-tracking ref, for an existing branch and for a new branch. A commit on no remote is still gated. If the server cannot be read, every commit in the range is gated. The task is the (TASK-ID) suffix on the subject, or a Proofline-Task trailer. A commit that names no task is gated on the active task. The base is the most recent pin from proofline next for that task, otherwise the parent of the commit being pushed, and every refusal prints that base. A worktree with no evidence still gates. Evidence left in the worktree you push from cannot block a commit that passes at its own sha. An active task whose head is an ancestor of origin/main, or whose pushed criterion has a PASS record, has landed: next, verify and the hooks clear .proofline/active and say so, and a landed task is never gated. A push with no active task and no named task is refused, and the refusal prints proofline next. Before any task has a start record, a push that names no task passes and prints proofline next.
A contract change is refused unless an approval marker is present. proofline init --approvals <dir> (re-runnable) stores that directory in .proofline/config.json, which is never committed. The marker is a file in that directory named with the sha256 of the staged proofline.json bytes. The refusal prints the weakenings, the sha256 and the marker path. A marker named for any other bytes does not count, and what else the commit stages makes no difference. With no directory configured, every contract change is refused. There is no bypass.
verify and gate read the same marker for the current proofline.json bytes. When that marker is a regular file, the weakenings are an approved contract change: the report names the marker path, and the decision is not blocked. A missing marker, a marker for other bytes, or a symlink still blocks.
Base revision
Every diff check (forbidden scan, scope, test_red_green, contract weakening) compares the base revision with the working tree. The base is taken from, first match wins:
--base <rev>onverifyorgate(MCP:base);- the task's own
basein the contract; - the most recent base pinned for the task (
proofline nextrecords it in the local.proofline/log,proofline next --base <rev>records a newer pin, and the brief prints the one that wins); - a
Proofline-Base: <sha>trailer on the HEAD commit (optional; it must name an ancestor of HEAD, or the gate is BLOCKED); - the default:
defaults.base, else<defaults.remote>/<defaults.branch>(origin/mainwhen neither is set).
A repository whose remote is not called origin sets defaults.remote (for example "github") and leaves defaults.base out; pushed, claim reconciliation and the default base then use that remote.
Every report says which one it used, and brief <TASK> [--base <rev>] says which base verify and gate will use and whether it would block. A fresh clone has no log, and after the push the default base is HEAD, so the diff is empty and every diff check would pass on nothing. In that case the gate is BLOCKED, never PASS, and the corrective line asks for --base <rev> (for one commit, its parent) or proofline next. The CI workflow passes the previous tip of the pushed branch as --base.
Reusing results (verify, then gate)
verify and gate run every check each time. When a task's slowest check is the full suite, verify, gate and the pre-push hook on the same commit run it two or three times with nothing changed. A contract can opt in to reuse:
"defaults": { "reuse_results": true, "reuse_max_age_h": 24 }
reuse_results(true/false, defaultfalse): with it off, or left out, every check runs every time, as before. Turning it on or off is not a contract weakening.- Only
commandandmetricresults are reused.test_red_green,scope,wiring,grep,docs,pushed, the forbidden scan and the weakening check always run: they are cheap, or they depend on the base. - Only a PASS is stored. A FAIL, a flaky result, a busy-machine block or an error runs again every time.
- A PASS is reused only on the same HEAD with a clean tree:
git statusshows nothing outside.proofline/, untracked files included. An uncommitted edit never reuses a result, and a check run on a dirty tree is not stored. - The key is the criterion's verifier object (canonical JSON), the HEAD sha,
process.versionand the values of the env vars the command names ($VAR,${VAR};{VAR}in a metric'soutput_file); for a metric also its baseline and the regression tolerance. Change any of them and the check runs again. Gitignored files, env vars the command does not name and tools outside the repo are not in the key: a check that depends on them needs--fresh. reuse_max_age_h(a positive number, default 24): an older PASS runs again.- A metric PASS is reused only if the load per CPU it recorded is within
defaults.max_load_per_cpu, when that is set. Its measured value is reused with it, so claims are checked against it. - A fresh PASS is recorded in the evidence log (a
resultentry) and.proofline/cache/<sha256 of key>.jsonpoints at that entry with its hash, time, status, detail and evidence (exit code, test counts, duration). A result is reused only from that entry, and only while it is in an intact chain with the same hash; an edited or truncated log, or a cache file that names another hash, means the check runs again. - Every reused criterion says
reused from <time> (evidence entry <n>)in its report line, the gate report lists reused criteria under Reused results (not run again in that gate), and the gate's evidence entry carries the same lines. --freshonverifyandgate(MCP:fresh: true) ignores stored results and runs every check; a PASS it gets replaces the stored one.
Demo (claimed done with no evidence, FAIL, then real work, PASS): npm run demo.
proofline MCPのよくある質問
proofline MCPをClaude Codeに追加するには
ターミナルでclaude mcp add proofline -- npx -y @optitransfer/prooflineを実行します。すべてのプロジェクトで利用するには--scope userを追加します。
proofline MCPをCursorに追加するには
~/.cursor/mcp.jsonを開き、上記のインストールセクションに示すCursor設定を使ってmcpServersの下にサーバーを追加します。
エージェントがタスク完了を報告した際、Prooflineはどのように動作しますか?
Prooflineは報告をそのまま受け入れません。機械的に検証可能な「完了の定義」を保持しており、すべてのチェックを自ら再実行します。証拠がPASSを裏付ける場合にのみ、コミットを許可します。
エージェントが自身を評価するルールを変更することはできますか?
できません。オーナーがコントラクトのハッシュを承認する必要があり、git hooksが承認済みのマーカーがないコントラクトの変更を拒否するためです。
エージェントがテストのスキップやタイムアウトの延長を試みた場合はどうなりますか?
test.skip やタイムアウトの延長などは禁止されたショートカットとみなされるため、pre-commit hookによって拒否されます。
Prooflineに依存関係は必要ですか?
Prooflineは依存関係なしで構築されており、Node 22以降が必要です。