# Code Guardian 17.13: Fertig ist, was belegt ist *Quelle: https://www.provimedia.de/blog/code-guardian-17-13-neuerungen · Stand: 2026-10-26* > Der Agent meldet „Tests grün“, doch der Testlauf hat nie stattgefunden. Code Guardian 17.13 schließt so eine Aufgabe nicht mehr ab, und zeigt, woran Sie ein belegtes Ergebnis erkennen. Der Agent meldet „Tests grün“, doch der Testlauf hat nie stattgefunden. Ab Code Guardian 17.13 schließt so eine Aufgabe nicht mehr ab. Dieser Überblick zu 17.10 bis 17.13 beantwortet eine Frage: Woran merken Sie, dass das Ergebnis stimmt? Den Artikel zur Fassung davor finden Sie unter [Code Guardian 17.9: Neuerungen](https://www.provimedia.de/blog/code-guardian-17-9-neuerungen). ## Was Sie jetzt tun sollten 1. Nur Codex-Nutzer mit eigenen Profilwerten: Notieren Sie Ihre Werte aus `agents/cg-*.toml`. Ein Update setzt sie zurück. 2. Installieren Sie das Update mit `bash install.sh`. Die neuen Hinweise wirken sofort. 3. Codex-Nutzer: Tragen Sie Ihre Werte danach wieder ein. 4. Legen Sie Ihre nächste Aufgabe mit `aufgabe.py neu` an; `aufgabe.py` ist das Werkzeug für Aufgabenordner. Der neue Ordner trägt „Graph: ja“ automatisch. ## Wann gilt eine Aufgabe bei Code Guardian als fertig? Seit 17.13 trägt jeder neue Aufgabenordner einen Arbeitsgraphen mit sechs Knoten. Diese sechs belegen Sie; den Abschluss trägt Code Guardian selbst ein. Knoten Womit Sie ihn belegen Plan Protokoll mit `exit=0` oder Bericht des Plan-Prüfers (`--datei`) Vorprüfung (preflight) Der rote Lauf vor der Änderung (`--rot`) Änderung (edit) Ein Commit; nach `git commit` trägt der Hook ihn selbst ein Audit Protokoll (`--datei`), Commit (`--sha`) oder `--entfaellt` mit Grund Kalt-Review Der fertige Bericht des Diff-Prüfers (`--datei`). Kalt-Review heißt: Gegenlesen durch einen Prüfer ohne Kenntnis des Plans Testlauf (suite) Protokoll mit `exit=0`; wird nie automatisch belegt **Jeder Knoten ist offen, behauptet, belegt oder entfällt.** „Behauptet“ heißt: als erledigt eingetragen, aber ohne geprüften Nachweis. Das schließt nicht ab, denn eine von Hand geschriebene Zeile belegt nichts. Belegt ist ein Knoten nur mit einem Nachweis: einer Protokolldatei mit `exit=0`, einem Commit oder einem begründeten „entfällt“. Protokoll und Commit müssen jünger sein als der Graph-Start, also der Zeitpunkt, an dem der Ordner seinen Graphen bekam. Beim Abschluss prüft Code Guardian alle Knoten erneut. Fehlt ein Beleg, meldet es „NICHT FERTIG: N Graph-Knoten ohne Beleg“. Eine Behauptung allein schließt keine Aufgabe ab. **Für Sie heißt das:** „Fertig“ ist nachprüfbar. Ein Dritter sieht im Ordner, was geprüft wurde und womit. ### So belegen Sie einen Knoten 1. Stand ansehen, rein lesend: `aufgabe.py graph --id `. 2. Je Knoten einen Nachweis wählen, mit `aufgabe.py beleg --id --knoten ` und genau einer dieser Angaben: - `--datei `: Die letzte nicht leere Zeile muss `exit=0` tragen, und die Datei muss jünger sein als der Graph-Start. - `--sha `: Der Commit muss jünger sein als der Graph-Start und in einem Zweig oder Tag liegen. - `--entfaellt `: Ohne Grund bleibt der Knoten offen. - Sonderfall Vorprüfung: Dort belegt `--rot ` den roten Lauf vor der Änderung, dessen Exit-Code ungleich 0 ist. 3. Abschließen mit `aufgabe.py abschliessen`. Nach einem `git commit` belegt der Hook den Knoten `edit` selbst, wenn der Commit höchstens zehn Minuten alt ist. Den Testlauf (`suite`) belegt er nie. **Wenn NICHT FERTIG erscheint:** `aufgabe.py abschliessen` nennt je fehlendem Knoten den passenden Aufruf von `aufgabe.py beleg`. Führen Sie ihn aus und schließen Sie erneut ab. Beachten Sie: `abschliessen` liest nur den Abschnitt `## Erkenntnisse`. Erkenntnisse unter einer eigenen Überschrift zählen nicht. ## Wird dadurch meine laufende Arbeit blockiert? Nein. Die Sperre gilt nur für neue Ordner mit „Graph: ja“. Bestehende Ordner bekommen den Graphen und nur einen Hinweis. Neu sind drei Hinweise: `[graph]`, `[wiederaufnahme]` und `[abbruch]`. Der letzte meldet einen abgebrochenen Prüf-Subagenten, der bisher still verschwand. Keiner dieser Hinweise blockiert etwas. Außerdem ist der Fehlalarm des Zauns, der Dateigrenze einer Aufgabe, in verschachtelten Repositories behoben. **Für Sie heißt das:** Die Belegpflicht trifft nur Aufgaben, die Sie neu anlegen. Alles andere läuft weiter wie bisher. ## Woran erkenne ich, woher ein Befund stammt? Das Review kennt jetzt die Risikostufe H. Sie gilt, wenn eine Änderung die Sperrliste berührt, also Bereiche wie Datenbank, Zahlung, Deploy und Geheimnisse. Sie gilt auch, wenn die Prüfung auf sicherheitsrelevante Codemuster einen Wert über 0 meldet. Dann laufen die Prüferarme, die unabhängigen Prüf-Agenten, mit höherer Denktiefe (xhigh). Im Abschlussblock leuchtet die Lampe „Risiko H“. Nach drei Kalt-Review-Runden greift ein Rundendeckel, das Review dreht sich nicht endlos im Kreis. Zu jedem Befund gibt es eine Einordnung des Fehlertyps samt Suchmuster für Stellen, an denen derselbe Fehler noch stecken kann. Dazu kommt die Herkunft: eigen, vorbestehend oder unbestimmt. Die Herkunft verschiebt kein Urteil. Sie zeigt nur, ob der Fund aus Ihrer Änderung stammt. Vor Änderungen an bestehender Architektur verlangt Code Guardian außerdem einen Steckbrief mit sieben Feldern. **Für Sie heißt das:** Riskante Änderungen werden gründlicher geprüft, und Sie sehen sofort, ob ein Befund Ihr eigener ist. ## Stimmen meine Zahlen, wenn ich mit Arbeitskopien arbeite? Ja, das ist das Ziel dieser Änderungen: Ihre Befunde und Zahlen beziehen sich auf Ihren Code und nicht mehr auf Kopien davon. Wer mit Git-Arbeitskopien unter `.claude/worktrees/` arbeitet, bekam bisher verzerrte Zahlen. Seit 17.12 zählen Arbeitskopien nicht mehr doppelt. Sieben Werkzeuge wurden umgestellt, dazu kommen Windows-Korrekturen für Klonsuche und Abhängigkeitsprüfung. 17.13 zieht nach: Weitere Prüfwerkzeuge, darunter Narbensuche, Planinventur und die Analysen für PHP, Python, JS und HTML, überspringen Arbeitskopien und den PHPStan-Cache. Die Werkzeuge erben außerdem `GIT_DIR` und `GIT_WORK_TREE` nicht mehr. **Ausnahme: Geheimnissuche und Rechtstext-Erkennung prüfen Arbeitskopien bewusst weiter.** **Für Sie heißt das:** Wer unter `.claude/worktrees/` arbeitet, muss nichts tun. Die umgestellten Werkzeuge übergehen die Kopien von selbst. ## Kann Code Guardian selbst dazulernen? Seit 17.11 gibt es den Skill `auto-self-improve`. Er blickt nach getaner Arbeit selbst zurück. Er ist standardmäßig aus, protokolliert vor jeder Änderung und fasst keinen Schutzriegel an. Seit 17.12 wartet er, solange eine Rückfrage an Sie offen ist. Einschalten: Setzen Sie in `~/.claude/code-guardian.conf` die Zeile `auto_self_improve = true`. Die Vorgabe ist false. Ebenfalls seit 17.11: der Skill `autorun` für unbeaufsichtigtes Durcharbeiten und ein Hinweis bei Schleifen, der einen immer wieder erfolglosen Schritt sichtbar macht. Keiner von beiden löst einen Schutzriegel, und der Hinweis sperrt nichts. **Für Sie heißt das:** Sie entscheiden, ob der Rückblick von selbst läuft. Ohne Ihre Einstellung bleibt alles beim Alten. ## Warum hält mich ein Riegel an, und warum seltener? Riegel sind die Schutzsperren vor riskanten Befehlen. Ein Halt soll einen Grund haben, ein harmloser Befehl keinen. Seit 17.10 erkennen die Migrations- und Deploy-Riegel einen Fernaufruf auch dann, wenn ssh nicht wörtlich im Befehl steht, sondern aus einer Variable kommt. Bisher lief eine Migration oder ein Deploy auf einem fremden Rechner dann ohne Halt durch. Der Lösch-Riegel erkennt Fernlöschen über eine ssh-Variable, auch hinter `timeout`. Gleichzeitig gibt es weniger Fehlalarme: - Ein lesendes `grep` auf ein Deploy-Skript wird erlaubt (17.11). - Ein Deploy-Name in einem Literal zählt nicht mehr als Deploy (17.11). - Eine vollständig gequotete ssh-Nutzlast, die nur eine selbst angelegte Wegwerfdatei löscht, schlägt nicht mehr an (17.10). Die Absagetexte des Lösch-Riegels sind klarer. Der Riegel fragt jetzt nach, wenn sich eine Zahl im Befehl nicht eindeutig lesen lässt (etwa nan oder inf), statt zu raten. **Für Sie heißt das:** Weniger Halte bei harmlosen Befehlen, mehr Aufmerksamkeit bei echten Risiken. ## Welche Grenzen bleiben offen? Wir nennen sie offen: - **Belegpflicht:** Sie gilt nur für neue Ordner mit „Graph: ja“. Was Sie tun können: Legen Sie wichtige Aufgaben neu an, dann gilt die Pflicht. - **ssh-Variable:** Erkannt wird sie an ihrer Schreibweise, und nicht jede Schreibweise ist abgedeckt. Was Sie tun können: Schreiben Sie ssh bei riskanten Befehlen wörtlich in den Befehl, statt es über eine Variable aufzurufen. - **Freigabebericht:** Migrations- und Deploy-Riegel akzeptieren noch einen selbst geschriebenen Bericht. Die Lücke ist für ein kommendes Release geplant. Was Sie tun können: Lesen Sie Freigabeberichte selbst gegen. - **Windows:** Ein normal beendeter Lauf zählt nicht mehr als abgebrochen. Die bekannte Grenze: Ein Lauf, der ausschließlich beim Windows-Starter unter der Git-bash abbricht, wird durch die Korrektur nicht mehr als Abbruch erkannt. Was Sie tun können: Prüfen Sie bei einem solchen Abbruch die Ausgabe selbst. - **Codex:** Die Risikostufe H wird unter Codex nur gemeldet und hebt nichts an. Was Sie tun können: Stellen Sie die Denktiefe im Profil selbst ein. **Für Sie heißt das:** Verlassen Sie sich bei Migration und Deploy nicht allein auf einen Freigabebericht. ## Was ändert sich für Codex-Nutzer? Die Codex-Ausgabe bekommt den Arbeitsgraphen mit Belegpflicht und die Herkunftsangaben. Dazu drei Unterschiede: - Die Risikostufe H wird nur gemeldet, sie hebt nichts an. Die Denktiefe der Prüferarme stellen Sie im Profil selbst ein. - Ein Update überschreibt die Agentenprofile `agents/cg-*.toml` und setzt eigene Werte zurück. Dafür sind die Schritte 1 und 3 oben gedacht. - Die Kostenmessung zeigte bei `session-cost --geld` bisher eine stille Null statt der Werte. Jetzt kommen die Tokenmengen aus den Meldungen von Codex. **Für Sie heißt das:** Notieren Sie Ihre Profilwerte vor dem Update und tragen Sie sie danach wieder ein. ## Was bringt Code Guardian messbar? Stand der Vergleichsmessung: Der jüngste gültige Lauf vom 15.10.2026 misst v17.10: im Mittel 5,9 mit gegen 5,2 ohne Code Guardian. Der Wert ist ein Punktwert je Aufgabe, höher ist besser. Der p-Wert beträgt 0,017, das Ergebnis lautet „belegt“. Für 17.11 bis 17.13 liegt noch keine eigene Messung vor. Insgesamt gibt es 10 gültige Vergleiche. Die Methode steht unter [den Benchmarks](https://www.provimedia.de/code-guardian#benchmarks). Mehr zum Produkt finden Sie auf der [Produktseite](https://www.provimedia.de/code-guardian). ## Häufige Fragen zu Code Guardian 17.13 ### Was tue ich bei NICHT FERTIG? Führen Sie den Aufruf aus, den `aufgabe.py abschliessen` für jeden fehlenden Knoten nennt. Schließen Sie danach erneut ab. ### Wie schalte ich den Selbst-Rückblick ein? Setzen Sie in `~/.claude/code-guardian.conf` die Zeile `auto_self_improve = true`. Er rührt keinen Schutzriegel an und verändert nichts Unumkehrbares. ### Was passiert nach drei Kalt-Review-Runden? Die Lampe zeigt „Rundendeckel 3 Runden — Ansatz überdenken“. Überdenken Sie dann den Ansatz, statt eine vierte Runde zu drehen. ### Muss ich als Codex-Nutzer etwas beachten? Ja: die Schritte 1 und 3 oben und die Denktiefe der Prüferarme im Profil. ## Hinweis zu 17.11 In der Notiz zu 17.11 waren zwei Angaben ungenau: Die drei Review-Agenten waren nicht neu, und der Steckbrief hat sieben Felder. ## Quellen - Changelog Code Guardian 17.10–17.13 (Claude-Paket und Codex-Paket), im Kundenportal - Vergleichsmessung, Lauf vom 15.10.2026 (Benchmarks auf der Produktseite) Stand: 26.10.2026 --- Kanonische Version: