Veto vs Squawk
Squawk ist der Postgres-Migrations-Linter für CI. Veto ist der deterministische Check, den dein KI-Agent über MCP aufruft, bevor ein Statement läuft. Wer eine Squawk-Alternative für KI-Agenten sucht, findet hier die Abgrenzung.
Auf einen Blick
| Squawk | Veto | |
|---|---|---|
| Wann | CI / pre-commit auf Migrationsdateien | Runtime — vor jedem Statement des Agents |
| Schnittstelle | CLI, GitHub Action | MCP-Tool analyze_sql über HTTP |
| Fokus | Lock-lastige Schema-Änderungen | Destruktive DML/DDL, Korrektheitsfallen, Kosten, Org-Policies (Pro) |
| Verbindet zur DB | Nein | Nein — optional EXPLAIN auf Scratch-Postgres |
Beides nutzen
Squawk in CI auf eingecheckte Migrationen, Veto zur Laufzeit auf alles, was der Agent generiert. Squawk prüft Migrations-Handwerk; Veto fängt agent-generiertes destruktives SQL ab, das nie durch einen PR ging.
Ein Trade-off, den man klar benennen sollte: Squawk läuft vollständig auf deiner Maschine — dein SQL verlässt sie nie. Veto ist heute ein gehosteter Dienst, Statements werden also zur Analyse an seinen Endpoint gesendet (gespeichert wird nur das Urteil und welche Regeln ausgelöst haben, nie dein SQL oder Schema). Wenn null Egress gerade eine harte Anforderung ist, spricht das echt für Squawk; Vetos Self-Hosting ist auf der Roadmap.
Ist Veto ein Squawk-Ersatz?
Nein. Für CI-Lint bleibt Squawk die richtige Kategorie. Veto füllt die Lücke: deterministisches Pre-Execution-Gate im autonomen Agent-Loop.