docs: ADR-0023-Nachtrag - AT-SPI-Autoklicker fertig+verifiziert, neuer partman-rebuild-cache-Blocker gefunden

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

adr/0023-ubiquity-priority-critical-fuer-echte-stille.md

@@ -333,3 +333,99 @@ robusteste Lösung wäre AT-SPI (Accessibility-API) statt Pixel-/Fenster-
 Heuristik - findet Buttons über ihre Rolle ("Push Button") und ihren
 (übersetzten) Namen, unabhängig von X11-Fensterüberlappung. Nicht
 recherchiert, da Zeitrahmen dieser Sitzung erschöpft.
+
+## Nachtrag (29.08.2026): AT-SPI-Autoklicker gebaut, live verifiziert -
+## neuer, tieferer Blocker in ubi-partman.py selbst gefunden
+
+**AT-SPI-Umbau, Status: fertig und live verifiziert.** `autoclicker.sh`
+klickt jetzt über die Linux-Barrierefreiheits-API (`python3-pyatspi`)
+statt über Bildschirmkoordinaten/Enter-Taste:
+
+- `live-updates/usr/share/ubiquity/tuxflotte-atspi-env.sh` (neu, per
+  Ein-Zeilen-Sed-Patch in `start-ubiquity-dm` eingebunden, *vor* dem
+  GTK-Start von Ubiquity, da die Bruecke sich nachtraeglich nicht mehr
+  laden laesst): aktiviert `GTK_MODULES=gail:atk-bridge`, startet bei
+  Bedarf einen Session-Bus (`dbus-launch`) und `at-spi-bus-launcher`.
+- `live-updates/opt/tuxflotte/scripts/atspi_click.py` (neu): findet den
+  zu klickenden Button ueber Rolle (`PUSH_BUTTON`) im Accessibility-Baum.
+  **Wichtig, real beim Testen entdeckt:** trotz festem
+  `debian-installer/language=de` ist nicht jede Seite deutsch beschriftet
+  - die Mint-eigene "Multimedia-Codecs"-Seite zeigt reale englische
+  Buttons ("Quit"/"Back"/"Continue"), vermutlich derselbe fehlende
+  .mo-Uebersetzungskatalog wie beim schon gepatchten
+  ubi-prepare.py-None-Bug (siehe oben). Eine anfaengliche reine deutsche
+  Werteliste blieb dort haengen. Umgestellt auf eine sprachunabhaengige
+  Strategie: bekannte rueckwaerts-/abbrechende Beschriftungen (zweisprachig)
+  werden ausgeschlossen, von den verbleibenden Kandidaten wird bevorzugt
+  wer eine bekannte vorwaerts-Beschriftung traegt, sonst der einzige
+  uebrige Kandidat (Sole-Survivor-Regel); bei echter Mehrdeutigkeit wird
+  bewusst NICHT geklickt.
+- **Live-Beleg, dass AT-SPI selbst zuverlaessig funktioniert:** Log zeigt
+  103 aufeinanderfolgende, korrekt erkannte Klicks auf "Jetzt
+  installieren" im 2-Sekunden-Takt, ueber mehrere Minuten, ohne einen
+  einzigen Fehlklick. Die Fenstergeometrie-/Dekorationsprobleme, an denen
+  der xdotool-Ansatz scheiterte, treten mit AT-SPI nicht mehr auf.
+
+**Nebenfund beim Testen, live gefixt:** der Kexec-Append in
+`backend_launch()` setzte anders als der Grub-Eintrag des ersten Boots
+kein `username=`/`hostname=` - dadurch verlangte der Live-Nutzer beim
+zweiten (Kexec-)Boot ein echtes, unbekanntes Passwort statt des sonst
+leeren Live-Session-Passworts (fuer den GTK-Assistenten selbst
+folgenlos, erschwerte aber die Fehlersuche via Konsole unnoetig). Fix:
+`username=mint hostname=mint` ergaenzt, Konsistenz zum ersten Boot
+wiederhergestellt.
+
+### Neuer, tieferer Blocker (noch offen): `ubiquity/partman-rebuild-cache`
+### fuehrt nach erfolgreichem Klick zurueck in die Partitionierung
+
+Mit funktionierendem AT-SPI-Klick wurde ein neues, von der Klick-Technik
+unabhaengiges Problem sichtbar: der Klick auf "Jetzt installieren" auf der
+manuellen Partitionierungsseite ("Etwas Anderes" - Ubiquity zeigt diese
+Seite fuer jedes nicht eingebaute/custom `expert_recipe`, korrektes
+Verhalten) wird tatsaechlich ausgefuehrt und fuehrt laut
+`/var/log/installer/debug` nachweislich in den Erfolgspfad
+(`grub-installer/bootdev seen` wurde erreicht - das passiert laut
+Quelltext direkt nach `self.finish_partitioning = True; self.succeeded =
+True; self.exit_ui_loops()`), aber kurz danach springt der Installer
+zurueck in dieselbe Partitionierungsseite, und der Autoklicker beginnt
+von vorn - ueber 100 Zyklen beobachtet, ohne jemals durchzukommen.
+
+Quelltext-Analyse (`/usr/lib/ubiquity/plugins/ubi-partman.py` auf dem
+Live-Medium, per Konsole gelesen) zeigt die Ursache strukturell:
+
+```python
+def rebuild_cache(self):
+    assert self.current_question == 'partman/choose_partition'
+    self.building_cache = True
+```
+
+aufgerufen, wann immer Debconf die Frage `ubiquity/partman-rebuild-cache`
+stellt (Zeile ~2195: `if question == 'ubiquity/partman-rebuild-cache':`).
+Diese Frage kommt von partmans eigenen Shell-Skripten (nicht von
+ubi-partman.py selbst), noch nicht bis zur Quelle zurueckverfolgt, ob
+partman sie hier zu Recht/wiederholt stellt oder ob unser eigenes
+`expert_recipe` (insb. das `$reusemethod{ }`-Flag auf der ESP-Stanza,
+siehe `_tuxflotte_render_partman_recipe()` - laut Code-Kommentar dort
+bewusst aus der eingebauten "atomic"-Recipe uebernommen, weil ohne dieses
+Flag die ESP frueher nicht als gueltig erkannt wurde) eine partman-interne
+Neubewertung immer wieder auf "muss neu validiert werden" kippen laesst.
+
+**Wichtig fuer die weitere Suche:** dieser Loop ist strukturell derselbe
+wie der oben (Fix 3) bereits dokumentierte `choose_partition`/
+`building_cache`-Loop, tritt hier aber nachweislich auch bei einem
+tatsaechlichen, korrekten GTK-Klick auf (nicht nur bei direktem
+Preseeden einer Debconf-Antwort ohne echten Seitenaufbau) - die Ursache
+liegt also tiefer in partmans eigener Zustandsverwaltung bzw. in unserem
+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):
+(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.