Code Guardian 17.16: Fertig nur mit Beleg, und eine Riegel-Lücke

Wann ist eine Aufgabe fertig? Seit 17.15 schließen neue Aufgabenordner erst, wenn jedes Pflichtkriterium belegt ist. Der zweite Grund, dieses Update zu lesen: Die Riegel für Löschen, Deploy und Migration haben eine Lücke, und 17.16 hat die Notiz dazu berichtigt. Dieser Überblick zu 17.14 bis 17.16 sagt, wann eine Aufgabe als fertig gilt, was die Riegel neu abfangen, welche Lücke bleibt und was Sie vorher tun sollten.

Den Artikel zur Fassung davor finden Sie unter Code Guardian 17.13: Neuerungen.

Was Sie jetzt tun sollten

1. Führen Sie den Installer aus. Beim Update meldet er jede lokal geänderte oder ergänzte Datei eines Begleit-Skills einzeln.
2. Prüfen Sie, dass Python 3.9 oder neuer installiert ist. Fehlt python3, erscheint je Code-Edit eine Zeile [toolchain] mit dem Fix.
3. Legen Sie Ihre nächste Aufgabe mit aufgabe.py neu an. Der neue Ordner trägt Akzeptanzkriterien.
4. Lassen Sie Testläufe, die als Beleg dienen sollen, über beleg-lauf.py laufen. Dann ist das Protokoll gesiegelt.
5. Schreiben Sie Befehle zum Löschen, Deployen und Migrieren ohne umleitenden Block, oder prüfen Sie sie selbst. Die Formen stehen im Abschnitt „Welche Grenzen bleiben offen?“.

Wann schließt eine Aufgabe jetzt ab?

Neue Aufgabenordner (aufgabe.py neu) tragen seit 17.15 Akzeptanzkriterien. Sie werden vor dem ersten eigenen Commit eingefroren und gesiegelt. aufgabe.py abschliessen schließt erst, wenn jedes Pflichtkriterium belegt ist.

Für Sie heißt das: „Fertig“ braucht einen Beleg für jedes Pflichtkriterium. Eine Behauptung genügt nicht.

Wie wird ein Testprotokoll zum Beleg?

Das neue Werkzeug beleg-lauf.py versiegelt ein Testprotokoll mit dem Inhaltsstand Ihres Arbeitsbaums. Ändert sich der Baum während des Laufs, gilt der Beleg als veraltet. Übersprungene Tests (SKIP) belegen nichts. Steht HEAD inzwischen auf einem anderen Commit, etwa nach einem Rebase, nennt die Absage genau diesen Fall.

Dazu kommen verdeckte Abnahmefälle. Ein Kriterium der Art review · holdout gilt nur durch Fälle, die ein frischer Subagent nach dem Einfrieren schreibt und die beim Bauen nicht sichtbar sind. Jeder Fall braucht ein gesiegeltes Protokoll.

Für Sie heißt das: Starten Sie den Testlauf, der als Beleg dienen soll, über beleg-lauf.py und ändern Sie währenddessen nichts am Arbeitsbaum. Zählen Sie nicht auf übersprungene Tests.

Was können die zwei neuen Skills?

Das Claude-Paket hat jetzt 31 Skills, vorher waren es 29. Beide neuen starten nur auf Ihren Aufruf und stehen auf der Sperrliste des Schreib-Riegels. Im unbeaufsichtigten Lauf sind sie nicht überschreibbar.

goalengine

• Was er tut: Er macht aus einer Zielabsicht einen Zielvertrag mit festen Versionen. Ein Vertrag gilt erst nach ausdrücklicher Freigabe einer benannten Version und ist danach eingefroren. Ein Kriterium gilt nur mit Beleg als erfüllt: einem Commit, einem Protokoll mit exit=0, einer URL oder einer benannten Handprüfung. Bei der Freigabe gibt er einen kopierbaren /goal-Prompt aus.
• Was er nicht tut: Kein Hook erzwingt den Vertrag.
• Wo Sie ihn sehen: Der Leitstand hat die neuen Reiter „Goal Engineering“ und „Todos“ je Projekt. Ihre Ziele liegen im jeweiligen Projekt im Ordner .goals/; unter ~/.claude/goals/ steht nur die Liste der Projekte mit Zielen.

codeguard-master

• Was er tut: Er beobachtet die Projekte Ihres Rechners, die Sie ihm nennen (ohne Liste die mit goalengine-Zielen). Im festen Takt sammelt er ohne Modell die Lage.
• Was er nicht tut: Er greift nicht auf Verdacht ein. Nur wenn ein fester Auslöser neu anschlägt, wählt ein Modell ohne Werkzeuge wenige Maßnahmen aus, mit Mindestabstand und Tagesbudget. Ausgehende Texte kommen nur aus festen Vorlagen. Liegt er zu oft falsch, schaltet er auf reines Melden um.
• Was es kostet: Den Takt über launchd richten Sie selbst ein, und jeder Modelllauf kostet Tokens.

Für Sie heißt das: Beide Skills sind Angebote. Ohne Ihren Aufruf passiert nichts.

Was ändert sich bei der Prüfung nach jeder Dateiänderung?

Seit 17.14 läuft sie in einem einzigen python3-Prozess, dem Modul hooks/_cg_reminder.py. Vorher startete sie rund 115 Hilfsprozesse. Texte und Reihenfolge der Hinweise bleiben gleich. Sie müssen nichts tun: Die Prüfung läuft nach jedem Edit von selbst, sie braucht nur python3 (siehe Schritt 2 oben).

Ergebnis unter Windows: Die Prüfung ist im typischen Fall (Median) 2,4- bis 7,7-mal schneller als bisher. Nur bei Markdown-Dateien bleibt sie gleich.

Ziel und Stand: Unter Windows soll die Prüfung kaum länger dauern als unter Linux und macOS. Gemessen heißt das: Von 100 Aufrufen dauern 95 höchstens das 1,25-Fache des langsameren der beiden anderen Systeme. Für Shell-Skripte und Markdown stimmt das nach der vorläufigen Messung. Den Stand der übrigen Sprachen nennt der Abschnitt „Welche Grenzen bleiben offen?“.

Weitere Änderungen aus 17.14, die Sie merken:

• [security-shape] meldet sicherheitsrelevante Formen nur noch in den Zeilen, die der Edit geschrieben hat. Der Hinweis läuft nur für PHP, Python, JavaScript, TypeScript und Vue.
• Der neue Hinweis [plan-abweichung] meldet einmal je Datei und Sitzung, wenn Sie eine Code-Datei bearbeiten, die in keiner offenen TRACE steht. Er sperrt nie.
• log-inventur.py inventur findet die Logquellen und markiert, welche Datei AKTUELL und welche VERALTET ist.

Hält mich ein Riegel jetzt häufiger an?

Dort, wo bisher etwas durchrutschte, ja. Dort, wo er zu Unrecht hielt, seltener.

Schärfer seit 17.15:

• Der Lösch- und der Migrations-Riegel prüfen ein Programm, das per Pipe in einen Interpreter läuft, wie ein Programm nach -c.
• Ein Ausweg-Kommentar gibt nichts mehr frei, wenn ihm eine ausführbare Zeile folgt.
• Ein Deploy-Bericht gilt nur noch für die Ziele seiner Target:-Zeile.

Neu erkennen die Riegel:

• rsync, scp und sftp auf eine IPv6-Adresse,
• ein Deploy-Skript über stdin oder mit vorangestelltem Shell-Schalter,
• einen Interpreter mit einer .sql-Datei.

Zwei Folgen dieser Schärfe, den SQL-Linter und env -S, nennt die Liste der offenen Grenzen weiter unten.

Weniger Fehlalarme: Reines Lesen und Konfigurationsdateien gelten nicht mehr als „geschrieben und gestartet“. Lesebefehle von npm und composer gelten nicht mehr als Schreiber, und Wörter wie „form“ oder „platform“ zählen nicht mehr als Löschbefehl. Auch eine Commit-Nachricht mit maskiertem Anführungszeichen löst keinen Fehlalarm mehr aus.

Neu: Kommt dieselbe Riegel-Absage oder derselbe Werkzeugfehler zum dritten Mal, nennt Code Guardian einmal den vorgesehenen Ausweg. Der Hinweis sperrt nie.

Außerdem schreiben Prüfagenten mit Shell-Zugang nicht mehr in Ihren Arbeitsbaum. Schreibende git-Proben laufen nur noch in einem Wegwerf-Repository.

Für Sie heißt das: Mehr Absagen bei den neu erkannten Formen, weniger bei reinem Lesen. Beim dritten gleichen Stopp nennt Code Guardian den Ausweg.

Welche Korrekturen sind dabei?

Das sind Korrekturen und keine neuen Fähigkeiten:

• Beim Update zählt Python-Bytecode nicht als lokal geänderte Datei eines Begleit-Skills.
• aufgabe.py findet den Aufgabenordner auch aus einer git-Arbeitskopie (Meldung eines Kunden).
• Die Audit-Erinnerung erscheint nicht mehr für Dateien im Scratchpad oder in $TMPDIR.
• Der Sitzungsstart kommt wieder vollständig an: Anker, Todo-Zahl und Drift-Hinweis stehen wieder im Kontext.
• Die Kontingent-Anzeige im Leitstand zeigt auch dann eine frische Messung, wenn Claude Code nur den Wochenwert liefert.
• Den Hinweis auf /clear nach abschliessen zeigt Code Guardian nur noch, wenn die Sitzung keine offene Aufgabe mehr hält.

Außerdem neu: Mit aufgabe.py uebergabe schreiben Sie am Sitzungsende eine Übergabedatei.

Was ändert sich für Codex-Nutzer?

Die Codex-Ausgabe bekommt die Akzeptanzkriterien, beleg-lauf.py, die schärferen Riegel und die Prüfung in einem Prozess. Die Skills goalengine und codeguard-master gibt es dort nicht. Weitere Unterschiede:

• Ein lesender PowerShell-Aufruf mit $env: oder Select-String wird nicht mehr als env -S angehalten.
• Die schreibenden git-Proben der Prüfagenten entfallen und werden im Bericht als nicht ausgeführt benannt.
• Der Installer weist ein relatives CODEX_HOME ab, auch bei --probe, und zwar vor dem ersten Schreibzugriff. Setzen Sie es auf einen absoluten Pfad, etwa $HOME/.codex, oder lassen Sie es leer.

Welche Grenzen bleiben offen?

Diese Liste ist die vollständige Stelle für alle Vorbehalte dieses Artikels.

• Befehle in einem Block mit Umleitung dahinter: Die Notiz zu 17.15 nannte hier nur eine seltene Schreibweise beim Migrations-Riegel. Das war zu eng, und 17.16 berichtigt die Texte; das Verhalten der Riegel ist gleich geblieben. Der Lösch-, der Deploy- und der Migrations-Riegel übersehen Befehle in einem Block, dessen Eingabe erst hinter dem Block umgeleitet wird. Dieselbe Anweisung ohne Block erkennen sie. Gemeint sind diese Formen:

  { befehl; } < eingabe
  ( befehl ) < eingabe
  while read zeile; do befehl; done < eingabe
  if bedingung; then befehl; fi < eingabe

  Behoben wird das im Folgerelease. Bis dahin schreiben Sie riskante Befehle ohne umleitenden Block oder prüfen Löschen, Deploy und Migration in so einem Block selbst.
• SQL-Linter: Auch ein reiner Linter mit einer .sql-Datei wird angehalten. Einen Ausweg nennt die Fassung nicht.
• env -S: Mit weiteren Wörtern führt es im Claude-Paket zu einer Rückfrage und unter Codex zu einer Sperre. Auch hier nennt die Fassung keinen Ausweg.
• Windows-Laufzeit: Für PHP, Python, JavaScript und CSS ist das Ziel noch nicht erreicht. Die macOS-Basis der vorläufigen Messung wurde unter Last gemessen, eine Neumessung auf ruhiger Maschine ist für das nächste Release vorgesehen. Die Abnahme des Ziels ist fest für das nächste Release eingeplant und nicht als erledigt gezählt.
• Codex: Verdeckte Abnahmefälle (review · holdout) sind dort nicht verfügbar.

Für Sie heißt das: Die Abnahme ist belegbar geworden, die Riegel sind dichter. Eine Lücke bleibt bis zum Folgerelease, und wir benennen sie.

Mehr zum Produkt finden Sie auf der Produktseite.

Quellen

• Changelog Code Guardian 17.14–17.16 (Claude-Paket und Codex-Paket), im Kundenportal

Stand: 04.11.2026