Was eine KI-Session aufzeichnet

Das meiste, was Pathrule über dein Projekt lernt, lernt es aus der Arbeit, nicht aus dem Schreiben. Wenn eine KI-Session ein Stück Arbeit abschließt, zeichnet sie einen kurzen strukturierten Eintrag auf, und genau auf diesem einen Eintrag bauen mehrere andere Features auf.

Diese Seite beschreibt, was in diesem Eintrag steht, was bewusst weggelassen wird und wofür er anschließend genutzt wird.

Was aufgezeichnet wird

Jeder Eintrag besteht aus einer Handvoll Felder, alle klein:

• Bereich, Aktion und Scope. Welche Art von Sache berührt wurde (ui, backend, database, infra, config, test, docs), was damit gemacht wurde (create, update, fix, refactor, delete, style) und auf welcher Ebene (eine Komponente, eine Seite, eine API, eine Migration, ein Service).
• Themen. Bis zu fünf kleingeschriebene Schlagwörter, so wie du die Arbeit im Gespräch taggen würdest.
• Eine Zusammenfassung in einem Satz. Was sich geändert hat und warum, in einer Zeile.
• Die berührten Pfade, gruppiert nach Bereich.
• Welcher KI-Client die Session ausgeführt hat und wann.
• Wie der Turn verlaufen ist: wie viele Tool-Aufrufe er gebraucht hat, wie viele davon fehlgeschlagen sind, und ein Kurzcode für jede Fehlerart (timeout, exit_nonzero, not_found und ähnliche). Nur Zählwerte und Codes, nie der Befehl oder der Fehlertext.

Das ist der gesamte Eintrag. Er soll auch Monate später auf einen Blick lesbar sein, und deshalb bleibt er kurz. Die Ansicht Recent Activity in Pathrule für VS Code listet die neuesten Einträge des Workspaces auf.

Der Assistent schreibt den Satz. Pathrule fügt die Messung hinzu. Zusammenfassung, Bereich und Pfade stammen von der Session, die die Arbeit erledigt hat, während die Anzahl der Tool-Aufrufe, die Fehlschläge und welche der gelieferten Einträge tatsächlich herangezogen wurden, von der Schicht beobachtet werden, die sie geliefert hat. Diese Aufteilung ist wichtig: Ein Assistent kann vergessen zu erwähnen, dass vier Befehle fehlgeschlagen sind, und die Zahl ist trotzdem da.

Was nie aufgezeichnet wird

Dein Code steht nicht darin. Keine Dateiinhalte, keine Diffs, keine Patches, keine Commit-Messages und kein Prompt-Text. Die Pfade sind da, damit spätere Features erkennen können, wo gearbeitet wurde; der Inhalt der Änderung wird nicht gespeichert.

Pfade werden außerdem vor dem Speichern normalisiert. Ein Pfad kommt so an, wie der Agent ihn auf der jeweiligen Maschine gesehen hat, und wird in workspace-relative Form umgewandelt, sodass aus /Users/you/projects/app/src/api.ts ein src/api.ts wird. Nichts Maschinenspezifisches gelangt in das geteilte Team-Wissen, und dieselbe Datei bleibt dieselbe Datei, egal wer sie angefasst hat.

Was ein Eintrag speist

Wertvoll wird der Eintrag durch das, was ihn liest:

• Arbeitsepisoden. Zusammengehörige Einträge aus einer Arbeitssession werden zu einem betitelten Eintrag über eine Sache zusammengefasst, die dein Team gelöst hat, und eine spätere Session kann ihn abrufen.
• Dateien, die sich gemeinsam ändern. Aus den Pfaden in jedem Eintrag lernt Pathrule, welche Dateien paarweise auftreten.
• Retrieval-Lernen. Wenn einem Agenten Wissen vorgelegt wurde und er danach im selben Bereich gearbeitet hat, ist das ein Hinweis darauf, dass das Wissen relevant war. Mit der Zeit verschiebt das die Priorität, beschrieben unter Wie Retrieval das richtige Wissen findet.

Für nichts davon brauchst du einen eigenen Schritt. Alles stammt aus demselben kurzen Eintrag.

Logging blockiert nie die Arbeit

Eine bewusste Designentscheidung verdient einen eigenen Hinweis, weil sie sich im Verhalten des Tools zeigt. Das Logging schlägt nie wegen der Größe fehl. Wird eine Zusammenfassung zu lang oder hat eine Aufgabe Dutzende Dateien berührt, wird der Eintrag auf dem Server gekürzt und gespeichert, statt abgelehnt zu werden.

Ihn abzulehnen wäre schlimmer, als ihn zu kürzen. Ein Agent, der einen Validierungsfehler bekommt, liest ihn als „korrigiere die Argumente und versuch es noch einmal“ und verbringt die nächsten Turns damit, eine Zusammenfassung umzuschreiben, statt deine Aufgabe zu erledigen. Deshalb werden die Limits stillschweigend beim Eingang angewendet, und die Antwort teilt dem Agenten mit, was gespeichert wurde.

Wofür die Fehlerzählwerte genutzt werden

Über die Zählwerte für Tool-Aufrufe und Fehlschläge beantwortet Pathrule die Frage „in welchen Dateien dieser Codebasis tut sich ein Assistent schwer“ anhand echter Arbeit statt anhand von Meinungen. Zwei Dinge lesen sie.

Das erste ist eine wöchentliche Gruppierung. Jeder Fehlschlag wird als Tripel erfasst: die Art des Tools, die Datei, an der es gearbeitet hat, und ein Kurzcode dafür, wie es fehlgeschlagen ist. Nach Wochen gruppiert ergibt das eine schlichte Liste der Dateien, in denen ein Assistent am häufigsten scheitert, und welche Art von Fehler dort auftritt. Eine Datei, die immer wieder unter file_not_found auftaucht, ist meist ein veralteter Pfad in deiner eigenen Doku oder ein verschobenes Modul, das niemand nachgezogen hat. Eine unter syntax_error ist meist eine Datei, die sich schwer sicher bearbeiten lässt.

Das zweite ist das Retrieval-Lernen. Wenn ein Turn Wissen von Pathrule erhalten hat und trotzdem auf Tool-Fehlschläge gestoßen ist, zählt das gegen das gelieferte Wissen. Dieses Signal fließt in dieselbe Lernschleife ein, die unter was Wissen höher priorisiert beschrieben ist, sodass Wissen, das immer wieder in schlecht verlaufenden Turns auftaucht, nach und nach nicht mehr ausgewählt wird.

Was ein Fehlerzählwert sehen kann und was nicht

Das hängt vom Assistenten ab, den du nutzt, und die ehrliche Antwort fällt nicht einheitlich aus.

Datei-Tools melden sauber. Ein fehlgeschlagenes Lesen, Bearbeiten oder Schreiben kommt mit seiner Meldung an und wird daher klassifiziert und der richtigen Datei zugeordnet. Genau das ist der wertvolle Fall, denn erst der Dateipfad macht die Zahl handlungsrelevant.

Beim Exit-Status von Shell-Befehlen ist das oft nicht so. Manche Assistenten melden einen Exit-Code ungleich null überhaupt nicht: Ein fehlgeschlagener und ein erfolgreicher Befehl kommen identisch an. Pathrule rät nicht. Es zeichnet auf, was der Assistent tatsächlich gemeldet hat, und klassifiziert den Rest als unbekannt, statt einen Fehlschlag zu erfinden, denn ein falscher Fehlschlag an einer Datei ist schlimmer als ein fehlender.

Zugriff und Geltungsbereich

Einträge liegen in dem Workspace, in dem sie aufgezeichnet wurden, hinter derselben benutzerbezogenen Zugriffskontrolle wie Memories, Regeln und Skills. Ein Teammitglied sieht die Aktivität der Workspaces, die es ohnehin sehen kann, und sonst nichts. Die ältesten Einträge laufen nach einem festen Zeitplan aus, statt sich endlos anzusammeln.