diff --git a/adr/0009-anaconda-live-kickstart-verworfen.md b/adr/0009-anaconda-live-kickstart-verworfen.md
index c3a3a7b..ced4502 100644
--- a/adr/0009-anaconda-live-kickstart-verworfen.md
+++ b/adr/0009-anaconda-live-kickstart-verworfen.md
@@ -160,3 +160,15 @@ Das ist keine Entscheidung gegen Fedora als Backend grundsätzlich — die Fedor
 **Für die Fortsetzung mit Mint/Ubuntu gilt dasselbe, in diesem ADR erarbeitete Architekturmodell** (personalisierte ISO pro Workspace/Backend/Medienvariante, Kickstart/Autoinstall bereits eingebacken, `network`-Direktiven im Installationsschritt selbst vermeiden, Provisioning Agent übernimmt WLAN/Handshake/Blueprint-Anwendung beim ersten Boot des fertig installierten Systems) — nur mit Ubuntus/Mints eigenem Installer-Stack (Subiquity/Autoinstall oder Ubiquity/Preseed, siehe Prüfplan weiter oben, Schritt 1 „welchen Installer bringt Mint mit" ist damit jetzt wieder relevant und weiterhin ungeklärt) statt Anaconda/Kickstart.
 
 **Nächster Schritt:** dasselbe empirische Vorgehen wie hier für Fedora — realer Test auf derselben Notebook-Hardware, sobald der Nutzer bereit ist weiterzumachen. Nicht proaktiv fortsetzen, ohne dass der Nutzer das wieder aufgreift.
+
+## Update (31.07.2026): Mint/Ubiquity real getestet — WLAN und Live-Kontakt zu anode funktionieren während der Installation
+
+Schritt 1 aus dem ursprünglichen Prüfplan ist geklärt: Linux Mint (Cinnamon) nutzt **Ubiquity** (nicht Subiquity, das ist Ubuntu-Server-spezifisch), mit klassischem Debian-Installer-Preseed-Format (`d-i <template> <type> <wert>`). Automatisierter Modus über den Kernel-Parameter `automatic-ubiquity` zusammen mit `file=/cdrom/preseed/<datei>.seed` (Preseed-Datei direkt auf dem Medium, analog zu Fedoras `inst.ks=cdrom:/ks.cfg`).
+
+**Struktureller Unterschied zu Fedora, der sich als entscheidend herausstellte:** Ubiquitys automatisierter Modus bootet weiterhin über `boot=casper` — dasselbe Live-Environment wie die normale interaktive Live-Sitzung, kein separates, abgespecktes Installer-Environment wie Anacondas Netinstall/DVD-Stage2. Damit entfällt die Fedora-typische Treiberlücke von vornherein: Das Boot-Medium (`linuxmint-22.3-cinnamon-64bit.iso`) hat außerdem keine versteckte zweite FAT-ESP-Partition mit eigenem `grub.cfg` — `/boot/grub/grub.cfg` im ISO9660-Baum ist die einzige, tatsächlich gelesene Konfigurationsdatei, kein Analogon zu Fedoras `BOOT.conf`-Falle.
+
+**Realer Test:** Preseed-Datei mit `ubiquity/success_command` (läuft `in-target`/chrooted, nach Paketinstallation, vor Neustart) — der Befehl führt `nmcli device wifi connect stallinux password ...` aus und ruft danach `https://anode.tuxflotte.de/health` per `curl` auf. Ergebnis: WLAN verbindet sich erfolgreich (`wlp9s0` → `connected`, echter Intel-AX210-Chip auf derselben Testhardware, die bei Fedora gar kein Interface fand), und `curl` liefert eine echte Antwort vom Provisioning-Server zurück (`{"status":"ok","service":"provisioning-server","version":"0.1.0"}`). Damit ist zum ersten Mal in dieser gesamten Untersuchung ein **echter, funktionierender Live-Kontakt zur Plattform während der Installation** demonstriert — nicht nur eine post-install Möglichkeit.
+
+**Beobachtung mit Konsequenz:** Nach dem Neustart ins fertig installierte System war die WLAN-Verbindung nicht mehr vorhanden, der Nutzer musste sich erneut verbinden. Wahrscheinliche Ursache: `in-target` chrootet zwar die Dateisystem-Sicht des Kommandos, aber `nmcli` sprach dabei vermutlich weiterhin mit dem laufenden NetworkManager-Dienst der **Live-Sitzung** (über den gemeinsam gemounteten `/run`), nicht mit einer Instanz, die für das Zielsystem persistent schreibt — das Verbindungsprofil landete dadurch im flüchtigen Live-Medium, nicht auf der installierten Platte. Für Persistenz muss die `.nmconnection`-Datei zusätzlich **direkt als Dateioperation** ins gechrootete `/etc/NetworkManager/system-connections/` geschrieben werden (dieselbe Technik, die für Fedora schon durchdacht, aber nie real getestet wurde) — reines `nmcli connect` reicht für die Installation selbst (bewiesen), aber nicht für Persistenz über den Reboot hinaus.
+
+**Einordnung:** Das eröffnet für das Mint-Backend eine echte Alternative zum bisher erarbeiteten Modell (alles auf den Provisioning Agent nach dem ersten Boot verschieben) — Installationsvorgaben könnten dynamisch zur Installationszeit von `anode` geholt werden, statt vollständig vorab in die personalisierte ISO eingebacken zu sein. Ob das tatsächlich so umgesetzt wird, ist noch nicht entschieden, nur als real funktionierende Möglichkeit bestätigt.