diff --git a/adr/0009-anaconda-live-kickstart-verworfen.md b/adr/0009-anaconda-live-kickstart-verworfen.md
index ced4502..8ba1d4b 100644
--- a/adr/0009-anaconda-live-kickstart-verworfen.md
+++ b/adr/0009-anaconda-live-kickstart-verworfen.md
@@ -172,3 +172,13 @@ Schritt 1 aus dem ursprünglichen Prüfplan ist geklärt: Linux Mint (Cinnamon)
 **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.
+
+### Nachtrag (31.07.2026): Persistenz-Fix real getestet — mit einer wichtigen Nebenerkenntnis zu Debconf-Preseed selbst
+
+Der direkte Dateischreib-Ansatz aus dem Absatz oben wurde als eigener, mehrzeiliger `ubiquity/success_command`-Preseed-Wert getestet (Aufbau, Berechtigungen setzen, `.nmconnection`-Inhalt per `printf` schreiben) — Ergebnis: **kein Log, keine Datei**, obwohl derselbe Bash-Code lokal fehlerfrei lief (`bash -n`/tatsächliche Ausführung geprüft). Der komplette `success_command`-Aufruf wurde also offenbar nie ausgeführt, nicht einmal die erste `echo`-Zeile — ein reiner Bash-Syntaxfehler war damit ausgeschlossen, die Ursache lag also vermutlich an Debconfs Preseed-Zeilenverkettung selbst (viele verschachtelte Anführungszeichen/eckige Klammern über mehrere per `\` fortgesetzte Zeilen hinweg), nicht am Skriptinhalt.
+
+**Fix:** Das komplette Skript Base64-kodiert, `success_command` reduziert auf eine einzige, kurze Zeile ohne jegliche Sonderzeichen: `in-target bash -c 'echo <base64> | base64 -d | bash'`. Damit lief alles fehlerfrei durch — WLAN verbindet sich per `nmcli` während der Installation, `curl` erreicht `anode`, und die `.nmconnection`-Datei landet korrekt (`600`, `root:root`, richtiger Inhalt) auf der Zielplatte unter `/target/etc/NetworkManager/system-connections/` (verifiziert vor dem Reboot, da `ubiquity/reboot boolean false` gesetzt wurde, um genau das zu prüfen, bevor die Live-Sitzung verschwindet).
+
+**Für spätere `success_command`/`late_command`-Preseed-Werte festhalten:** lange, mehrzeilige, stark verschachtelte Preseed-Werte sind riskant und scheitern ohne hilfreiche Fehlermeldung — Base64-Kodierung des eigentlichen Skripts ist der robustere, empfohlene Weg, nicht nur ein Notbehelf für diesen einen Fall.
+
+Ob die WLAN-Verbindung nach einem echten Reboot ins fertig installierte System jetzt automatisch (ohne erneute Passworteingabe) steht, ist der letzte noch ausstehende Prüfschritt.