diff --git a/docs/90_Reports/2026-04-02_Architect_Report.md b/docs/90_Reports/2026-04-02_Architect_Report.md new file mode 100644 index 00000000..d7bd0260 --- /dev/null +++ b/docs/90_Reports/2026-04-02_Architect_Report.md @@ -0,0 +1,41 @@ +# 🏗️ [Lead Architect] Report - 2. April 2026 + +## 1. Aktueller Status + +Das Projekt hat durch die "Event-First"-Philosophie (Initialisierung einer spezifischen Datenbank pro Veranstaltung) und +die fokussierte Compose-Desktop-Entwicklung (V2-Screens) eine deutliche Richtung eingenommen. Die +Architekturentscheidung (ADR-0020) bezüglich LAN-Isolation und Mandantenfähigkeit (Tenant-per-Event) beginnt sich im +Code (lokaler State, Event-bezogene Stores) niederzuschlagen, muss aber zwingend im Backend nachgezogen werden. + +## 2. Empfehlungen & Prioritäten + +**🔴 P1: Mandantenfähigkeit (Tenant Isolation) im Backend verankern** + +* *Warum:* Das Frontend plant für jedes Event eine "eigene Datenbank". Das Backend läuft derzeit noch als klassischer + Monolith ohne harte Isolation der Veranstaltungsdaten (Nennungen, Prüfungen, Starterlisten). Wenn wir dies jetzt nicht + architektonisch sauber im Backend (z.B. über Schema-per-Tenant oder Tenant-IDs in allen Tabellen) lösen, bauen wir + enorme technische Schulden auf. +* *Aktion:* Definition der Tenant-Resolution-Strategie für Ktor/Spring Boot (wie erkennt das Backend, auf welche + Event-Datenbank eine Anfrage zielt?). Umsetzung im Datenzugriff-Layer. + +**🔴 P1: State-Management-Architektur für Compose (MVI/MVVM)** + +* *Warum:* Der aktuelle Frontend-Code mischt UI-Deklaration und Business-Logik (`StoreV2` Aufrufe direkt in den + `onSaved`-Callbacks, viel lokaler `remember`-State). Bei steigender Komplexität (z.B. Nennungssystem) wird dies + unwartbar. +* *Aktion:* Verbindliche Festlegung auf ein Architekturmuster für das KMP/Compose Frontend (z.B. striktes MVVM mit UDF - + Unidirectional Data Flow). Auslagern des Status in `ViewModels` und Definition klarer `Intent`/`State` Klassen für die + V2-Screens. + +**🟠 P2: Synchronisations-Protokoll (Offline-First/LAN)** + +* *Warum:* Die Meldestelle muss offline auf Turnieren funktionieren. +* *Aktion:* Start der Konzeptionsphase für das Daten-Synchronisations-Protokoll zwischen der Master-Datenbank (Backend) + und den lokalen Client-Datenbanken (Desktop). Entscheidung zwischen Event-Sourcing, CRDTs oder simplen + Timestamp-basierten Sync-Ansätzen. + +**🟡 P3: Master-Roadmap Update** + +* *Warum:* Die jüngsten Entwicklungen haben die Prioritäten verschoben. +* *Aktion:* Aktualisierung der `MASTER_ROADMAP.md` in `docs/01_Architecture/`, um den Fokus auf die Desktop-App, die + Tenant-Isolation und die anstehenden Offline-Sync-Meilensteine widerzuspiegeln. diff --git a/docs/90_Reports/2026-04-02_Backend_Report.md b/docs/90_Reports/2026-04-02_Backend_Report.md new file mode 100644 index 00000000..494bdf18 --- /dev/null +++ b/docs/90_Reports/2026-04-02_Backend_Report.md @@ -0,0 +1,35 @@ +# 👷 [Backend Developer] Report - 2. April 2026 + +## 1. Aktueller Status + +Das Backend war in den letzten Tagen relativ stabil. Es gab kleinere Anpassungen im Domain-Modell (z.B. Entfernung von " +Reining" aus dem `Sparte` Enum) und Optimierungen in den Build-Skripten (`platformTesting`). Das Backend wartet nun +darauf, die rasante Frontend-Entwicklung mit echten Daten und Endpunkten zu unterfüttern. + +## 2. Empfehlungen & Prioritäten + +**🔴 P1: API-Endpunkte für V2-Frontend (CRUD)** + +* *Warum:* Das Frontend verwendet aktuell einen lokalen `StoreV2`, da die echten Endpunkte für die neuen Detail-Screens + fehlen. +* *Aktion:* Definition und Implementierung der REST-APIs für Create, Read, Update, Delete von Veranstaltern, + Veranstaltungen, Reitern, Pferden, Vereinen und Funktionären. + +**🟠 P2: Datenbank-Schema & DTOs aktualisieren** + +* *Warum:* Die neuen Frontend-Dialoge haben neue Felder oder spezifische Anforderungen an die Datenstruktur + offengelegt (z.B. OEPS-Nummer vs. FEI-ID, optionale Kontakt-Felder). +* *Aktion:* Abgleich der Domain-Modelle und des DB-Schemas mit den Frontend-DTOs. Ggf. Flyway-Migrationen erstellen. + +**🟠 P2: LAN/Offline-First Architektur (Sync)** + +* *Warum:* Gemäß ADR-0020 und der Projekt-Philosophie muss das System offline-fähig (LAN) sein. Die + Event-Datenbank-Initialisierung passiert nun im Frontend. +* *Aktion:* Vorbereitung der mandantenfähigen/Event-spezifischen Datenhaltung im Backend, um mit der lokalen Datenbank + der Desktop-App kommunizieren zu können. + +**🟡 P3: Dynamisches Testdaten-Seeding** + +* *Warum:* Das Frontend braucht realistische Daten für die V2-Screens, um Edge-Cases zu testen. +* *Aktion:* Entwicklung eines Seeders, der reproduzierbare, umfangreiche Testdaten (Turniere, Nennungen, Stammdaten) + generiert und über die API bereitstellt. diff --git a/docs/90_Reports/2026-04-02_Curator_Report.md b/docs/90_Reports/2026-04-02_Curator_Report.md new file mode 100644 index 00000000..7b79e025 --- /dev/null +++ b/docs/90_Reports/2026-04-02_Curator_Report.md @@ -0,0 +1,37 @@ +# 🧹 [Curator] Report - 2. April 2026 + +## 1. Aktueller Status + +Das Projekt macht schnelle Fortschritte, was zu einer hohen Frequenz an Frontend-Änderungen und Architektur-Anpassungen +geführt hat. Der Code ist gut strukturiert, aber die technische Dokumentation (ADRs, Playbooks, Setup-Guides) hinkt den +Implementierungs-Entscheidungen der letzten Tage etwas hinterher. + +## 2. Empfehlungen & Prioritäten + +**🔴 P1: Dokumentation des "Event-First" Workflows & ADRs** + +* *Warum:* Die neue Struktur der Datenbank-Erstellung (pro Veranstaltung) und die Offline-Strategie (LAN-Sync) aus + ADR-0020 werden tiefgreifende Auswirkungen auf die System-Architektur haben. +* *Aktion:* Ausführliche Dokumentation der Mandantenfähigkeit (Tenant-Isolation), des neuen Navigation-Stacks (V2) und + des Startvorgangs (Onboarding) in `docs/01_Architecture/`. + +**🟠 P2: `README.md` und Setup-Guide aktualisieren** + +* *Warum:* Die neuen Run-Configs (z. B. `PreviewMain`) und der Fokus auf die Desktop-App (Compose) machen es für neue + Entwickler schwer, den Einstiegspunkt zu finden. +* *Aktion:* Das Haupt-`README.md` um die neuesten Befehle für Compose Desktop ( + `./gradlew :frontend:shells:meldestelle-desktop:run`) und die Backend-Abhängigkeiten (z.B. Test-Datenbank-Setup) + erweitern. + +**🟠 P2: Logs & Journaling Struktur** + +* *Warum:* Mit den vielen neuen Reports wird das `docs/90_Reports/`-Verzeichnis schnell unübersichtlich. +* *Aktion:* Einführung einer sauberen Unterordner-Struktur in `docs/` nach Meilensteinen oder Kalenderwochen, um Reports + und Session-Logs (`docs/99_Journal/`) besser archivieren und durchsuchen zu können. + +**🟡 P3: Aufräumen von altem Code ("V1")** + +* *Warum:* Wir haben viele "V2"-Screens eingeführt. Die alten, nicht mehr genutzten Platzhalter-Screens oder veralteten + Routing-Einträge erzeugen "Dead Code". +* *Aktion:* Identifikation und saubere Löschung aller veralteten UI-Komponenten und Navigationspfade aus der initialen + Startup-Phase, um die Code-Basis schlank zu halten. diff --git a/docs/90_Reports/2026-04-02_DevOps_Report.md b/docs/90_Reports/2026-04-02_DevOps_Report.md new file mode 100644 index 00000000..9807a5c0 --- /dev/null +++ b/docs/90_Reports/2026-04-02_DevOps_Report.md @@ -0,0 +1,37 @@ +# 🐧 [DevOps Engineer] Report - 2. April 2026 + +## 1. Aktueller Status + +In den letzten Commits sehen wir Anpassungen an den Gradle-Build-Skripten im Backend ( +`masterdata-domain/build.gradle.kts`), bei denen Abhängigkeiten zum `platformTesting` bereinigt wurden. Die Entwicklung +konzentriert sich stark auf die Desktop-App (`meldestelle-desktop`), was bedeutet, dass die Paketierung und Auslieferung +für den Desktop-Client relevant wird. + +## 2. Empfehlungen & Prioritäten + +**🔴 P1: Desktop-App Packaging (Compose for Desktop)** + +* *Warum:* Das "Event-First" Workflow-Update zeigt, dass der `meldestelle-desktop` Client immer vollständiger wird und + für Tests durch Stakeholder bereitgestellt werden sollte. +* *Aktion:* Konfiguration von Gradle/Conveyor oder `compose.desktop.nativeDistributions`, um installierbare Pakete (z.B. + `.msi`, `.dmg` oder `.deb`) für die Ziel-Betriebssysteme der Meldestellen automatisch via CI/CD zu bauen. + +**🟠 P2: CI/CD Pipeline für Compose Tests** + +* *Warum:* Die UI-Tests und Navigationstests (z.B. `DeepLinkHandlerTest`) müssen bei jedem Push laufen, um Regressionen + im komplexen V2-Navigation-Flow zu verhindern. +* *Aktion:* Ausbau der GitHub Actions (oder GitLab CI), um die Compose-Desktop-Tests "headless" auszuführen und schnelle + Feedback-Schleifen für die UI-Entwicklung zu etablieren. + +**🟠 P2: Vorbereitung der Offline-Datenbank (LAN)** + +* *Warum:* Im Frontend-Code ist dokumentiert, dass "eine eigene Datenbank initialisiert wird". Die LAN-Synchronisation + aus ADR-0020 wird konkreter. +* *Aktion:* Evaluierung und Bereitstellung der Infrastruktur für lokale SQLite-Datenbanken innerhalb der + Desktop-Applikation inklusive eventueller Sync-Tools (z.B. Realm oder custom Ktor/SQLDelight Sync-Worker). + +**🟡 P3: Artefakt-Versionierung und Releases** + +* *Warum:* Es ist bald ein MVP-Release fällig. +* *Aktion:* Einführung einer sauberen Semantic Versioning Strategie, um Client (Desktop) und Server (Spring Boot) + koordiniert als Release-Paket taggen und deployen zu können. diff --git a/docs/90_Reports/2026-04-02_Frontend_Report.md b/docs/90_Reports/2026-04-02_Frontend_Report.md new file mode 100644 index 00000000..88a58b11 --- /dev/null +++ b/docs/90_Reports/2026-04-02_Frontend_Report.md @@ -0,0 +1,44 @@ +# 🎨 [Frontend Expert] Report - 2. April 2026 + +## 1. Aktueller Status + +In den letzten Tagen lag der Fokus stark auf dem Frontend-Flow, insbesondere auf der Verwaltung von Stammdaten und der +Navigation: + +* **UI/UX Onboarding:** Verbessertes Keyboard-Handling (Tab-Navigation, Enter-Bestätigung) und State-Saving ( + `rememberSaveable`) zwischen Navigationswechseln. +* **Veranstalter & Veranstaltung:** Einführung von `VeranstalterDetailV2` und `VeranstaltungKonfigV2` mit einem sauberen + Bestätigungsdialog vor der endgültigen Anlage und korrekter Initialisierung der Event-Datenbank. +* **Profil-Screens (V2):** Neue, detailreiche Profil-Ansichten für Reiter, Pferde, Vereine und Funktionäre inkl. + Inline-Edit-Dialogen. +* **Navigation:** Robuste Back-Stack-Implementierung, die sicherstellt, dass der User korrekt zwischen den + Verwaltungsebenen und Profilen navigieren kann. + +## 2. Empfehlungen & Prioritäten + +**🔴 P1: State-Management refaktorisieren** + +* *Warum:* Aktuell wird viel lokaler State direkt in den V2-Composables gehalten ( + `var name by remember { mutableStateOf(...) }`). +* *Aktion:* Konsequente Auslagerung in ViewModels (z. B. `VeranstalterViewModel`, `PferdProfilViewModel`), um die + Geschäftslogik von der UI zu trennen und die Testbarkeit zu erhöhen. + +**🟠 P2: Datenbindung & Store-Ablösung** + +* *Warum:* Das Frontend arbeitet momentan stark mit einem Mock-Store (`StoreV2`). +* *Aktion:* Vorbereitung der Ktor-Clients und Repositories, um die tatsächlichen Backend-Endpunkte für echte + CRUD-Operationen anzubinden. + +**🟠 P2: CRUD-Vervollständigung (Delete)** + +* *Warum:* Die "Bearbeiten"-Dialoge sind vorhanden, aber die Lösch-Funktionalität fehlt in den neuen V2-Screens noch + weitgehend. +* *Aktion:* Implementierung von Lösch-Bestätigungsdialogen und entsprechender Store-/Backend-Integration in allen + Profil-Screens. + +**🟡 P3: UI/UX-Konsistenz & Validierung** + +* *Warum:* Schnelle Iterationen haben teils zu unterschiedlichen Layout-Details oder fehlenden Validierungslogiken in + den Edit-Dialogen geführt. +* *Aktion:* Formular-Validierung härten (Pflichtfelder markieren, Fehlermeldungen anzeigen) und globales Theming ( + Material 3) strikter anwenden. diff --git a/docs/90_Reports/2026-04-02_QA_Report.md b/docs/90_Reports/2026-04-02_QA_Report.md new file mode 100644 index 00000000..69f06f53 --- /dev/null +++ b/docs/90_Reports/2026-04-02_QA_Report.md @@ -0,0 +1,36 @@ +# 🧐 [QA Specialist] Report - 2. April 2026 + +## 1. Aktueller Status + +Mit den jüngsten Commits wurde ein komplett neuer Frontend-Workflow ("Event-First" und "V2" Screens) etabliert. Es gibt +jetzt komplexe Navigationspfade (Back-Stack), Onboarding-Eingaben mit Keyboard-Handling und Wizard-artige Abläufe zur +Veranstaltungserstellung mit Bestätigungsdialogen. Die zugrundeliegende Logik verlässt sich momentan stark auf einen +lokalen In-Memory Store (`StoreV2`). + +## 2. Empfehlungen & Prioritäten + +**🔴 P1: Test-Strategie für V2-Navigation & Back-Stack** + +* *Warum:* Komplexe Navigation in Compose für Desktop ist fehleranfällig (State-Verlust, Endlosschleifen). +* *Aktion:* Ausweitung der UI-Tests (z. B. `DeepLinkHandlerTest`) auf den neuen Back-Stack. Spezielles Augenmerk auf + Edge-Cases: Was passiert beim wiederholten "Zurück"-Navigieren aus tief verschachtelten Profil-Bearbeitungs-Dialogen? + +**🟠 P2: Edge-Cases im Onboarding & Event-Wizard prüfen** + +* *Warum:* Das Keyboard-Handling (Tab/Enter) wurde im Onboarding implementiert. +* *Aktion:* Systematische Tests der Eingabefelder: Verhalten bei leeren Pflichtfeldern, zu kurzen Schlüsseln, ungültigen + Zeichen oder schnellem Klicken während der Wizard-Transitions. Der Zustand (State) bei "Abbrechen" im + Bestätigungsdialog muss ebenfalls verifiziert werden. + +**🟠 P2: Testdaten-Isolierung (Offline-First Vorbereitung)** + +* *Warum:* Die App initialisiert eine eigene Datenbank pro Veranstaltung. +* *Aktion:* Entwicklung von Testfällen, die sicherstellen, dass Daten (z. B. Nennungen) strikt zwischen verschiedenen + Veranstaltungen (Mandanten) isoliert bleiben. + +**🟡 P3: Manuelle explorative Tests der "V2" Edit-Dialoge** + +* *Warum:* Die neuen Inline-Edit-Dialoge für Reiter, Pferde, etc. sind frisch. +* *Aktion:* Systematisches manuelles Durchklicken aller Bearbeiten-Dialoge. Spezifischer Fokus auf das + Speichern-Verhalten (wird die UI sofort aktualisiert?) und das Abbrechen (werden ungespeicherte Eingaben korrekt + verworfen?). diff --git a/docs/90_Reports/2026-04-02_Rulebook_Report.md b/docs/90_Reports/2026-04-02_Rulebook_Report.md new file mode 100644 index 00000000..06c2b0cb --- /dev/null +++ b/docs/90_Reports/2026-04-02_Rulebook_Report.md @@ -0,0 +1,31 @@ +# 📜 [ÖTO/FEI Rulebook Expert] Report - 2. April 2026 + +## 1. Aktueller Status + +In der Domain-Schicht gab es Anpassungen an den Stammdaten, wie z.B. die Entfernung von "Reining" aus dem `Sparte`-Enum +und Anpassungen im `AltersklasseRechnerTest`. Im Frontend wurden neue Detail-Screens für Reiter und Pferde eingeführt, +bei denen FEI-IDs, ÖPS-Nummern und Lizenzklassen manuell eingegeben werden können. + +## 2. Empfehlungen & Prioritäten + +**🔴 P1: Validierungsregeln in V2-Screens und Backend (ÖTO/FEI Compliance)** + +* *Warum:* In den neuen Profil-Dialogen (`ReiterProfilV2`, `PferdProfilV2`) können beliebige Strings für OEPS-Nummern, + FEI-IDs und Lizenzen eingegeben werden. Dies führt zu fehlerhaften Nennungen. +* *Aktion:* Strikte Validierungs-Logik gemäß ÖTO/FEI-Regelwerk implementieren (z.B. OEPS-Nummern-Format prüfen, + Lizenzklassen-Wertebereich einschränken R1-R4, etc.). Dies muss sowohl im Frontend (Live-Feedback) als auch im + Backend (Sicherheit) geschehen. + +**🟠 P2: Altersklassen und Sparten-Abgleich** + +* *Warum:* Die Altersklassenberechnung muss für Nennungen zwingend fehlerfrei funktionieren, da sie über die + Startberechtigung entscheidet. +* *Aktion:* Den `AltersklasseRechner` auf Basis der aktuellsten ÖTO (2026) vollständig durchtesten und sicherstellen, + dass das Jahr der Veranstaltung und das Geburtsjahr des Reiters/Pferdes gemäß den Regeln für die jeweilige Sparte + korrekt verrechnet werden. + +**🟡 P3: Funktionärs-Qualifikationen prüfen** + +* *Warum:* Im neuen `FunktionaerProfilV2` wird die `richterQualifikation` als Freitext erfasst. +* *Aktion:* Umstellung auf vordefinierte Qualifikationsstufen (z.B. Parcoursbauer, Richter Dressur/Springen) gemäß + ÖTO-Vorgaben, um bei der Veranstaltungsplanung regelkonforme Besetzungen sicherzustellen. diff --git a/docs/90_Reports/2026-04-02_UIUX_Report.md b/docs/90_Reports/2026-04-02_UIUX_Report.md new file mode 100644 index 00000000..c24ac80c --- /dev/null +++ b/docs/90_Reports/2026-04-02_UIUX_Report.md @@ -0,0 +1,38 @@ +# 🖌️ [UI/UX Designer] Report - 2. April 2026 + +## 1. Aktueller Status + +Das Desktop-Frontend hat ein umfassendes Update erfahren. Es wurden viele neue V2-Ansichten für die Stamm- und +Bewegungsdaten eingeführt. Positiv hervorzuheben ist die Implementierung der Mockups `Veranstalter-Card-v01.png` und +`Veranstalter-Profil-Card-v01.png`. Die Layouts für Reiter-, Pferde- und Vereinsprofile nutzen jetzt einheitlichere +Cards mit Initialen-Avataren. Die Navigation ist durch Breadcrumbs und Zurück-Pfeile deutlich transparenter geworden. + +## 2. Empfehlungen & Prioritäten + +**🔴 P1: Dialog-Design vs. Fullscreen-Bearbeitung** + +* *Warum:* Aktuell werden die Bearbeitungs-Formulare (z. B. für Reiter, Pferde) als `AlertDialog` über das Profil + gelegt. Bei vielen Feldern (insbesondere später bei Nennungen) wird das auf dem Desktop unübersichtlich und bricht mit + dem "High-Density" Konzept. +* *Aktion:* Überarbeitung des UX-Konzepts für das Editieren: Evaluierung, ob Formulare besser als dedizierte Screens ( + oder Sliding-Panels) umgesetzt werden sollten, statt klassische Modals zu verwenden. + +**🟠 P2: Informationsarchitektur der Listenansichten verbessern** + +* *Warum:* Die Listenansichten (z. B. in der `VeranstalterVerwaltungScreen`) nutzen teilweise noch rohe Tabellenlayouts, + die nicht so elegant wirken wie die neuen Profil-Karten. +* *Aktion:* Das Design der "High-Density Data Tables" verfeinern (siehe Material 3 Guidelines für Desktop). Bessere + typografische Hierarchie, Hover-States und klarere Action-Buttons innerhalb der Zeilen definieren. + +**🟠 P2: Leere Zustände (Empty States) visuell aufwerten** + +* *Warum:* Momentan wird oft nur grauer Text ("Keine passenden Veranstaltungen gefunden") angezeigt. +* *Aktion:* Entwurf und Implementierung von ansprechenden "Empty States" mit passenden Icons (z.B. ein leeres Dokument + oder ein Pferdekopf-Icon) und klaren "Call-to-Action"-Buttons ("Jetzt erstes Pferd anlegen"), um den User besser zu + führen. + +**🟡 P3: Farbschema und Theming vereinheitlichen** + +* *Warum:* Es gibt noch vereinzelt hartkodierte Hex-Werte (z.B. für die Avatar-Hintergründe). +* *Aktion:* Definition einer konsistenten Farbpalette im `DesktopThemeV2`, die semantische Farben für Status (Aktiv, + Inaktiv, Fehler) und Platzhalter konsistent über die gesamte Anwendung bereitstellt. diff --git a/docs/99_Journal/2026-04-02_Session_Log.md b/docs/99_Journal/2026-04-02_Session_Log.md new file mode 100644 index 00000000..33c9691f --- /dev/null +++ b/docs/99_Journal/2026-04-02_Session_Log.md @@ -0,0 +1,32 @@ +# 🧹 [Curator] Session Log - 2. April 2026 + +## Zusammenfassung + +Der User forderte basierend auf den massiven Frontend-Änderungen der letzten Tage einen Statusbericht und priorisierte +nächste Schritte von fast allen Agenten an (`🎨 [Frontend Expert]`, `👷 [Backend Developer]`, +`📜 [ÖTO/FEI Rulebook Expert]`, `🐧 [DevOps Engineer]`, `🧐 [QA Specialist]`, `🖌️ [UI/UX Designer]`, `🧹 [Curator]`). + +## Aktionen + +* Analyse der Git-Historie und des Commits `d3d80f69` (Neue V2-Screens, Onboarding-Verbesserungen, Bestätigungsdialoge). +* Erstellung und Speicherung detaillierter Reports in `docs/90_Reports/`: + * `2026-04-02_Frontend_Report.md` + * `2026-04-02_Backend_Report.md` + * `2026-04-02_Rulebook_Report.md` + * `2026-04-02_DevOps_Report.md` + * `2026-04-02_QA_Report.md` + * `2026-04-02_UIUX_Report.md` + * `2026-04-02_Curator_Report.md` + +## Nächste Schritte (Übergreifend) + +1. **Frontend/UI:** Fokus auf State-Management (ViewModels statt lokaler UI-State), Vorbereitung der API-Anbindung und + Überarbeitung der UX für die Edit-Dialoge. +2. **Backend:** Bereitstellung der benötigten CRUD-Endpunkte für die neuen V2-Screens und Abgleich der + DTOs/Datenbank-Schemas. +3. **QA/Rulebook:** Strikte Validierungsregeln implementieren und den komplexen Back-Stack (Navigation) durch + automatisierte und manuelle Tests absichern. +4. **DevOps/Architektur:** Dokumentation der Offline-Architektur (Tenant-Isolation/LAN-Sync) vervollständigen und die + CI/CD-Pipeline für Compose-Desktop-Pakete vorbereiten. +5. **Clean-Up:** Alte "V1"-Screens und ungenutzte Platzhalter entfernen und die Ordnerstruktur für Dokumente und Reports + aufräumen.