diff --git a/adr/0023-ubiquity-priority-critical-fuer-echte-stille.md b/adr/0023-ubiquity-priority-critical-fuer-echte-stille.md
index 717c24d..d5d9436 100644
--- a/adr/0023-ubiquity-priority-critical-fuer-echte-stille.md
+++ b/adr/0023-ubiquity-priority-critical-fuer-echte-stille.md
@@ -421,11 +421,49 @@ Rezept, nicht (nur) im Preseed-Mechanismus.
 **Status:** AT-SPI-Klick-Mechanismus als Aufgabe abgeschlossen und
 verifiziert - die verbleibende Blockade ist ein eigenstaendiges,
 partman-internes Problem, keine Klick-Zuverlaessigkeitsfrage mehr.
-Naechste sinnvolle Schritte (nicht mehr in dieser Sitzung verfolgt):
+
+### Getestete Hypothese, WIDERLEGT: `$bootable{ }` auf der Root-Partition
+
+Vermutung: die Original-Recipe `/usr/lib/partman/recipes-amd64-efi/30atomic`
+(Quelle unserer ESP-Stanza) markiert im UEFI-Fall NUR die ESP als boot-
+faehig (`method{ efi }`), nicht zusaetzlich die Root-Partition - unser
+Rezept setzte dagegen unbedingt `$primary{ } $bootable{ }` auf Root,
+unabhaengig von EFI/BIOS. `_tuxflotte_render_partman_recipe()` entsprechend
+angepasst (`root_extra_flags` bedingt: kein `$bootable{ }` mehr im
+EFI-Zweig, weiterhin gesetzt im BIOS-Zweig, wo keine ESP existiert).
+
+**Live getestet (29.08.2026) - Ergebnis: KEIN Unterschied.** Nach dem Fix
+weiterhin exakt dasselbe Verhalten: Autoklicker-Log zeigt 119
+aufeinanderfolgende Klicks auf "Jetzt installieren" ohne jeden
+Fortschritt, identisch zum Verhalten vor dem Fix. Die Aenderung bleibt im
+Code (harmlos, entspricht der Original-Recipe und ist an sich korrekter),
+loest aber nicht das eigentliche Problem - `$bootable{ }` auf Root war
+NICHT die (alleinige) Ursache des Loops.
+
+**Nebenfund waehrend dieses Testlaufs:** der zum Testen verwendete
+Aktivierungscode (enrollment_sessions.id, Liebherr-Org) erschoepfte real
+sein Kontingent (`devices_used = max_devices = 20`) nach den vielen
+Testlaeufen dieser Sitzung - `/activate` schlaegt dann mit
+"invalid_activation_code" fehl, obwohl der Code selbst nicht abgelaufen
+oder widerrufen ist (siehe `find_enrollment_session()` in
+`provisioning-server/app.py`). Kein Bug, aber fuer weitere Testrunden
+relevant: entweder `recharge_enrollment_session()`-Semantik per direktem
+`UPDATE enrollment_sessions SET max_devices = max_devices + N` nachbilden,
+oder von vornherein mit einem grosszuegigen `max_devices` fuer
+Testsessions arbeiten.
+
+**Naechste sinnvolle Schritte (nicht mehr in dieser Sitzung verfolgt):**
 (a) die partman-Shell-Skripte (nicht nur ubi-partman.py) daraufhin
-durchsuchen, was `ubiquity/partman-rebuild-cache` stellt und ob es an
-`$reusemethod{ }` auf einer frischen/leeren Platte haengt, oder (b)
-pruefen, ob eine der eingebauten Recipes (z. B. "atomic" direkt statt
-eines eigenen `expert_recipe`) fuer unsere Anforderungen ausreicht und
-damit die manuelle "Etwas Anderes"-Seite (und ihre rebuild-cache-
-Interaktion) ganz umgeht.
+durchsuchen, was `ubiquity/partman-rebuild-cache` sonst noch ausloesen
+koennte (`$reusemethod{ }` auf der ESP selbst ist noch nicht einzeln
+getestet - nur die Root-Flags wurden bisher angepasst), (b) pruefen, ob
+eine der eingebauten Recipes (z. B. "atomic" direkt statt eines eigenen
+`expert_recipe`) fuer unsere Anforderungen ausreicht und damit die
+manuelle "Etwas Anderes"-Seite (und ihre rebuild-cache-Interaktion) ganz
+umgeht, oder (c) untersuchen, ob AT-SPIs `doAction(0)` auf dem Button
+tatsaechlich denselben Codepfad ausloest wie ein echter Mausklick (das
+Debug-Log erreichte in einem frueheren Testlauf einmalig
+"grub-installer/bootdev seen", also einen Schritt NACH der
+Partitionierung - dieser Fortschritt trat aber nur einmal auf und wurde
+seither nicht reproduziert, was auf einen nicht-deterministischen Faktor
+hindeutet statt auf einen stets gleich reproduzierbaren Blocker).