7. Verifikationsloops — die Definition von „fertig” im System festschreiben

Dies ist Teil 7 der Alice Way-Serie. In Teil 6 Multi-Agent-Delegation erschien automatisierte Verifikation als Gate für delegierte Arbeit. Dieser Beitrag hebt diese Verifikation eine Ebene höher — ob die Arbeit direkt oder delegiert erledigt wurde, das System erzwingt einen Loop in dem Moment, in dem „fertig" den Mund des Betreibers verlassen soll.

0. Ein Verifikationsloop ist das System, das nachprüft, was der Geist für fertig hält

Der Moment, in dem sich Arbeit fertig anfühlt, ist der gefährlichste. Der Geist ist in die Erleichterung des „okay, das war's" gekippt und fehlende Verfahren fallen kaum auf. Lint nicht ausgeführt, Build gebrochen, Tests übersprungen — und „fertig" wird trotzdem getippt.

Der Verifikationsloop ist das Gerät, das diesen Moment kurz unterbricht. Kurz bevor „fertig" geschrieben wird, laufen lint · build · test · Sicherheits- · Diff-Prüfungen automatisch, und der Bericht kann nicht rausgehen, wenn sie nicht bestehen. Das System prüft nach, was der Geist für fertig hält.

Ich denke, was einen Verifikationsloop von einer Checkliste unterscheidet, ist genau das: Er feuert automatisch, nicht absichtlich — weil Verifikation, die bewusst aufgerufen werden muss, in Momenten der Erschöpfung oder des Zeitdrucks übersprungen wird, statt zuverlässig zu funktionieren. Ursprünglich hatte ich eine manuelle Checkliste; heute ist die automatische Auslösung das Entscheidende, da sie die kognitive Last des Erinnerns vollständig beseitigt.

Dieser Beitrag ist eine Aufzeichnung, welche sieben Schritte diesen Loop ausmachen, was das Auto-Fire auslöst und wie Umgehung gehandhabt wird.

Der Auto-Fire-Mechanismus ist das Anthropic Claude Code Hooks-System, bereits zitiert in Teil 5 — Hooks und Automatisierung. Dieser Beitrag ist die Aufzeichnung der Verifikationsschritte, die der Betreiber auf diesem Mechanismus aufgebaut hat.

1. Warum Auto-Fire erforderlich ist

Wenn der Betreiber Verifikation bewusst aufrufen muss — wird sie manchmal übersprungen. Übersprungene Verifikation akkumuliert sich — irgendwann bricht Prod. Wenn Überspringen ein kognitives Limit ist, muss die Erzwingung außerhalb der Kognition leben.

Das Dritte ist die Antwort. Verifikation vor dem Bericht erzwingen und das Versäumnis wird auf Systemebene blockiert. CI ist ein sekundäres Sicherheitsnetz, nicht die erste Linie.

2. Der 7-Schritte-Verifikationsloop

Was ich herausgearbeitet habe. Jeder Schritt hält sofort bei Fehler an und meldet eine klare Meldung.

2.1 Lint

Stil, ungenutzte Variablen, offensichtliche Fehler. Das Schnellste und Am-häufigsten-Erkannte. Zuerst ausführen — Fehler hier spart die Zeit späterer Schritte.

2.2 Typprüfung

TypeScript / mypy / andere statische Typ-Prüfer. Fängt tiefere Fehler, die Lint nicht kann.

2.3 Build

Bricht der tatsächliche Build. Stoppt Änderungen, die der Compiler nicht bestehen lässt, vor dem Merge.

2.4 Test

Unit-Tests + Integrationstests. Integrationstests treffen echte Ressourcen, keine gemockten — einmal bestanden gemockte Tests und eine Prod-Migration brach; dieser Vorfall setzte die Regel.

2.5 Sicherheitsprüfung

Secret-Hardcoding · SQL-Injection-Muster · Betreiber-Echtname-Leckage — grep nach Risiken. Eine 8-Punkte-Checkliste läuft bei jeder Änderung. Sofort anhalten bei jedem Treffer.

2.6 Diff-Review

Stimmen die geänderten Zeilen mit der Absicht des Betreibers überein? Hat sich etwas Unbeabsichtigtes eingeschlichen? Das letzte menschliche Augenlicht-Gate.

2.7 Report-Output-Prüfung

Trägt der Berichtstext selbst Leckagerisiko (Secrets · interne Bezeichner · Echtnamen)? Noch ein grep kurz bevor der Bericht gesendet wird.

Der „fertig"-Bericht kann nicht rausgehen, bis alle sieben bestanden haben. Jeder Fehler — der Bericht ist blockiert und der Betreiber bekommt eine einzeilige „Schritt X fehlgeschlagen"-Meldung.

3. Auto-Fire-Auslöser — wann läuft es

Bedingungen, unter denen der Verifikationsloop automatisch feuert.

3.1 Expliziter Auslöser — kurz vor der „fertig"-Formulierung

Genau dann, wenn der Betreiber versucht, „fertiggestellt" / „erledigt" / „bereit" oder Äquivalentes auszugeben, greift der Hook ein. Vor der Ausgabe, nicht danach — danach wäre zu spät.

3.2 Expliziter Auslöser — „PR bereit" / „mergebar"-Berichte

Meldungen wie „der PR ist bereit" feuern auch denselben Hook. Verifikation läuft nicht nachdem der PR rausgeht; sie läuft davor.

3.3 Expliziter Auslöser — „commit-bereit"-Berichte

„Bereit zum Commit" — dasselbe. Blockiert den Commit selbst nicht, erzwingt aber noch einmal Verifikation, bevor dieses Signal den Betreiber erreicht.

3.4 Explizite Invokation — /verify

Wenn der Betreiber bewusst verifizieren möchte, ruft der Slash-Befehl denselben Loop auf. Zwei Eingänge, die auf dasselbe Verfahren wie der Hook zeigen.

4. Wann Auto-Fire übersprungen wird (SKIP)

Nicht jede Arbeit braucht Verifikation. Die folgenden Bedingungen sind als SKIP für Auto-Fire deklariert.

• Nur-Lese-Arbeit — Scans · Überprüfungen · Untersuchungen. Keine Codeänderung, nichts zu verifizieren.
• Nur-Docs-Änderungen — nur .md-Dateien berührt. Lint/Build ist hier bedeutungslos.
• Absichtliches Scratchpad — Experimente, Prototypen. Betreiber deklariert.
• Betreiber sagte explizit „Verifikation überspringen" — explizite Umgehung.

Die SKIP-Bedingungen leben in der Persona — der Hook urteilt also automatisch. Der Betreiber muss nicht jedes Mal „überspringen" sagen.

5. Die von der Umgehung hinterlassene Spur

Manchmal muss der Betreiber absichtlich umgehen — beim Debugging, Ad-hoc-Arbeit, laufendem Hotfix.

Umgehung ist möglich. Aber die Tatsache der Umgehung landet immer im Log.

[verify] BYPASSED at 2026-05-17 14:23 — reason: emergency hotfix
[verify] Skipped: lint / build / test / security / diff / report
[verify] Note: re-run /verify manually after hotfix lands

So — Umgehungen sind nachverfolgbar und nachträgliche „Warum wurde das nicht verifiziert?"-Untersuchungen sind einfach. Die Umgehung ist nicht blockiert, aber die Spur bleibt.

Wenn Umgehung nicht möglich ist, schaltet der Betreiber die Verifikation vollständig aus. Einmal ausgeschaltet, bleibt sie für immer ausgeschaltet.

6. Fehler behandeln

Was der Betreiber sieht, wenn Verifikation fehlschlägt.

[verify] FAILED at step: Test (3/7)
[verify] 2 tests failed:
  - integration/auth.test.ts > "github oauth callback redirects to next"
  - integration/db.test.ts > "rls policy blocks other user's row"
[verify] Full log: /tmp/verify-2026-05-17-1423.log
[verify] Report blocked.

Das Kernprinzip: Fehlerinformation auf einen Bildschirm komprimieren. Wo es scheiterte, was das Problem ist, wo das detaillierte Log lebt. Der Betreiber entscheidet von diesem einen Bildschirm aus weiter (reparieren / umgehen / SKIP).

Das vollständige Log in die Konsole kippen lässt den Betreiber es selbst zusammenfassen — das ist selbst frische kognitive Last.

7. Fallen — Muster, bei denen Verifikation scheitert

7.1 Zu langsam

Dauert Verifikation mehr als 30 Sekunden, beginnt der Betreiber zu denken „das ist zu langsam" und greift häufig zur Umgehung. Wird Umgehung zum Standard, verliert Verifikation ihren Sinn. → Günstigste Schritte zuerst (lint/type fängt die meisten Fehler), teure Schritte später.

7.2 Zu viele False Positives

Schlägt Verifikation oft falschen Alarm, beginnt der Betreiber ihr zu misstrauen. Misstrauen führt zu Umgehung. → Verifikation selbst muss vertrauenswürdig sein. Sobald ein False Positive erkannt wird, sofort die Verifikationslogik selbst reparieren.

7.3 Nur Pass/Fail, keine Details

Nur „fehlgeschlagen" ohne wo/warum zu sagen — der Betreiber muss selbst durch Logs graben. Die Last verlagert sich zurück auf den Betreiber. → Ausgabe bleibt kurz, aber spezifisch (welcher Schritt, welcher Test, welche Zeile).

7.4 SKIP-Bedingungen zu eng

Feuert Verifikation bei fast jeder Aktion, erschöpft das den Betreiber. Nur-Lese-Arbeit zu verifizieren macht Verifikation selbst zum Rauschen. → Ausreichend SKIP-Bedingungen in der Persona angeben.

8. Auf ein Prinzip verdichtet

Der Kern von Verifikationsloop-Design kollabiert auf einen Satz.

„In dem Moment, in dem der Betreiber „fertig" sagen will, schneidet das System für einen Moment ein. Nur wenn es besteht, kann dieses Wort rausgehen. Umgehung ist möglich, hinterlässt aber immer eine Spur."

Wenn das gilt, wird der Verifikationsloop zu einem Sicherheitsnetz, das die Erleichterung des Betreibers für einen Moment anhält. Wenn es bricht — Verifikation wird ausgeschaltet, oder als False Positives misstraut, oder Umgehung wird zum Standard.

Der nächste Beitrag behandelt die grundlegende Ressource, von der alles oben (Verifikation, Gedächtnis, Skills, Hooks) abhängt — die Token-Ökonomie, d.h. was man ins context window aufnimmt und was man draußen lässt.