unlazy: Gate-Ledger statt Vertrauen in Agenten-Behauptungen

Das Problem: Agenten melden Fertigstellung, nicht Nachweis

Ein Agent, der eine Aufgabe als erledigt markiert, liefert damit keine Prüfung. Die README beschreibt genau diese Lücke und setzt dagegen eine Reihenfolge: erst das Akzeptanz-Ledger schreiben, dann geprüfte Checks ausführen, dann zurückgegebene Arbeit erneut verifizieren, und am Ende nur berichten, was die Belege stützen. Das Zielpublikum sind nicht Endanwender, sondern Entwickler und Teams, die Agenten in laufende Repositories lassen und deren Abschlussmeldungen nicht ungeprüft übernehmen wollen. Der Fokus liegt auf substanzieller Arbeit, also Refactorings, Migrationen und Änderungen mit mehreren betroffenen Pfaden, nicht auf Einzeilern.

Der Gate-Vertrag und was ein Gate zur Laufzeit tut

Ein Gate ist ein Markdown-Block mit einer ID, einer Beschreibung und den Zeilen CHECK, EXPECT, optional CWD und EVIDENCE. CHECK enthält Shell-Code, EXPECT einen Text, der in der kombinierten Ausgabe vorkommen muss. Ein Gate gilt nur dann als bestanden, wenn der Prozess mit 0 endet und EXPECT in der kombinierten Ausgabe von stdout und stderr gefunden wird. Beide Größen, also die erfasste Ausgabe und die kanonische UTF-8-Zeichenkette für den Vergleich, müssen unter 1 MiB bleiben; der Checker kürzt eine zu große Vergleichszeichenkette nicht zu einem Erfolg. Die automatische Evidenz beginnt laut README mit einem versionierten SHA-256-Digest über die geparsten Zeilen CHECK, EXPECT und das rohe CWD, gefolgt von Exit-Code und Fingerprint der erfolgreichen Ausgabe, danach gekappte Umgebungsdetails. Ein Gate mit fehlender, gewöhnlicher Prosa-, Alt- oder fehlerhafter Evidenz gilt als veraltet und unerfüllt. Der Checker kann nur das Kommando-Orakel prüfen, das der Nutzer selbst erklärt. Er kann nicht ableiten, dass ein englischer Titel und ein beliebiges Shell-Kommando dasselbe bedeuten. Genau hier liegt die eigentliche Arbeit: Gates müssen das Artefakt lesen, nach bestandenen Assertions einen Erfolgsmarker ausgeben und bei Abwesenheitsprüfungen gegen eine bekannte Positivkontrolle testen.

Installation und die vier Betriebsmodi des Checkers

Die Installation läuft über die Skills-CLI mit npx skills add Leonxlnx/unlazy, optional mit -g für eine Nutzerinstallation oder --all für alle erkannten Agenten. Manuell klont man das Repository nach ~/.claude/skills/unlazy für Claude Code oder nach ~/.codex/skills/unlazy für die Codex CLI. Aufgerufen wird es als /unlazy, in Codex als $unlazy oder über natürliche Sprache. Der Checker und der optionale Hook brauchen Node 16 oder neuer und keine Laufzeit-Abhängigkeiten Dritter. Für eine Einzelaufgabe kopiert man templates/gates-leaf.md nach GATES.md, ersetzt alle Platzhalter und liest das Ledger zunächst ohne Ausführung mit node <pfad>/scripts/gate-check.mjs --status GATES.md. --status ist der einzige Modus, der immer nicht ausführend ist. Ein normaler Lauf auf einem neuen Orakel ohne exakte Freigabe gibt Kommando, Erwartung, Arbeitsverzeichnis, Shell und PATH aus, ohne etwas auszuführen. Die README warnt ausdrücklich davor, diesen Modus als dauerhaften Probelauf zu behandeln, denn sobald das exakte Orakel freigegeben ist, kann der normale Lauf es ausführen. Nach dem Lesen aller Kommandos und aufgerufenen Skripte folgt node <pfad>/scripts/gate-check.mjs --approve GATES.md. Mit --reverify laufen alle ausführbaren Gates erneut, auch die bereits als abgeschlossen markierten.

Shell, PATH und die Windows-Falle

Der Checker wählt die Shell in dieser Reihenfolge: zuerst --shell, dann die Umgebungsvariable UNLAZY_SHELL, dann die Plattformvorgabe von Node. Unter Unix ist das /bin/sh, unter Windows process.env.ComSpec mit Plattform-Fallback. Checks erben die Startumgebung einschließlich PATH. Das ist unter Windows relevant, weil ein aus Git Bash gestarteter Checker Unix-artige Werkzeuge sieht, die derselbe Checker aus PowerShell nicht sieht. --shell wechselt nur den Interpreter; grep, tail oder tr werden dadurch nicht installiert. Die README empfiehlt deshalb portable Beispiele, die repository-eigene Node-Skripte aufrufen. Für die Nachverifikation durch eine übergeordnete Instanz gilt: dieselbe deklarierte Shell und dieselbe Werkzeugkette verwenden. Eine Abweichung bei Shell oder PATH ist eine fehlgeschlagene Verifikation, die zu klären ist, und kein gültiger Beleg. Diese Regel ist unbequem, aber sie verhindert genau die Klasse von Fehlern, bei denen ein Gate auf dem Rechner des Autors grün ist und in der CI rot.

Die Freigabe ist Einwilligung, kein Sandkasten

Freigabedatensätze liegen standardmäßig unter ~/.unlazy/approved. Über UNLAZY_APPROVAL_DIR lässt sich ein anderes Verzeichnis wählen, dessen kanonisches Ziel aber außerhalb des geprüften Repositories liegen muss und dem Eigentümer privat gehören muss. Symlink-Speicher sowie verlinkte, ersetzte oder nicht private Datensätze werden abgelehnt. Ein Datensatz bindet das absolute Ledger und Gate, exakte CHECK- und EXPECT-Zeilen, aufgelöstes CWD und Shell, Timeout, Ausgabe- und Regex-Limits, Regex-Worker-Limits, Plattform und den vollständigen geerbten PATH. Wird eine gebundene Eingabe geändert, ist eine erneute Freigabe nötig. Die README formuliert die Grenze klar: Die Bindung erkennt strukturelle Drift, nicht Manipulation des Ledgers. Wer ein Ledger bearbeiten kann, kann kanonisch aussehende Evidenz fälschen. Ebenso wenig werden aufgerufene Skripte, Fixtures, Abhängigkeiten oder andere transitive Eingaben gehasht. --status und der Stop-Punkt prüfen die Definitionsbindung, inspizieren diese Artefakte aber nicht. Wer die Identität von Abhängigkeiten selbst gestalten will, findet in SECURITY.md ein begrenztes Digest-Muster.

Abbruch, Parser-Regeln und die Grenze der Nachverifikation

Der Parser lehnt Ledger ohne Gates, doppelte IDs, unvollständige ausführbare Gates, ungültige Erwartungen und einen Abbruch ohne Begründung oder mit unbekannter Gate-ID ab. Eingezäunte Beispiele werden ignoriert, CRLF oder LF beim Aktualisieren beibehalten, eine fehlende Evidenzzeile wird eingefügt. Ein gültiger Abbruch ist terminale Übergabe und kein Erfolg: Der Checker endet mit Exit-Code 1 und der Meldung HANDOFF REQUIRED, der Stop-Punkt erlaubt den Ausstieg und meldet die qualifizierten IDs. Ein wichtiger Punkt, den die README betont: Alte Evidenz ist keine erneute Ausführung. Die übergeordnete Verifikation muss --reverify verwenden, sonst bleibt die Prüfung auf dem Stand des letzten Laufs. Das ist die praktische Schwachstelle des Verfahrens, wenn zwischen zwei Läufen Abhängigkeiten, Fixtures oder Umgebungen wechseln. Wer das ignoriert, hält ein Ledger für aktuell, das nur die alte Umgebung beschreibt.

Wo unlazy das falsche Werkzeug ist

Das Skill passt nicht, wenn sich für ein Ergebnis kein reproduzierbares Kommando und kein Erfolgsmarker formulieren lässt. Die README sagt selbst, dass der Checker nur das erklärte Kommando-Orakel beweisen kann und dass englische Titel und beliebiger Shell-Code nicht automatisch dasselbe bedeuten. Bei Gestaltungsarbeit, bei explorativer Recherche oder bei Aufgaben, deren Ergebnis nur ein Mensch beurteilen kann, bleibt deshalb nur ein manuelles Gate mit menschlicher Evidenz; diese Gates bleiben kompatibel, tragen aber nicht dieselbe Beweislast. Ebenfalls ungeeignet ist es dort, wo keine Node-16-Laufzeit vorhanden ist oder wo Kommandos nicht ausgeführt werden dürfen. Die Freigabe ist ausdrücklich kein Sandkasten: Wer nicht bereit ist, jedes CHECK-Kommando vor der Freigabe zu lesen, sollte das Werkzeug nicht einsetzen, weil die Freigabe die Ausführung autorisiert und nicht einschränkt. Als Alternative bietet sich ein CI-Lauf mit einem Testframework wie node:test oder Vitest an. Der Unterschied liegt im Ansatz: unlazy ist ein Ledger mit Freigabebindung und Evidenz-Digest, das auch außerhalb einer Pipeline funktioniert, während ein Testframework die Prüfungen selbst ausführt und keine Akzeptanzliste mit Freigabedatensätzen führt. Wer ohnehin eine CI mit erzwungenen Checks betreibt, bekommt dort einen Teil desselben Schutzes ohne zusätzliche Ledger-Datei.

Wartung, Lizenz und was vor der Adoption zu klären ist

Der Quellstand zielt laut README auf Version 2.1.0 und ist dort nicht als getaggtes GitHub-Release ausgewiesen. Für eine unveränderliche Installation empfiehlt die README, einen exakten Commit zu pinnen; das Änderungsset steht in CHANGELOG.md. Das ist ein Hinweis auf die Reife: Es gibt keine abrufbaren Releases, also auch keine Versionsnummer, an der man sich ohne Commit-Hash festhalten kann. Die Lizenz ist MIT. Das erlaubt Weitergabe und Änderung unter Beibehaltung des Lizenztexts, und es schließt eine Gewährleistung aus. Wer das Skill in ein eigenes Produkt einbettet, muss den MIT-Hinweis mitführen; das ist eine technische Einordnung und keine Rechtsberatung. Der Wartungsaufwand liegt weniger im Skill selbst als in den Gates: Jede Änderung an einem gebundenen CHECK, EXPECT oder CWD erfordert eine neue Freigabe, und jede Änderung an aufgerufenen Skripten erfordert eine erneute Inspektion und --reverify. Vor der Adoption sollte man deshalb klären, ob das Team diese Nacharbeit akzeptiert und ob die Gates im eigenen Shell- und PATH-Kontext laufen. Der Statuslauf mit --status und der Linter scripts/gate-lint.mjs, gegebenenfalls mit --strict, sind die ersten konkreten Schritte, um das zu prüfen.

Redaktionelles Fazit

Wer Agentenarbeit mit ausführbaren Prüfungen belegen muss und Node 16 oder neuer ohnehin im Projekt hat, kann unlazy als Ledger-Werkzeug einsetzen. Wer keine reproduzierbaren Kommandos für seine Ergebnisse formulieren kann, für den ist das Verfahren ungeeignet, weil das Skill nur den selbst erklärten Kommando-Orakel prüfen kann. Vor dem ersten Einsatz sollte man mit node <pfad>/scripts/gate-check.mjs --status GATES.md das Ledger ohne Ausführung lesen und mit scripts/gate-lint.mjs prüfen, ob die Gates mechanisch tragen; erst danach ist die Zeile --approve sinnvoll.

Offizielle Quellen

1. Issues
2. Leonxlnx/unlazy on GitHub
3. License: MIT
4. README