ZeroClaw als Alert-Gate: erst verstehen, nicht gleich reparieren

ZeroClaw liest Alerts und Clusterzustand, bündelt Symptome und schlägt nächste Schritte vor. Wie die aktuelle Triage im Lab funktioniert, weshalb ihre Monitoring-Identität keine Secrets lesen darf — und wo Promptregeln, Laufzeitrechte und fehlende Zustell-Fallbacks die Grenzen des Modells zeigen.

Ein Monitoring-System kann völlig korrekt arbeiten und trotzdem schlechte Nachrichten produzieren. Ein Storage-Problem wird zu mehreren Volume-Alerts, daraus werden Pod-Probleme, und am Ende meldet sich noch ein Dienst, dessen Abhängigkeit gerade fehlt. Jede einzelne Meldung stimmt. Zusammen beantworten sie aber noch nicht die wichtigste Frage: Was ist passiert, und was muss ich jetzt entscheiden?

An dieser Stelle sitzt ZeroClaw in meinem Lab. Nicht als zusätzlicher Controller, der Deployments repariert, sondern als Alert-Gate und lesender Triage-Assistent: Zustand abfragen, zusammengehörige Symptome einordnen, bekannte Meldungen zurückhalten und bei neuen relevanten Vorfällen eine verständliche Zusammenfassung liefern.

Das klingt einfach. Die interessanten Fragen beginnen bei den Grenzen: Wer darf die Daten lesen? Wer darf etwas verändern? Und was passiert, wenn ausgerechnet der Assistent schweigt?

tailnet-operator: Verbindungen deklarieren statt Proxys verkabeln

Kubernetes und Headscale sprechen nicht automatisch dieselbe Sprache. Mein tailnet-operator verbindet beide Welten: Services für entfernte Ziele, private HTTPS-Eingänge, abgeleitete Zugriffsregeln und Statusmeldungen, die mehr sagen als ‚Pod läuft‘. Eine Vorstellung anhand des realen Lab-Einsatzes.

Die Datenbank ist erreichbar. Jedenfalls vom Laptop. Aus dem Pod nicht. Der Tunnel steht, die Route ist angekündigt, der Proxy läuft, und trotzdem bleibt die Verbindung hängen. Irgendwo zwischen Kubernetes-Service, Headscale-Policy, Routenfreigabe und DNS fehlt ein Stück — nur gehört dieser Zusammenhang keinem einzelnen System.

Genau für diese Lücke entwickle ich tailnet-operator. Er macht aus Verbindungen zwischen Kubernetes und einem Headscale-Tailnet eigene Ressourcen: Ein Namespace bekommt einen stabilen Service für ein entferntes Ziel. Eine Anwendung bekommt einen privaten HTTPS-Eingang. Und die dazugehörigen Identitäten, Freigaben und Statusinformationen entstehen aus derselben Deklaration.

Nicht noch ein VPN. Sondern die fehlende Betriebslogik zwischen zwei bereits vorhandenen Welten.

Paperless-ngx im Lab: vom Scan zum brauchbaren Archiv

Ein Dokumentenarchiv ist mehr als OCR hinter einer Weboberfläche. Wie ich Scanner, Mailimport, PostgreSQL, kontrollierte KI-Klassifikation und Off-site-Backups zusammenführe — und warum Eigentümer, Upload-Grenzen und Restore-Zeitpunkte dabei wichtiger sind als der Modellname.

Ein Scanner löst das Papierproblem nur zur Hälfte. Danach liegt die Rechnung nicht mehr auf dem Schreibtisch, sondern als scan_0042.pdf in einem Verzeichnis. Man kann sie öffnen, aber noch lange nicht zuverlässig wiederfinden. Bei E-Mails ist es ähnlich: Der Anhang ist irgendwo vorhanden, der Zusammenhang steckt im Postfach, und ob beides wirklich gesichert ist, bleibt eine andere Frage.

Paperless-ngx soll in meinem Lab genau diese Lücke schließen: Dokumente aufnehmen, durchsuchbar machen und mit brauchbaren Metadaten versehen. Die interessante Arbeit begann allerdings erst nach dem ersten erfolgreichen Upload. Wie landet ein Scan vollständig im Archiv? Was darf ein Sprachmodell entscheiden? Und wie stelle ich Dateien und Datenbank so wieder her, dass sie auch zusammenpassen?

Lab-Rückblick: weniger blinde Flecken, bessere Rückwege

Vom Sommer bis Anfang Oktober: Alloy statt Promtail, Langzeitmetriken mit Thanos, SLOs mit Pyrra und verschlüsselte Off-site-Backups bei Cloudflare R2. Dazu die weniger glamourösen Änderungen, die ein Lab im Alltag belastbarer machen.

Im letzten größeren Lab-Rückblick stand eine ziemlich lange offene Rechnung: bessere Beobachtbarkeit, Backups über mehrere Schichten und weniger Handarbeit an den Betriebsgrenzen. Seitdem kamen neue Dienste hinzu. Interessanter finde ich aber die Änderungen, die man auf einem Screenshot kaum sieht: Logs fehlen nicht mehr ausgerechnet von der Control Plane, Backups verlassen die Ausfalldomäne des Clusters, und ein stilles Monitoring gilt nicht automatisch als gesund.

Hier die relevanten Veränderungen seit dem Sommer — keine Liste aller Image-Bumps, sondern das, was am Betriebsmodell tatsächlich etwas geändert hat. Stand ist die öffentliche Lab-Konfiguration Anfang Oktober 2026.

fabric: Eine Machbarkeitsstudie für ein selbstheilendes P2P-Mesh

Wie finden sich Knoten, wenn Adressen wechseln, Verbindungen abbrechen und kein zentraler Dienst die Topologie kennt? fabric ist meine Forschungsplattform für Peer-Discovery, Route-Healing, mehrstufige Transportwege und klar begrenztes Vertrauen. Dieser Beitrag beschreibt, was bereits funktioniert, wo die Selbstheilung heute endet und warum gerade diese Grenze interessant ist.

Ein Mesh ist auf dem Whiteboard immer gesund. Ein paar Kreise, einige Linien dazwischen, vielleicht noch eine Wolke für „das Internet“ — fertig ist das dezentrale Netz. Interessant wird es erst, wenn man eine Linie wegradiert. Oder drei. Wenn ein Knoten umzieht, eine Adresse nur aus einem privaten Netz erreichbar ist, UDP plötzlich verschwindet und niemand mehr zuverlässig sagen kann, welcher Weg zum Ziel noch existiert.

Genau dort beginnt fabric. Das Projekt untersucht, ob sich aus wenigen, bewusst begrenzten Bausteinen ein Peer-to-Peer-Netz zusammensetzen lässt, das neue Teilnehmer sicher aufnimmt, seine Nachbarn selbst entdeckt, indirekte Wege lernt und veraltete Routen wieder überprüft. Nicht als fertiges Produkt und nicht als Versprechen, jedes kaputte Netz magisch zu reparieren, sondern als Machbarkeitsstudie für Discovery und Auto-Healing: ausführbar, testbar und offen genug, dass auch die Lücken sichtbar bleiben.