docs: Gegenlese aller 19 ADRs - zwei lange vorgemerkte Diskrepanzen endlich behoben

ADR-0006: Der zitierte Befehl (epiphany --application-mode --profile=...)
wurde nachweislich nie ausgeliefert - ADR-0004s eigene, einen Tag später
datierte Folgeuntersuchung (Fund 2) stellte fest, dass --application-mode
für skriptgesteuerte Einrichtung unbrauchbar ist. Der tatsächlich seit dem
allerersten Commit ausgelieferte Befehl (start-kiosk.sh) nutzt nur
--profile, nie --application-mode. Diese Diskrepanz wurde beim ersten
Lesen von ADR-0004/0006 in einer früheren Session bereits bemerkt, aber
nie zu Ende verfolgt - jetzt korrigiert, an beiden Stellen (Entscheidung +
Konsequenzen), inkl. Verifikation gegen den echten Code.

ADR-0004: 'grouped-window-list@cinnamon.org' war von Anfang an falsch
dokumentiert - der Code verwendet seit demselben Ausgangscommit bewusst
das einfache 'window-list@cinnamon.org' (Begründung stand nur als
Code-Kommentar: die gruppierte Variante brachte ungewollte Pinned-Apps-
Starter mit). Kein späterer Kurswechsel, sondern ein Autorenfehler im
ADR selbst.

ADR-0018: kleinere Wortwahlkorrektur ('gestrichelte' -> 'durchgezogene'
Konturlinien - das SVG hat kein stroke-dasharray, die Linien sind nicht
gestrichelt).

Alle 19 ADRs vollständig neu gelesen (nicht nur grep-Stichproben),
Cross-Referenzen und Struktur erneut geprüft - sonst keine weiteren
Funde.

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

adr/0004-kiosk-ui-epiphany.md

@@ -59,4 +59,6 @@ Alle drei lokal auf Korrektheit der dconf-Syntax geprüft (`dconf write`/`dconf
 
 Der erste Versuch, das Panel per `panels-enabled = []` komplett zu entfernen, löste beim echten Boot-Test Cinnamons eigenen Sicherheits-Dialog aus: "You don't have any panels added. Do you want to open panel settings?" — im Cinnamon-Quellcode (`js/ui/panel.js`, ~Zeile 879) fest verdrahtet als Reaktion auf eine Laufzeit-**Änderung** von `panels-enabled` auf leer (nicht beim Sitzungsstart selbst, da unser Autostart-Skript den Wert erst nach dem Start von Cinnamon ändert) — keine Möglichkeit, ihn zu unterdrücken, ohne die Panel-Anzahl unverändert zu lassen.
 
-Fix, mit Absicht so gewählt statt eines echten Null-Panel-Setups (das bräuchte einen systemweiten dconf-Default vor dem Cinnamon-Start, deutlich mehr Aufwand/Risiko): `panels-enabled` bleibt unangetastet, stattdessen wird nur `enabled-applets` auf zwei nützliche Einträge reduziert — `grouped-window-list@cinnamon.org` (damit ein Nutzer ein versehentlich minimiertes Epiphany-Fenster wiederherstellen kann) und `power@cinnamon.org` (Shutdown/Reboot bleiben erreichbar). Alle anderen Applets (Menü, Systray, Uhr, Workspace-Switcher etc.) entfernt. Lokal auf dconf-Syntax geprüft. Noch nicht per Boot verifiziert.
+Fix, mit Absicht so gewählt statt eines echten Null-Panel-Setups (das bräuchte einen systemweiten dconf-Default vor dem Cinnamon-Start, deutlich mehr Aufwand/Risiko): `panels-enabled` bleibt unangetastet, stattdessen wird nur `enabled-applets` auf zwei nützliche Einträge reduziert — `window-list@cinnamon.org` (damit ein Nutzer ein versehentlich minimiertes Epiphany-Fenster wiederherstellen kann) und `power@cinnamon.org` (Shutdown/Reboot bleiben erreichbar). Alle anderen Applets (Menü, Systray, Uhr, Workspace-Switcher etc.) entfernt. Lokal auf dconf-Syntax geprüft. Noch nicht per Boot verifiziert.
+
+**Korrigiert (23.08.2026, bei der Gegenlese gegen den tatsächlich ausgelieferten Code gefunden):** Der oben genannte `grouped-window-list@cinnamon.org` war ein Fehler in diesem ADR selbst, nicht eine spätere Kursänderung — `live-updates/opt/tuxflotte/kiosk/start-kiosk.sh` verwendet laut Git-Historie seit dem allerersten Commit (22.07.2026) durchgehend die einfache Variante `window-list@cinnamon.org`, bewusst nicht die gruppierte: Letztere liefert standardmäßig feste „Pinned Apps"-Starter (`firefox.desktop`, `org.gnome.Terminal.desktop`, `nemo.desktop`) mit, die auch nach Entfernen aller anderen Applets im Panel sichtbar blieben — die einfache Variante kennt kein Pinned-Apps-Konzept, zeigt ausschließlich tatsächlich offene Fenster. Diese Begründung stand nur als Code-Kommentar, nie in diesem Dokument.

adr/0006-kiosk-ui-zurueck-zu-epiphany.md

@@ -20,6 +20,8 @@ Der vierte Fix behob das ICU-Problem nachweislich (lokal per `strace` verifizier
 
 Zurück zu Epiphany im Application-Mode (`epiphany --application-mode --profile=/home/liveuser/.local/share/tuxflotte-kiosk`, wie ursprünglich in ADR-0004 beschrieben), trotz sichtbarer Adressleiste und Fenstermenü.
 
+**Korrigiert (23.08.2026, bei der Gegenlese gefunden):** Der hier genannte Befehl wurde so nie ausgeliefert. ADR-0004s eigene, einen Tag später datierte Folgeuntersuchung (Fund 2, 22.07.2026) stellte fest, dass `--application-mode` für eine rein skriptgesteuerte Einrichtung unbrauchbar ist (verlangt eine nur per GUI erzeugbare Webapp-Registrierung) — der tatsächlich funktionierende und bis heute unverändert ausgelieferte Befehl (`live-updates/opt/tuxflotte/kiosk/start-kiosk.sh`, seit dem allerersten Commit vom 22.07.2026) ist `epiphany --profile=/home/liveuser/.local/share/tuxflotte-kiosk ...`, ganz **ohne** `--application-mode`. Dieses Dokument wurde nie mit diesem am selben Tag gewonnenen Fund nachgezogen — die grundsätzliche Entscheidung dieses ADRs (zurück zu Epiphany, sichtbare Adressleiste bewusst in Kauf genommen) bleibt davon unberührt, nur der zitierte Befehl war falsch.
+
 Das ist explizit kein Kompromiss unter Zeitdruck, sondern eine bewusste Neubewertung des ursprünglichen Ablehnungsgrundes: die sichtbare Adressleiste ist in der Praxis kaum relevant, weil
 
 - der angezeigte Inhalt zentral vom Provisioning Server bereitgestellt wird, nicht hartkodiert auf der ISO liegt — es gibt keine sensiblen, auf dem Medium gespeicherten Inhalte, die ein Benutzer über die Adressleiste erreichen könnte,
@@ -34,7 +36,7 @@ Die kosmetische Frage (Epiphany doch noch vollständig chromelos bekommen, z.B.
 
 `scripts/build.sh`: `install_chromium()` und ihr Aufruf entfernt, `check_dependencies()` verlangt wieder nur `xorriso`, kein Root/`dnf`/Internetzugriff mehr nötig für den Build. `tuxflotte-installer/build-deps/` (Fedora-GPG-Key) entfernt, da nicht mehr referenziert.
 
-`tuxflotte-installer.desktop`: wieder `epiphany --application-mode --profile=...` wie vor ADR-0005.
+`tuxflotte-installer.desktop`: wieder `epiphany --profile=...` wie vor ADR-0005 (siehe Korrektur oben zum tatsächlichen Befehl — ohne `--application-mode`).
 
 ADR-0005 bleibt als historischer Datensatz stehen (git-loses Repo — das ist die einzige Quelle für die dort dokumentierten, tatsächlich funktionierenden Techniken: Isolation unter `/opt`, Loader-Relokation für `/proc/self/exe`, SquashFS-Verpackung), gilt aber als überholt/verworfen.
 

adr/0018-logo-und-flotte-umbenennung-kundenplattform.md

@@ -11,7 +11,7 @@
 
 **Logo:** `pics/tuxflotte-beschriftet-schatten.svg` wird unverändert als `kundenplattform/static/tuxflotte-logo.svg` eingebunden und erscheint im Header links vom Markennamen, auf jeder Seite der Anwendung — auch auf der Login-Seite, da diese wie alle Templates von `base.html` erbt und der Header dort nicht an einen eingeloggten Nutzer gebunden ist.
 
-Vor dem Einbau wurde das SVG probehalber als PNG gerendert (`convert`, sowohl auf hellem als auch auf dunklem Hintergrund) und visuell geprüft, statt es ungesehen zu verlinken: Das Bild besteht ausschließlich aus gestrichelten Konturen in Markenblau (`rgb(52,101,164)`, dieselbe Farbe wie im bestehenden GRUB-Farbschema) ohne deckende Hintergrundfläche — funktioniert dadurch unverändert in beiden Farbschemata (hell/dunkel), ohne eine eigene Variante pflegen zu müssen. Als Nebenbefund zeigte die Vorschau, dass das Bildmotiv selbst bereits die Wortmarke „Tux"/„Flotte" enthält — ein zusätzlicher, ungeplanter Beleg dafür, dass die parallel entschiedene Umbenennung (siehe unten) zum bestehenden Markenbild passt, nicht umgekehrt konstruiert.
+Vor dem Einbau wurde das SVG probehalber als PNG gerendert (`convert`, sowohl auf hellem als auch auf dunklem Hintergrund) und visuell geprüft, statt es ungesehen zu verlinken: Das Bild besteht ausschließlich aus durchgezogenen Konturlinien in Markenblau (`rgb(52,101,164)`, dieselbe Farbe wie im bestehenden GRUB-Farbschema) ohne deckende Hintergrundfläche — funktioniert dadurch unverändert in beiden Farbschemata (hell/dunkel), ohne eine eigene Variante pflegen zu müssen. Als Nebenbefund zeigte die Vorschau, dass das Bildmotiv selbst bereits die Wortmarke „Tux"/„Flotte" enthält — ein zusätzlicher, ungeplanter Beleg dafür, dass die parallel entschiedene Umbenennung (siehe unten) zum bestehenden Markenbild passt, nicht umgekehrt konstruiert.
 
 Das Original in `pics/` bleibt unangetastet und unoptimiert (ungenutzter LibreOffice-Export-Boilerplate wie leere Bullet-Char-Templates); die kopierte Version in `static/` wird bewusst nicht bereinigt, um das Quellbild nicht anzufassen — bei ca. 78 KB und einmaligem Laden pro Browser-Sitzung (danach gecacht) kein spürbares Performance-Thema für die aktuelle Nutzungsgröße.