Was Pathrule berechnet

Du schreibst drei Arten von Dingen: Memories, Regeln und Skills. Dieser Teil ist bewusst, kuratiert und gehört dir.

Er ist aber auch die kleinere Hälfte. Das meiste, was die Schicht zu jedem Zeitpunkt enthält, hat niemand getippt. Es wird daraus abgeleitet, wie die Arbeit tatsächlich läuft, pro Workspace gehalten und neu berechnet, während die Arbeit weitergeht. Diese Seite benennt jeden abgeleiteten Teil, denn wer weiß, was da ist, versteht, warum sich das Retrieval so verhält, wie es sich verhält.

Eine Bedeutungsrepräsentation für jeden Eintrag

Jede Memory, jede Regel und jeder Skill existiert zusätzlich als berechnete Repräsentation dessen, was er bedeutet. Kommt eine Anfrage herein, wird sie in dieselbe Art von Repräsentation umgewandelt und direkt damit verglichen.

Dieser Teil sorgt dafür, dass Matching über Sprachgrenzen hinweg funktioniert. Ein Prompt auf Türkisch bringt eine auf Englisch geschriebene Memory zum Vorschein, wenn beide eine Idee teilen, aber kein einziges Wort. Eine Stichwortsuche kann das nicht, weil es keine gemeinsame Zeichenkette gibt, auf die sie matchen könnte. Der Vergleich findet in einem Raum statt, in dem „der Payment-Webhook versucht es zweimal erneut“ und „ödeme webhook'u iki kez deniyor“ nah beieinanderliegen.

Einträge werden neu repräsentiert, wenn sich ihr Inhalt ändert. Der Match spiegelt also wider, was der Eintrag jetzt aussagt, nicht was er bei seiner Erstellung aussagte.

Ein gemessenes Fenster um jede Auslieferung

Wenn Pathrule Wissen für einen Turn ausliefert, legt es einen Datensatz zu dieser Auslieferung an. Er hält fest, welche Einträge gesendet wurden, auf welchem Pfad und für welche Art von Intention.

Der Turn meldet anschließend in dasselbe Fenster zurück:

• welche der ausgelieferten Einträge der Assistent tatsächlich herangezogen hat, im Unterschied dazu, sie bloß zu empfangen
• wie viele Tool-Aufrufe der Turn brauchte und wie viele davon fehlschlugen
• welche Dateien bearbeitet wurden, relativ zum Workspace angegeben
• wie sich die Fehler aufschlüsseln, als kurze Codes statt als Fehlertext

Dieses Fenster ist das Rohmaterial für alles, was darunter folgt. Es ist auch der Grund, warum Pathrule einen gut gelaufenen Turn von einem schlecht gelaufenen unterscheiden kann, ohne dass irgendjemand etwas bewertet.

Gelernte Gewichte, pro Art von Arbeit

Fenster sammeln sich an. Mit der Zeit trägt jeder Eintrag einen Stellenwert für jede Art von Arbeit, in die er ausgeliefert wurde, und dieser Stellenwert bewegt sich mit der Evidenz: nach oben, wenn der Eintrag bei sauber verlaufener Arbeit herangezogen wurde, nach unten, wenn er in einen Turn ausgeliefert wurde, der sich schwertat.

Die Folge: Die Priorisierung ist nicht eine einzelne Zahl pro Eintrag. Dieselbe Memory kann für eine Migration hohe und für eine kleine UI-Anpassung niedrige Priorität haben, weil das unterschiedliche Arten von Arbeit sind und die Evidenz sich unterscheidet. Ein einzelnes „importance“-Feld in einer Datei kann das nicht ausdrücken, und wer eines von Hand pflegt, müsste raten.

Das Lernen ist bewusst konservativ. Ein uneindeutiges Ergebnis lehrt nichts, statt das Falsche zu lehren, ein einzelner klarer Fehlgriff senkt den Stellenwert, statt die Historie zu löschen, und der Einfluss lässt nach, wenn sich der Code wegbewegt. Wie Retrieval das richtige Wissen findet beschreibt dieses Verhalten im Detail.

Ein Graph von Dateien, die sich gemeinsam ändern

Aus den Pfaden, die Turns melden, baut Pathrule ein Bild davon auf, welche Dateien dein Team gewohnheitsmäßig im selben Arbeitsschritt ändert. Wissen, das an einer dieser Dateien hängt, kann dann eine Session erreichen, die an ihrer Nachbardatei arbeitet.

Niemand deklariert diese Beziehungen, und keine Datei wird geöffnet, um sie zu finden. Sie ergeben sich aus protokollierter Arbeit, haben eine Rauschschwelle, damit ein einzelner Zufall nicht zählt, und verfallen, wenn die Paarung nicht mehr vorkommt. In einem Cloud-Workspace bekommt der Graph außerdem einen Vorsprung: Wenn ein Agent zum ersten Mal nach tiefem Kontext fragt, wird er aus den Dateipfaden der jüngeren Git-Historie vorbefüllt und ist damit nützlich, bevor dein Team viel Arbeit protokolliert hat. Siehe Dateien, die sich gemeinsam ändern.

Eine Friction-Map

Fehler werden zu einem Tripel gruppiert: die Art des Tools, die Datei und ein kurzer Code dafür, wie es fehlschlug. Wochenweise gruppiert ergibt das ein Bild davon, wo ein Assistent in deiner Codebasis immer wieder hängen bleibt und wie. Es fließt als negatives Signal in die Priorisierung ein, wenn ein Turn, der Wissen erhalten hat, trotzdem in Schwierigkeiten geriet. Siehe Dateien, die einen Assistenten ausbremsen.

Ein Maß dafür, ob das Routing stimmte

Jeder Prompt bekommt außerdem eine Route: die Pfade, in denen die Arbeit am wahrscheinlichsten liegt, benannt, bevor der Assistent irgendetwas öffnet. Pathrule hält dann fest, ob der Assistent dorthin gegangen ist. Über ein rollierendes Zeitfenster wird daraus eine einzige Trefferquote, zusammen mit der Information, wie viel Arbeit mit Datei-Tools eine geroutete Session im Vergleich zu einer nie gerouteten braucht.

Es ist die eine Zahl, die zeigt, ob der Verweis auf einen Pfad tatsächlich hilft und nicht nur hilfreich klingt, und sie ist der Grund, warum sich das Routing anhand von Evidenz statt nach Geschmack abstimmen lässt.

Jede Ebene meldet, ob sie noch Daten erhält

Jede der oben beschriebenen abgeleiteten Ebenen hängt davon ab, dass Arbeit in sie hineinfließt, und eine Ebene, die nichts mehr erhält, liefert nichts zurück. Das sieht genauso aus wie eine Ebene, die nichts zu melden hat. Beide Fälle verlangen gegensätzliche Reaktionen, deshalb lässt Pathrule sie nicht gleich aussehen.

Jede Ebene wird regelmäßig gefragt, wann sie zuletzt Daten erhalten hat, und die Antwort wird als einer von drei Zuständen festgehalten: aktuell, in letzter Zeit nichts erhalten oder nie mit Daten versorgt. Dieselbe Prüfung bemerkt Turns, die von einem Client kommen, der so alt ist, dass er einen Teil des Datensatzes noch nicht kennt. Ein lohnendes Update erscheint so als benannte Anzahl statt als Ergebnisse, die unbemerkt schlechter geworden sind.

Deshalb ist eine abgeleitete Ebene, die verstummt, ein gemeldeter Zustand mit Datum und nicht etwas, das Monate später jemandem auffällt, der sich fragt, warum ein Ergebnis schlechter geworden ist.

Episoden und Einschätzungen zur Aktualität

Zwei weitere abgeleitete Ebenen bauen auf derselben Aktivität auf.

Arbeitsepisoden fügen zusammengehörige Turns zur Geschichte zusammen, wie etwas gelöst wurde. So hat „wie haben wir das letztes Mal gemacht“ eine Antwort, die nicht von der Erinnerung einer Person abhängt. Siehe Wie haben wir das beim letzten Mal gelöst.

Einschätzungen zur Aktualität vergleichen, was ein Eintrag behauptet, mit der Richtung, in die sich der Code seitdem entwickelt hat, und bringen die Einträge, die überholt wirken, als vorgeschlagene Änderungen ein, statt ihre Priorität stillschweigend zu senken. Siehe Vorschläge und Selbstprüfung.

Persönliche Präferenzen, auf deinem Rechner

Eine Ebene beginnt bei dir statt bei protokollierter Arbeit. Wenn du Pathrule sagst, wie du gern arbeitest, zum Beispiel pathrule me teach "I prefer incremental refactors", macht das optionale On-Device-Modell aus dem Satz eine kurze, abgegrenzte Präferenz. Sie wird auf deinem Rechner gespeichert, nicht hochgeladen, und dort an deine Agents ausgeliefert, wo sie zutrifft.

Du behältst die Kontrolle darüber: pathrule me list zeigt, was in Gebrauch ist, pathrule me explain zeigt, woher eine Präferenz stammt, pathrule me scope beschränkt sie auf einen Workspace oder lässt sie workspaceübergreifend gelten, pathrule me forget beendet ihre Verwendung, und pathrule me context zeigt vorab, was ein Agent für eine Aufgabe erhalten würde. Siehe User Intelligence.

Woraus nichts davon entsteht

Nicht aus dem Inhalt deines Quellcodes. Der Quellcode des Repositorys wird nicht automatisch hochgeladen. Jede oben beschriebene abgeleitete Ebene entsteht aus dem, was dein Team bewusst aufgeschrieben hat, und dem, was die Arbeit über sich selbst gemeldet hat, und es werden weder Diffs noch Commit-Nachrichten gespeichert.

Zwei Dinge werden aus deinem Checkout gelesen, beide nur in einem Cloud-Workspace und beide beim ersten Mal, wenn ein Agent nach tiefem Kontext fragt:

• Dateipfade aus der jüngeren Git-Historie, um herauszufinden, welche Dateien im selben Commit geändert wurden. Sehr große Commits, meist Refactorings oder Umbenennungen, werden übersprungen. Die resultierenden Dateipfad-Paare werden im Workspace als Ausgangspunkt des Co-Change-Graphen gespeichert. Commit-Nachrichten, Autoren und Diffs werden nicht gelesen.
• Dateinamen nahe der Spitze des Ordnerbaums, um anhand von Konfigurationsdateien die eingesetzten Technologien zu erkennen, etwa ein Setup mit TypeScript, Vite, Docker oder GitHub Actions. Jede erkannte Technologie wird zu einer kurzen Memory im Workspace-Root, angelegt ohne Rückfrage. Es ist eine gewöhnliche Memory, die du bearbeiten oder löschen kannst.

Solange die eigene Historie des Workspaces noch dünn ist, nennt dieselbe tiefe Antwort außerdem die Ordner der obersten Ebene des Projekts und die Dateien, die in der jüngeren Git-Historie am häufigsten geändert wurden. Diese werden aus deinem Checkout gelesen und für diese Antwort an den Agent übergeben, aber nicht von Pathrule gespeichert.

Ein lokaler Workspace, der ohne Account auf deinem Rechner liegt, macht nichts davon: Sein Co-Change-Graph entsteht allein aus protokollierter Arbeit.

Zwei weitere Dinge verlassen im Cloud-Modus deinen Rechner, und beide werden hier genannt:

• Der Anfang jedes Prompts. Der erste Teil des Prompts, ungefähr die ersten 1.000 Zeichen, wird an Pathrule Cloud gesendet, um Wissen dafür zu priorisieren.
• Ein Projekt-Snapshot, wenn du oder dein Agent pathrule snapshot ausführt. Er lädt den Dateibaum, Manifeste, kurze Auszüge aus der Dokumentation und aktuelle Git-Metadaten hoch. Er läuft nur, wenn er aufgerufen wird.

Der Projekt-Scan ist ein separater Schritt, den du selbst startest, indem du deinen Agent bittest, Pathrule für das Projekt einzurichten. Dein Agent liest das Projekt, um Memories, Regeln und Skills vorzuschlagen, und gespeichert wird nur, was du freigibst.

Unabhängig davon kann eine angemeldete, verwaltete CLI anonyme Nutzungstelemetrie erst dann senden, wenn du mit pathrule telemetry enable zustimmst. Sie enthält keinen Code, keine Pfade, Prompts, kein Wissen, keine Dateinamen, E-Mail-Adressen oder Account-IDs. pathrule telemetry disable, NO_TELEMETRY=1 und DO_NOT_TRACK=1 halten sie ausgeschaltet.

Dateipfade werden in eine workspace-relative Form normalisiert, bevor irgendetwas gespeichert wird, sodass auch nichts Rechnerspezifisches übertragen wird.

Warum dieselben Dateien in einem Ordner nicht dasselbe sind

Du könntest dieselben Memories, Regeln und Skills in ein Verzeichnis legen und einen Assistenten darauf verweisen. Teams machen das. Was dieses Verzeichnis nicht kann, ist alles auf dieser Seite.

Es weiß nicht, was im letzten Turn ausgeliefert wurde, also kann es nicht erkennen, was geholfen hat. Es hat keine Repräsentation von Bedeutung, also findet eine anders formulierte Frage nichts. Es weiß nicht, welche Dateien sich gemeinsam ändern, also erreicht Wissen, das an einer Datei festgehalten wurde, nie ihre Nachbardatei. Es kann einen Aufgabentyp nicht von einem anderen unterscheiden, also hat alles für alles dieselbe Priorität. Und es wächst: Jeder neue Eintrag macht jeden künftigen Turn schwerer, weil ein Verzeichnis keine Möglichkeit hat, nur die wenigen zu senden, die zählen.

Die geschriebenen Einträge sind der Teil, den du kontrollierst. Die abgeleitete Schicht macht daraus die richtigen wenigen für diesen Turn, und sie ist der Grund, warum die Antwort besser wird, während die Arbeit weitergeht, statt genau so gut zu bleiben wie an dem Tag, an dem sie geschrieben wurde.