Dateien, die sich gemeinsam ändern

Manche Dateien gibt es nur im Doppelpack. Eine Route und ihr Validator. Eine Migration und der Typ, der sie abbildet. Eine Komponente und die Token-Datei, die sie einliest. Aufgeschrieben wird das nirgends, und an der Ordnerstruktur sieht man es selten, aber nach ein paar Monaten weiß es jeder im Team.

Pathrule lernt es aus der Arbeit selbst. Wenn deine Agents protokollieren, was sie getan haben, enthält jeder Eintrag die Pfade, die dabei berührt wurden. Tauchen zwei Pfade immer wieder im selben Arbeitsschritt auf, hält Pathrule fest, dass sie sich gemeinsam ändern. In einem Cloud-Workspace bekommt es zusätzlich einen Vorsprung aus deiner Git-Historie, sodass das Signal schon in der ersten Woche nützt und nicht erst nach ein paar Monaten.

Was es für das Retrieval bringt

Pfadbezug und bedeutungsbasiertes Matching gehen beide von der Stelle aus, an der du gerade bist. Co-Change ergänzt die Dateien daneben.

Wenn der Assistent in /apps/api/payments/refund.ts arbeitet, berücksichtigt das Retrieval bereits, was an diesen Pfad gebunden ist und was zur Absicht passt. Durch Co-Change kann zusätzlich Wissen nach oben rücken, das an den Pfaden hängt, die üblicherweise mit diesem zusammen geändert werden. So kann eine Regel zum Ledger-Writer eine Session erreichen, in der das Ledger nie erwähnt wurde, weil Refunds und Ledger in dieser Codebasis schon immer gemeinsam bearbeitet wurden.

Am meisten zählt das bei Wissen, das niemand an zwei Stellen hinterlegt hätte. Eine Entscheidung, die einmal festgehalten wurde, an der Datei, an der sie getroffen wurde, kann trotzdem die Sessions erreichen, die sie brauchen.

Was der Assistent sieht

In einem Cloud-Workspace taucht Co-Change an drei Stellen in dem Kontext auf, den ein Agent bei Pathrule anfordert (über pathrule_get_context):

• Ein Hinweis. Wenn eine Nachbardatei besonders häufig zusammen mit der Datei geändert wird, die der Assistent vor sich hat, bekommt er genau eine Zeile dazu: Diese Datei ändert sich typischerweise zusammen mit dieser hier. Höchstens eine Zeile und nur bei einer starken Beziehung, damit sie als Warnung wirkt und nicht als Rauschen.
• Verwandte Pfade. Zusätzlich zum Kontext einer fokussierten oder tiefen Anfrage erhält der Assistent eine kurze Liste der Pfade, die sich üblicherweise mit dem ändern, an dem er gerade arbeitet.
• Gekoppelte Bereiche in einer tiefen Antwort. Fordert ein Agent Deep Context an, nennt die Antwort die Teile des Workspace, die mit dem betreffenden Bereich gekoppelt sind, samt den Titeln der dort hinterlegten Memories, Regeln und Skills.

Diese Daten werden separat abgerufen. Schlägt der Abruf fehl, kostet das also nicht den Turn mit den Memories und Regeln, die sie begleiten sollten.

Wie die Beziehung gemessen wird

Ein protokolliertes Paar zählt, wenn beide Pfade im selben protokollierten Arbeitsschritt vorkommen. Ein gemeinsamer Ordner reicht nicht, und auch nicht, dass verschiedene Aufgaben die Dateien am selben Tag geändert haben. Die Einheit ist ein Arbeitsschritt, denn genau das deutet auf eine echte Abhängigkeit hin und nicht auf einen Zufall der Ordnerstruktur.

Die Beziehungen werden aus der jüngeren Aktivität neu aufgebaut. Eine Beziehung, die nicht mehr auftritt, verblasst also, ohne dass jemand sie entfernen muss. Ein Refactoring, das zwei Dateien voneinander trennt, zeigt sich daran, dass ihre Beziehung in den folgenden Wochen schwächer wird.

Der Vorsprung aus der Git-Historie

Ein neuer Workspace hat noch keine protokollierte Arbeit, und genau dann wäre es am hilfreichsten, die Nachbarn zu kennen. Deshalb liest die lokale Runtime in einem Cloud-Workspace beim ersten Mal, wenn ein Agent Deep Context bei Pathrule anfordert, die Dateipfade der jüngeren Git-Historie. Dateien, die im selben Commit geändert wurden, bilden ein Paar. Sehr große Commits, meist Refactorings oder Umbenennungen, werden übersprungen, weil sie alles mit allem paaren würden. Die so entstandenen Dateipfadpaare werden zusammen mit der Häufigkeit jedes Paars im Workspace in Pathrule Cloud gespeichert.

Das passiert einmalig, ohne Rückfrage, und liest nichts außer Dateipfaden. Je mehr Arbeit dein Team protokolliert, desto stärker zählen die dabei erfassten Beziehungen und desto weniger der Git-Seed. Das Bild verschiebt sich also von der Frage, wie sich der Code früher verändert hat, zu der, wie dein Team heute daran arbeitet.

Woraus es besteht und woraus nicht

Das Signal basiert ausschließlich auf Dateipfaden: den Pfaden in der Arbeit, die deine Agents protokollieren, und in einem Cloud-Workspace den Dateipfaden der jüngeren Git-Historie. Pathrule liest weder deinen Quellcode noch deine Diffs oder Commit-Messages, um es zu berechnen, und außer dem Pfad fließt nichts über eine Datei ein.

Ein lokaler Workspace, der ohne Account genutzt wird, hat keinen Git-Seed. Seine Paare stammen allein aus protokollierter Arbeit, und das hat eine praktische Folge, die du kennen solltest: Er braucht eine echte Bearbeitungshistorie. Ein Workspace, in dem jede protokollierte Aufgabe genau eine Datei berührt, liefert überhaupt keine Paare, weil es nichts zu paaren gibt. In diesem Fall arbeitet das Retrieval weiter mit Pfadbezug und Bedeutung, und Co-Change trägt nichts bei, statt zu raten.

Außerdem gilt das Signal pro Workspace. Beziehungen, die in einem Workspace gelernt wurden, werden nicht auf einen anderen übertragen, und das Signal unterliegt derselben Zugriffskontrolle wie der Rest deines Wissens.

Wo du nachsehen kannst

Co-Change arbeitet im Hintergrund, es gibt also nichts zu konfigurieren und nichts einzuschalten. Es wird nützlicher, je mehr Arbeit dein Team protokolliert, und genau das macht auch Arbeitsepisoden und Vorschläge nützlicher. Wenn deine Agents ihre Arbeit protokollieren, sammelt sich das bereits an. Was Pathrule berechnet listet auf, was Pathrule aus einem Checkout liest.