docs: Gegenlese aller 15 ADRs - sicherheitsrelevanten Widerspruch behoben

Wichtigster Fund: 13-live-provisioning-boot.md widersprach sich selbst
zum GRUB-Standardeintrag - ein noch nicht korrigierter Abschnitt
('Auto-Eintrag ist Index 0 und damit Standardauswahl') stand neben der
bereits vorhandenen Korrektur weiter oben im selben Dokument ('Standard
ist von lokaler Festplatte booten', Erkenntnis vom 01.08.2026). Ein
Reader des älteren Abschnitts hätte das sicherheitsrelevante Verhalten
bei destruktiven Installationen falsch verstanden. Jetzt konsistent,
mit Verweis auf die Korrektur. ADR-0003 (Ursprungsentscheidung, dort
unkorrigiert) bekam denselben Nachtrag.

Kleinere Korrekturen: zwei Anführungszeichen-Inkonsistenzen (ADR-0009,
ADR-0011) - gerade Anführungszeichen für eigene Zusammenfassungen des
Autors statt der sonst durchgängigen „..."-Form, während echte wörtliche
Zitate (Terminal-Fehlermeldungen, Anaconda-Doku) unangetastet bleiben,
weil die Originalschreibweise dort bewusst erhalten werden soll.

Alle ADR-Querverweise (0001-0015) auf Gültigkeit geprüft, keine toten
Verweise gefunden.

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

adr/0003-live-provisioning-boot.md

@@ -27,6 +27,8 @@ Ein Standardeintrag mit Countdown, der bei Nichtstun automatisch in den unbeaufs
 
 Ein manuell auswählbarer zweiter Eintrag für den interaktiven, gebrandeten Ablauf.
 
+**Korrigiert (01.08.2026, siehe ADR-0009-Update vom selben Tag):** Welcher der beiden Einträge bei Nichtstun (Countdown-Ablauf) automatisch ausgewählt wird, wurde hier zunächst falsch entschieden — nicht der unbeaufsichtigte Ablauf, sondern „von lokaler Festplatte booten" ist der Standard. Die destruktive, unbeaufsichtigte Installation erfordert eine aktive, bewusste Auswahl aus dem Menü, kein bloßes Verstreichenlassen eines Zeitfensters. Umgesetzt in `architecture/13-live-provisioning-boot.md`.
+
 Der unbeaufsichtigte Ablauf ist ausschließlich für bereits registrierte Geräte zulässig, erkennbar an `device.registration_status == "existing"` in der Antwort von `POST /api/v1/activate`. Bei einem unbekannten Gerät (`registration_status == "registered"`) bricht der unbeaufsichtigte Ablauf kontrolliert ab (Fail-Closed) und verweist auf den interaktiven Ablauf mit expliziter Geräteaufnahme-Bestätigung gemäß `11-device-enrollment.md`.
 
 Dass ein bereits registriertes Gerät ohne erneute interaktive Rückfrage automatisiert neu installiert werden kann, wird explizit Bestandteil der Bedingungen, denen bei der Geräteregistrierung zugestimmt wird.

adr/0009-anaconda-live-kickstart-verworfen.md

@@ -13,7 +13,7 @@ Vor der Implementierung wurde recherchiert und real getestet, ob das funktionier
 
 Der `liveinst`-Wrapper (`/usr/bin/liveinst`, Teil des `anaconda`-Pakets) lehnt `ks=`/`kickstart=`-Argumente laut eigenem Quellcode aktiv ab und erzwingt stattdessen den interaktiven Modus — Zitat aus der Anaconda-Projektdokumentation: *"anaconda developers really, really do not want to support kickstart from liveinst!"*. Auch die eigene `anaconda --help`-Ausgabe dokumentiert `--kickstart KICKSTART_PATH` explizit als *"not supported for live installations"*.
 
-Direkter Test am Wrapper vorbei (`anaconda --liveinst --kickstart=<datei>`, auf echtem Fedora 44 / Anaconda 44.30-2.fc44) bestätigte das empirisch, mit einer noch ungünstigeren Fehlerart als "klar abgelehnt":
+Direkter Test am Wrapper vorbei (`anaconda --liveinst --kickstart=<datei>`, auf echtem Fedora 44 / Anaconda 44.30-2.fc44) bestätigte das empirisch, mit einer noch ungünstigeren Fehlerart als „klar abgelehnt":
 
 - **Mit `-T` (Text-Modus):** Anaconda startet, übernimmt Sprache/Zeitzone/Partitionierungsart (`autopart`) korrekt aus der Kickstart-Datei, ignoriert aber `rootpw` und `user` **kommentarlos** — beide Felder mussten vollständig manuell nachgetragen werden ("Root-Konto ist deaktiviert", "Es wird kein Benutzer erstellt", trotz korrekter Kickstart-Zeilen). Kein Fehler, keine Warnung — nur eine leise, unvollständige Übernahme.
 - **Mit `-C` (Cmdline-Modus, laut Hilfetext für nicht-interaktive Automatisierung gedacht):** sauberer, aber ebenso eindeutiger Abbruch, Exit-Code 1, mit explizitem Log-Eintrag:
@@ -36,7 +36,7 @@ Ausdrücklich **nicht** gewählt: Anaconda umgehen und Partitionierung/Dateisyst
 ## Konsequenzen
 
 - `13-live-provisioning-boot.md` (Abschnitt "Nativer Installer aus der Live-Sitzung") muss überarbeitet werden, sobald der tatsächliche Weg feststeht — noch nicht Teil dieser Entscheidung.
-- Betroffene Anaconda-Version zur Einordnung: 44.30-2.fc44 ("bluesky", Pre-Release, neue WebUI-basierte Oberfläche) — die "Kickstart auf Live-Medien nicht unterstützt"-Haltung selbst ist aber laut Anaconda-Projektdokumentation langjährig und nicht auf diese Version beschränkt.
+- Betroffene Anaconda-Version zur Einordnung: 44.30-2.fc44 ("bluesky", Pre-Release, neue WebUI-basierte Oberfläche) — die „Kickstart auf Live-Medien nicht unterstützt"-Haltung selbst ist aber laut Anaconda-Projektdokumentation langjährig und nicht auf diese Version beschränkt.
 
 ## Update (23.07.2026): Muster erkannt, verfeinerter Prüfplan
 

adr/0011-kundenplattform-getrennter-dienst.md

@@ -13,7 +13,7 @@ Eine menschliche, sitzungsbasierte Kunden-Login-Oberfläche im selben Prozess/de
 2. **Mehrmandantenfähigkeit:** Der bestehende `TUXFLOTTE_ADMIN_TOKEN` ist ein einzelnes globales Betreiber-Secret, keine pro-Organisation skalierende Authentifizierung. Ein echtes Kunden-Login braucht Accounts, die einer Organisation zugeordnet sind und nur deren eigene Geräte sehen dürfen.
 3. **Verfügbarkeit:** Anode muss zuverlässig für die Geräte-Flotte erreichbar bleiben. UI-Traffic (z.B. viele gleichzeitig eingeloggte Kunden) sollte diese Zuverlässigkeit nicht gefährden können.
 
-Im Repo existiert noch kein Benutzerkonto-Konzept (nur Maschinen-Secrets für Geräte, siehe `devices.agent_secret_hash`) und keine bestehende "Kundenplattform"-Dokumentation — nur vereinzelte Prosa-Erwähnungen einer künftigen "Verwaltungsoberfläche"/eines "Self-Service-Portals" (u.a. ADR-0008, das bereits eine Neugeräte-Bestätigung über eine solche künftige Oberfläche vorsieht, dort aber nicht spezifiziert).
+Im Repo existiert noch kein Benutzerkonto-Konzept (nur Maschinen-Secrets für Geräte, siehe `devices.agent_secret_hash`) und keine bestehende „Kundenplattform"-Dokumentation — nur vereinzelte Prosa-Erwähnungen einer künftigen „Verwaltungsoberfläche"/eines „Self-Service-Portals" (u.a. ADR-0008, das bereits eine Neugeräte-Bestätigung über eine solche künftige Oberfläche vorsieht, dort aber nicht spezifiziert).
 
 ## Entscheidung
 

architecture/13-live-provisioning-boot.md

@@ -178,7 +178,9 @@ Ein eigenes, schlankeres Live-System anstelle des Fedora-Live-Images wurde gepr
 
 Das in der Boot-Ablauf-Grafik oben genannte Kernel-Cmdline-Flag heißt konkret `tuxflotte.mode` und wird als `tuxflotte.mode=auto` beziehungsweise `tuxflotte.mode=interactive` an den Kernel übergeben, zusätzlich zu den vom Live-Medium ohnehin benötigten Parametern (`root=live:CDLABEL=TUXFLOTTE rd.live.image`) sowie `vconsole.keymap=de`. `installer.sh` soll den gewählten Modus zur Laufzeit aus `/proc/cmdline` lesen (siehe „Noch nicht umgesetzt" unten) — aktuell durchläuft es unabhängig vom Flag immer den vollständigen interaktiven Ablauf.
 
-Das GRUB-Menü verwendet einen Countdown von 10 Sekunden; der Auto-Eintrag ist Index 0 und damit Standardauswahl. Ein dritter Menüpunkt zum Booten des bereits installierten lokalen Systems bleibt erhalten (vormals in `01-layered-provisioning.md` als Anforderung an das Bootmenü genannt).
+Das GRUB-Menü verwendet einen Countdown von 10 Sekunden. Ein dritter Menüpunkt zum Booten des bereits installierten lokalen Systems bleibt erhalten (vormals in `01-layered-provisioning.md` als Anforderung an das Bootmenü genannt).
+
+**Korrigiert (01.08.2026, siehe ADR-0009-Update vom selben Tag):** Der Auto-Eintrag ist entgegen der ursprünglichen Angabe hier **nicht** Index 0/Standardauswahl. Bei Nichtstun (Ablauf des Countdowns) bootet stattdessen „von lokaler Festplatte" — die destruktive Installation muss aktiv aus dem Menü ausgewählt werden, kein Zeitfenster zum Abbrechen. Siehe auch die zusammenfassende Erwähnung weiter oben im Abschnitt „WLAN-Zugangsdaten"/Auto-Modus-Gate.
 
 `scripts/build.sh` und `scripts/extract.sh` extrahieren die Quell-ISO über `xorriso -osirrox` statt über einen Loop-Mount und benötigen dadurch keine Root-Rechte mehr für den Build selbst.