Dateien, die einen Assistenten ausbremsen

Manche Dateien sind für einen Assistenten schwieriger zu bearbeiten als andere, und der Grund liegt meist nicht im Code selbst. Ein Pfad in deiner Doku, der verschoben wurde. Eine generierte Datei, die sich nicht gefahrlos bearbeiten lässt. Ein Verzeichnis, das eine Berechtigung braucht, die der Agent nicht hat. Welche Dateien das ungefähr sind, weißt du längst, weil sie dich selbst schon geärgert haben. Pathrule erfasst es genau.

Was erfasst wird

Wenn ein Tool, das ein Assistent aufruft, fehlschlägt, werden drei Dinge gespeichert: die Art des Tools, die Datei, an der es gearbeitet hat, und ein kurzer Code für die Art des Fehlschlags. file_not_found, permission_denied, timeout, rate_limit, token_limit, syntax_error oder unknown, wenn der Fehlschlag echt ist, aber nichts ihn erkennt.

Das ist der gesamte Datensatz. Nicht der Befehl. Nicht die Fehlermeldung. Nicht die Datei. Eine Zählung und ein Code, verknüpft mit einem Pfad. In einem Cloud-Workspace werden diese Zählungen und Codes zusammen mit dem Workspace in Pathrule Cloud gespeichert.

Der Fehlschlag wird beobachtet, nicht gemeldet. Der Tool-Hook von Pathrule überwacht den Aufruf selbst, die Zählung hängt also nicht davon ab, dass der Assistent seinen eigenen Fehler bemerkt, sich an eine Session erinnert oder hinterher irgendetwas aufruft. Ein Assistent, der still scheitert und einfach weitermacht, wird genauso erfasst wie einer, der es ankündigt. Wie lange der Aufruf gedauert hat, gehört zur selben Beobachtung, und genau das macht es möglich, einen hängengebliebenen Befehl von einem abgelehnten zu unterscheiden. Das gilt für Clients, in denen Pathrule Tool-Hooks hat: Claude Code, Codex, Cursor und GitHub Copilot. Windsurf hat keine Pathrule-Hooks, seine Tool-Aufrufe werden daher nicht auf diese Weise beobachtet.

Der Pfad wird zuerst in eine Form relativ zum Workspace normalisiert, und das ist wichtiger, als es klingt. Ein absoluter Pfad auf einem Laptop lautet /Users/<name>/…, und dieser Name hat in geteiltem Wissen nichts verloren. Relative Pfade sorgen außerdem dafür, dass dieselbe Datei teamweit korrekt gruppiert wird, statt einmal pro Rechner.

Wofür es genutzt wird

Ein Bild davon, wo die Arbeit hängen bleibt. Fehlschläge werden mit der Zeit nach Datei, Tool und Code gruppiert. Heraus kommt eher eine kurze Liste als ein Diagramm: die Dateien, in denen ein Assistent am häufigsten scheitert, und auf welche Weise. Eine Datei, die immer wieder unter file_not_found auftaucht, ist meist ein veralteter Pfad irgendwo in deinen eigenen Anweisungen. Eine unter syntax_error ist meist eine Datei, die tatsächlich umständlich zu bearbeiten ist. Eine unter permission_denied ist meist ein Setup-Problem, das du einmal beheben kannst.

Retrieval-Lernen. Hat ein Turn Wissen von Pathrule erhalten und ist trotzdem auf Fehlschläge gestoßen, bekommt dieses Wissen ein negatives Signal. Manche Arten von Fehlschlägen wiegen dabei schwerer als ein gewöhnlicher Fehlgriff, weil sie meist bedeuten, dass die Anleitung den Assistenten an eine Stelle geschickt hat, an die er nicht gelangen konnte. Das Signal fließt in den Kreislauf ein, der in wie Retrieval das richtige Wissen findet beschrieben ist. Wissen, das immer wieder in Turns auftaucht, die schiefgehen, wird nach und nach seltener ausgewählt, ohne dass jemand es prüfen muss.

Was das Signal nicht sehen kann

Dieser Teil hängt davon ab, welchen Assistenten du nutzt, und er ist nicht einheitlich.

Datei-Tools melden Fehlschläge sauber. Ein fehlgeschlagenes Lesen, Bearbeiten oder Schreiben kommt mit seiner Meldung an, wird klassifiziert und landet bei der richtigen Datei. Das ist der Fall, auf den es ankommt, denn erst ein Dateipfad macht eine Zählung umsetzbar.

Shell-Befehle tun das oft nicht. Manche Assistenten melden überhaupt keinen Exit-Code, sodass ein fehlgeschlagener und ein erfolgreicher Befehl identisch aussehen. Pathrule leitet keinen Fehlschlag aus dem Ausgabetext ab: Ein Suchergebnis kann völlig legitim die Worte „no such file or directory“ enthalten, und ein falscher Fehlschlag an einer Datei ist schlimmer als ein fehlender. Meldet der Assistent keinen Fehlschlag, wird nichts erfasst, und meldet er einen, den keine Regel erkennt, lautet der Code unknown statt einer Vermutung.

Was es nicht tut

Das Erfassen eines Fehlschlags blockiert keinen Tool-Aufruf und erscheint nicht im Kontext des Assistenten. Ein Fehlschlag ist eine Tatsache über deine Codebasis, die im Nachhinein erfasst wird. Er ändert nichts daran, was der Assistent tun darf, und eine Datei mit schlechter Bilanz wird nicht als gesperrt behandelt. Nichts davon ist eine Bewertung, die an einer Person hängt: Der Datensatz betrifft Dateien, nicht die Leute, die darin gearbeitet haben.