Emetgate: Ein Prüftor zwischen LLM und Quellcode

Was Emetgate ist

Emetgate ist ein Open-Source-Projekt auf GitHub (emetgate/emetgate). Die README beschreibt es als „einen deterministischen Verifikationskern, der zwischen einem Sprachmodell und Ihrem Quellbaum sitzt". Das Motto lautet „Nothing passes but the truth." (Nur die Wahrheit kommt durch). Laut README ist das Projekt noch früh und bewusst schmal gehalten. Es zielt nur auf Windows, ist in Zig 0.16.0 geschrieben, verarbeitet TypeScript- und JavaScript-Code und spricht das Model Context Protocol (MCP). Ein MCP-Client wie Claude Code kann sich also direkt verbinden.

Die Idee ist leicht zu beschreiben. Ein Sprachmodell darf Code lesen und eine Änderung an einem Symbol vorschlagen. Es darf keine Datei schreiben und keine Arbeit für beendet erklären. Ein kleiner Kern prüft jeden Vorschlag und übernimmt ihn entweder atomar oder lehnt ihn mit einer Begründung ab. Die README fasst das so zusammen: „Das Modell schlägt vor. Der Kern verifiziert. Nichts Unverifiziertes erreicht die Platte."

Warum der Autor es gebaut hat

Die README nennt Fehlerbilder, die jeder kennt, der von LLM erzeugten Code ernsthaft nutzt: Code, der kompiliert und trotzdem falsch ist; ein Modell, das eine Aufgabe als erledigt meldet, obwohl sie es nicht ist; eine Regel von vor drei Runden, die stillschweigend vergessen wird; ein zu Sitzungsbeginn vereinbarter Plan, der am Ende verschwunden ist. Der Autor argumentiert, dass diese Probleme getrennt wirken, aber eine gemeinsame Ursache haben: Zwischen Modell und Festplatte ist nichts dafür zuständig, das Ergebnis des Modells zu prüfen.

Nach der README konkurrieren die heutigen Werkzeuge über Autonomie und Tempo, was die Menge ungeprüfter Ausgaben erhöht. Das Modell kann die Lücke nicht selbst schließen, denn es ist „ein Sampler, kein Orakel" und hat kein dauerhaftes Gedächtnis. Emetgate gibt dem Modell deshalb gar keine Autorität und legt die gesamte Autorität in den Kern. Die README vergleicht das mit Theorembeweisern im LCF-Stil, bei denen Taktiken alles vorschlagen dürfen, aber nur ein kleiner vertrauenswürdiger Kern ein Theorem erzeugen kann. Der Name stammt aus der Legende vom Prager Golem: Das Wort *emet* („Wahrheit") auf der Stirn belebt den Golem, und streicht man einen Buchstaben, bleibt *met* („tot").

Der Weg einer Änderung durch das Tor

Die README beschreibt sechs Schritte.

1. **Adressierung.** Jedes Symbol wird durch eine Referenz wie `Class.method` oder `add` und einen 128-Bit-Hash seines aktuellen Inhalts identifiziert. Ein Vorschlag muss den Hash nennen, auf dem er beruht. Hat sich die Datei inzwischen geändert, passt der Hash nicht mehr und der Vorschlag wird abgelehnt. Das Modell kann also keinen Code überschreiben, den es nicht gesehen hat.

2. **Parsen.** Der neue Funktionsrumpf wird nach Byte-Bereich in den Quelltext eingesetzt, und die ganze Datei wird mit tree-sitter neu geparst.

3. **Wächter.** Der Kern prüft, ob das Ergebnis sauber parst, ob der Rumpf nicht aus seinen Klammern ausbricht, ob er nicht leer oder ein Platzhalter ist und ob jedes Byte außerhalb des Zielbereichs unverändert bleibt.

4. **Eingrenzung.** Der Kern berechnet den Wirkungsradius. Die Analyse ist eine positive Zählung in einer geschlossenen Welt: Eine Änderung gilt nur dann als `BOUNDED`, wenn jeder Weg, auf dem sie entkommen könnte, ausgeschlossen wurde. Alles, was die Analyse nicht erklären kann, ist `UNBOUNDED`.

5. **Test.** `UNBOUNDED`-Änderungen werden auf eine Schattenkopie angewendet, und der Testbefehl des Projekts läuft dagegen in einer Sandbox. Die Sandbox ist ein Windows Job Object mit kill-on-close, Grenzen für Echtzeit und Speicher sowie einer Ausgabeobergrenze. Der Befehl läuft unter einem eingeschränkten Token niedriger Integrität. Lässt sich dieses Token nicht bauen und prüfen, wird der Befehl verweigert, statt ihn ungeschützt auszuführen. Ein fehlgeschlagener Test lehnt die Änderung ab und gibt die Ausgabe an das Modell zurück.

6. **Übernahme.** Akzeptierte Änderungen laufen über ein Write-Ahead-Journal und ein atomares Schreiben mit Umbenennen. Ein Absturz hinterlässt entweder die alte oder die neue Datei, nie einen halb geschriebenen Zustand. Der Befehl `recover` spielt das Journal ab und verweigert alles, was er nicht belegen kann.

Die README nennt den Kern fail-closed: Kann er nicht beweisen, dass eine Änderung sicher ist, lehnt er sie ab.

Die MCP-Oberfläche und Lockdown

Der Server stellt Werkzeuge zum Lesen und zum Ändern bereit. Zum Lesen gehören `emetgate_symbols`, `emetgate_skeleton`, `emetgate_read_symbol`, `emetgate_read_file`, `emetgate_list` und `emetgate_search`, wobei die letzten drei auf das Repository beschränkt sind. `emetgate_mutate` prüft einen vorgeschlagenen Rumpf strukturell, ohne zu schreiben. `emetgate_try` verifiziert, schleust durch das Tor und übernimmt einen Rumpf. `emetgate_try_batch` behandelt mehrere Vorschläge als eine Einheit. `emetgate_scan` misst einen Prüfausdruck gegen das Repository und schreibt nichts.

Der Befehl `emetgate lockdown` startet Claude Code mit genau diesen Werkzeugen, sodass das Modell außer dem Tor keinen Weg zur Platte hat. Das Repository liefert außerdem einen Claude-Code-Skill namens `md-audit` mit. Er ordnet jeden Anweisungssatz einer CLAUDE.md- oder AGENTS.md-Datei einer von vier Klassen zu (durchsetzbar, wartet auf einen Mechanismus, nicht überprüfbar oder Glaube) und misst die durchsetzbaren mit `emetgate_scan`. Er ändert nichts.

Wie der Kern selbst verifiziert wird

Die README sagt, eine Verifikationsschicht, die nicht selbst verifiziert wurde, sei „nur eine aufwendigere Form des Hoffens". Sie nennt zwei Verfahren. Das erste ist Mutationstesten: Wächter werden mutiert (eine Prüfung entfernt, eine Bedingung abgeschwächt, ein Vergleich umgedreht), und die Testsuite muss für jeden Mutanten fehlschlagen. Für die Engine-Module `cas`, `boundedness`, `symbol` und `functions` nennt die README 44 Mutanten: 37 getötet, 4 als äquivalent bewiesen, 1 redundanter Wächter als Verteidigung in der Tiefe behalten und 2 offen. Das zweite Verfahren sind Red-Team-Testsuiten, die Rümpfe mit Klammerausbruch, veraltete Hashes, zerrissene Journaleinträge, vergiftete Repository-Konfiguration und Zugriffe auf Dateien außerhalb des Repositorys angreifen.

Die README berichtet auch einen Token-Benchmark. Bei sechs Szenarien (zwei davon echte Dateien) mit dem Tokenizer `o200k_base` brauchten Vorschläge auf Symbolebene im Median 1,80-mal weniger Tokens als Suchen-und-Ersetzen, bei einer Spanne von 1,15 bis 3,77. Bei den echten Dateien beträgt der Gewinn 1,15 bis 1,17. Die README nennt die Token-Ersparnis „einen Nebeneffekt, nicht den Zweck".

Unsere Einschätzung

Bemerkenswert ist, wo das Vertrauen sitzt. Viele Coding-Werkzeuge fragen, wie sich das Modell verlässlicher machen lässt. Emetgate fragt, wie sich seine Unzuverlässigkeit harmlos machen lässt. Weil die Prüfungen deterministische Funktionen ihrer Eingaben sind, kann ein Reviewer sie lesen, testen und angreifen. Das ist eine andere Art von Zusicherung als die Aussage des Modells, die Aufgabe sei erledigt.

Zwei Details fallen auf. Inhalts-Hashes machen aus „das Modell hat veralteten Code bearbeitet" einen abgelehnten Vorschlag statt eines stillen Fehlers. Und die Eingrenzungsregel der geschlossenen Welt führt im Zweifel standardmäßig die Tests aus und tauscht damit Tempo gegen Sicherheit.

Grenzen und offene Fragen

Die README ist offen über Grenzen. Code, der parst, in seinen Grenzen bleibt und die Tests besteht, kann trotzdem das falsche Verhalten umsetzen. Das Testtor ist nur so stark wie die Tests. Die Garantien gelten nur für Änderungen, die durch das Tor gehen; Änderungen anderer Werkzeuge umgehen es, weshalb es Lockdown gibt. Das Token niedriger Integrität verhindert Schreiben außerhalb der Schattenkopie, schränkt aber weder Lesen noch Netzwerkzugriff ein. Ein feindlicher Testbefehl könnte daher noch Dateien lesen, für die er Rechte hat, und das Netzwerk erreichen. Ein AppContainer ist geplant. Architektur, API-Design und Nutzererlebnis sind keine Eigenschaften, die ein Kern prüfen kann.

Laut Statustabelle ist das Entscheidungsbuch noch nicht als MCP-Werkzeug verfügbar, und die Regeldurchsetzung am Bearbeitungstor ist in Arbeit. Unterstützt werden nur TypeScript und JavaScript sowie nur Windows. Wir haben nur die README gelesen. Wir haben das Werkzeug nicht ausgeführt, und die Zahlen zu Benchmark und Mutationen stammen vom Autor selbst.

Praktische Hinweise

Teams unter Windows, die TypeScript oder JavaScript schreiben, können die Release-Binärdatei und ihre SHA-256-Prüfsumme herunterladen, beide vergleichen und den Server dann mit `claude mcp add` registrieren. Die README weist darauf hin, dass die Binärdatei nicht code-signiert ist und SmartScreen deshalb beim ersten Start warnt. Der Bau erfordert Zig 0.16.0 und `zig build`.

Die Befehle für Typprüfung und Tests stammen vom Betreiber, über `--typecheck` und `--test` oder aus `.emetgaterc.json` mit `--allow-repo-config`. Das Modell kann sie nie selbst liefern. Für alle anderen Leser ist die README eine knappe Darstellung eines nützlichen Prinzips: dem Modell keinen Schreibzugriff geben und jede akzeptierte Änderung durch eine Prüfung schicken, die ein Mensch nachvollziehen kann.