Hauptgedanke

Eine CLAUDE.md-Datei im Wurzelverzeichnis eines Projekts sagt dem Agenten, wie er arbeiten soll: die Konventionen des Repos, die erlaubten Formate, was er niemals tun darf. Man hält sie gern für das Gedächtnis des Projekts, weil sie da ist, weil sie bleibt und weil der Agent sie jedes Mal liest.

Das ist sie nicht. Diese Datei legt fest, was immer gelten soll; sie sagt nicht, was geschehen ist. Sie enthält weder den Bug vom Freitag noch den versuchten und wieder verworfenen Fix, noch die Entscheidung, die mitten in der Sitzung fiel, weil der erste Ansatz nicht trug. Nichts von dem, was passiert ist, schlägt sich darin nieder, und nichts darin altert.

Zwei Gegenstände, zwei Arten zu schreiben. Die Regel wird einmal verfasst, mit Abstand, und gilt, bis man sie ändert. Das Journal entsteht laufend, unmittelbar, und ist nur für den Tag wahr, an dem es datiert ist. Wer beides in einer einzigen Datei führen will, bekommt entweder Regeln voller Anekdoten oder ein Journal, das sich für eine Doktrin hält.

Warum das wichtig ist

Es ist die Lücke, die niemand sieht, weil schon etwas ihren Platz einnimmt. Ein Projekt mit Regeldatei hält sich für gut ausgestattet – und erklärt trotzdem jeden Montag aufs Neue, was in der Vorwoche getan wurde.

Die Diagnose taugt auch jenseits von Agenten: Eine Teamdokumentation, eine Charta, ein Konventionenkatalog haben genau denselben blinden Fleck.

Nuancen und Grenzen

Die Grenze verschiebt sich. Eine mitten in einer Sitzung getroffene und dreimal bestätigte Entscheidung wird zur Regel – und gerade das Journal macht es möglich, das zu bemerken.

Und eine schlecht gepflegte Regeldatei enthält immer Spuren von Geschichte: Verbote, die nach einem Vorfall aufgeschrieben wurden und die niemand mehr datieren kann.

Offene Fragen

• Wer entscheidet, ob eine Entscheidung zur Regel aufsteigt, wenn das Journal vom Agenten und die Regeln vom Menschen geführt werden?