docs: switch provisioning ISO to live medium with auto/interactive boot modes (ADR-0003)

Moves from a Fedora DVD/netinst base (GRUB boots straight into Anaconda
via a static inst.ks= URL, bypassing installer.sh entirely) to a real
live medium. installer.sh runs as an application inside the live
session; backend_launch() starts the native installer explicitly at
the end instead of a boot-time kickstart parameter.

The boot menu offers two entries: a default with a countdown that
leads to an unattended flow, and a manual entry for the branded
interactive flow. The unattended flow is gated on
device.registration_status == "existing" - unknown devices always
fail closed into the interactive enrollment path. Device registration
now documents that this is a condition of registering a device.

Also notes the tension with the installer roadmap's long-term
minimal-medium vision: distribution packages still aren't bundled and
are pulled per install, but the live environment itself makes the
medium larger, accepted for the UX it enables.

Details: architecture/13-live-provisioning-boot.md.

00-glossary.md

@@ -94,3 +94,15 @@ Beispiele:
 - Calamares
 - Debian Installer
 - Subiquity
+
+## Auto-Modus
+
+Ein Bootmodus der Provisionierungs-ISO, in dem Bereitstellungsvorlage-Auswahl und Commit-Point-Bestätigung ohne Benutzereingabe erfolgen.
+
+Nur für bereits registrierte Geräte zulässig (`device.registration_status == "existing"`).
+
+Details: `architecture/13-live-provisioning-boot.md`.
+
+## Interaktiv-Modus
+
+Der in F-005 (`architecture/10-interactive-provisioning-flow.md`) beschriebene Ablauf mit expliziter Benutzerinteraktion bei Bereitstellungsvorlage-Auswahl und Installationsbestätigung.

adr/0003-live-provisioning-boot.md

@@ -0,0 +1,44 @@
+# ADR-0003: Live-ISO als Provisionierungsmedium mit Auto- und Interaktiv-Modus
+
+**Status:** Beschlossen
+**Datum:** 18.07.2026
+
+## Kontext
+
+Das bisherige Provisionierungsmedium ist eine gepatchte Fedora-DVD/Netinst-ISO. GRUB startet Anaconda dort direkt über einen fest verdrahteten Kernel-Parameter (`inst.ks=https://.../ks.cfg`), der auf eine statische Kickstart-Datei auf dem Provisioning-Server zeigt.
+
+Das hat zwei Konsequenzen:
+
+Der in `10-interactive-provisioning-flow.md` (F-005) beschriebene und in `scripts/installer.sh` umgesetzte Ablauf (Netzwerk, Hardware, Aktivierung, Bereitstellungsvorlage-Auswahl, Runtime Blueprint, Backend) hat auf der aktuellen ISO keinen Einstiegspunkt. Anaconda startet, bevor `installer.sh` je ausgeführt wird.
+
+Eine gebrandete, frei gestaltbare Oberfläche für Workspace-Auswahl und Provisioning-Server-Authentifizierung ist auf dieser Basis nur über Anaconda-eigene Erweiterungsmechanismen (Addons) erreichbar, die eng an Anacondas UI-Framework gebunden und aufwendig sind.
+
+Gleichzeitig ist eine durchgängige interaktive Bestätigungspflicht für jede Installation bei Massenrollouts und Geräteersatz unpraktikabel.
+
+## Entscheidung
+
+Tuxflotte wechselt die Grundlage der Provisionierungs-ISO von einer Fedora-DVD/Netinst-Basis auf ein echtes Live-Medium (z. B. Fedora Workstation Live, erkennbar an `/LiveOS/squashfs.img`).
+
+`scripts/installer.sh` läuft als Anwendung innerhalb dieser Live-Sitzung. Der native Installer wird nicht mehr über einen boot-zeitlichen `inst.ks=`-Parameter gestartet, sondern erst am Ende des Ablaufs explizit durch `backend_launch()`, mit der von `backend_generate_config()` erzeugten Konfiguration.
+
+Das Bootmenü bietet zwei Einträge, die dieselbe Live-Umgebung starten, sich aber in einem Kernel-Cmdline-Flag unterscheiden:
+
+Ein Standardeintrag mit Countdown, der bei Nichtstun automatisch in den unbeaufsichtigten Ablauf führt.
+
+Ein manuell auswählbarer zweiter Eintrag für den interaktiven, gebrandeten Ablauf.
+
+Der unbeaufsichtigte Ablauf ist ausschließlich für bereits registrierte Geräte zulässig, erkennbar an `device.registration_status == "existing"` in der Antwort von `POST /api/v1/activate`. Bei einem unbekannten Gerät (`registration_status == "registered"`) bricht der unbeaufsichtigte Ablauf kontrolliert ab (Fail-Closed) und verweist auf den interaktiven Ablauf mit expliziter Geräteaufnahme-Bestätigung gemäß `11-device-enrollment.md`.
+
+Dass ein bereits registriertes Gerät ohne erneute interaktive Rückfrage automatisiert neu installiert werden kann, wird explizit Bestandteil der Bedingungen, denen bei der Geräteregistrierung zugestimmt wird.
+
+## Konsequenzen
+
+`scripts/build.sh` und `scripts/extract.sh` benötigen künftig ein Live-ISO als Quelle statt einer DVD/Netinst-ISO. Die GRUB-Konfiguration erhält einen zweiten Menüeintrag sowie ein Kernel-Cmdline-Flag zur Moduswahl.
+
+Die statische `ks.cfg` sowie ihr Server-Endpoint (`GET /installers/fedora-workstation/ks.cfg`) entfallen mit der Umstellung.
+
+WLAN-Zugangsdaten für die Live-Provisionierungsumgebung selbst müssen weiterhin im ISO-Build hinterlegt werden, da ohne Netzwerk kein Zugriff auf den Provisioning-Server möglich ist. WLAN-Zugangsdaten für das installierte Zielsystem gehören zum noch unspezifizierten `Network Profile`-Modell der Organization (`09-data-model-v1.md`).
+
+Die Geräteregistrierung (`11-device-enrollment.md`) wird um den ausdrücklichen Hinweis ergänzt, dass registrierte Geräte automatisiert neu installiert werden können.
+
+Details zum Ablauf: `architecture/13-live-provisioning-boot.md`.

architecture/00-provisioning-flow.md

@@ -1,5 +1,7 @@
 Boot
  ↓
+GRUB-Menü: Auto- oder Interaktiv-Modus (siehe 13-live-provisioning-boot.md)
+ ↓
 Preflight
  ↓
 Netzwerk
@@ -12,9 +14,9 @@ Device Registration
  ↓
 Assignment
  ↓
-Runtime Blueprint
+Runtime Blueprint erzeugen
  ↓
-Backend Selection
+Backend laden
  ↓
 Backend API
  ↓
@@ -26,6 +28,8 @@ Provisioning Agent
  ↓
 Managed System
 
+Der Schritt „Assignment" unterscheidet sich je nach Modus: Im Interaktiv-Modus wählt der Benutzer eine Bereitstellungsvorlage und bestätigt den Commit Point explizit. Im Auto-Modus geschieht beides automatisch, und nur für bereits registrierte Geräte (siehe `13-live-provisioning-boot.md`).
+
 ## Aktivierung und Gerätebindung
 
 Ein neues Gerät authentifiziert den ersten Provisionierungsvorgang mit einem Aktivierungscode.
@@ -48,4 +52,4 @@ Geräteregistrierung oder Wiedererkennung
         ↓
 Bereitstellungsvorlage-Zuordnung
         ↓
-Runtime Blueprint
+Runtime Blueprint erzeugen

architecture/07-runtime-layout.md

@@ -68,7 +68,7 @@ Beispiele:
 - 17_device_status.sh liest aus /run/tuxflotte/server/ und schreibt nach /run/tuxflotte/provisioning/
 - 20_profile_selection.sh liest aus /run/tuxflotte/server/ und schreibt nach /run/tuxflotte/assignment/
 - 25_installation_confirm.sh liest aus /run/tuxflotte/assignment/ und schreibt nach /run/tuxflotte/installation/
-- Der Runtime-Builder liest aus /run/tuxflotte/server/
+- Der Runtime-Builder (30_runtime_blueprint.sh) liest aus /run/tuxflotte/network/, /run/tuxflotte/server/ und /run/tuxflotte/assignment/ und schreibt nach /run/tuxflotte/runtime/
 - Der Backend-Orchestrator liest aus /run/tuxflotte/runtime/
 
 Direkte Funktionsaufrufe zwischen Modulen sind nicht vorgesehen.

architecture/10-interactive-provisioning-flow.md

@@ -8,6 +8,8 @@ F-005 beschreibt den interaktiven Provisionierungsablauf zwischen Netzwerkinitia
 
 Ziel ist ein vollständig testbarer Provisionierungsprozess, der vor dem Start der eigentlichen Betriebssysteminstallation kontrolliert abgebrochen werden kann.
 
+Dieser Ablauf beschreibt den Interaktiv-Modus. Für bereits registrierte Geräte existiert daneben ein automatisierter Modus, der Bereitstellungsvorlage-Auswahl und Commit-Point-Bestätigung ohne Benutzereingabe durchläuft (siehe `13-live-provisioning-boot.md`).
+
 ## Ablauf
 
 ```text

architecture/11-device-enrollment.md

@@ -112,6 +112,14 @@ Gerät erneut provisionieren?
 [j/N]
 ```
 
+### Automatisierte Reprovisionierung
+
+Für ein bereits registriertes, über seinen Hardware-Fingerprint wiedererkanntes Gerät (`registration_status == "existing"`) kann die Reprovisionierung auch automatisiert erfolgen, ohne die oben gezeigte interaktive Rückfrage (siehe `13-live-provisioning-boot.md`).
+
+Mit der Registrierung eines Geräts wird akzeptiert, dass es künftig auf diesem Weg ohne erneute interaktive Bestätigung neu installiert werden kann, solange es als bereits registriert erkannt wird.
+
+Diese Eigenschaft gilt ausschließlich für bereits registrierte Geräte. Die Aufnahme eines unbekannten Geräts bleibt in jedem Fall an eine explizite, interaktive Bestätigung gebunden (siehe Sicherheitsprinzip unten).
+
 ## Enrollment Sessions
 
 Für Massenrollouts und Werkstattumgebungen kann eine Organisation zeitlich begrenzte Enrollment Sessions erstellen.

architecture/13-live-provisioning-boot.md

@@ -0,0 +1,110 @@
+# Live-Provisionierung und Boot-Modi
+
+**Status:** Beschlossen
+**Datum:** 18.07.2026
+
+## Zweck dieses Dokuments
+
+Dieses Dokument beschreibt, wie die Provisionierungs-ISO bootet, wie der automatisierte und der interaktive Ablauf sich unterscheiden, und wie der native Installer aus der Live-Umgebung heraus gestartet wird.
+
+Es ergänzt `10-interactive-provisioning-flow.md` (F-005), das den interaktiven Ablauf selbst beschreibt, um die Boot-Ebene davor.
+
+Siehe `ADR-0003` für die Entscheidung und ihre Begründung.
+
+---
+
+## Ausgangslage
+
+Die bisherige ISO basiert auf einer Fedora-DVD/Netinst-Struktur ohne Live-Umgebung. GRUB startet Anaconda direkt, mit einer über `inst.ks=` fest verdrahteten Kickstart-URL. Der gesamte in F-005 beschriebene Ablauf hat darauf keinen Einstiegspunkt.
+
+Die neue ISO basiert stattdessen auf einem echten Live-Medium (erkennbar an `/LiveOS/squashfs.img`). `scripts/installer.sh` läuft als gewöhnliche Anwendung innerhalb dieser Live-Sitzung, mit vollem Zugriff auf Netzwerk (NetworkManager, WLAN), Bildschirm und Tastatur.
+
+---
+
+## Boot-Ablauf
+
+```text
+Boot
+ ↓
+GRUB-Menü (Countdown)
+ ├── Zeitüberschreitung oder Standardeintrag
+ │     ↓
+ │   Live-Umgebung startet mit tuxflotte.mode=auto
+ │
+ └── manuelle Auswahl des zweiten Eintrags
+       ↓
+     Live-Umgebung startet mit tuxflotte.mode=interactive
+ ↓
+installer.sh liest tuxflotte.mode
+ ↓
+Netzwerk, Hardware, Aktivierung (wie bisher, "always"-Module)
+ ↓
+Moduswahl
+ ├── auto
+ │     ↓
+ │   device.registration_status prüfen
+ │     ├── existing    → Bereitstellungsvorlage automatisch wählen (is_default), Commit Point automatisch bestätigen
+ │     └── registered  → Fail-Closed-Abbruch, Verweis auf interaktiven Ablauf
+ │
+ └── interactive
+       ↓
+     bisheriger F-005-Ablauf (Bereitstellungsvorlage-Auswahl, explizite Bestätigung)
+ ↓
+Runtime Blueprint erzeugen → Backend laden → backend_generate_config()
+ ↓
+backend_launch() startet den nativen Installer explizit aus der Live-Sitzung heraus
+```
+
+Beide Moduspfade laufen ab „Runtime Blueprint erzeugen" identisch weiter. Der Unterschied liegt ausschließlich davor: in der Frage, ob eine Bereitstellungsvorlage interaktiv gewählt und der Commit Point interaktiv bestätigt wird, oder ob beides automatisch anhand vorhandener Daten geschieht.
+
+---
+
+## Auto-Modus-Gate
+
+Der automatisierte Ablauf ersetzt keine Sicherheitsprüfung, sondern ersetzt nur, wer die Bestätigung gibt: statt einer Benutzereingabe entscheidet ein bereits bestehender, geprüfter Zustand.
+
+Voraussetzung für den automatisierten Ablauf ist ausschließlich:
+
+`device.registration_status == "existing"` in der Antwort von `POST /api/v1/activate`.
+
+Ein unbekanntes Gerät (`registration_status == "registered"`) durchläuft niemals den automatisierten Ablauf, unabhängig vom gewählten Bootmenüeintrag. Die Geräteaufnahme bleibt gemäß `11-device-enrollment.md` an eine explizite, interaktive Bestätigung gebunden.
+
+Das Fail-Closed-Prinzip aus `10-interactive-provisioning-flow.md` gilt unverändert: Fehlt eine gültige Grundlage für die automatische Bestätigung (zum Beispiel eine unerwartete oder unlesbare Serverantwort), bricht der Ablauf ab, statt ersatzweise eine Bestätigung anzunehmen.
+
+---
+
+## Konsequenz für die Geräteregistrierung
+
+Wer ein Gerät registriert, akzeptiert damit, dass dieses Gerät künftig ohne erneute interaktive Rückfrage automatisiert neu installiert werden kann, solange es über seinen Hardware-Fingerprint als bereits registriert erkannt wird.
+
+Dies wird bei der Geräteregistrierung ausdrücklich kommuniziert (siehe `11-device-enrollment.md`).
+
+---
+
+## Nativer Installer aus der Live-Sitzung
+
+Der native Installer wird nicht mehr über einen boot-zeitlichen Parameter gestartet.
+
+Stattdessen ruft `backend_launch()` (siehe `06-backend-api.md`) den nativen Installer explizit auf, mit der zuvor von `backend_generate_config()` erzeugten, lokal vorliegenden Konfiguration.
+
+Die statische Kickstart-Datei sowie ihr Server-Endpoint (`GET /installers/fedora-workstation/ks.cfg`) entfallen damit.
+
+---
+
+## WLAN-Zugangsdaten
+
+Zwei getrennte Anwendungsfälle:
+
+**WLAN für die Live-Provisionierungsumgebung.** Ohne Netzwerk ist der Provisioning-Server nicht erreichbar. Zugangsdaten für dieses Netzwerk müssen deshalb bereits im ISO-Build hinterlegt sein (zum Beispiel als NetworkManager-Verbindungsprofil in einem organisationsspezifischen ISO-Build), nicht dynamisch vom Server geladen werden.
+
+**WLAN für das installierte Zielsystem.** Dies ist eine dauerhafte, organisationsweite Vorgabe und gehört zum noch unspezifizierten `Network Profile`-Modell der Organization (siehe `09-data-model-v1.md`). Die Anwendung erfolgt wie andere organisationsweite Vorgaben, nicht als Teil der Provisionierungs-Bootphase.
+
+---
+
+## Zusammenfassung
+
+Die Live-ISO ersetzt das direkte Booten in Anaconda durch eine vorgeschaltete, frei gestaltbare Live-Sitzung, in der `installer.sh` läuft.
+
+Ein Bootmenü mit Countdown unterscheidet zwischen automatisiertem und interaktivem Ablauf; beide münden ab der Runtime-Blueprint-Erzeugung in denselben Codepfad.
+
+Automatisierung ersetzt keine Sicherheitsprüfung, sondern bindet die Bestätigung an eine bereits bestehende, geprüfte Gerätezuordnung statt an eine Benutzereingabe.

roadmap/installer-roadmap.md

@@ -65,6 +65,8 @@ Ziel: Vollständiger Einstieg in die Provisioning-Plattform.
 
 ## Langfristige Vision
 
+**Hinweis:** Der Kerngedanke dieser Vision – Distributionspakete werden nicht auf dem Medium mitgeführt, sondern je Installation aus dem Netz gezogen – bleibt mit `ADR-0003` unverändert bestehen. Für den interaktiven, gebrandeten Ablauf wurde dort jedoch bewusst ein volles Live-Medium statt eines minimalen Boot-Mediums gewählt (siehe `architecture/13-live-provisioning-boot.md`); das Medium selbst wird dadurch größer, nicht die mitgeführten Installationsdaten der Distribution. Dieser größere Fußabdruck wird für die damit gewonnenen UX-Möglichkeiten bewusst in Kauf genommen.
+
 Der Installer soll kein klassisches Installationsmedium sein.
 
 Langfristig enthält er nur noch die Komponenten, die zum Starten eines Geräts erforderlich sind (Bootloader, Kernel, initrd). Alle weiteren Daten werden über den Provisioning Server bereitgestellt.