Wie Pathrule harte Aussagen belegt

Der technische Maßstab von Pathrule ist einfach: Eine Produktaussage braucht eine begrenzte Eingabe, ein definiertes Verhalten, wenn Evidenz fehlt, und ein Ergebnis, das sich unabhängig testen lässt.

Diese Seite sammelt diese Verträge dafür, wie Wissen in Pathrule hineinkommt, wie es ausgewählt und wie es ausgeliefert wird. Eine Remote MCP-Verbindung hat eine andere Auslieferungsgrenze: Sie installiert keine Hooks, Wissen kommt also an, wenn der Agent die Tools von Pathrule aufruft.

Wissensqualität hat mehrere Schranken

Pathrule packt nicht jede Markdown-Datei in jeden Prompt. Wissen durchläuft unabhängige Kontrollen:

1. Selektive Erkennung. Wenn dein Agent den Projekt-Scan ausführt, werden aktive Instruktionsdateien, ihre Importkette, Tool-Regeln und Entscheidungsdokumente von allgemeiner Dokumentation unterschieden. Breite Dokumentation wird zur Prüfung angeboten, statt standardmäßig als aktive Instruktion importiert zu werden.

2. Prüfung vor dem Speichern, mit benannten Ausnahmen. Abgeleitetes Wissen wartet auf einen Menschen: Kandidaten aus dem Projekt-Scan werden nur nach Freigabe übernommen, Team Intelligence-Vorschläge erreichen Agents erst, wenn ein Mensch sie bestätigt, Korrekturen an veraltetem Wissen ändern nichts, bis eine Refresh-Aufgabe erledigt ist, und eine ausführbare Bedingung, die ein Agent für eine Regel vorschlägt, wird als Vorschlag gespeichert und erst durchgesetzt, wenn ein Mensch sie freigibt. Eigene Schreibvorgänge eines Assistenten laufen über die Schreib-Tools von Pathrule, werden als vom Assistenten stammend markiert, versioniert und sind umkehrbar. Erkenntnisse aus dem Projektlernen werden ohne Prüfschritt geteilt, als zu prüfende Hinweise und nie als Regeln. Zwei Dinge werden ohne Rückfrage geschrieben, nur in einem Cloud-Workspace und nur beim ersten Mal, wenn ein Agent nach tiefem Kontext fragt: die aus der jüngeren Git-Historie gelesenen Dateipfadpaare, die vorbelegen, welche Dateien sich gemeinsam ändern, und kurze Technologie-Memories im Workspace-Stammverzeichnis, die anhand von Dateinamen erkannt werden. Für keins von beiden werden Dateiinhalte, Diffs oder Commit-Nachrichten gelesen. Siehe Wie sich Wissen aufbaut.

3. Pfadzuständigkeit. Ein Eintrag gehört zum engsten Workspace-Pfad, der für ihn zuständig ist. Arbeit außerhalb dieses Pfads bekommt ihn nicht, nur weil er im selben Repository liegt.

4. Relevanz für die Anfrage. Ein Eintrag muss sich trotzdem für die aktuelle Anfrage qualifizieren, und zwar jedes Mal. Eignung und Reihenfolge werden getrennt entschieden und tauschen nie die Rollen: Das eine entscheidet, ob ein Eintrag geeignet ist, das andere entscheidet über die Reihenfolge unter den bereits geeigneten. Lernen beeinflusst nur die Reihenfolge. Es kann eine bewährte Memory vom vierten auf den ersten Platz holen; einen ungeeigneten Eintrag bringt es nie in die Auslieferung. Auch die Menge ist begrenzt: Die Auslieferung passt in ein Budget pro Prompt, die ausgelieferte Menge wächst also nicht mit der Größe der Wissensbasis.

   Deshalb ist diszipliniertes Schreiben keine Voraussetzung für einen ruhigen Prompt. Ein vager oder schlecht geschriebener Eintrag wird nicht zu Rauschen; er qualifiziert sich schlicht nie für eine Anfrage, mit der er nichts zu tun hat. Der sichtbare Preis einer schwachen Memory ist, dass sie nicht auftaucht.

5. Gemessene Auslieferung und Nutzung. Pathrule erfasst, was es ausgeliefert und was der Assistent herangezogen hat. Abgeleitete Schichten melden, wann sie zuletzt Daten erhalten haben, sodass sich ein ruhiges System von einem getrennten unterscheiden lässt.

   Dieselbe Disziplin gilt für die Frage, warum ein Eintrag nicht ausgeliefert wurde. „Nichts qualifizierte sich“, „der Priorisierungsaufruf hat das Zeitlimit überschritten“, „die Antwort war fehlerhaft“ und „es gab nichts zu priorisieren“ werden als unterschiedliche Ergebnisse erfasst statt mit einem einzigen Wort, weil es verschiedene Situationen mit verschiedenen Lösungen sind. Ein langsamer Moment wird auch als solcher gemeldet und so nie mit einer leeren Wissensbasis verwechselt.

   Wenn relevantes Wissen nicht ins Budget passt oder sein Inhalt nicht bereits auf dem Rechner liegt, wird es per Titel angeboten statt verworfen, damit der Assistent es gezielt abrufen kann. Eine richtige Antwort zu verwerfen, nur weil sie ungünstig liegt, ist genau das Ergebnis, das hier vermieden werden soll.

6. Prüfbare Pflege. Wissen, das ein Agent als veraltet, vom Code widerlegt, doppelt oder unklar erkennt, wird als Refresh-Aufgabe zur Prüfung vorgelegt, und nichts wird geändert, bis diese Aufgabe erledigt ist. Schreibvorgänge sind versioniert, Konflikte explizit und Löschungen umkehrbar.

Diese Schranken machen aus geteiltem Wissen ein kleines, nachvollziehbares Betriebssystem für ein Repository. Sie sind der Grund, warum ein Projekt Entscheidungen ansammeln kann, ohne sein gesamtes Dokumentationsarchiv zum Standardkontext zu machen. Siehe Wie sich Wissen aufbaut und Vorschläge und Selbstprüfung.

Datierte Verifikation

Am 23. August 2026 liefen gezielte automatisierte Prüfungen für diese Verträge im Haupt-Repository des Pathrule-Produkts erfolgreich durch, darunter Wissenserkennung, Importreihenfolge und der Ausschluss verrauschter Quellen.

Der öffentliche Benchmark zur Kontextauslieferung ist separat reproduzierbar unter github.com/pathrule/benchmarks. So messen wir veröffentlicht Methode, Rohdaten und gemischte Ergebnisse. Gemessene Ergebnisse beschreiben die Setups, auf denen sie gemessen wurden; sie sind keine Garantie für dein Repository.

Eine nützliche Bewertungsregel

Stell bei jeder Aussage von Pathrule drei Fragen:

1. Welche Evidenz fließt in die Entscheidung ein?
2. Was passiert, wenn diese Evidenz fehlt oder mehrdeutig ist?
3. Welches Ergebnis darf die Arbeit verändern oder blockieren?

Die obigen Verträge beantworten alle drei. Das ist der Unterschied zwischen einer Feature-Beschreibung und einer technischen Aussage.