mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: update roadmap with finalized frontend modernization phase, refactor turnier and veranstalter features to adhere to Plug-and-Play architecture, and improve code hygiene in core frontend modules
Some checks failed
Desktop CI — Headless Tests & Build / Compose Desktop — Tests (headless) & Build (push) Has been cancelled
Details
Build and Publish Docker Images / build-and-push (., backend/infrastructure/gateway/Dockerfile, api-gateway, api-gateway) (push) Has been cancelled
Details
Build and Publish Docker Images / build-and-push (., backend/services/ping/Dockerfile, ping-service, ping-service) (push) Has been cancelled
Details
Build and Publish Docker Images / build-and-push (., config/docker/caddy/web-app/Dockerfile, web-app, web-app) (push) Has been cancelled
Details
Build and Publish Docker Images / build-and-push (., config/docker/keycloak/Dockerfile, keycloak, keycloak) (push) Has been cancelled
Details

Browse Source
This commit is contained in:
Stefan Mogeritsch 2026-04-20 10:55:24 +02:00
parent 8aef46bba1
commit 5887ac7b6c
2 changed files with 14 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
docs/01_Architecture/MASTER_ROADMAP.md
View File

@ -2,12 +2,12 @@
type: Roadmap type: Roadmap
status: ACTIVE status: ACTIVE
owner: Lead Architect owner: Lead Architect
last_update: 2026-04-11 last_update: 2026-04-20
--- ---
# MASTER ROADMAP: Meldestelle # MASTER ROADMAP: Meldestelle
🏗️ **[Lead Architect]** | 11. April 2026 🏗️ **[Lead Architect]** | 20. April 2026
**Strategisches Ziel:** **Strategisches Ziel:**
Entwicklung einer ÖTO-konformen, offline-fähigen Turnier-Meldestelle als Compose Desktop App (KMP). Entwicklung einer ÖTO-konformen, offline-fähigen Turnier-Meldestelle als Compose Desktop App (KMP).
@ -276,18 +276,16 @@ und über definierte Schnittstellen kommunizieren.
## 4. Geplante Phasen ## 4. Geplante Phasen
### PHASE 13: Export & ZNS-Rückmeldung ✅ ABGESCHLOSSEN (18. April 2026) ### PHASE 13: Frontend-Modernisierung & Cleanup ✅ ABGESCHLOSSEN (20. April 2026)
*Ziel: Finalisierung der Turnier-Daten und Rückübermittlung an den OEPS.* *Ziel: Finalisierung der Turnier-Daten, Rückübermittlung an den OEPS und architektonische Bereinigung.*
* [x] **Mail-Service Integration:** Online-Nennungen via REST/Mail empfangen und persistieren. ✓ (April 2026) * [x] **"V2"-Bereinigung:** Vollständige Eliminierung aller "V2"-Suffixe in Dateinamen und Symbolen (z.B. `TurnierWizardV2`, `VeranstalterAuswahlV2`). ✓ (20. April 2026)
* [x] **Connectivity-Diagnose:** Stabiles Diagnose-Tool für Backend-, DB- und Auth-Verbindung in der Desktop-App. ✓ ( * [x] **Plug-and-Play (Turnier):** Umstellung des `turnier-feature` auf ADR-0024. Entfernung von Reflection-Zugriffen auf die Shell und Einführung von ViewModel-Hoisting. ✓ (20. April 2026)
18. April 2026) * [x] **Plug-and-Play (Veranstalter):** Umstellung des `veranstalter-feature` auf ADR-0024. Einführung des `VeranstalterDetailViewModel` und Konsolidierung der Screens in der Desktop-Shell. ✓ (20. April 2026)
* [x] **Plug-and-Play Architektur:** Umstellung der Frontend-Komponenten auf fachlich autarke Organismen (ADR-0024). * [x] **Code-Hygiene:** Beseitigung von Code-Smells, redundanten Validierungen und ungenutzten Parametern in den zentralen Frontend-Modulen. ✓ (20. April 2026)
✓ (18. April 2026) * [x] **Connectivity-Diagnose:** Stabiles Diagnose-Tool für Backend-, DB- und Auth-Verbindung in der Desktop-App. ✓ (18. April 2026)
* [x] **WASM-Transition:** Projektweite Umstellung auf JVM (Desktop) und wasmJs (Web). Eliminierung von `js(IR)`. ✓ ( * [x] **WASM-Transition:** Projektweite Umstellung auf JVM (Desktop) und wasmJs (Web). Eliminierung von `js(IR)`. ✓ (18. April 2026)
18. April 2026) * [x] **Geräte-Initialisierung:** Refactoring des Onboarding-Prozesses in das Plug-and-Play Modul `device-initialization`. ✓ (18. April 2026)
* [x] **Geräte-Initialisierung:** Refactoring des Onboarding-Prozesses in das Plug-and-Play Modul
`device-initialization`. ✓ (18. April 2026)
* [ ] **XML-Export:** Vollständiger B-Satz Export (inkl. Ergebnisse und Platzierungen). * [ ] **XML-Export:** Vollständiger B-Satz Export (inkl. Ergebnisse und Platzierungen).
* [ ] **ZNS-Portal:** Upload-Integration in das OEPS-ZNS. * [ ] **ZNS-Portal:** Upload-Integration in das OEPS-ZNS.
* [ ] **Archivierung:** Langzeit-Archivierung abgeschlossener Turniere. * [ ] **Archivierung:** Langzeit-Archivierung abgeschlossener Turniere.

3
docs/01_Architecture/adr/0024-plug-and-play-architektur.md
View File

@ -10,6 +10,9 @@ Das Projekt "Meldestelle" strebt eine Multiplattform-Anwendung (KMP) für Deskto
Stabilitätsprobleme im Frontend (der "Kartenhaus-Effekt") wurden durch eng gekoppelte UI-Komponenten und Screens Stabilitätsprobleme im Frontend (der "Kartenhaus-Effekt") wurden durch eng gekoppelte UI-Komponenten und Screens
verursacht. Änderungen in einem Bereich (z.B. Routing) führten zu Zusammenbrüchen in nicht verwandten Features. verursacht. Änderungen in einem Bereich (z.B. Routing) führten zu Zusammenbrüchen in nicht verwandten Features.
Besonders kritisch waren direkte Zugriffe auf Shell-interne Datenstrukturen via Reflection oder direkte Injektion von
ViewModels innerhalb von Composables via `koinInject()`, was die Unabhängigkeit der Feature-Module untergrub.
## Entscheidung ## Entscheidung
Wir führen eine "Plug-and-Play"-Architektur für alle Frontend-Komponenten ein. Diese Strategie stellt sicher, dass Wir führen eine "Plug-and-Play"-Architektur für alle Frontend-Komponenten ein. Diese Strategie stellt sicher, dass