Ein Mensch. Eine KI. Und eine Werkbank voller Agenten.

Entscheidet

Was gebaut wird und warum. Prioritäten. Was „gut“ für den Nutzer heißt. Wann etwas fertig genug ist.

Bringt ein

Zielgruppe, Produktgefühl, Geschmack, Geschäftsentscheidungen — und das Beharren auf einer Messung, wenn fünf plausible Ursachen im Raum stehen.

Pflicht

Entscheiden, auch bei Unsicherheit. Und wenn ein Einwand überstimmt wird: den Grund in die ADR schreiben.

Zeit

Fünf bis fünfzehn Stunden pro Woche. Der Sonntag ist geblockt, dazu abends ein bis zwei Stunden. Der Basiswächter läuft in der Nacht auf Sonntag, damit der Bericht wartet, wenn er sich hinsetzt.

Handle

sm0x — auf dem Build Service und auf GitHub.

Woher der Name kommt

Die Smaragdeidechse sonnt sich auf den Trockenmauern der Weinterrassen im Kamptal. Diese Mauern hat niemand am Reißbrett geplant — sie sind über Generationen von Hand gesetzt worden, Stein für Stein, von Leuten, die dort ohnehin gearbeitet haben. Und das Tier wirft nach dem Winter seine Haut ab und kommt farbiger heraus als vorher.

Liest keinen Code — und findet trotzdem Fehler

„Das Problem ist, dass ich das nicht beurteilen kann“, steht im Tagebuch. Das ist keine Lücke, für die man sich entschuldigt, sondern die Konstruktionsbedingung des ganzen Projekts: Die Maschine prüft den Code, der Mensch nimmt das Produkt ab. Am 1. September 2026 fand er in zwanzig Minuten zwei Defekte, indem er ein Bootmenü las — der gesamte Torwächter hatte sie nicht gefunden.

Davor

Ein Fingerabdrucktreiber für den ELAN-Sensor 04f3:0c63, den es sonst nirgends gab: Der Sensor ist mit 16,6 mm² zu klein für die übliche Erkennung, also ein anderer Matcher — Abweisungen beim Einlernen von 992 auf null, veröffentlicht auf dem Build Service für Tumbleweed und Ubuntu. Und das Vorgängerprojekt, aus dem die Arbeitskonventionen stammen: Regeln, die nicht in einem Hook stehen, sind Wünsche.

Erreichbar über das Formular auf dieser Seite.

Entscheidet

Wie es gebaut wird. Architektur, Abhängigkeiten, Modulschnitt, Testaufbau, Reihenfolge im Kleinen.

Bringt ein

Technische Folgen, Kosten, Risiken, Fakten — und den Widerspruch, wenn etwas nicht trägt.

Werkzeug

Claude Code, mit dem jeweils neuesten Claude-Modell. Die Leitplanken stehen nicht als Prosa, sondern als Hooks und Berechtigungen: product.yaml, base.yaml, UNTOUCHABLE.md und Signaturschlüssel sind für jeden Automaten tabu.

Darf nicht

In main schreiben ohne die sechs Tore. Einen Test löschen oder stilllegen. Nach :release veröffentlichen. Sein eigenes Werk abschließend prüfen. Sicherheitstexte selbst formulieren.

Werkzeug, nicht Autor

Jede Zeile hat einen Menschen, der für sie verantwortlich ist — jemanden, der sie verstanden hat und im Zweifel verteidigt. Dass eine KI sie geschrieben hat, ändert daran nichts. KI-Beteiligung steht im Commit; das Developer Certificate of Origin bleibt eine Aussage über Herkunft, die ein Modell nicht machen kann.

Die erste Messung

Rund 13 000 Zeilen Rust in zwei Tagen, für KryptMail. Das belegt, dass Bauen billig geworden ist. Es belegt nicht, dass Besitzen billig geworden ist: Jede Funktion muss danach durch jeden wöchentlichen Basiswechsel weiter funktionieren, für immer. Die Grenze des Projekts ist deshalb nicht die Zeilenzahl, sondern die Zahl der Szenarien, die eine Person dauerhaft grün halten kann — etwa achtzig.

Was nicht funktioniert hat

Der Torwächter war acht Tage lang auf GitHub rot, während er lokal jedes Mal bestand. Fünf plausible Ursachen an einem Tag, alle falsch. Ein Test, der grün war, weil seine Attrappe das Gewünschte zurückgab. Alles protokolliert — die falschen Annahmen sind der nützlichste Teil des Tagebuchs.

läuft Ein Shellskript von rund 1 400 Zeilen, 20 Abschnitte, 38 Prüfungen, in der CI bei jedem Push. Es prüft die Tore 1 bis 3 und 6: Bauen, Robustheit, Nachweispflichten, Rechteänderungen.

Was es zurückweist

Jeden literalen Farbwert im Anwendungscode. Jede Handänderung in einem erzeugten Verzeichnis. Jedes Paket aus der Liste der Unantastbaren. Jeden hart verdrahteten Basis- oder Produktnamen außerhalb seiner einen Datei. Einen Werkzeugkasten, in dem ein Diagnosewerkzeug fehlt. Eine Farbe, die WCAG AA nicht erreicht. Eine systemd-Unit, die systemd nicht so liest, wie sie gemeint war.

Was es gelernt hat

Am 31. August 2026 meldeten zwei Prüfungen „bestanden, 0 geprüft“ in einem Container, in dem find fehlte. Seither weigert er sich zu laufen, wenn eines seiner Werkzeuge fehlt. Eine Prüfung, die nichts findet, weil sie kaputt ist, sieht genauso aus wie eine, die nichts findet, weil nichts da ist.

Auftrag geschrieben, einmal von Hand gefahren Ein zweiter Lauf, getrennter Kontext, anderer Auftrag: „Finde, was hier schiefgehen kann.“ Er kennt die Begründung des Autors nicht und gibt keine Freigabe, sondern eine Liste von Bedenken, die im Pull Request stehen bleibt.

Worauf er achtet

Fehlerpfade, die kein Test abdeckt. Nebenwirkungen auf Daten des Nutzers. Annahmen über Hardware, die auf dem schwachen Referenzgerät nicht gelten. Stellen, an denen ein Fehlschlag stillschweigend passiert. Widersprüche zwischen zugesagter Eigenschaft und tatsächlichem Verhalten.

Sein erster Fund

Am 9. September 2026 fand er in einer eigenen Sitzung, dass eine Vorprüfung des Theme-Aktivators verlangte, ein Dienst heiße genau sddm.service — was kein openSUSE erfüllt. Die Testsuite war grün, weil ihre Attrappe genau das zurückgab. Die tragende Regel: Autor und Prüfer sind niemals derselbe Lauf.

Phase 2 Das Herzstück der Werkbank, und das, was Phase 1 noch schuldet. Er holt den neuen Slowroll-Stand, ordnet jede Änderung in eine von vier Klassen — Sicherheitsfix, Routine, Bruchkandidat, Rot — bestimmt die Auswirkung auf unsere Pakete und öffnet einen Pull Request mit Bericht, einer Unsicherheitsangabe je Änderung und einer Begründung.

Der wertvollste Teil

Er sucht auch nach überflüssig gewordenen eigenen Anpassungen. Das ist das Gegenmittel gegen die Dauerlast: Die Schicht schrumpft von selbst, statt zu wachsen. Und er beobachtet die Rücknahmebedingungen jeder ADR — bekommt openSUSE ein transientes /usr-Overlay? Verlässt Slowroll den Beta-Status?

Was er schon gelernt hat, bevor er existiert

Die Kette lesen, nicht das Aggregat. Am 9. September hing das Live-Abbild an einem Qt-Übergang der Basis, der im veröffentlichten Repository längst konsistent war — nur in der Zwischenschicht nicht.

Phase 2 Gleicht die maschinenlesbaren Sicherheitsdaten von openSUSE mit der ausgelieferten Paketliste ab. Bei einer Lücke mit CVSS ab 7 und verfügbarem Fix löst er den Eilweg aus und öffnet ein Issue.

Was er ausdrücklich nicht darf

Sicherheitstexte selbst formulieren. Ein Sprachmodell, das CVE-Texte frei umschreibt, wird irgendwann eine Lücke verharmlosen. Für die Handvoll wirklich relevanter Pakete liegen von Menschen geschriebene Klartexte bereit; für alles andere sagt das System ehrlich „Sicherheitsupdate verfügbar“, ohne Drama zu erfinden. Und „sofort“ ist nicht einlösbar — „am selben Tag, an dem die Basis es veröffentlicht“ ist es.

Phase 2 Misst das Leistungsbudget auf dem schwachen Referenzgerät und schreibt die Zahlenreihe fort. Kaltstart bis Anmeldebildschirm höchstens 25 Sekunden, Anmeldung bis benutzbarer Desktop 8 Sekunden, RAM im Leerlauf 900 MB — auf zwei Kernen mit 4 GB. Eine Verschlechterung ist ein roter Test, kein Schönheitsfehler.

Woran er hängt

Am Gerät. Ein Ryzen 9 ist das genaue Gegenteil eines Referenzgeräts, und eine VM mit gedrosselten Kernen taugt nicht: Die entscheidenden Größen sind Datenträgerlatenz und Grafikverhalten. Ein gebrauchtes Notebook aus der Zielgruppe ist die einzige Anschaffung, die dieses Projekt braucht.

Phase 2 Sucht Lücken in der Testsuite: Welches Feature aus dem Handbuch hat kein E2E-Szenario? Welcher Test war die letzten vier Wochen nie rot und nie grün — also stillgelegt? Welcher Test läuft unzuverlässig?

Warum er der wichtigste Nebenagent ist

Weil in diesem Projekt niemand den Code liest, ist die Suite die Prüfinstanz. Der klassische Tod einer Testsuite ist nicht, dass niemand Tests schreibt, sondern dass ein roter Test „reparaturhalber“ gelöscht wird. Ein Test darf nur entfernt werden, wenn das Feature entfernt wird — und das braucht eine ADR. Der Testwart ist die Kontrolle über die Kontrolle.

später Schreibt die Versionshinweise aus den zusammengeführten Pull Requests — in einfacher Sprache, in beiden Sprachen. Ein Mensch liest gegen. Sätze im Schnitt höchstens 15 Wörter, keiner über 25, kein Fachwort ohne Erklärung. Die Lesbarkeit misst der Torwächter mit.

später Prüft, ob die Quellen aus der Ergänzungsliste noch existieren und die Pakete noch heißen wie angegeben — Medienformate, NVIDIA, Microsoft-Schriften, Spiele, Windows-Programme, Behördendienste. Eine tote Ergänzung ist ein kaputtes Versprechen.

Einen Teil davon macht heute schon ein Skript des Torwächters: Es löst jeden Paketnamen gegen die echten Repository-Metadaten auf, in vier Sekunden. 15 von 139 Namen waren am ersten Tag geraten und falsch.

später Prüft, ob jede sichtbare neue Funktion eine Handbuchseite hat — in beiden Sprachen, mit allen fünf Teilen: die Situation, die Handgriffe, warum das so ist, die Felder, die Meldungen. Und ob die Gegenprobe sauber ist: Jede Beschriftung, die das Handbuch nennt, kommt in der Oberfläche noch vor.

Ein Vorgang, der im Handbuch steht und nirgends durchgespielt wird, ist ein ungeprüfter Vorgang. Wird eine Frage zweimal gestellt, ist die Antwort ein Handbuchkapitel, nicht ein längerer Forenbeitrag.