docs: WLAN driver gap on netinstall forces rethink of the auto-mode boot flow

Real hardware test (Intel AX210) shows the tested Fedora Everything
netinstall initrd ships no iwlwifi driver at all -- three kickstart
variants all hung identically at dracut-initqueue regardless of syntax,
confirming the cause was never the kickstart itself. Documents the
kexec test series (ADR-0009), the DB-driven kickstart success on
netinstall, and the resulting architecture: a personalized installer
ISO per workspace/backend/media-variant with the kickstart baked in,
no live-session/kexec transition, WLAN and blueprint application moved
to the Provisioning Agent's first boot on the fully installed target
system instead of the constrained installer environment.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

adr/0009-anaconda-live-kickstart-verworfen.md

@@ -53,6 +53,59 @@ Offener Punkt dabei: das Medium ist laut WLAN-Autoprovisionierungs-Entscheidung
 3. Nur falls Schritt 2 scheitert: dasselbe Reboot-Muster mit dem in Schritt 1 geklärten Ubuntu/Mint-Mechanismus.
 4. Nur falls auch das scheitert: die unten konkretisierte Ultima Ratio.
 
+## Update (29.–30.07.2026): Schritt 2 real getestet und gescheitert — direkter Wechsel zur Ultima Ratio
+
+Schritt 2 (Fedora + Kickstart per Reboot) wurde real in einer Proxmox-VM getestet, nicht per Firmware-Reboot, sondern per `kexec` (siehe Begründung unten) — mit eindeutig negativem, aber sauber erklärbarem Ergebnis.
+
+**Testaufbau:** `kexec -l`/`kexec -e` aus der laufenden Live-Sitzung heraus, um denselben Kernel mit neuer Kernel-Cmdline zu starten, ohne den Umweg über GRUB — das reguläre Live-Medium ist bewusst nicht dauerhaft beschreibbar, GRUB liest seine Config also bei jedem echten Reboot ohnehin nur wieder vom unveränderten Medium. `kexec` umgeht dieses Problem vollständig, da kein Firmware-/GRUB-Durchlauf nötig ist.
+
+**Versuch 1:** `root=live:CDLABEL=TUXFLOTTE rd.live.image ... inst.ks=file:/tuxflotte-ks.cfg` (Kickstart-Datei direkt als zusätzliches cpio-Archiv ans Initrd angehängt). Ergebnis: kexec-Sprung fand nachweislich statt (kein Firmware-/GRUB-Screen, X-Server brach weg, neue Boot-Infozeilen), landete aber unverändert im normalen Live-Desktop (Epiphany) — `inst.ks=` wurde ignoriert.
+
+**Versuch 2:** dieselbe Cmdline, aber Kickstart-Zustellung per `inst.ks=https://...` (bestehender Endpunkt auf `anode`, s.u.) statt per Initrd-Anhang, um eine mögliche Ursache (fehlerhafte cpio-Verkettung) auszuschließen. Vorher wurde tatsächlich ein Initrd-Verkettungsfehler beobachtet (`initramfs unpacking failed: invalid magic at start of compressed archive` — vermutlich weil das Basis-Initrd xz-/zstd-komprimiert ist und sich anders als ein Gzip-Initrd nicht einfach per `cat` verketten lässt); die Zustellung per HTTPS umgeht dieses Nebenproblem vollständig, ändert am Kernbefund aber nichts.
+
+**Versuch 3:** `inst.stage2=hd:LABEL=TUXFLOTTE:/ ... inst.ks=https://...` **ohne** `root=live`/`rd.live.image`, in der Annahme, dass Letzteres Dracuts `dmsquash-live`-Pfad erzwingt und `inst.ks=` dabei grundsätzlich übergangen wird. Ergebnis: Dracut Emergency Shell, `Warning: Can't mount root-filesystem` — ohne `root=live` gab es gar keine auflösbare Root-Definition mehr, `inst.stage2=hd:LABEL=...` konnte sie nicht ersetzen.
+
+**Entscheidender Befund:** `lsinitrd /run/initramfs/live/boot/x86_64/loader/initrd | grep -i anaconda` liefert **keinen Treffer**. Das `anaconda`-Dracut-Modul, das `inst.ks=`/`inst.stage2=` überhaupt erst auswerten und auf `anaconda.service` statt auf den normalen Live-Desktop umschalten würde, ist in diesem Initrd schlicht nicht enthalten. Das erklärt beide Fehlschläge ursächlich und einheitlich: keine Kombination von Boot-Parametern kann etwas bewirken, das im Initrd gar nicht als Auswertungslogik vorhanden ist. Dies ist keine Cmdline-Syntax-Frage, sondern eine strukturelle Eigenschaft des Fedora-Cinnamon-Live-Images (vermutlich, weil Live-Spins mit `dmsquash-live` gebaut werden, aber nicht zwangsläufig mit dem für Netinst-/DVD-Medien gedachten `anaconda`-Modul).
+
+**Entscheidung (30.07.2026):** Schritt 3 (Mint/Ubuntu-Reboot-Test) wird bewusst ausgelassen, nicht aus Zeitmangel, sondern weil dieselbe strukturelle Ursache dort ebenfalls plausibel erscheint (Ubuntu-Desktop-Live-Images/Casper und Mint-Editionen bringen ihre unbeaufsichtigten Installationswege (Subiquity/Preseed) typischerweise auf einem separaten Server-/Netinst-Image, nicht im Desktop-Live-ISO) — diese Vermutung wurde nicht empirisch geprüft, ist aber Grundlage der Entscheidung, direkt zur unten stehenden Ultima Ratio überzugehen, statt einen strukturell vermutlich gleich ausgehenden Test zu wiederholen.
+
+Nebenbefund ohne Bezug zum eigentlichen Test: Für die Zustellung in Versuch 2/3 wurde vorübergehend der bestehende, bereits produktiv genutzte Endpunkt `https://anode.tuxflotte.de/installers/fedora-workstation/ks.cfg` mit einer Testdatei überschrieben (Original gesichert unter `ks.cfg.bak-2026-07-29`) und muss vor einer erneuten Nutzung dieses Endpunkts wiederhergestellt werden.
+
+## Update (30.07.2026): Ultima Ratio, Schritt 1a real bestätigt
+
+Erster kleinster Ausschnitt der Ultima Ratio (siehe unten) real getestet, nicht mit synthetischen Testwerten, sondern mit den tatsächlichen DB-Daten: `POST /api/v1/activate` mit dem echten Aktivierungscode `LAB-2026-START` gegen die laufende `provisioning-server`-Instanz auf `anode`, danach `POST /api/v1/templates/{id}/resolve` für die Fedora-Bereitstellungsvorlage (`Schulcomputer (Fedora)`) — liefert den echten `runtime_blueprint` mit den drei realen Blueprints (`guest-session-ephemeral`/`guest-session`, `browser-brave`/`brave-fedora`, `office-onlyoffice`/`onlyoffice-fedora`).
+
+Dieser `runtime_blueprint` wurde mit derselben `envsubst`-Logik wie `backend_generate_config()` (nur serverseitig statt geräteseitig ausgeführt) in `kickstart.tpl` eingesetzt und testweise wieder über `https://anode.tuxflotte.de/installers/fedora-workstation/ks.cfg` ausgeliefert (Original erneut gesichert und danach wiederhergestellt). Boot-Medium diesmal ein reguläres **Fedora-Netinstall-ISO** (nicht das Live-/Cinnamon-Image), `inst.ks=https://...` klassisch über die GRUB-Bootzeile gesetzt — derselbe Weg, der schon beim Meilenstein vom 16.06.2026 funktioniert hat, jetzt aber mit aktuellem DB-Stand statt der alten `config.json`.
+
+**Ergebnis:** vollautomatischer Durchlauf, Login danach funktioniert, `rootpw`/`user` vollständig übernommen — genau der Fehler, an dem die live-Session-Variante in diesem ADR ursprünglich gescheitert ist, tritt hier nicht auf. Damit ist die Kernannahme der Ultima Ratio bestätigt: der native Installer lässt sich zuverlässig unattended betreiben, wenn er über seinen offiziell unterstützten Weg (Netinstall-Medium + `inst.ks=`) und nicht aus einer Live-Sitzung heraus gestartet wird.
+
+Schritt 1 (Mint-Installer-Typ klären) aus dem ursprünglichen Prüfplan bleibt weiterhin offen, ist für die Ultima Ratio aber ohnehin separat zu klären (jede Distribution bekommt ihr eigenes Backend/ihre eigene Installer-Logik).
+
+**Offen, nächster Schritt:** Dieser Test lief auf einer Proxmox-VM mit virtio/DHCP — die reale Zielhardware (Pilotschulen) hat vermutlich nur WLAN. `inst.ks=https://...` erfordert Netzwerk bereits im frühen Dracut-Boot der Netinstall-Umgebung, bevor die Kickstart-Datei geladen werden kann — ob und wie WPA/WLAN dort ohne bereits laufendes NetworkManager funktioniert, ist exakt dieselbe unbeantwortete Frage wie schon beim ursprünglichen Live-Boot-Ansatz, hier nur erneut aufgeschoben statt gelöst. Als Nächstes vereinbart: WLAN-Autoprovisionierung (Baken der NetworkManager-Zugangsdaten ins Image, siehe „WLAN-Zugangsdaten" oben) real auf echter Hardware (Notebook) testen.
+
+## Update (30.07.2026): WLAN-Test auf echter Hardware — Ursache gefunden, kein Kickstart-Problem
+
+Realer WLAN-Test auf einem Notebook (Intel-Hardware) mit einem angepassten Fedora-Everything-Netinstall-ISO, `ks.cfg` direkt auf dem Medium (`inst.ks=cdrom:/ks.cfg`, keine Netz-Zustellung nötig). Drei Kickstart-Varianten der Reihe nach real getestet, alle mit identischem Ergebnis (`dracut-initqueue.service` hängt unbegrenzt):
+
+1. `network --device=wlan0 --essid=... --wpakey=... --activate`
+2. Dieselbe Zeile ohne `--activate`
+3. Gar keine WLAN-Angabe mehr in der `network`-Zeile, stattdessen `nmcli device wifi connect ...` in einem `%pre`-Skript (das laut Kickstart-Ablauf erst in Anacondas vollerem `install.img`-Environment läuft, nach dem Stage2-Laden)
+
+Da auch Versuch 3 identisch hängt, obwohl er gar kein WLAN mehr in der Dracut-verarbeiteten Kickstart-Direktive referenziert, war die Ursache nie die genaue Kickstart-Syntax.
+
+**Diagnose per `rd.break=initqueue`** (Dracut-Haltepunkt, öffnet eine Shell direkt auf der Hauptkonsole, kein Konsolenwechsel nötig — relevant, weil auf diesem Notebook `Strg+Alt+F2` nicht funktionierte): `ip link show` zeigt nur Loopback und die kabelgebundene Ethernet-Schnittstelle, **kein WLAN-Interface**. `nmcli device status` zeigt konsequent kein WLAN-Gerät. Über `/sys/bus/pci/devices/` und `/sys/bus/usb/devices/` wurde die Hardware identifiziert: Intel AX210 (PCI `8086:2725`, Wi-Fi 6E), Bluetooth-Teil per USB (`8087:0032`) — ein verbreiteter, unter Linux gut unterstützter Chip.
+
+**Root cause:** Das Boot-Initrd dieses Fedora-Everything-Netinstall-ISOs (`images/pxeboot/initrd.img`) enthält **keinen `iwlwifi`-Treiber** (kein `iwlwifi.ko` im gesamten Initrd, keine zugehörige Firmware) — die einzigen enthaltenen WLAN-Treiber sind aus der MediaTek-`mt76`-Familie (`mt7921`/`mt76-sdio` etc.). `cfg80211`/`mac80211` (der generische 802.11-Stack) sind vorhanden, aber ohne passenden Hardware-Treiber wirkungslos. Das ist eine Lücke im offiziellen Fedora-Netinstall-Image selbst, nicht Folge irgendeiner eigenen Anpassung — kein Kickstart- oder Boot-Parameter-Trick kann einen im Initrd schlicht fehlenden Kernel-Treiber ersetzen.
+
+**Einordnung:** Alle drei Kickstart-Versuche waren strukturell zum Scheitern verurteilt, unabhängig von ihrer jeweiligen Begründung — das Problem lag nie in der Kickstart-Syntax, sondern eine Ebene tiefer, im Treiberumfang des Boot-Mediums selbst. Damit bleibt die Kernaussage des vorherigen Updates unverändert gültig (Kickstart-getriebene, unattended Installation über den offiziellen Netinstall-Weg funktioniert, siehe DB-Blueprint-Test), aber die WLAN-Frage ist auf einer anderen Ebene offen als angenommen.
+
+**Nicht mitgetestet, aber relevant:** Ob das Intel-AX210-Beispiel repräsentativ für tatsächliche Pilotschul-Hardware ist, ist unbekannt — dieser Test lief auf dem persönlichen Notebook des Nutzers, nicht auf Zielhardware. Möglich, dass andere Geräte (z.B. mit MediaTek-Chips) mit genau diesem Image bereits funktionieren würden.
+
+**Optionen für den nächsten Schritt (noch nicht entschieden):**
+1. `iwlwifi`-Treiber und passende Firmware nachträglich ins Netinstall-Initrd einbauen (echte Lösung der Ursache, aber Initrd-Chirurgie mit eigenem Risiko — das naive Anhängen eines weiteren Initrd-Segments per `cat` scheiterte schon einmal an Kompressionsformat-Fragen, siehe Update vom 29.–30.07.2026 oben; ein sauberer Fix müsste entpacken/ergänzen/neu komprimieren statt nur anhängen).
+2. Ein anderes Fedora-Installationsmedium mit breiterer Treiberabdeckung testen (z.B. eine reguläre Fedora-Workstation-Netinstall/DVD-Variante, die ggf. großzügiger bestückt ist).
+3. Klären, welche WLAN-Chips die tatsächliche Pilotschul-Hardware mitbringt, bevor weiter am Treiberumfang gearbeitet wird — falls diese Hardware ohnehin andere Chips hat, wäre dieser konkrete Fund für die Praxis nicht blockierend.
+
 ## Ultima Ratio (konkretisiert 23.07.2026): personalisierte, vorentschiedene Installer-ISO
 
 Falls sich zeigt, dass sich der native Installer generell nicht zuverlässig aus einer Live-Sitzung heraus (auch nicht per Reboot mit dynamisch nachgeladener Konfiguration) automatisieren lässt, verschiebt dieser Weg die Workspace-/Backend-Entscheidung komplett **vor** den Boot-Vorgang, auf die zentrale Plattform:
@@ -74,3 +127,13 @@ Die Staging-Partition ist dabei bewusst **kein dauerhafter Sonderbereich**: Soba
 Für einen späteren Workspace-/Distributionswechsel muss die Staging-Partition nicht dauerhaft bestehen bleiben — sie wird beim nächsten Wechsel einfach neu angelegt. Sobald der Provisioning Agent existiert, könnte dieser das komplett von innerhalb des laufenden, installierten Systems selbst anstoßen (neue ISO laden, Partition neu befüllen, Boot-Eintrag setzen, Reboot auslösen) — echte Remote-Reprovisionierung ganz ohne erneuten physischen Medienzugriff.
 
 **Einordnung:** dieser verfeinerte Weg ist mehr als nur eine Umgehung des Anaconda-Live-Problems — er vereinfacht die Gesamtarchitektur spürbar. Die gesamte Kategorie an Problemen der letzten Tage (Cinnamon-Panel-Defaults, Epiphany-Versionsunterschiede, dconf-Wettlaufbedingungen, EROFS-Umgehung für ein volles Live-Image) entsteht ausschließlich dadurch, dass eine volle Live-Desktop-Umgebung betrieben werden muss — ein schlankes Bootstrap-Medium braucht das nicht. Er passt zudem besser zur Grundphilosophie ("Tuxflotte installiert keine Distributionen, sondern orchestriert die nativen Installer") als der bisherige Ansatz: Tuxflottes eigener Code bleibt distributionsunabhängig (ISO holen, staging, per Loopback booten), alles Distributionsspezifische bleibt beim jeweiligen nativen Installer in dessen eigener, offiziell unterstützter Automatisierung.
+
+### Präzisierung (30.07.2026): Bootstrap-Medium muss hardwaretechnisch breit sein, nicht nur schlank
+
+Der reale WLAN-Test oben deckt eine unausgesprochene, falsche Gleichsetzung in der Verfeinerung auf: „schlank" und „hardwaretechnisch breit aufgestellt" wurden implizit als dasselbe behandelt, sind aber zwei unabhängige Eigenschaften. Das schmal gebaute Fedora-Netinstall-Initrd spart Größe gerade durch Verzicht auf breite Treiber-/Firmware-Abdeckung (`iwlwifi` fehlt komplett, siehe oben) — für ein Bootstrap-Medium, dessen einziger Zweck „auf möglichst jeder Hardware ein Netzwerkinterface finden" ist, ist genau das fatal.
+
+**Präzisierte Anforderung:** Das Bootstrap-Medium sollte auf einem hardwaretechnisch breit ausgestatteten Live-Image basieren (Fedora- oder Ubuntu-Live-artig, mit vollem Firmware-/Treiberumfang), nicht auf einem schlanken Netinstall-Image. Das widerspricht der ursprünglichen Verfeinerung nicht in der Sache, sondern korrigiert nur eine unausgesprochene Annahme darin: „schlank" sollte sich von Anfang an nur auf die UI-Schicht beziehen (kein Fenstermanager, kein Kiosk-Browser, kein Panel, kein dconf) — genau die Problemklasse, die die Verfeinerung zurecht vermeiden wollte, bleibt vermieden, solange das Bootstrap-Medium headless/terminal-only läuft. Das ist orthogonal zur Treiberbreite, nicht identisch damit.
+
+**Konkrete Anknüpfung:** Das bestehende, real geprüfte Fedora-Cinnamon-Live-Image ist ein plausibler Ausgangspunkt für das Bootstrap-Medium selbst — WLAN, Server-Handshake, Aktivierung und Bereitstellungsvorlage-Auflösung laufen darauf bereits nachweislich (siehe `milestones.md`). Zu entfernen wäre nur die Kiosk-UI-Ebene (Epiphany-Autostart, Panel-Anpassungen) — die wird für den reinen Bootstrap-Zweck nicht gebraucht. Neu zu bauen ist ausschließlich der Übergangsmechanismus selbst: personalisierte Ziel-ISO vom Server laden, in eine Staging-Partition schreiben, per GRUB `loopback`/`iso-scan` dorthin booten (siehe oben) — dieser Teil existiert bisher nur als Idee, nicht als Code. Der frühere Ansatz (Kickstart aus der laufenden Live-Sitzung heraus starten, per `kexec` oder sonstwie) bleibt verworfen (siehe ADR-Titel und Updates oben).
+
+Die Basis-Distribution des Bootstrap-Mediums ist dabei unabhängig von der später installierten Ziel-Distribution wählbar — Fedora-Live zur Wiederverwendung des bereits Vorhandenen, oder Ubuntu-Live wegen möglicherweise noch breiterer Hardwareunterstützung. Offene Frage, noch nicht entschieden.

architecture/09-data-model-v1.md

@@ -161,6 +161,8 @@ Beziehungen:
 - besteht aus mehreren Merkmalen
 - wird in mehreren Bereitstellungsvorlagen referenziert
 
+**Notiz für später (30.07.2026):** Ein Workspace ist zwar distributionsunabhängig benannt, aber nicht jedes Merkmal hat für jeden Backend ein Blueprint (siehe unten). Für den noch nicht gebauten, selbst-bedienten Workspace-Creator (Kunde stellt sich einen eigenen Workspace aus Merkmalen zusammen) folgt daraus eine UX-Reihenfolge, keine Schema-Änderung: **erst Backend wählen, dann Merkmale** — die Merkmalsauswahl im Creator sollte auf `blueprints`-Zeilen für den bereits gewählten Backend gefiltert sein, damit kein Workspace entsteht, der auf der gewünschten Distribution gar nicht realisierbar ist. Nicht dringend, betrifft nur den noch nicht priorisierten Self-Service-Teil (siehe [[project-tuxflotte-pilot-roadmap]]).
+
 ## Merkmal
 
 Ein Merkmal ist eine einzelne fachliche Eigenschaft eines Workspace, distributionsunabhängig benannt (siehe `12-feature-blueprint-model.md`).

architecture/13-live-provisioning-boot.md

@@ -13,6 +13,57 @@ Siehe `ADR-0003` für die Entscheidung und ihre Begründung.
 
 ---
 
+## Status (30.07.2026): automatisierter Pfad grundlegend überarbeitet
+
+Der weiter unten beschriebene Ablauf (Live-Sitzung → `installer.sh` → `backend_launch()` aus der laufenden Sitzung heraus) ist für den **automatisierten Pfad** nicht mehr aktuell. Vollständige Herleitung und alle real getesteten Sackgassen (Anaconda-Kickstart aus der Live-Sitzung lehnt Kickstart ab; `kexec` in Anaconda scheitert am fehlenden `anaconda`-Dracut-Modul im Live-Initrd; Fedora-Netinstall-Kickstart funktioniert zwar unbeaufsichtigt, aber das getestete Netinstall-Image hatte keinen Treiber für den WLAN-Chip der Testhardware) stehen in ADR-0009.
+
+Der Rest dieses Dokuments (insbesondere „Boot-Ablauf" und „Nativer Installer aus der Live-Sitzung" weiter unten) beschreibt weiterhin den **interaktiven Pfad** (F-005, spontane Vor-Ort-Entscheidung ohne vorherige Portal-Konfiguration) — der bleibt technisch bestehen und relevant, ist aber nicht mehr der primäre Weg für automatisierte Bereitstellung.
+
+### Neuer automatisierter Ablauf
+
+```text
+Self-Service-Portal (Kunde)
+ ↓ wählt: Bereitstellungsvorlage (Workspace × Backend),
+ ↓ Medienvariante (Netinstall vs. DVD/Everything — siehe unten),
+ ↓ WLAN-Zugangsdaten (falls Autoprovisionierung gewünscht),
+ ↓ GRUB-Bootmenü-Verhalten (Timeout, Standardeintrag)
+ ↓
+Server baut personalisierte, distributionsspezifische Installer-ISO
+ ↓ (Kickstart-Datei bereits eingebacken, referenziert per
+ ↓  inst.ks=cdrom:/ks.cfg im GRUB-Bootmenü — kein Nachladen zur Laufzeit)
+ ↓
+Kunde bootet diese ISO direkt (kein Bootstrap-/Live-Zwischenschritt nötig)
+ ↓
+GRUB-Countdown (konfigurierbar) — De-facto-Bestätigungsfenster:
+ ↓ Standardeintrag startet automatisch, jede Taste vor Ablauf hält an
+ ↓
+Nativer Installer (Anaconda/Subiquity/...) startet direkt aus GRUB,
+ ↓ in seiner offiziell unterstützten, unbeaufsichtigten Betriebsart —
+ ↓ keine Live-Sitzung, kein kexec, kein Late-Binding
+ ↓
+Installation läuft durch (Partitionierung, Pakete, %post installiert
+ ↓ zusätzlich den Provisioning Agent als Paket)
+ ↓
+Reboot ins fertig installierte Zielsystem
+ ↓
+Provisioning Agent läuft erstmalig (voller Treibersatz des installierten
+ ↓ Systems, nicht des eingeschränkten Installer-Environments) —
+ ↓ stellt WLAN her, Handshake mit anode, holt Runtime Blueprint,
+ ↓ wendet es per Ansible an
+```
+
+**Warum das die bisherigen Probleme umgeht:**
+
+- Kein Übergang *innerhalb derselben Boot-Sitzung* von „interaktiv/entscheidungsfähig" zu „Installer" mehr nötig — genau dieser Übergang erforderte `kexec` und scheiterte an fehlenden Dracut-Modulen. Die Installation ist jetzt von Anfang an unbeaufsichtigt und entscheidungsfrei, weil alle Entscheidungen schon vor dem Boot im Portal getroffen wurden.
+- WLAN-Einrichtung passiert nicht mehr im eingeschränkten Installer-Initrd (schmaler Treibersatz, siehe ADR-0009), sondern erst beim ersten Boot des fertig installierten Zielsystems, mit dessen vollem, distributionsüblichem Treiberumfang.
+- Die Auto-Modus-Gate-Bestätigung (siehe unten, ADR-0008) verschiebt sich von „vor der Installation" auf „nach der Installation, vor Anwendung einer organisationsspezifischen Konfiguration": Die destruktive Installation selbst setzt nur physische Anwesenheit voraus (wer den Stick bootet, hat das bereits entschieden), die eigentlich sicherheitsrelevante Freigabe — welcher Organisation gehört dieses Gerät — bleibt bestehen, nur zeitlich auf den Agenten-Erstlauf verschoben.
+
+**Netinstall vs. DVD/Everything — Kundenwahl, kein Tuxflotte-Standard:** Beide Medienvarianten haben einen echten, sich ausschließenden Nachteil. Netinstall braucht bei der Installation selbst Netzwerk (Pakete vom Mirror) — riskant bei WLAN-only-Zielhardware, falls das Installer-Image dafür keinen passenden Treiber mitbringt (real beobachtet, siehe ADR-0009). DVD/Everything braucht dafür keine Netz zur Installationszeit, kann aber veraltet sein (Nachholbedarf beim ersten Update nach der Installation). Welche Variante sinnvoll ist, hängt vom Einsatzkontext des Kunden ab (kabelgebundene Rechner beim Erstboot vs. mobile, nur-WLAN-Geräte) — das wird deshalb als Kundenoption im Self-Service-Profil geführt, nicht als projektweite Festlegung. Tuxflotte muss beide Basis-Varianten pro Backend bauen/pflegen können, aber nicht zwangsläufig für jeden Backend sofort beide.
+
+**Agent statt Kickstart-`%post`:** Die Anwendung des Runtime Blueprints (Ansible) bleibt explizit Aufgabe des Provisioning Agent, nicht der Kickstart-`%post`-Sektion — das war schon vorher so dokumentiert (`06-backend-api.md`), wird durch dieses Update nur bestätigt, nicht neu festgelegt. Der Agent selbst ist als Paket Teil der personalisierten Installation.
+
+---
+
 ## 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.