Der Anfang

Irgendwann hörte dieses Repository auf, ein Ort zu sein, an dem nur ich allein codiere, und wurde zu einem Ort, an dem auch ein KI-Agent — konkret Claude Code — echte Arbeit erledigt: Dateien lesen, über Module hinweg bearbeiten, Befehle ausführen, MCP-Tools aufrufen. Das ist eine andere Art Mitarbeiter als ein Linter oder eine CI-Prüfung, und früh hatte ich keine gute Antwort darauf, was passiert, wenn er etwas auf eine Weise falsch macht, die nicht offensichtlich falsch ist.

Die erste Lösung

Die erste Korrektur war die naheliegende: mehr in CLAUDE.md schreiben. Jedes Mal, wenn ich bemerkte, dass der Agent eine Regel verpasste — Evidenzauswahl muss deterministisch bleiben, keine Shell-Interpolation in einem Python-Spawn-Aufruf, Inhalte brauchen immer beide Sprachen —, fügte ich eine Zeile hinzu, die ihm sagte, das nicht noch einmal zu tun, und erinnerte ihn zu Beginn der nächsten Sitzung erneut daran, falls es wieder passierte.

Was kaputtging

Das funktionierte eine Weile, in dem Sinne, dass eine einzelne, flache Instruktionsdatei einiges abfangen kann, bevor sie aufhört zu funktionieren. Was tatsächlich kaputtging, war nicht die Korrektheit in irgendeinem Einzelfall — es war, dass der Fehlermodus, um den ich mir Sorgen machte, nicht "der Agent schreibt schlechten Code" war, sondern "der Agent schreibt Code, der vollkommen in Ordnung aussieht und leise eine Invariante verletzt, von der ihm niemand erzählt hat", weil diese Invariante nur in meinem Kopf existierte, nicht in etwas, das der Agent selbst prüfen konnte. Mit der wachsenden Zahl an Teilsystemen — Anschreiben, CVs, Fotografie, Ask Vikram, MCP, eine Admin-Oberfläche für jedes — konnte eine einzelne Instruktionsdatei all dieses "Warum" nicht mehr fassen, ohne unlesbar zu werden, und selbst wenn sie die Regel enthielt, musste der Agent immer noch raten, welche Teile für die gerade anstehende Aufgabe relevant waren.

Das andere, was kaputtging, war die Kontinuität. Sitzungen werden unterbrochen, komprimiert oder enden einfach mitten in einer Aufgabe, und die nächste Sitzung würde entweder Kontext neu herleiten, den sie schon einmal hatte — langsam —, oder schlimmer, auf einer veralteten Annahme weitermachen, weil nichts sie zwang zu prüfen, was sich tatsächlich verändert hatte.

Die Entscheidung

Die verlockende Korrektur für "der Agent weiß nicht, was relevant ist" ist ein klügerer Router — Embeddings oder ein kleiner Klassifikator, der entscheidet, welcher Kontext für eine Aufgabe geladen wird. Ich habe das erwogen und verworfen, aus einem Grund, der nichts damit zu tun hatte, ob es funktionieren würde: Eine so gebaute Routing-Schicht bräuchte selbst dieselbe Sicherheits- und Korrektheitsprüfung wie jede andere LLM-zugewandte Oberfläche in diesem Repository, und ich wollte dem Ding, dessen ganze Aufgabe es ist, den Agenten geerdet zu halten, keine probabilistische Abhängigkeit hinzufügen. Stattdessen wählte ich eine statische Nachschlagetabelle mit zwölf Kategorien — ein JSON-Manifest, validiert auf dieselbe Weise wie Code, das eine Sitzung von Auge abgleicht. Das ist weniger clever. Es ist dafür vollständig git-überprüfbar und braucht kein eigenes Bedrohungsmodell.

Die zweite Entscheidung betraf, was Automatisierung tun darf, sobald sie etwas bemerkt. Jeder Hook in diesem System — Sitzungsstart, Pre-Commit, Pre-Push, der Checkpoint-Schreiber — meldet oder blockiert. Keiner davon repariert, committet oder wendet eine Änderung in meinem Namen an. Selbst an der einen Stelle, an der ein zweites Modell ins Spiel kommt und aus dem gestagten Diff eine Commit-Nachricht entwirft, endet das, bevor tatsächlich irgendetwas committet wird, ohne ein explizites Ja von mir. Ich wollte kein System, das technisch sicherer ist, dessen Ausgabe ich aber aufgehört habe, tatsächlich zu lesen — der Wert von "der Agent schlägt vor, ich entscheide" gilt nur, wenn diese Grenze in der Praxis sichtbar bleibt, nicht nur in der Dokumentation.

Die neue Architektur

Aufgabe ↓ context-engine/routing-manifest.json (statisch, 12 Kategorien, kein LLM) ↓ knowledge/-Konzepte + CodeGraph-Einstiegspunkte (geladen, nicht auswendig gelernt) ↓ Bearbeitung ↓ Hooks: melden oder blockieren, nie automatisch reparieren ↓ Checkpoint (Sitzungszustand automatisch rekonstruiert) ↓ Commit-Entwurf (zweites Modell schlägt vor, ich bestätige — y/e/n)

Die Knowledge-Schicht darunter behandelt knowledge/ so, wie ein Compiler Quellcode behandelt — etwas, das validiert und gelintet wird, nicht etwas, das für mich geschrieben wird. Sieben Validatoren prüfen Metadaten, Links und Veralterung gegen die Git-Historie; das eine vollständig mechanische Artefakt (index.md) wird aus validierter Frontmatter neu generiert, und alles, was echtes Urteilsvermögen braucht, läuft über einen Vorschlag, den weiterhin ein Mensch annehmen muss — nicht weil ich Automatisierung bei kleinen Dingen nicht vertraue, sondern weil ich eine klare Linie zwischen "mechanisch" und "urteilsbedürftig" wollte, keine verschwommene.

Was ich gelernt habe

Das Ehrlichste, was ich über das Proposal-Framework — Proposal → Review → Accept → Apply — sagen kann, ist, dass es vollständig existiert und heute null registrierte Generatoren hat. Ich habe das Gerüst vor der Automatisierung gebaut, die es eigentlich nutzen sollte, in der Annahme, dass ein fertiges Framework das Schreiben des ersten Generators leicht machen würde, sobald der Bedarf auftaucht. Der Bedarf ist noch nicht aufgetaucht, und ich bin mir inzwischen nicht mehr sicher, ob das Vorausbauen Weitsicht war oder einfach Begeisterung für das Framework selbst.

Die MCP-Dokumentationsabweichung, die ich in der Geschichte der Plattform erwähnt habe — mcp/README.md beschreibt Bearer-Token-Auth noch immer als primär, nachdem das System auf OAuth 2.1 umgestellt wurde — ist im Rückblick der beste Beleg dafür, dass dieses ganze Schutzsystem notwendig ist und nicht paranoid. Es ist genau die Art von stillem Auseinanderlaufen zwischen Geschriebenem und Wahrem, die die Staleness-Prüfungen der Knowledge-Schicht abfangen sollen, und es ist in einer Ecke passiert, die die Prüfungen noch nicht abdeckten.

Der Blick nach vorn

Den ersten Knowledge-Builder-Proposal-Generator zu schreiben — am ehesten etwas Kleines, wie das Markieren einer Konzeptdatei, deren updated:-Datum von der Git-Historie ihrer zitierten Quelle abgewichen ist — ist der konkrete nächste Schritt, der das Proposal-Framework zu etwas Genutztem macht statt zu einem gut gebauten Pfad, den noch niemand gegangen ist. Ich würde außerdem bun knowledge:validate und die Index-Aktualitätsprüfung gerne als blockierenden CI-Schritt sehen, nicht nur als lokalen Git-Hook — HUSKY=0 ist ein dokumentierter, legitimer Weg, Hooks zu überspringen, was genau der Grund ist, warum er nicht das Einzige sein sollte, das zwischen einem Verstoß und einem Merge steht.

Fazit

Nichts von diesem Gerüst macht den Agenten schlauer. Was es tut, ist sicherzustellen, dass ich bei allem, was der Agent entscheidet, immer sagen kann, ob er gehandelt oder vorgeschlagen hat — und dass diese Grenze sichtbar bleibt, ist der einzige Grund, warum ich mich damit wohlfühle, ihm so viel Zugriff zu geben, wie er hat.