Regeln als Leitplanken

Eine Regel in Pathrule ist keine Notiz, die der Assistent irgendwann später liest. Sie ist eine Leitplanke, die ankommt, bevor der Assistent handelt. Die meiste Dokumentation sagt dir erst nach dem Release, was schiefgelaufen ist. Eine Leitplanke kann die Änderung stoppen, bevor sie landet.

Diese Seite erklärt den Unterschied zwischen Kontext, der einen Turn informiert, und einer Regel, die einen Turn blockieren kann. Wie Hooks Kontext ausliefern, liest du zuerst unter So funktionieren Hooks nach. Hier geht es darum, was eine strikte Regel tut, sobald dieser Kontext bereitsteht.

Pull fragt nach. Push liefert.

Das alte Modell ist Pull. Der Assistent muss daran denken, nach deinen Konventionen zu fragen, ein Tool aufzurufen und das Ergebnis zu lesen, bevor er etwas bearbeitet. Vergisst er das, bearbeitet er blind, und du findest das Problem im Review.

Das Hook-Modell ist Push. Bei Claude Code und Codex kommt der Kontext ohne Nachfrage des Assistenten an, wenn du einen Prompt abschickst und unmittelbar bevor der Assistent ein Tool verwendet. Cursor und GitHub Copilot haben keinen Prompt-Submit-Hook, dort übernimmt der Session-Start-Hook den Bootstrap, und die Tool-Hooks liefern die Regeln für den betroffenen Pfad. So oder so liegen die Regeln für einen Pfad bereits vor dem Assistenten, wenn er gerade eine Datei schreiben will. Windsurf hat keine Hooks: Es liest die Regeldatei von Pathrule und fragt beim lokalen MCP-Server nach mehr, deshalb informieren Regeln unter Windsurf zwar, blockieren aber nicht.

Zwei Stufen: beratend und blockierend

Nicht jede Regel sollte den Assistenten unterbrechen. Pathrule behandelt Regeln auf zwei Stufen.

• Beratende Regeln laufen als Kontext mit. Sie erscheinen neben der Datei, die der Assistent gleich anfassen will, zusammen mit ihrer Priorität, damit der Assistent sie berücksichtigen kann. Sie stoppen nichts. Die meisten Regeln sind beratend, unabhängig von ihrer Priorität.
• Strikte Regeln können blockieren. Eine Regel wird strikt, wenn sie ein Blockiermuster trägt, das eine Person freigegeben hat: eine verbotene Form im Inhalt, etwa ein Import, ein Bezeichner, ein Klassenname oder eine CSS-Deklaration, ein verbotener Ablageort für eine Datei oder beides. Will der Assistent eine Datei auf eine Weise bearbeiten oder schreiben, die darauf passt, stoppt der Hook den Tool-Aufruf, bevor die Datei geschrieben wird, und gibt den Grund zurück. Der Assistent liest ihn und versucht es erneut, diesmal innerhalb der Vorgabe.

Priorität und Blockieren sind unabhängig voneinander. Die Priorität (hoch, mittel, niedrig) bestimmt, wie prominent eine Regel erscheint und welche Regeln es bei knappem Platz in die Auswahl schaffen. Über das Blockieren entscheidet sie nicht: Jede strikte Regel für den Pfad wird geprüft, egal welche Priorität sie hat.

Wie eine Regel strikt wird

Ein Assistent kann ein Blockiermuster nicht selbst scharf schalten.

1. Die Regel wird zuerst in Klartext formuliert, von dir oder von einem Assistenten, den du darum gebeten hast.
2. Ein Assistent kann über die MCP-Tools zum Schreiben und Aktualisieren von Regeln ein Blockiermuster dafür vorschlagen. Die bevorzugte Form nennt den verbotenen Text genau so, wie die Regel ihn schreibt, mit echten Beispielen, die erkannt werden müssen, und Beinahe-Treffern, die nicht erkannt werden dürfen. Pathrule baut daraus das Muster und testet es gegen beide Mengen. Schlägt eine davon fehl, wird der Vorschlag mit Begründung abgelehnt, statt ihn abzuschwächen.
3. Der Vorschlag wird mit der Regel gespeichert und nicht durchgesetzt.
4. Erst wenn eine Person ihn freigibt, beginnt der Hook zu blockieren, und die dafür formulierte Abhilfe wird zum „Do this instead“, das der Assistent sieht.

Eine Regel kann auch eine Pflichtprüfung tragen: einen Verifikationsbefehl, der erfolgreich durchgelaufen sein muss, bevor der Turn endet, etwa die Testsuite eines Pakets. Wie ein Blockiermuster wird sie vorgeschlagen und erst durchgesetzt, wenn eine Person sie freigibt. Nach der Freigabe hält der Hook bei Claude Code und Codex den Turn offen und nennt den genauen auszuführenden Befehl, bis dieser erfolgreich war.

Was der Assistent sieht

Eine blockierte Bearbeitung kommt mit dem Regelnamen, einer kurzen Vorschau der Regel, der freigegebenen Abhilfe und einem Verweis auf die vollständige Regel zurück. Für eine Regel namens „No direct database client in UI components“ sieht das so aus:

Pathrule blocked: "No direct database client in UI components"

UI components never import the database client. Data goes through the data layer hooks.

Do this instead: call the data layer hook for this resource.

Your edit matches this rule's forbidden pattern. Read the full rule via pathrule_read_rule(<id>) and retry without the violation.

Claude Code, Codex, Cursor und GitHub Copilot erhalten dies als Ablehnung des Tool-Aufrufs, jeweils im Hook-Format des Clients. Windsurf hat keine Hooks, dort wird also nichts blockiert. Blockiert werden Dateibearbeitungen und Schreibvorgänge, ein Shell-Befehl erhält die Regel weiterhin als Kontext.

Diese Trennung ist Absicht. Eine unkritische Bearbeitung zu blockieren, verschwendet den Turn des Assistenten und deine Zeit. Blockieren ist den Regeln vorbehalten, bei denen ein Verstoß eine echte Regression ist und jemand genau abgezeichnet hat, was als Verstoß gilt.

Vorher und nachher

Nimm eine Regel, die besagt, dass Secrets niemals in committete Dateien gehören, mit einem freigegebenen Blockiermuster für das Schlüsselformat deines Anbieters.

Dasselbe Muster gilt für jede Regel, für die ein Team in Produktion bereits bezahlt hat: eine Datenzugriffsrichtlinie, die nach Benutzer filtern muss, eine Migrationskonvention, eine generierte Datei, die nicht von Hand bearbeitet werden darf. Die Regel ist dann kein Kommentar mehr, von dem man hofft, dass der Assistent ihn gelesen hat, sondern eine Prüfung, die läuft, bevor die Bearbeitung landet. Ein Blockiermuster erkennt die Formen, für die es freigegeben wurde, es ergänzt also das Review, statt es zu ersetzen.

Dateinamen holen die passende Memory

Du musst nicht immer auf einen Tool-Aufruf warten. Nennt dein Prompt bei Claude Code und Codex eine Datei, auf die sich eine angehängte Memory bezieht, kann der Prompt-Hook den Inhalt dieser Memory einblenden, bevor der Assistent irgendetwas öffnet. Oft reicht es schon, die Datei zu nennen, an der du arbeitest, damit im ersten Turn der richtige Kontext vor dem Assistenten liegt. Passt mehr als eine Memory zum selben Dateinamen, zeigt der Hook die Kandidaten an, statt zu raten.

Bewusst offen fehlschlagend

Eine Leitplanke, die deinen Workflow lahmlegt, wenn sie selbst kaputtgeht, ist schlimmer als gar keine. Pathrule schlägt offen fehl. Kann der Hook eine Regel nicht auswerten, tritt ein Fehler auf oder läuft er in einen Timeout, blockiert er deine Arbeit nicht. Die Änderung geht durch. Die Durchsetzung ist ein Sicherheitsnetz, keine Schranke, hinter der du festhängen kannst.

Du behältst die Kontrolle. Wenn du Hooks irgendwann komplett abschalten willst, genügt dafür eine einzige Datei.

Prüf es selbst

Du musst das Verhalten nicht einfach glauben.

Welche Hooks dein KI-Client registriert hat, siehst du in seiner Einstellungsdatei. Für Claude Code registriert Pathrule seine Hooks im Projekt:

cat .claude/settings.json

Cursor verwendet .cursor/hooks.json, Codex verwendet .codex/hooks.json und GitHub Copilot verwendet .github/hooks/pathrule.json.

Um alle Pathrule-Hooks sofort abzuschalten (der Notschalter), legst du eine Datei an:

touch ~/.pathrule/kill-hooks

Der nächste Tool-Aufruf läuft dann ohne jede Beteiligung von Pathrule durch. Entferne die Datei, um die Hooks wieder einzuschalten:

rm ~/.pathrule/kill-hooks

Um zu bestätigen, dass eine Regel tatsächlich einem Pfad zugeordnet ist, führst du im Ordner pathrule rule list aus oder öffnest in deinem Editor die Pathrule-Kontextansicht des Assistenten. Die Regel erscheint mit ihrer Priorität, bevor der Assistent auf diesem Pfad handelt, und eine strikte Regel zeigt ihre Blockade, sobald zum ersten Mal eine Bearbeitung darauf passt.

Weiterlesen

• So funktionieren Hooks zur Auslieferung und zum Verhalten ohne Inhalte.
• Regeln schreiben dazu, wie du eine Regel verfasst, die es wert ist, durchgesetzt zu werden.
• MCP-Überblick zum ausführlichen Weg, den der Assistent nutzt, wenn der Hook nicht ausreicht.