docs: massive restructuring of documentation, development guides and agent playbooks

2026-06-15 12:54:38 +02:00
parent e4988b4397
commit ce63303b2c
686 changed files with 45423 additions and 319 deletions
@@ -0,0 +1,34 @@
+🏗️ **[Curator Journal]**
+Datum: 30. April 2026 (Abschluss-Update)
+
+# 🧹 Session-Abschluss: POC-Status & Kritische Analyse
+
+## 🚀 Implementierte Änderungen (Zusammenfassung)
+
+- **Zero-Config & UI-Fixes:** mDNS-Discovery mit sprechenden Namen, "Wait-State" für Clients und native Dateidialoge
+  integriert.
+- **Master-UX Optimierung:** Die Konfiguration im Wizard ist nun beim Start entsperrt; Master können erwartete Clients
+  hinzufügen/bearbeiten.
+- **Fehlerbehebung:** Kompilierfehler im `DeviceInitializationViewModel` (JVM/Common-Abstraktion) und Docker-Compose
+  YAML-Struktur korrigiert.
+
+## 🔴 Aktueller Status: POC FEHLGESCHLAGEN
+
+Trotz der technischen Umsetzungen meldet der User, dass der POC auf der Hardware weiterhin nicht funktioniert.
+
+- **Feedback:** "Es funktioniert noch immer nicht!"
+- **Konsequenz:** Die Session wird zur Dokumentation beendet. Eine tiefergehende Fehleranalyse (Netzwerk-Traces,
+  Log-Inspektion) ist für die Abend-Session zwingend erforderlich.
+
+## 📋 Checkliste für die Abend-Session (Analyse-Fokus)
+
+1. **mDNS Sichtbarkeit:** Warum finden sich Master und Client trotz "Zero-Config" nicht zuverlässig? (Mögliche
+   Firewall-Themen oder Interface-Binding-Priorität).
+2. **Handshake-Logik:** Verbleibt der Client im "Wait-State" oder schlägt der Verbindungsversuch aktiv fehl?
+3. **UI-State Persistence:** Werden die Master-Einstellungen (Name, Key) korrekt für den mDNS-Broadcast übernommen?
+4. **Log-Analyse:** Prüfung der App-Logs auf dem Zielsystem (falls verfügbar).
+
+## 📅 Nächste Schritte
+
+- Start der Abend-Session mit Fokus auf **Debugging der Netzwerk-Discovery**.
+- Verifikation der `init_device.aes` Erstellung bei manuellem Durchlauf des Masters.