verdict

コーディングエージェントのための構造化・サンドボックス化された検証フィードバック。

エージェントの pytest シェルアウトを、エージェントのインナーループ向けに作られたものに置き換える MCP サーバーです。影響を受けたテストを選択し、隔離された環境で実行し、生のランナー出力の40,000トークンではなくコンパクトな型付き判定を返します。さらに失敗フィンガープリントにより、失敗が自分のリグレッションなのか、元々壊れていたのかをエージェントに伝えます。

raw pytest dump:  ~40,000 tokens, unstructured, run un-sandboxed on your machine
verdict:              ~400 tokens, typed JSON, run in a rootless container, with memory

なぜ

エージェント型コーディングで最も頻度の高いツール呼び出しは検証ですが、最も構造化されていません。エージェントは1つのモジュールが変更されただけでスイート全体を再実行し、ANSIコード化されたトレースバックを解析してコンテキストを消費し、任意のコードを直接マシン上で実行し、既存の破損を自分のリグレッションと誤診して（壊れていないコードを「修正」して）しまうことがよくあります。verdict はこれら4つすべてを修正します。

Related MCP server: Debugging MCP Server

ツール

すべての失敗にはフィンガープリントが付与されます。これは正規化された失敗シグネチャの安定したハッシュです（揮発性トークン — アドレス、一時パス、ID、期間 — は省略されます）。同じ論理的失敗は、実行やリファクタリングをまたいでも同じフィンガープリントになります。フィンガープリントこそが verdict に記憶を与えます。

クイックスタート

インストール手順は不要です — uvx が初回使用時に取得します。（または、uv tool install verdict-mcp / pip install verdict-mcp で永続的な verdict-mcp コマンドをインストールできます。）

Claude Code — プロジェクトルートの .mcp.json:

{
  "mcpServers": {
    "verdict": {
      "command": "uvx",
      "args": ["verdict-mcp"],
      "env": { "VERDICT_PROJECT": "." }
    }
  }
}

Cursor — .cursor/mcp.json に同じ形で配置します。

リポジトリルートに任意の verdict.toml:

[project]
packages = ["your_package"]          # for impact selection (auto-guessed if omitted)

[runner]
image = "ghcr.io/you/yourproj-test"  # prebuilt env with your deps
setup_cmd = "pip install -e .[test]" # or install on the fly (runs with network; tests don't)
# prefer = "local"                   # escape hatch if you have no container runtime

[limits]
max_failures = 10

エージェントなしで試す:

cd examples/demo_project
VERDICT_PROJECT=. verdict-mcp   # then connect any MCP client, or use the MCP inspector

サンドボックス姿勢 (v0.1)

チェックは一時コンテナ（podman優先、dockerフォールバック）で実行されます。作業ツリーは /src に読み取り専用でマウントされ、コンテナ内の書き込み可能な /work にコピーされ、チェック実行時は --network=none が設定されます。ホスト環境がテスト実行によって変更されることはありません。setup_cmd が設定されている場合、そのステップはチェック前にネットワークありで実行されます。より厳格な姿勢にはプリビルドイメージを推奨します。コンテナランタイムがない場合、明示的な prefer = "local" フォールバックにより、作業ツリーの一時コピーに対してチェックが実行されます（それでも元の場所では実行されません）。完全な脅威モデルと既知の制限については SECURITY.md を参照してください。

トラブルシューティング: 判定で container engine 'podman' could not start the check と表示された場合は、提案された podman pull <image> を手動で実行してください。エンジン自身のエラーが答えです。macOSでの既知の落とし穴: ~/.docker/config.json の "credsStore": "gcloud" 行により、podman がすべてのレジストリ（docker.ioを含む）で gcloud 資格情報ヘルパーを呼び出します。gcloud のログインが期限切れだと、すべてのプルが失敗します。gcloud auth login で修正するか、その行を削除してください。

正直な制限

• 影響選択は静的インポートグラフを使用します — 設計上近似です。動的インポート、フィクスチャ名による解決、データ駆動テストは見逃される可能性があります。verify(scope="all") は常に利用可能で、verdict はフォールバック時に selection_note でその旨を伝えます。

• 現在はPython/pytestのみ、およびruff/mypy。アダプターインターフェースは小さく文書化されています — vitest と go test -json アダプターが最も要望の多いコントリビューションです（CONTRIBUTING.md）。

• フレーク検出とカバレッジマップベースの選択は v0.2 です（ロードマップ）。

ロードマップ

v0.2: カバレッジベースの影響マップ（正確な選択）、フィンガープリントの交互によるフレーク検出、devcontainer.json サポート、(ツリーハッシュ、チェック、イメージダイジェスト) をキーとする結果キャッシュ。その後: vitest/jest、go test、cargo test アダプター、リポジトリごとの verdict デーモンモード。

ライセンス

Apache-2.0