verdict

Strukturiertes, in einer Sandbox ausgeführtes Verifikations-Feedback für Coding-Agenten.

Ein MCP-Server, der die pytest-Shell-Aufrufe deines Agents durch etwas ersetzt, das für die innere Schleife von Agenten gebaut ist: wirkungsselektierte Tests, die in einer isolierten Umgebung laufen und kompakte typisierte Verdicts zurückgeben, statt 40.000 Token roher Runner-Ausgabe – mit Fehler-Fingerprints, die dem Agenten sagen, ob ein Fehler seine Regression ist oder schon immer bestand.

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

Warum

Der am häufigsten aufgerufene Tool-Call in agentischem Coding ist die Verifikation – und sie ist am wenigsten strukturiert. Agenten führen ganze Test-Suiten erneut aus, wenn sich ein Modul geändert hat, verbrennen Kontext beim Parsen von ANSI-codierten Tracebacks, führen beliebigen Code direkt auf deiner Maschine aus und diagnostizieren routinemäßig vorbestehende Fehler fälschlich als eigene Regression (und "reparieren" dann Code, der nicht kaputt war). verdict behebt alle vier Probleme.

Related MCP server: Debugging MCP Server

Tools

Jeder Fehler trägt einen Fingerprint: einen stabilen Hash der normalisierten Fehlersignatur (flüchtige Tokens – Adressen, tmp-Pfade, IDs, Dauern – werden kollabiert). Derselbe logische Fehler, derselbe Fingerprint, über Läufe und Refactorings hinweg. Fingerprints sind es, die verdict ein Gedächtnis geben.

Schnellstart

Kein Installationsschritt nötig – uvx holt es bei der ersten Verwendung. (Oder uv tool install verdict-mcp / pip install verdict-mcp für einen dauerhaften verdict-mcp-Befehl.)

Claude Code – .mcp.json im Projektstamm:

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

Cursor – gleiche Form in .cursor/mcp.json.

Optionale verdict.toml im Repo-Stamm:

[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

Probiere es ohne Agent aus:

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

Sandbox-Posture (v0.1)

Checks laufen in einem ephemeren Container (podman bevorzugt, docker als Fallback): Worktree schreibgeschützt unter /src gemountet, in ein beschreibbares /work im Container kopiert, --network=none für den Check-Lauf. Deine Host-Umgebung wird durch einen Testlauf nie verändert. Wenn setup_cmd konfiguriert ist, läuft dieser Schritt mit Netzwerk vor dem Check; bevorzuge ein vorgebautes Image für eine strengere Posture. Kein Container-Runtime → expliziter prefer = "local"-Fallback führt Checks gegen eine temporäre Kopie deines Worktrees aus (immer noch nie an Ort und Stelle). Siehe SECURITY.md für das vollständige Bedrohungsmodell und bekannte Einschränkungen.

Fehlerbehebung: Wenn ein Verdict sagt container engine 'podman' could not start the check, führe das vorgeschlagene podman pull <image> von Hand aus – die eigene Fehlermeldung der Engine ist die Antwort. Eine bekannte Falle auf macOS: Eine "credsStore": "gcloud"-Zeile in ~/.docker/config.json bringt podman dazu, den gcloud-Credential-Helper für jede Registry aufzurufen, einschließlich docker.io; ein abgelaufener gcloud-Login bricht dann alle Pulls. Behebe das mit gcloud auth login oder entferne diese Zeile.

Ehrliche Einschränkungen

• Die Wirkungsauswahl verwendet den statischen Import-Graph – von Natur aus approximativ. Dynamische Importe, Auflösung von Fixtures nach Namen und datengetriebene Tests können übersehen werden; verify(scope="all") ist immer verfügbar und verdict sagt in selection_note, wann immer es zurückfällt.

• Python/pytest nur heute, plus ruff/mypy. Die Adapter-Schnittstelle ist klein und dokumentiert – vitest- und go test -json-Adapter sind die am meisten gewünschten Beiträge (CONTRIBUTING.md).

• Flake-Erkennung und Auswahl auf Basis von Coverage-Maps sind v0.2 (roadmap).

Roadmap

v0.2: Coverage-basierte Wirkungs-Karten (präzise Auswahl), Flake-Erkennung über Fingerprint-Alternation, devcontainer.json-Unterstützung, Ergebnis-Cache mit Schlüssel (Baum-Hash, Check, Image-Digest). Später: vitest/jest, go test, cargo test-Adapter; Per-Repo-verdict-Daemon-Modus.

Lizenz

Apache-2.0