README: Ausführung über Archiv von anode (ADR-0046), ansible-pull als Rückfall

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

README.md

@@ -1,15 +1,21 @@
 # ansible-content
 
-Ansible-Rollen, die der Tuxflotte Provisioning Agent per `ansible-pull` gegen installierte Geräte anwendet.
+Ansible-Rollen, die der Tuxflotte Provisioning Agent auf installierten Geräten anwendet.
 
 Rollennamen entsprechen 1:1 der Spalte `ansible_role` in der `blueprints`-Tabelle des Provisioning-Servers (siehe `provisioning-server/migrations/0005_seed_workspace_backend_blueprint_data.sql`).
 
 **Namenskonvention:** Der Fedora-Installer wurde zurückgestellt (Installationsprobleme, Pilot-Schulen laufen auf Mint) — aktueller Fokus liegt auf dem Management von Mint-Geräten, später weiteren Distros, ggf. auch wieder Fedora. Rollen ohne Distro-Suffix (z.B. `brave`, `onlyoffice`, `guest-session`) sind bewusst distributionsunabhängig gebaut und laufen auf jedem unterstützten Backend. Ein `-mint`-Suffix kennzeichnet eine Rolle, die tatsächlich Mint/Debian-spezifische Logik braucht (aktuell keine vorhanden). Kein Backend-Name sollte für eine Rolle stehen, die eigentlich generisch funktioniert.
 
-`site.yml` bindet jede Rolle unter einem zu ihrem Namen passenden Tag ein. Der Agent ruft sie über:
+`site.yml` bindet jede Rolle unter einem zu ihrem Namen passenden Tag ein. Seit ADR-0046 holt der Agent diesen Stand als Archiv von anode (je Ausrollstufe, nur mit Agent-Secret) und ruft im entpackten Stand auf:
 
 ```
-ansible-pull -U <repo-url> --tags <rolle1>,<rolle2>,... -i localhost, site.yml
+ansible-playbook -c local --tags <rolle1>,<rolle2>,... -i localhost, -e @<extra-vars> site.yml
+```
+
+Rückfall, solange Gitea von außen erreichbar ist (ohne Stand von anode oder wenn der Archiv-Weg scheitert):
+
+```
+ansible-pull -U <repo-url> --tags <rolle1>,<rolle2>,... -i localhost, -e @<extra-vars> site.yml
 ```
 
 ## Aktueller Stand
@@ -26,7 +32,7 @@ Alle drei Rollen haben echten Inhalt (Stand 2026-08-04) — die Marker-Dateien u
 
 Merkmale, die für die geräteweise Ad-hoc-Zuweisung über den Auftragskatalog freigegeben sind (`merkmale.im_auftragskatalog = true`), können nicht nur zugewiesen, sondern auch wieder abgewählt werden — und das muss real etwas zurückbauen, nicht nur zukünftige Anwendung verhindern.
 
-Dafür reicht der Agent bei jedem `ansible-pull`-Lauf eine Variable `tuxflotte_auftrag_states` durch (Rollenname → `"present"`/`"absent"`, aus der Check-in-Antwort `auftraege`), die `site.yml` pro Rolle als `tuxflotte_state` an die jeweilige Rolle weiterreicht. Rollen, die dort nicht auftauchen (zum Beispiel weil sie nur workspace-komponiert sind, nicht katalogfähig), laufen unverändert additiv über `--tags`, ohne `absent`-Zustand — siehe `tuxflotte_auftrag_states.get(<rolle>, 'present')` in `site.yml`.
+Dafür reicht der Agent bei jedem Lauf eine Variable `tuxflotte_auftrag_states` durch (Rollenname → `"present"`/`"absent"`, aus der Check-in-Antwort `auftraege`), die `site.yml` pro Rolle als `tuxflotte_state` an die jeweilige Rolle weiterreicht. Rollen, die dort nicht auftauchen (zum Beispiel weil sie nur workspace-komponiert sind, nicht katalogfähig), laufen unverändert additiv über `--tags`, ohne `absent`-Zustand — siehe `tuxflotte_auftrag_states.get(<rolle>, 'present')` in `site.yml`.
 
 Jede Rolle, die katalogfähig werden soll, muss deshalb ihre Tasks auf `tuxflotte_state` verzweigen: