feat(device-initialization, core): Theme-Support hinzugefügt, Fokus- und UI-Optimierungen umgesetzt

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
2026-04-29 15:02:55 +02:00
parent fd78404d72
commit b94984043c
21 changed files with 447 additions and 293 deletions
@@ -2,12 +2,12 @@
 type: Roadmap
 status: ACTIVE
 owner: Lead Architect
-last_update: 2026-04-21
+last_update: 2026-04-29
 ---

 # MASTER ROADMAP: Meldestelle

-🏗️ **[Lead Architect]** | 20. April 2026
+🏗️ **[Lead Architect]** | 29. April 2026

 **Strategisches Ziel:**
 Entwicklung einer ÖTO-konformen, offline-fähigen Turnier-Meldestelle als Compose Desktop App (KMP).
@@ -75,17 +75,20 @@ und über definierte Schnittstellen kommunizieren.

 Fokus: Physische Implementierung der Turnier-Hierarchie und technisches Onboarding.

-### MEILENSTEIN 0: Technische Geräte-Initialisierung (Prio 1) 🔵 IN ARBEIT
+### MEILENSTEIN 0: Technische Geräte-Initialisierung (Prio 1) 🚧 IN ARBEIT (VERIFIKATION AUSSTEHEND)

 *Ziel: Ein stabiles, offline-fähiges technisches Fundament für die Desktop-App.*

-*   [ ] **OS-Pfad-Auflösung:** Umstellung der `settings.json` auf OS-Standardpfade (`%APPDATA%`, `~/.config`).
-*   [ ] **Netzwerk-Interface-Binding:** Manuelle Auswahl des Netzwerkadapters zur Vermeidung von Fehl-Discovery.
-*   [ ] **Geführte Discovery ("Radar-Modus"):** Visuelle Suche nach Mastern im LAN inkl. Hilfe-Tooltips.
-*   [ ] **Plan-USB Integration:** Paralleler, verschlüsselter Delta-Export auf Wechseldatenträger inkl. Sync-Vorschau.
-*   [ ] **Offline-Lizenzierung:** Vorbereitung des Ticket-Systems ("Pay-per-Event") zur Offline-Validierung.
+*   [x] **OS-Pfad-Auflösung:** Implementiert (Wartet auf Hardware-Test).
+*   [x] **Netzwerk-Interface-Binding:** Implementiert (Wartet auf Hardware-Test).
+*   [x] **Geführte Discovery ("Radar-Modus"):** Implementiert (Wartet auf Hardware-Test).
+*   [x] **Plan-USB Integration (UI):** Implementiert (Wartet auf Hardware-Test).
+*   [x] **Offline-Lizenzierung (Konzept):** Dokumentiert (ADR-0026).
+*   [x] **UX-Optimierung:** Implementiert (Wartet auf Hardware-Test).
+*   [ ] **PoC Verifikation:** 🔴 OFFEN (Hardware-Test durch User erforderlich).
+*   [ ] **Plan-USB Implementierung:** 🔴 OFFEN (Verschlüsselter Datei-Export).

-### MEILENSTEIN 1: Die Basis-Hierarchie (Prio 1)
+### MEILENSTEIN 1: Die Basis-Hierarchie (Prio 1) ⚪ GEPLANT

 *Ziel: Veranstaltung -> Turnier -> Bewerb/Abteilung physisch anlegen und speichern.*

@@ -1,7 +1,7 @@
 # ADR-0025: "Plan-USB" & Offline-Datenintegrität

 ## Status
-Vorgeschlagen
+In Prüfung (Wartet auf PoC)

 ## Kontext
 Im professionellen Turniersport ist eine stabile Netzwerkverbindung (LAN/WLAN) nicht immer garantiert. Ein Ausfall des Netzwerks darf den laufenden Betrieb (Ergebniserfassung, Meldestelle) nicht blockieren. Zudem müssen sensible Reiter- und Pferdedaten (DSGVO) auch auf physischen Datenträgern geschützt sein.
@@ -9,10 +9,10 @@ Im professionellen Turniersport ist eine stabile Netzwerkverbindung (LAN/WLAN) n
 ## Entscheidung
 Wir führen die "Plan-USB" Strategie als primären Fallback und parallelen Sicherungsmechanismus ein.

-1. **Permanenter Delta-Export:** Der Master-PC schreibt kontinuierlich verschlüsselte Delta-Pakete (JSON-basiert) in ein definiertes Backup-Verzeichnis.
-2. **Verschlüsselung:** Alle Daten auf dem USB-Stick werden mit dem `Shared Key` (AES-256) verschlüsselt. Dies stellt sicher, dass bei Verlust des Sticks keine personenbezogenen Daten gelesen werden können.
+1. **Permanenter Delta-Export:** Der Master-PC schreibt kontinuierlich verschlüsselte Delta-Pakete (JSON-basiert) in ein definiertes Backup-Verzeichnis. Dies ist bereits in der UI als Pfad-Option vorbereitet.
+2. **Verschlüsselung:** Alle Daten auf dem USB-Stick werden mit dem `Shared Key` (AES-256) verschlüsselt. Der Benutzer legt diesen Schlüssel einmalig während der Initialisierung fest.
 3. **Datenintegrität:** Pakete werden signiert, um Manipulationen durch Texteditoren zu verhindern.
-4. **Sync-Vorschau:** Die UI bietet eine visuelle Bestätigung ("Sync-Dashboard"), welche Daten zuletzt erfolgreich auf den Stick geschrieben wurden.
+4. **Sync-Vorschau:** Die UI bietet eine visuelle Bestätigung ("Sync-Dashboard"), welche Daten zuletzt erfolgreich auf den Stick geschrieben wurden. (Umgesetzt im UI-Design der Initialisierung).
 5. **Manueller Not-Import:** Clients erhalten eine Funktion, um Delta-Pakete manuell von einem Stick einzulesen und eigene Ergebnisse dorthin zurückzuschreiben.

 ## Konsequenzen
@@ -1,7 +1,7 @@
 # ADR-0027: Netzwerk-Discovery & Interface-Binding

 ## Status
-Vorgeschlagen
+In Prüfung (Wartet auf PoC)

 ## Kontext
 Desktop-Rechner auf Turnieren sind oft mit mehreren Netzwerken gleichzeitig verbunden (z.B. LAN für das Turnier-Netzwerk, WLAN für Internet-Hotspot). Automatische Discovery-Dienste (JmDNS) wählen ohne explizite Konfiguration oft das falsche Interface, wodurch sich Clients und Master nicht finden.
@@ -9,10 +9,10 @@ Desktop-Rechner auf Turnieren sind oft mit mehreren Netzwerken gleichzeitig verb
 ## Entscheidung
 Wir führen ein explizites Netzwerk-Management für die Initialisierung ein.

-1. **Interface-Selektion:** Der Benutzer muss bei der technischen Initialisierung explizit wählen, über welches Netzwerk-Interface (IP-Adresse/Adapter) die App kommunizieren soll.
-2. **Geführte Discovery:** Sobald ein Interface gewählt ist, startet ein "Radar-Modus". Dieser scannt aktiv nach vorhandenen Master-Geräten.
-3. **Adaptive Rolle:** Findet die Discovery einen Master, wird dem Benutzer die Rolle "Client" mit automatischer Konfigurationsübernahme vorgeschlagen. Werden nur Clients oder nichts gefunden, wird die Rolle "Master" empfohlen.
-4. **Validierung:** Vor Abschluss der Initialisierung wird ein Verbindungstest durchgeführt (Pre-Flight Check).
+1. **Interface-Selektion:** Der Benutzer muss bei der technischen Initialisierung explizit wählen, über welches Netzwerk-Interface (IP-Adresse/Adapter) die App kommunizieren soll. Die UI zeigt hierfür benutzerfreundliche Namen (WLAN, Ethernet) an.
+2. **Geführte Discovery:** Sobald ein Interface gewählt ist, startet ein "Radar-Modus". Dieser scannt aktiv via JmDNS nach vorhandenen Master-Geräten.
+3. **Adaptive Rolle:** Findet die Discovery einen Master, wird dem Benutzer die Rolle "Client" vorgeschlagen. Die UI bleibt jedoch flexibel für manuelle Rollenwechsel.
+4. **Fokus-Management:** Nach Auswahl der Rolle wird der Fokus automatisch in das erste relevante Eingabefeld (Gerätename) gesetzt, um einen reibungslosen Workflow zu ermöglichen.

 ## Konsequenzen
 - Verhindert "Geistersuchen" im falschen Netzwerk.