Ein Planer, der nichts onboarden wird

Einen neuen Service in mein Homelab zu bringen ist repetitiv: klassifizieren, was es ist, entscheiden, wo es lebt, herausfinden, ob es eine Datenbank, ein Backup-Ziel, ein Monitoring, eine Route, einen DNS-Eintrag braucht und welche davon tatsächlich tragend sind. Genau diese Art von Arbeit lädt zur Automatisierung ein – und genau hier geht Automatisierung oft stillschweigend schief.

Deshalb ist es in zwei Teile geteilt, und die Trennung liegt beim Verb.

Level 4A klassifiziert und plant. Es kann nicht handeln.

Der Planer liest Kandidaten-Datensätze, klassifiziert sie und schreibt einen lokalen Operator-Plan – JSON und Markdown, in einem Laufzeitverzeichnis. Das ist die gesamte Fähigkeit. Er erstellt keine Container, schreibt keine Compose-Dateien, registriert keinen DNS und berührt keinen Host. Selbst das Schreiben ist nur optional hinter einem Apply-Flag; ohne dieses gibt das Tool aus, was es geschrieben hätte.

Der Executor ist eine separate Ebene, separat abgesichert, die einen dauerhaften Genehmigungsdatensatz benötigt, der den genauen Plan benennt, auf den er handeln darf. Live-Ausführung ist standardmäßig deaktiviert.

Einen Kandidaten aktivieren ist ein Rename

Kandidaten-Datensätze liegen als Dateien in einem Verzeichnis. Dateien mit den normalen Daten-Endungen werden gescannt; Dateien mit der Endung .disabled nicht.

Das bedeutet, dass die Aktion, ein Beispiel zu einem aktiven Kandidaten zu machen, ein Datei-Umbenennen ist, das in einem Diff als Rename erscheint, in einem Pull Request als überprüfbare Änderung und in der Repository-Historie als datiertes Ereignis mit Autor.

Das gefällt mir viel besser als ein boolesches Feld in der Datei. Ein aktiviertes Flag, das von false auf true wechselt, ist ein einzelnes Zeichen im Diff, leicht im Review zu übersehen und in der Verzeichnisauflistung nicht sichtbar. Ein Rename ist von außen sichtbar. Wenn du etwas baust, dessen Sicherheit davon abhängt, dass Menschen es bemerken, sollte der Schalter dort sein, wo Menschen sowieso hinschauen.

Warum nur Planer kein halber Schritt ist

Ich treffe immer wieder auf die Annahme, dass ein System, das plant, aber nicht handelt, unvollständig ist – ein Zwischenschritt zur Autonomie. In meinem Homelab ist es genau andersrum. Der Engpass war nie meine Fähigkeit, Befehle auszuführen. Es war zu wissen, welche Befehle es wert sind, ausgeführt zu werden.

Ein Tool, das mir einen korrekten, belegten, vollständigen Plan liefert, nimmt mir den Teil ab, in dem ich schlecht bin. Die Ausführung dauert Minuten, und darin bin ich gut. Die Hälfte zu automatisieren, in der ich gut bin, um die Hälfte zu sparen, in der ich schlecht bin, wäre der falsche Tausch – und würde das gesamte Sicherheitsbudget des Systems für den am wenigsten wertvollen Schritt aufbrauchen.