Neun Agenten, die niemand einstellen muss

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.