GateGuard — „Fact-Forcing“-Prüfungsschritt vor der Bearbeitung

Ein „PreToolUse“-Hook, der Claude dazu zwingt, vor der Bearbeitung Nachforschungen anzustellen. Anstelle einer Selbsteinschätzung („Bist du dir sicher?“) verlangt er konkrete Fakten. Der Akt der Nachforschung schafft ein Bewusstsein, das die Selbsteinschätzung nie hervorgebracht hat.

Wann aktivieren?

• Bei der Arbeit an jeder Codebasis, in der Dateibearbeitungen mehrere Module betreffen
• Projekte mit Datendateien, die bestimmte Schemata oder Datumsformate aufweisen
• Teams, in denen KI-generierter Code mit bestehenden Mustern übereinstimmen muss
• Jeder Workflow, in dem Claude dazu neigt, zu raten, anstatt Nachforschungen anzustellen

Kernkonzept

Die Selbstbewertung von LLMs funktioniert nicht. Fragt man: „Hast du gegen irgendwelche Richtlinien verstoßen?“, lautet die Antwort immer „nein“. Dies wurde experimentell bestätigt.

Die Frage „Liste alle Dateien auf, die dieses Modul importieren“ zwingt das LLM jedoch dazu, Grep und Read auszuführen. Die Untersuchung selbst schafft einen Kontext, der die Ausgabe verändert.

Dreistufiges Filterverfahren:

1. DENY  — block the first Edit/Write/Bash attempt
2. FORCE — tell the model exactly which facts to gather
3. ALLOW — permit retry after facts are presented

Kein Mitbewerber führt alle drei Schritte durch. Die meisten hören bei der Ablehnung auf.

Beweise

Zwei unabhängige A/B-Tests, identische Agenten, gleiche Aufgabe:

Beide Tools erzeugen Code, der läuft und Tests besteht. Der Unterschied liegt in der Tiefe des Designs.

Gate-Typen

Edit-/MultiEdit-Gate (erste Bearbeitung pro Datei)

MultiEdit wird identisch behandelt – jede Datei im Stapel wird einzeln geprüft.

Before editing {file_path}, present these facts:

1. List ALL files that import/require this file (use Grep)
2. List the public functions/classes affected by this change
3. If this file reads/writes data files, show field names, structure,
   and date format (use redacted or synthetic values, not raw production data)
4. Quote the user's current instruction verbatim

Schreib-Gate (erste Erstellung einer neuen Datei)

Before creating {file_path}, present these facts:

1. Name the file(s) and line(s) that will call this new file
2. Confirm no existing file serves the same purpose (use Glob)
3. If this file reads/writes data files, show field names, structure,
   and date format (use redacted or synthetic values, not raw production data)
4. Quote the user's current instruction verbatim

Destruktives Bash-Gate (jeder destruktive Befehl)

Ausgelöst durch: rm -rf, git reset --hard, git push --force, drop table, usw.

1. List all files/data this command will modify or delete
2. Write a one-line rollback procedure
3. Quote the user's current instruction verbatim

Routine-Bash-Gate (einmal pro Sitzung)

1. The current user request in one sentence
2. What this specific command verifies or produces

Schnellstart

Option A: Verwende den ECC-Hook (keine Installation)

Der Hook unter scripts/hooks/gateguard-fact-force.js ist in diesem Plugin enthalten. Aktivieren Sie ihn über hooks.json.

Falls „GateGuard“ Einrichtungs- oder Reparaturarbeiten blockiert, starten Sie die Sitzung mit ECC_GATEGUARD=off. Für die Steuerung auf Hook-Ebene verwenden Sie weiterhin ECC_DISABLED_HOOKS mit der Hook-ID „GateGuard“.

In langen Sitzungen geben nur die ersten GATEGUARD_FACT_FORCE_FULL_DENIALS „fact-force“-Ablehnungen (Standard: 3) geben den vollständigen Vier-Fakten-Block aus; spätere Ablehnungen werden auf eine einzige Zeile mit der Ablehnungsnummer verkürzt, damit sich nahezu identische Blöcke nicht im Kontextfenster ansammeln und Modellwiederholungsschleifen verstärken (#2142). Ein erneuter Versuch mit derselben Datei oder demselben Befehl nach der Darstellung von Fakten löst das Gate niemals erneut aus.

Option B: Vollständiges Paket mit Konfiguration

pip install gateguard-ai
gateguard init

Dies fügt .gateguard.yml für die projektbezogene Konfiguration (benutzerdefinierte Meldungen, zu ignorierende Pfade, Gate-Umschaltungen).

Anti-Muster

• Verwenden Sie stattdessen keine Selbstauswertung. Auf die Frage „Sind Sie sicher?“ lautet die Antwort immer „Ja“. Dies ist experimentell belegt.
• Überspringen Sie nicht die Überprüfung des Datenschemas. Beide A/B-Test-Agenten gingen von ISO-8601-Datumsangaben aus, obwohl in den tatsächlichen Daten %Y/%m/%d %H:%M. Die Überprüfung der Datenstruktur (mit maskierten Werten) verhindert diese gesamte Klasse von Fehlern.
• Führen Sie nicht bei jedem einzelnen Bash-Befehl eine Gate-Prüfung durch. Routinemäßige Bash-Gates erfolgen einmal pro Sitzung. Destruktive Bash-Gates finden jedes Mal statt. Diese Ausgewogenheit vermeidet Verlangsamungen und erfasst gleichzeitig echte Risiken.

Bewährte Vorgehensweisen

• Lassen Sie die Sicherheitsabfrage auf natürliche Weise ablaufen. Versuchen Sie nicht, die Fragen der Sicherheitsabfrage vorwegzunehmen – erst die Untersuchung selbst verbessert die Qualität.
• Passen Sie die Gate-Meldungen an Ihren Fachbereich an. Wenn Ihr Projekt spezifische Konventionen hat, fügen Sie diese den Gate-Aufforderungen hinzu.
• Verwenden Sie .gateguard.yml , um Pfade wie .venv/, node_modules/, .git/.

Verwandte Fähigkeiten

• safety-guard – Sicherheitsprüfungen zur Laufzeit (ergänzend, keine Überschneidungen)
• code-reviewer — Überprüfung nach der Bearbeitung (die „GateGuard“-Prüfung erfolgt vor der Bearbeitung)