Teil 12

Die Umgebung neu aufbauen, nicht das Gedächtnis

Die wertvollste Automatisierung ist nicht immer eine Geschäftsaufgabe. Manchmal ist es die Fähigkeit, auf einem neuen Hosting-Konto einen kleinen Core abzulegen, ein klares Rezept auszuführen und vertraute Werkzeuge und Arbeitsweisen zurückzubekommen.

Ihre Umgebung ist ein Rezept plus Zustand

Installierte Module, Interface-Pakete, Startup-Skripte und Präferenzen beschreiben das Terminalverhalten. Projektdateien und Datenbanken sind eine andere Zustandsschicht. Diese Trennung erleichtert Migration und Wiederherstellung erheblich.

Notieren Sie, was automatisch neu erzeugt und was aus Backups wiederhergestellt werden muss. Ein Setup-Rezept beschreibt Werkzeuge und sichere Defaults; Anwendungsdaten oder Zugangsdaten gehören nicht heimlich auf den neuen Host.

Vor dem Rezept die bereits verwendete Umgebung inventarisieren

core liefert das kompakte Core/UI/Modul-Bild, install -l listet installierte Module und Pakete, include zeigt den Interface-Paket-Speicher und upgrade -c prüft Modulversionen ohne zu schreiben.

Dieses Inventar trennt „ich glaube, diese Werkzeuge brauche ich“ von einer reproduzierbaren Stückliste. Veraltete Gewohnheiten entfernen, bevor sie dauerhaft in Setup-Automatisierung konserviert werden.

core

install -l

include

upgrade -c

`setup.lil` ist ein einmaliger Bootstrap, kein permanentes Startup-Skript

Der aktuelle Core erkennt ein reguläres setup.lil neben lil.php, führt es bei Bedarf nach der Autorisierung aus und löscht es erst, wenn alle Statements erfolgreich waren. Fehlt der vollständige Installer, kann Core ihn holen und die ursprüngliche Install-Operation fortsetzen.

Halten Sie die Einrichtung klar und ausdrücklich. Mehrere Module mit install in einem Aufruf zu installieren bleibt kompakt und lesbar; eine exakte Version mit -v ist sinnvoll, wenn ein reproduzierbares Rezept bewusst auf einen bestimmten Stand festgelegt werden soll. Passwörter, private Schlüssel und projektspezifische Datenbank-Zugangsdaten gehören nicht in diese Datei.

install help history upgrade dir pwd md mf edit find stat hash run

`autoload.lil` ist für kleine wiederkehrende Aktionen beim Session-Start

run prüft autoload.lil einmal pro autorisierter Session und löscht die Datei nicht. Das eignet sich für leichte Checks oder Umgebungsvorbereitung, die wiederholt werden sollen, nicht für eine einmalige Installation.

upgrade -auto check ist ein gutes Beispiel: Es verwaltet einen kleinen Block in autoload.lil und prüft Updates einmal pro Session. Automatische Updates sind eine stärkere Policy und bleiben Opt-in; wichtige Umgebungen fahren oft besser mit Check, Prüfung und erst dann Update.

upgrade -auto check

upgrade -info

Reproduzierbarkeit heißt zu wissen, welche Freiheit gewählt wurde

install <mod> wählt die aktuelle kompatible öffentliche Version; install <mod> -v <ver> fordert eine bestimmte veröffentlichte Versionsnummer an. Beide Formen beachten weiterhin die aktive Core-Generation und die Abhängigkeiten des Moduls.

Frühere Meilensteine der Generation 1 bleiben nur als Historie sichtbar und sind keine Installationsziele mehr. Unterstützt wird die aktuelle Version. Ab der nächsten veröffentlichten Version sollen nummerierte Releases als exakte Installationsziele verfügbar bleiben, sofern ein Release nicht ausdrücklich zurückgezogen wird.

install hash -i

install hash -v 1.1.3

Das Browser-Interface ist eine Paketschicht, nicht die Laufzeitumgebung der Befehle

include verwaltet kombinierbare CSS/JavaScript-Pakete wie lil, hotkeys und code. Session-Modus ist temporär; -s erzeugt persistente .lil.css- und .lil.js-Komposition.

Beim Host-Wechsel ist diese Trennung wertvoll: PHP-Befehlsmodule können korrekt funktionieren, auch wenn das bevorzugte UI-Paket fehlt. Erst Funktionalität wiederherstellen, dann Darstellung. Bei verwirrter Interface-Schicht setzt kill -include nur diese Ebene zurück, nicht den Core.

include -l

include lil -i

include -lil -s

Ein Setup-Rezept ist erst fertig, wenn es in einer sauberen Umgebung getestet wurde

Der beste Beweis ist eine Clean-Installation: frischen Core bereitstellen, Rezept ausführen und danach core, install -l und upgrade -c mit der beabsichtigten Umgebung vergleichen.

Dabei werden unsichtbare Abhängigkeiten sichtbar — ein vor Monaten manuell installierter Befehl, ein vergessenes Interface-Paket oder eine Erweiterung, die nur auf einem Host vorhanden ist. Reproduzierbarkeit zeigt sich beim Wiederaufbau, nicht durch Behauptung.