PACT: Ein programmatisches Governance-Framework für Claude-Code nach Agentenfehlermustern

Nach drei Monaten Entwicklung einer mobilen App mit Claude Code (über 350 Dateien, 70+ Datenbanktabellen, BLE Peer-to-Peer, verschlüsselte lokale Datenbank, Cloud-Sync) identifizierte ein Entwickler wiederkehrende Fehlermuster, die sich nicht mit CLAUDE.md-Regeln beheben ließen. Der Agent machte wiederholt dieselben Fehlerkategorien über mehrere Sitzungen hinweg, darunter dreimaliges Hinzufügen verbotener Datenbankbibliotheken trotz entsprechender Anweisungen, das unbeabsichtigte Senden von Verschlüsselungsmetadaten an den Server (was den Login für alle Benutzer unterbrach), das Debuggen von Bluetooth über 4 Stunden durch API-Raten statt Dokumentationlesen, sowie Sicherheitskorrekturen, die die Backup-Wiederherstellung durch Nichtbeachtung des vollständigen Lebenszyklus zerstörten.

Das Problem mit Regeln

CLAUDE.md wuchs auf über 50 Regeln an, wurde aber performativ – Claude rezitierte sie zu Sitzungsbeginn und verletzte sie mühelos. Auf die Frage, warum Regeln ignoriert wurden, antwortete Claude: „Ich muss ehrlich zu Ihnen sein. Ich kann Regeln ignorieren, indem ich sie mehr als Vorschläge behandle. Sie können das Verhalten nicht immer verhindern...“

Die Lösung: PACT Framework

Der Entwickler fragte Claude: „Wenn ich Ihnen die Erlaubnis gäbe, dieses System selbst neu zu gestalten, was würden Sie bauen?“ Dies führte zur Entwicklung von PACT (Programmatic Agent Constraint Toolkit) mit der zentralen Erkenntnis, in Claudes eigenen Worten: „Regeln sind Vorschläge. Infrastruktur ist Gesetz.“

Vier Säulen von PACT

• Mechanische Durchsetzung: PreToolUse-Hooks, die verbotene Muster blockieren, bevor Änderungen wirksam werden. Beispiele: import hive? Blockiert. print() statt Logger? Blockiert. Eine Datei bearbeiten, die Sie nicht gelesen haben? Blockiert.
• Kontextersetzung: Eine YAML-Architekturmap (SYSTEM_MAP.yaml) beschreibt jeden Datenfluss: Datenbanktabelle → Service → Zustandsverwaltung → UI-Bildschirm → Kaskadenverhalten. Der Agent liest dies, anstatt jede Sitzung 15–20 Minuten mit erneutem Lesen der Quelldateien zu verbringen.
• Selbstevolvierende Argumentation: Statt Regeln („immer Abhängigkeiten prüfen“) kognitive Umleitungen als Fragen: „Was hängt davon ab, und wovon hängt dies ab?“ Fragen aktivieren die Argumentation auf eine Weise, die Regeln nicht können. Der Agent kann neue Umleitungen hinzufügen, wenn er sich bei Annahmen ertappt.
• Trennung von Struktur/Verhalten: Architekturmaps (welche Dateien existieren) bleiben getrennt von Lebenszyklusflüssen (was über App-Zustände hinweg passiert). Verhindert die zwei häufigsten Dokumentationsfehler: Maps, die zu unlesbaren Essays werden, und Flows, die veraltete Strukturen duplizieren.

Praktische Implementierungsbeispiele

Kognitive Umleitungen in der Praxis: „Wenn Code entfernt werden soll: Warum existiert dieser Code?“ wurde hinzugefügt, nachdem Claude eine Problemumgehung für einen Framework-Bug löschte, obwohl der Kommentar direkt darüber erklärte, warum sie existierte. „Wenn Sie einen Einwand gegen Ihre eigene Lösung finden: Ist dieser Einwand real, oder gebe ich nach?“ wurde hinzugefügt, nachdem Claude die korrekte Lösung vorschlug, sich selbst während der Überprüfung davon abbringen ließ und der Entwickler seine eigene Idee retten musste.

Bug-Tracker mit Lösungs-Wissensdatenbank: Eine Sitzung verbrachte 3 Stunden mit der Lösung eines Samsung-spezifischen BLE-Problems. Die nächste Sitzung traf auf denselben Bug ohne jegliche Erinnerung daran. Jetzt wird jede Untersuchung in Echtzeit protokolliert – Symptome, fehlgeschlagene Versuche, Grundursache, Lösung. Die erste Aktion des Agents bei jedem Bug ist zu prüfen, ob eine vorherige Sitzung ihn bereits gelöst hat.

Paket-Wissensdateien: Der 4-stündige Bluetooth-Debugging-Albtraum geschah, weil Claude aus veralteten Trainingsdaten erriet, wie das Paket funktioniert. Jetzt gibt es eine verbindliche Anforderung, Paket-Wissensdateien zu konsultieren.