Vom Prose Rules zum Mechanical Gates: Die Absicherung einer Claude Code Agent Squad
Wie ein mehragentenbasierter Claude Code-Plugin ignorierte Persona-Anweisungen schrittweise durch Skripte, Hooks und gehäschte Beweise ersetzt hat, Version für Version, sowie was man kopieren kann.
Jeder, der Coding-Agents bereits seit mehreren Wochen betreibt, hat das beobachtet: Eine Regel steht im Systemhinweis, der Agent liest sie – und genau in dem Moment, in dem die Regel relevant wird, tut der Agent trotzdem das Verbotene und meldet Erfolg. Die Regel umzuformulieren, sie zu großschreiben oder „WICHTIG“ hinzuzufügen, hilft in der Regel nur kurzfristig. Dieser Artikel verfolgt die Veröffentlichungsgeschichte eines Open-Source-Plugins für Claude Code, blackgoat-agentskills, über fünfzehn Versionen hinweg und zeigt das Muster, auf das sich seine Betreuer geeinigt haben: Immer wenn eine schriftliche Anweisung während ihrer Gültigkeit missachtet wird, ersetzt man sie durch etwas, das ausgeführt oder geöffnet werden muss. Am Ende sollten Sie in der Lage sein zu erkennen, welche Ihrer eigenen Agent-Regeln noch Wünsche sind, und mehrere konkrete Methoden kennen, um sie in Kontrollmechanismen umzuwandeln.
Der Ausgangspunkt: ein Team von Spezialisten
Das Plugin organisiert die Softwareentwicklung als Team von spezialisierten Agenten. Das Aufgabenverteilungssystem umfasst die Anforderungsanalyse, Architektur und Planung; zwei Aufgabenrollen für die Implementierung; Testing, Code-Review und Sicherheitsaudits; Release-Engineering sowie einen Meta-Ingenieur, dessen Aufgabe es ist, die anderen Agenten zu verwalten. Ein Orchestrator, der in der Haupt-Sitzung von Claude Code läuft, weist den Agenten jeweils Aufgaben zu. Jeder Spezialist arbeitet in seinem eigenen isolierten Kontext und liefert ein strukturiertes Übergabedokument anstelle eines freien Chat-Verlaufs.
Version 1.0.0 brachte dreizehn Personas sowie fünf Pipelines mit, die Entdeckung (/bgpdd-discovery), Planung (/bgpdd-plan), einen vereinfachten Weg (/bgpdd-lite), Erstellung (/bgpdd-build) und Bereitstellung (/bgpdd-shipping) abdeckten. Zusätzlich wurden ein Befehl zur Fehlerbehebung für einzelne Agenten, eine Sammlung an Methodikfähigkeiten, die von den Agenten nur bei Bedarf heruntergeladen werden, ein Evaluationswerkzeug sowie eine frühe deterministische Überprüfung bereitgestellt: ein Abdeckungstest, der sicherstellt, dass jede „Must-Have“-Anforderung mit einem bestandenen Test übereinstimmt.
Die Designannahme zu diesem Zeitpunkt war vernünftig und üblich. Wenn jede Persona gut geschrieben ist und jede Methodik klar definiert ist, werden sich die Agenten korrekt verhalten. Fast jede Regel bestand aus einem Absatz Prosa, und fast jedes Urteil war ein Satz in einem Bericht. Der weitere Verlauf zeigt die schrittweise Aufgabe dieser Annahme.
Aufteilung eines Agenten, der versuchte, drei Aufgaben zu erledigen
Das erste Problem war nicht Ungehorsam, sondern Überlastung. Die Testersona Quinn verfügte über drei Modi: das Erkunden des Verhaltens von Bestandsfunktionen während der Analyse, das Testen neuer Versionen sowie die Überprüfung der Bereitschaft vor dem Veröffentlichen. Die Zusammenfassung all dieser Aufgaben in einer einzigen Persona führte zu einem Anleitungstext von etwa 5.000 Wörtern, und der resultierende Agent war bei jeder Aufgabe nur mittelmäßig.
In Version 1.1.0 wurde die Rolle in drei aufgeteilt. Echo analysiert während der Analyse das vorhandene Verhalten rückwärtsentwickelt. Vera ist für die Checkliste vor dem Veröffentlichen zuständig. Quinn hat nur noch eine Aufgabe: das Testen der Version.
Die gleiche Version brachte zwei wichtige Funktionskorrekturen mit sich. Jeder Agent erhielt eine Frist von vier Minuten für Shell-Befehle, da die Ausführungen aufgrund eines blockierten Prozesses endlos hängen geblieben waren. Zudem erhalten Meilensteine, die als sicherheitsrelevant gekennzeichnet sind, nun neben der üblichen Codeprüfung auch eine parallele Überprüfung durch Cipher, den Sicherheitsauditor.
Die allgemeine Erkenntnis ist aus menschlichen Teams bekannt: Eine Rolle mit mehreren unzusammenhängenden Aufgaben erhält eine lange, unpräzise Beschreibung. Bei einem LLM-Agenten ist diese Unpräzision buchstäblich, da jede zusätzliche Anweisung im selben Kontext um die Aufmerksamkeit konkurriert.
Ein sauberer Bericht, der es nicht war
Die Version 1.2.0 wurde durch einen fünfstufigen Build ausgelöst, der zwar Erfolg meldete, aber eine lange Liste an Problemen verbarg:
- vier Gate-Skripte, die weder von einem Paketskript noch von einer CI-Aufgabe jemals aufgerufen wurden
- Aussagen, die so unpräzise waren, dass nie ein Gate etwas abgelehnt hatte
Unangenehm ist, dass die Regeln bereits alles davon abdeckten. Die Regel „Grün bedeutet keine Beweislast“ war aktiv. Das Register der Blockaden war aktiv. Das Modell hat sie gelesen und weitergearbeitet.
Die Reaktion bestand aus der ersten Reihe von überprüfbaren Voraussetzungen des Projekts:
- Eine Kontrollstelle wird erst dann als zuverlässig angesehen, wenn jemand beobachtet hat, wie sie bei einer absichtlichen Verletzung versagt ist, wobei die Ergebnisse dieses Versagens gespeichert werden.
- Ein Plan kann keinen Überprüfungscode deklarieren, es sei denn, er nennt außerdem den Manifest-Eintrag sowie die CI-Aufgabe, die ihn ausführen wird.
- Die Freigabe eines Meilensteins erfordert zwei Dateiabrufe: Das neueste Prüfergebnis muss mit „Approve“ versehen sein und jünger als der Diff sein, außerdem muss das Array mit Blockierungen leer sein.
- Eine Korrektur für eine kritische Feststellung muss erneut getestet und überprüft werden, anstatt einfach am Ende hinzugefügt zu werden.
- Jede PASS-Zeile muss den genauen ausgeführten Befehl sowie dessen wörtliche Ausgabe enthalten.
Damit kamen zwei Prozessänderungen hinzu. Alle Delegationen wurden im Hintergrund ausgeführt, da eine blockierende Delegation den Orchestrator für die gesamte Dauer unerreichbar machte und eine lange Phase dadurch nicht von einem Absturz zu unterscheiden war. Zudem erstellt jeder Agent nun zu Beginn seine Ausgabedatei und füllt sie Abschnitt für Abschnitt aus, nachdem ein unterbrochener Ausführungsvorgang alles, was er erzeugt hatte, vernichtet hatte.
Die erste Voraussetzung verdient besondere Betonung. Eine Überprüfung, die noch nie fehlgeschlagen ist, ist eine Überprüfung, der man keinen Glauben schenken kann; das ist dieselbe Idee wie beim Beobachten, dass ein neuer Unit-Test zunächst rot wird, bevor er grün wird – angewandt auf die Tools selbst.
Release 2.0.0: Anweisungen in Programme umwandeln
Die Voraussetzungen von 1.2 waren eine Verbesserung, aber es handelte sich dabei immer noch um Text. „Zwei Datei-Lesungen durchführen“ ist eine Anweisung, und bei einem später beobachteten Ablauf führte der Orchestrator drei Meilensteine nacheinander aus, obwohl es negative Entscheidungen bezüglich von Anfrageänderungen gab.
Zwei weitere Probleme traten zur gleichen Zeit auf. Ein einzelnes Vue-UI-Milestone wies 51.000 Zeichen an Wake-up-Payload auf, da ein Entwickler Schema-, API- und Interface-Arbeiten gleichzeitig durchführte, wodurch die bereitgestellte Benutzeroberfläche bei Paginierung, Texteingaben und Autocomplete-Feldern mangelhaft war. Gleichzeitig führte das Parallellaufen der Entwickler auf derselben Branch dazu, dass sie ständig den HEAD-Pointer überschrieben, weshalb bei jeder Überprüfungsgeneration der gesamte sich ändernde Diff erneut geprüft werden musste.
Die Commit-Schleuse wird zu einem Skript
check_commit_gate.py übernimmt nun die Aufgaben, die früher in Textform angefordert wurden. Es liest den Entscheidungstoken, prüft, ob die Überprüfung neuer ist als der Diff, überprüft das Register der Blockierungen und führt anschließend den Commit selbst durch. Dieser letzte Punkt ist der wichtige: Da nur das Skript Commits vornehmen kann, ist es offensichtlich, wie man die Schleuse umgeht – es kommt einfach kein Commit zustande.
Bauherren nach Bereich aufgeteilt
Mason kümmert sich um die Meilensteine im Backend und Nova um die im UI. Jeder Meilenstein wird bereits bei der Planung gekennzeichnet, sodass seine Zuweisung an den richtigen Bauherren rein mechanisch erfolgt und kein Urteil des Orchestrators erforderlich ist.
Keine parallelen Bauherren mehr
Die parallele Aufteilung wurde vollständig beseitigt. Ein Bauherre arbeitet an einem einzigen Meilenstein, was bedeutet, dass nur ein Diff zur Überprüfung vorhanden ist.
Die Konvention hinter allem, was folgte
Die eigenen Anweisungen des Repositoriums erhielten eine Regel zu Regeln. Um es anders auszudrücken: Wenn eine prosaische Regel während ihrer Gültigkeit gebrochen wird, sollte sie weder umformuliert noch fett hervorgehoben werden; stattdessen muss sie in eine mechanische Prüfung umgewandelt werden. Jede Regel, die von einem Agenten verlangt, in dem Moment innezuhalten, in dem er am meisten weitermachen möchte, muss durch ein Artefakt gestützt werden, das ausgeführt oder geöffnet werden muss.
Das ist die Kernidee des gesamten Projekts, und sie lässt sich gut auf Bereiche jenseits dieses Plugins übertragen. Wenn Sie sich Ihre eigenen CLAUDE.md-Datei oder die Anweisungen für den Agenten ansehen, sind es in der Regel genau die Regeln, die Zurückhaltung unter Druck fordern – noch nichts abschließen, den Test nicht überspringen, dies nicht als erledigt markieren. Für einen umfassenderen Überblick darüber, was in dieser Datei enthalten sein sollte, sehen Sie unsere Anleitung zur Erstellung einer effektiven CLAUDE.md-Datei.
Definieren, was als Beweis gilt
Der zweite Teil von 2.0.0 befasste sich mit einem subtileren Fehler. Eine Reihe von Übertragungstests gibt Auskunft darüber, welche Tests durchgeführt wurden, sagt aber nichts darüber aus, was dabei weggelassen wurde. Ein Testhost im laufenden Prozess kann beispielsweise nicht angeben, was ein echter Client über das Netzwerk erhält: die serialisierte Antwortstruktur, die Reihenfolge, in der das Middleware-System ausgeführt wird, sowie die Umgebungskonfiguration. Die Agenten deklarierten Funktionen als „überprüft“, basierend auf einem einzigen Unit-Test und einer selbstsicheren Aussage.
Drei Ebenen der Beweislage
Das Projekt definierte drei Ebenen:
- Ebene 1 ist ein Unit-Test.
- Ebene 2 leitet Anfragen durch den tatsächlichen Anwendungsablauf, verwendet aber einen in Erinnerung gespeicherten Transportmechanismus.
- Ebene 3 beobachtet die laufende Anwendung von außen mit einem echten Client.
Eine Anforderung, die ein Niveau 3 erfordert, kann niemals durch einen Pass für Niveau 2 erfüllt werden. Die Spezifikation beschreibt diese Asymmetrie präzise: Eine Beobachtung im laufenden Prozess darf eine Behauptung über das Kabel widerlegen, aber niemals eine bestätigen.
Zur Planungszeit ausgewählte Überprüfungsflächen
Jeder Meilenstein erhält während der Planung ein Tag für die Überprüfungsfläche, und dieses Tag bestimmt, welche Beweise die Kontrollpunkte verlangen. Eine API-Überprüfungsfläche erfordert eine außerhalb des Prozesses aufgezeichnete Antwort sowie ein tatsächlich erreichbares OpenAPI-Dokument. Eine UI-Überprüfungsfläche erfordert renderierte Ausgaben. Die Benennung eines im Prozess verwendeten Testclients wie WebApplicationFactory oder supertest als Übertragungsmittel gilt als Versagen eines Kontrollpunkts, nicht als kluger Umweg.
Aufzeichnungen mit manipulationsersichtlichen Sidecars
Beweise werden als Aufzeichnung gesammelt: ein Befehl wird über einen unauffälligen Wrapper ausgeführt, der die Ausgabe zusammen mit einem von der Maschine erstellten Sidecar speichert. Das Sidecar protokolliert die argv, den Arbeitsverzeichnis, die Prozess-ID, Zeitstempel, den tatsächlichen Abbruchcode sowie die Hash-Werte beider Dateien. Gates berechnet diese Hash-Werte erneut, sodass eine Bearbeitung der Aufzeichnung nachträglich die Überprüfung verunmöglicht.
Dieser Standard breitete sich anschließend überall dort aus, wo eine Behauptung als Aussage formuliert wurde. Ein Überprüfungseintrag, der lediglich „PASS, erledigt“ angibt, wird als UNEVIDENCED markiert und als unüberprüft behandelt. Die Sicherheits- und Startagenten müssen jede ihrer Überprüfungszeilen damit abschließen, auf die dahinter liegende Aufzeichnung zu verweisen. Jeder „Persona“ wird außerdem ein ehrlicher Ausweg geboten: Wenn eine Überprüfung nicht durchgeführt werden konnte, ist das Ergebnis BLOCKED – niemals PASS – und es muss angegeben werden, was fehlte. Wie das Projekt betont, ist „überprüft“ eine Beschreibung, kein Beweisstück.
Die BLOCKIERTE Notausstiegsluke ist genauso wichtig wie die strengen Regeln. Wenn eine Agentur nur die Optionen „Erfolg“ oder „Fehler“ hat, steht sie unter Druck, einen Erfolg zu erfinden. Die Einführung eines legitimen dritten Zustands nimmt einen großen Teil dieses Drucks weg.
Auditing der Prüfer: Version 2.1.0
Während einer Sicherheitsüberprüfung wurde ein Frontmatter-Lint entdeckt, das zwei Fähigkeiten aufzeigte, deren YAML-Beschreibungen ohne Fehler nicht parsen ließen. bgpdd-verify war seit dem Veröffentlichungstag nie registriert worden, und doubt-driven-development war seit dem ursprünglichen Commit kein einziges Mal registriert worden. Bevor das Lint existierte, hatte eine vollständige Überprüfung des Plugins bei allen achtzehn Metriken ein einwandfreies Ergebnis ergeben.
Die Korrekturen in dieser Version schließen alle Lücken zwischen dem, was eine Überprüfung scheinbar überprüfen sollte, und dem, was sie tatsächlich überprüfte:
- Der Linter wird nun bei jeder Überprüfung zuerst ausgeführt: Die Dateien werden vor dem Lesen des Textes analysiert.
- Die Einträge im Gate-Ledger sind nun über Hash-Werte miteinander verknüpft, sodass Einfüge-, Bearbeitungs- oder Löschvorgänge erkannt werden können.
- Das Markieren eines Meilensteins als abgeschlossen erfolgt nun durch das Schreiben eines Skripts anstelle dessen, dass das Modell drei Zeichen eingibt.
- Der Probe-Client, der in einer Aufnahme erfasst wird, muss aus einer Liste zulässiger echter Clients stammen.
- Beweise für die dargestellte Benutzeroberfläche müssen nun ein echtes Bild sein: es darf nicht leer sein, muss die richtigen Magic-Bytes enthalten und jünger als die geänderten Dateien sein. Dies ergab sich, nachdem ein zero-bytes großes screenshot.png als erfüllend für die alte Überprüfung festgestellt wurde.
- Der Urteilstext, der in einem eingebetteten Beispiel oder unter einem Überschriftenabschnitt erscheint, wird bei der Bestimmung des Überprüfungsergebnisses ignoriert. Früher ersetzte ein illustrativer Block stillschweigend einen echten Antrag auf Änderung.
Der Fall mit dem Screenshot erinnert daran, dass Agenten sich danach optimieren, was die Überprüfung buchstäblich prüft. Wenn die Überprüfung „Es existiert eine Datei mit diesem Namen“ lautet, wird letztendlich eine Null-Byte-Datei erscheinen.
Eine Fehlerbehebungsschleife, die auf aufgezeichneten Beweisen beruht
Der ursprüngliche Befehl zur Fehlerbehebung durch einen einzelnen Agenten verhielt sich wie ein überstürzter Entwickler: Code lesen, ändern, etwas ausführen, commiten. Bei der ersten vollständigen Bewertung wurde die Korrektur bereits siebzehn Minuten vor Ausführung irgendeiner Kontrollstufe commitet.
Die Version 2.2.1 baute diese Schleife in sechs Phasen um, wobei zwischen jeder Phase eine Kontrollstufe lag:
- Ein Fehlerbericht, der eine Formatprüfung bestehen muss.
- Eine RED-Aufnahme, die vom Tester vor jeder Codeänderung erstellt wird, damit der Fehler dokumentiert ist.
- Ein Routingschritt, der von einem Skript und nicht vom Modell entschieden wird und dabei entweder den schnellen Weg, den vollständigen Weg oder eine Eskalation an die Planungsabteilung wählt.
Für instabile Fehler kann die Pipeline N grüne Ausführungen von N verschiedenen Prozessen erfordern, denn vier Erfolge von fünf bedeuten nicht automatisch, dass der Fehler behoben ist. Zudem hat der Builder überhaupt keine Möglichkeit, einen Commit vorzunehmen.
Pipelines für kleine Änderungen
Bis zur Veröffentlichung 2.3.0 handhabte das Plugin Epics gut, hatte aber nichts für kleine Anpassungen. Umbenennungen, Konfigurationsanpassungen oder das Hinzufügen eines einzigen Tests hatten keine eigene Pipeline, weshalb diese Arbeiten manuell durchgeführt wurden – und die Disziplin verschwand genau in dem Maße, in dem Fehler leicht übersehen werden können.
Die Neuerungen:
/bg, eine Eingangstür, die jede Anfrage klassifiziert und sie an genau einen Kanal sendet./bgpdd-quickfür Änderungen, die weniger als drei Dateien betreffen. Es erzeugt keine Agenten; es bittet um eine kurze Notiz von drei Zeilen, erfasst einen einzigen Check und beendet mit einer Schleuse, die den Commit vornimmt.- Ein immer aktiver Sitzungshook, damit eine gewöhnliche Chat-Sitzung weiß, dass die Kanäle existieren.
- Ein Überprüfungs-Paket: Dem Prüfer wird der Diff selbst, dargestellt und gehässt, übergeben anstelle von Dateipfaden, in denen man in einem Arbeitsbaum suchen müsste – dort sieht bereits eine Korrektur wie der Status quo aus und eine gelöschte Zeile ist unsichtbar.
Dieser letzte Punkt lohnt sich bereits ohne Agenten. Die Überprüfung von Dateien in ihrem endgültigen Zustand versteckt, was sich geändert hat; die Überprüfung des Diffs zeigt es hingegen.
Nutzung von Audits zur Findung der nächsten Schleuse
Die Version 2.4.0 entstand aus einer 21-mäßigen Überprüfung von Version 2.3, bei der sechs Blocker-Metriken identifiziert wurden. Zwei Beispiele: Die Sicherheits- und Startagenten konnten weiterhin einen Prüfungsergebnis als „PASS“ markieren, ohne jeglichen Nachweis zu liefern, und es wurde nichts durchgeführt, um den Ausgabecode im Capture-Body mit dem im Sidecar zu vergleichen. Die Integrationstestumgebung des Plugins enthielt sogar ein Capture, dessen Sidecar 223 Tage älter war als das Haupt-Capture.
Die Korrekturen verknüpfen die Anforderungen mit den Dateien. Jeder ausgeführte Check in diesen Berichten gibt nun die jeweilige Aufnahme an, deren Sidecar vorhanden sein muss, hash-konsistent ist und mit dem in der Zeile angegebenen Exit-Code übereinstimmt. Jede Schleuse, die eine Aufnahme verarbeitet, vergleicht außerdem ihren Inhalt mit ihrem Sidecar. Das Blocker-Register erhielt ein strukturiertes Schema mit Angaben zu Schweregrad und Meilensteinumfang. Das Team maß außerdem die Kosten einer Auswertung eines Triggers – zu dieser Zeit etwa 1,77 Dollar und 250 Sekunden pro Ausführung – und nutzte diese Zahl, um zu entscheiden, wie oft sie ausgeführt werden sollen.
In einer späteren Überprüfung von 2.6.0 wurden neun Objektive sowie dieselben 21 Metriken verwendet, wodurch 23 Blocker bestätigt wurden, die alle in 2.6.1 beseitigt wurden. Zwei Fälle heben sich ab. Die Herkunft der Beweise konnte nicht geklärt werden: Der Ersteller und der Prüfer teilten sich einen einzigen Beweisdirektor, sodass eine Prüfung, die zu keinem Ergebnis führte, auf das Screenshot des Erstellers hindeuten konnte. Zudem steckte ein UI-Meilenstein in einem Umfeld ohne Browser-Tools fest: Er konnte die entsprechende Voraussetzung nicht erfüllen, und die Voraussetzung lehnte die einzige Alternative ab, nämlich die Prüfung nur der Quelldatei.
The fixes split evidence directories by producer, made UI milestones stop and ask the user when no browser is available instead of looping, and insisted, without exceptions, that a capture match the command its note says was executed. Wake-up payloads were slimmed by moving rationale out of the core persona text into references, without losing any rules. The changelog also gained a "Known, not fixed" section, because a commit gate that would accept an entirely forged evidence base is a limit that should be documented rather than hidden.
From checking afterwards to refusing beforehand
Up to release 2.5.0 every gate ran after the fact, and the model still decided whether to run it. A rule like "do not commit by hand while a lane is active" can still be read and ignored.
Die Lösung war ein PreToolUse-Hook, der Tool-Aufrufe vor ihrer Ausführung blockiert. Er weigert sich:
- bei aktiver Schleife an einer manuellen
git commit - daran, während eines Bugfixes einen bereits vorhandenen Testdatei-Teil zu bearbeiten
- daran, einen Subagent zu starten, solange die Eingaben noch nicht bearbeitet wurden
- an manuellen Änderungen an irgendwelchen Dateien, die von einer Schleife erzeugt werden
Um zu entscheiden, ob eine Schleife aktiv ist, prüft der Hook die Zustandsdateien auf dem Datenträger und betrachtet sie 12 Stunden lang als aktuell; er vertraut niemals darauf, was das Modell über seinen eigenen Zustand sagt. Zudem führt er bei jedem internen Fehler zum Abbruch. Das ist ein bewusster Kompromiss: Ein Schutzmechanismus, der Sitzungen beendet, wird deinstalliert, und ein deinstallierter Schutzmechanismus setzt nichts durch.
Die Veröffentlichung fügte außerdem einen Treiber hinzu, der den nächsten obligatorischen Schritt ausführt, anstatt darauf zu vertrauen, dass der Orchestrator sich daran erinnert, sowie einen Validierer für die Übertragung an Agenten. Der Validierer prüft, ob die referenzierten Pfade existieren, ob die als geändert aufgeführten Dateien tatsächlich im Diff enthalten sind, und weist Widersprüche wie einen Status „BLOCKED“ neben einer Zeile mit dem Hinweis „None“ aus.
Absicherung der Arbeit zwischen Funktionen
Vor 2.6.0 verfügten verschiedene Arten routinemäßiger Ingenieurarbeiten überhaupt keine Methodik – darunter das Aufrüsten von Abhängigkeiten, die Einführung von Feature-Flags, das Schreiben von Hintergrundaufgaben, der Aufbau von Überwachungsmöglichkeiten sowie Änderungen an API-Verträgen. Die Agenten improvisierten dabei. Auch der Quick Lane schätzte die Testbefehle des Projekts nur grob ein.
Die Version fügte für diese Bereiche fünf Fähigkeiten hinzu, von jeder mit einem Umsetzungsvertrag sowie einer Bewertung, die den Vertrag überprüft. Ein Stack-Detector schlägt nun den Überprüfungsbefehl sowie die aus dem Repository stammenden eingefrorenen Testobjekte vor, und eine Person bestätigt diese anstelle dessen, dass der Prozessschritt stillschweigend ausgewählt wird. Für API-Meilensteine führt das Commit-Gate außerdem einen OpenAPI-Diff durch, was bedeutet, dass ohne schriftliche Begründung keine brisanten Änderungen eingeführt werden können. Immer dann, wenn es bei einer Gestaltungsentscheidung mindestens zwei mögliche Optionen gab, ist ein ADR erforderlich, und ein Linter überprüft, ob das Designregister darauf verweist. Schließlich erhielt jede Methodik eine „Quick Card“: die fünf Regeln, die für Änderungen an drei oder weniger Dateien relevant sind, wobei jede auf den entsprechenden vollständigen Abschnitt verweist, sodass der schnelle Prozessschritt eine kurze Karte statt des gesamten Vertrags laden kann.
Lektionen umwandeln, bevor sie zu Gewohnheiten werden
Die Veröffentlichung 2.6.2 entstand nach einer wahren Herausforderung. Quinn wurde viermal erneut mit der Lösung desselben Umgebungsproblems beauftragt, wodurch etwa 1,2 Millionen Tokens verbraucht wurden. Ein Übertragungsstatus von „COMPLETED“ wies auf ein Artefakt hin, das weiterhin voller TODO-Markierungen war. Zudem wurde das Erwecken eines bereits vorhandenen Agenten als völlig neue Aufgabe protokolliert, was die Laufprotokolle vergrößerte.
Der Lernprozess erfasste drei Lektionen und wandelte jede davon in eine Kontrollstufe um, bevor sie gespeichert wurden. Ein Übertragungsprozess, dessen Artefakt weiterhin Vorlagen enthält, scheitert nun an der Validierung. Ein erneutes Erwecken wird als solches erfasst. Wenn ein Hindernis nur von einem Menschen beseitigt werden kann – beispielsweise fehlende Zugangsdaten oder ein Dienst, der sich weigert zu starten – stoppt der Prozessablauf und kann nur durch einen klaren Befehl eines Menschen wieder aufgenommen werden. Genau dieser Stoppschritt hätte den größten Teil der 1,2 Millionen Tokens eingespart.
Teste erkennen, die sich selbst testen
Die Version 2.7.0 behebt eine der besorgniserregenderen Feststellungen. In einem echten Projekt waren dreizehn von zwanzig von den Workflows erzeugten Playwright-Spezifikationen gefälscht. Die Spezifikation implementierte die getestete Funktion entweder direkt oder innerhalb eines page.evaluate-Aufrufs und überprüfte anschließend ihre eigene Kopie. Ein solcher Test färbt sich dabei jedes Mal trivial auf ROT und GRÜN, wobei die ROT/GRÜN-Regelung dies nicht erkennen kann, da die Tautologie beide Schritte bestehen lässt.
check_test_authenticity.py wird nun bei jeder ROT-Erfassung in jedem Workflow ausgeführt, der Tests schreibt. Es sucht nach vier Arten von Fälschungen:
- eine Spezifikation, die nichts aus dem Produktionscode importiert
- eine inline-Neimplementierung des getesteten Codes
- die Auswertung von Quelltexten
- ein synthetischer DOM, der die echte Anwendung ersetzt
Im Vergleich zu diesem echten Testsuite-Set lehnt es genau die dreizehn Fälschungen ab und akzeptiert die sieben echten Spezifikationen, ohne irgendwelche Dateinamen fest einzuschreiben. Die Testmethode umfasst außerdem das sogenannte Löschtest: Wenn ein Test auch nach dem Löschen des Produktionscodes, den er angeblich abdeckt, noch bestehen bleibt, handelt es sich um eine kritische Feststellung. Es handelt sich dabei um eine schnelle mentale Überprüfung, die man auf jeden Test anwenden kann – egal ob er von Menschen geschrieben wurde oder nicht; unser Artikel zu Anti-Patterns bei React-Tests behandelt ähnliche Fälle, in denen Testsuites falsches Vertrauen wecken.
Lektionen aus einem weiteren Code-Review-Tool
Für Version 2.7.1 haben die Betreuer Alibabas Open-Code-Review untersucht, der Berichten zufolge bei einem öffentlichen Review-Benchmark eine Genauigkeit von etwa 34 Prozent erreicht, im Vergleich zu 7 bis 16 Prozent, wenn Claude Code ohne Unterstützung mit identischen Modellen Reviews durchführt. Man sollte diese Zahlen eher als die Einschätzung des Projekts zu diesem Benchmark zu jener Zeit betrachten und nicht als unabhängiges Ergebnis. Die interessante Beobachtung war, dass die beiden Review-Kriterien fast identisch waren. Der Unterschied lag in den Strukturen: einer festgelegten Liste von Dateien, die alle berücksichtigt werden müssen, generierten Dateien, die vor dem Anblick des Diffs vom Reviewer entfernt werden, einer Größenbeschränkung sowie einem Fact-Checking-Schritt, bei dem eine Feststellung nur aus zwei genannten Gründen zurückgenommen werden kann.
Zwei Evaluationsvorfälle flossen in dieselbe Veröffentlichung ein. Eine headless-Evaluierung ohne Git-Repository in ihren Fixtures suchte eines auf dem gesamten System und fragte einen echten Issue-Tracker ab. Zudem kostete ein durch Plugins ausgelöster Bugfix-Vorgang 11,06 Dollar, lieferte jedoch keinen Test, der bei der fehlerhaften Version fehlschlagen könnte – das bedeutet, niemand würde bemerken, wenn der Fix rückgängig gemacht würde.
Die resultierenden Änderungen:
- Das Commit-Gate lehnt eine Freigabe ab, wenn in dem Überprüfungsabschnitt irgendwo ungelöste kritische oder wichtige Mängel auftauchen. Im Grunde wird das Urteil anhand der Mängel ermittelt, wobei eine reguläre Ausdrucksweise diese Berechnung bestätigt.
- Fehlt eine eigene Überprüfungszeile für jede Datei im Diff, wird das Commit abgelehnt.
- Das Überprüfungspaket entfernt Lockfiles, minifizierte Dateien sowie generierte Dateien in beliebiger Tiefe, listet auf, was entfernt wurde, und lehnt Diffs mit mehr als 1.500 Zeilen ab, es sei denn, ein Mensch erstellt eine Freigabebestätigung.
Der Vergleich war nicht einseitig. Die 51 Sprachregel-Dokumente des anderen Tools enthielten nichts für C#, Vue, PowerShell oder SQL – diese Sprachen greifen auf eine allgemeine Checkliste zurück – und genau diese Technologien werden von den Fähigkeiten dieses Plugins abgedeckt.
Bei einer zweiten Lektüre wurden in 2.7.2 drei Präzisionsregeln hinzugefügt, noch bevor ein Fehler ihre Anwendung erforderte. Der Prüfer kann zur Einordnung jedes Datei lesen, doch die Erkenntnisse beschränken sich auf Dateien, die zum gepackten Diff gehören; Beobachtungen zu anderen Dateien werden als außerhalb des Geltungsbereichs gekennzeichnet und dem Orchestrator mitgeteilt. Die Datenbankmethodik erhielt eine Einfügungsregel mit einer ausdrücklichen Liste dessen, was auf keinen Fall gemeldet werden darf – wie beispielsweise parametrierte Bindungen und statische Anweisungen –, da falsche Erkenntnisse bei korrektem Code die Prüfer dazu verleiten, die echten Fehler zu übersehen. Zudem erfordert die Sicherheitsmethodik nun eine fünfteilige Struktur für Sicherheitsdokumente, wobei jede OWASP-Kategorie entweder eine Quelle oder eine begründete Angabe „Nicht anwendbar“ benötigt, da ein leeres Feld kein Urteil darstellt.
Stand des Projekts
Zum Zeitpunkt der Erstellung verfügt das Plugin über 16 Agent-Persönlichkeiten, 45 Fähigkeiten sowie 32 Gate-Skripte mit insgesamt 1.656 Selbsttests. Alle diese Gates sind deterministisch und erfordern keine LLM-Aufrufe; sie laufen vor jeder Veröffentlichung ab. Das Bewertungssystem umfasst 69 Fälle, die auf vier Ebenen verteilt sind; bei der Ergebnissebene werden Ausführungen mit und ohne aktiviertes Plugin anhand versteckter Tests verglichen, anstatt zu prüfen, ob ein bestimmter Pfad ausgelöst wurde. Seit dem ersten Tag haben 119 Commit-Zusätze insgesamt etwa 67.000 Zeilen hinzugefügt.
Die Metrik, die die Betreuer angeblich wirklich wichtig finden, ist keine dieser. Es handelt sich um die Anzahl der Regeln, die weiterhin in Prosa formuliert sind und das Modell auffordern, genau dann zurückhaltend zu sein, wenn es am meisten weitermachen möchte. Diese Zahl sinkt mit jeder Veröffentlichung, und jedes Sinken lässt sich auf Probleme zurückführen, die während der Aktivität einer Regel aufgetreten sind.
Kernpunkte
- Betrachten Sie eine während ihrer Gültigkeit verletzte Regel als Fehlerbericht bezüglich dieser Regel und beheben Sie sie mithilfe eines Kontrollmechanismus, nicht durch strengere Formulierungen.
- Lassen Sie Skripte irreversible Aktionen wie Commit-Vorgänge durchführen, sodass ein übersprungenes Überprüfungsverfahren eine sichtbare Abweichung statt eines stillen Bestehens hinterlässt.
- Definieren Sie Ebenen für Beweismittel und verlangen Sie den gespeicherten, gehashten Ausgabeinhalt von Befehlen anstelle einer Aussage wie „überprüft“.
- Geben Sie Agenten ein legitimes Ergebnis „BLOCKED“, damit das Erfinden eines Ergebnisses „PASS“ niemals der einfachste Weg ist.
- Beweisen Sie jeden Kontrollmechanismus, indem Sie beobachten, wie er bei absichtlichen Verstößen versagt, und prüfen Sie die Kontrollmechanismen selbst, da Überprüfungen oft zu Namenstests und Prüfungen auf Dateiverfügbarkeit abdriften.
- Blockieren Sie gefährliche Toolaufrufe, bevor sie ausgeführt werden, stellen Sie aber sicher, dass der Schutzmechanismus fehleranfällig bleibt, damit niemand versucht, ihn zu entfernen.
Zusätzliche Literatur
- Wo Claude Code-Anweisungen hingehören: CLAUDE.md, Pfadregeln oder Hooks — Erfahren Sie, warum Claude Code CLAUDE.md als Kontext behandelt, wie man es kürzt, Regeln nach Pfad begrenzt, Schritte, die ausgeführt werden müssen, in Hooks verschiebt und überprüft, was tatsächlich geladen wird.
- Ein praktisches Handbuch für das Schreiben einer wirksamen CLAUDE.md-Datei — Lernen Sie 21 konkrete, überprüfbare Regeln, um eine überdimensionierte CLAUDE.md-Datei zu verkleinern, damit Claude Code in langen Sitzungen zuverlässig, vorhersehbar und vertrauenswürdig bleibt.
- Claude Code für Ihr NestJS Monorepo unterrichten: Routing, Regeln und Fähigkeiten — Wie Sie CLAUDE.md, Regeln, Fähigkeiten und Berechtigungen konfigurieren, damit Claude Code den Code in den richtigen NestJS-Dienst platziert und die Konventionen Ihres Teams befolgt.
- Regeln für Enforcing Agents im Code: PreToolUse, PostToolUse und Stop Hooks — Erfahren Sie, warum die Autorisierung von LLM-Agenten in deterministischen Tool-Call-Hooks erfolgen sollte, wie Anrufe sicher abgelehnt werden können und wie ein Dispatcher ohne Rekursion umschlossen wird.