Eine 7-Dateien-Governance-Ebene zur Verhinderung von LLM-Sitzungsdrift

Ein Entwickler auf r/LocalLLaMA teilte eine Lösung, um zu verhindern, dass KI-Codierungsassistenten wie Claude architektonische Entscheidungen über Sitzungen hinweg stillschweigend rückgängig machen. Statt KI-Sitzungen als Gespräche zu behandeln, werden sie nun als zustandslose Prozesse betrachtet, die ein Protokoll benötigen.

Das Kernproblem

Jede KI-Sitzung beginnt ohne Gedächtnis. Man erklärt erneut, sie interpretiert neu und driftet selbstbewusst ab. Der Entwickler merkte an: "Man bemerkt es erst, wenn man tief im Projekt steckt, vielleicht drei oder vier Dateien tief oder wer weiß, sogar im letzten Teil des Projekts."

Die 7-Dateien-Governance-Ebene

Die Lösung ist kein besserer Prompt, sondern eine Governance-Ebene, die jedes Modell lesen und sofort darin arbeiten kann. Das System verwendet sieben Dateien, jede mit einer spezifischen Aufgabe ohne Überschneidungen:

• active_context.md - Sitzungscontroller, definiert, was gerade im Fokus steht
• contracts.md - Verhaltensgesetz, Datenschemata, Enumerationswerte, erforderliches Verhalten
• agent_core.md - Ausführungsdisziplin, wie man arbeitet, prüft, berichtet
• agent_project.md - Projektabsicht, warum dieses System existiert, erwartete Ergebnisse
• decisions.md - ADR-Protokoll, nicht offensichtliche Entscheidungen und warum sie akzeptiert wurden
• build_plan.md - Modul-Roadmap, Implementierungsreihenfolge und Liefergegenstände
• state.md - Lebendiges Journal, was erledigt ist, was sich geändert hat, was bleibt

Wichtige Designentscheidungen

Der Entwickler erläuterte zwei kritische Trennungspunkte:

Trennung von contracts.md und agent_core.md: "Wenn ein Verhaltenskonflikt auftrat, hatte das Modell keine Möglichkeit zu wissen, welcher Ebene es folgen sollte. War dies eine Schemaregel oder eine Ausführungspräferenz? Wenn sie getrennt sind, ist die Hierarchie eindeutig, Verträge gewinnen immer."

Einbeziehung von decisions.md: "Ich hätte es fast übersprungen ('Ich werde mich einfach erinnern'). Drei Wochen später konnte ich nicht rekonstruieren, warum wir für ein bestimmtes Modul Postgres statt SQLite gewählt hatten. Das ADR-Protokoll existiert genau deshalb, weil 'Ich werde mich erinnern' kein Protokoll ist."

Die operative Schleife

Jede Sitzung folgt dieser Reihenfolge, ohne Ausnahmen:

1. Lese active_context.md → extrahiere, was im Fokus steht
2. Erneut verankern gegen contracts.md → Verhaltensregeln gesperrt
3. Bestätige Betriebsbeschränkungen von agent_core.md + agent_project.md
4. Prüfe decisions.md → akzeptierte Entscheidungen nicht umkehren
5. Führe nur aus, was active_context.md autorisiert, gemäß build_plan.md
6. Validiere mit Tests – nicht ohne Beweise als erledigt erklären
7. Aktualisiere state.md mit faktischen Ergebnissen
8. Wenn eine neue nicht-triviale Entscheidung getroffen wurde, protokolliere sie in decisions.md

Auswirkungen auf den Arbeitsablauf

Die Bereichssperre von active_context.md erwies sich als besonders wertvoll: "Vorher begann ich eine Sitzung, um einen Fehler zu beheben, und endete damit, ein unabhängiges Modul umzustrukturieren, weil 'es genau dort war'. Fühlte sich produktiv an.........und war es auch."