chore: entferne veraltete Architekturdokumente
Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>
This commit is contained in:
@@ -0,0 +1,89 @@
|
||||
# Frontend-Komponenten Roadmap: Meldestelle-Biest
|
||||
|
||||
🏗️ **[Lead Architect]** | 31. März 2026
|
||||
|
||||
Diese Roadmap definiert den Weg von der aktuellen Prototypen-Phase hin zu einer professionellen, konsistenten und
|
||||
performanten Desktop-App. Wir setzen auf einen komponentengetriebenen Ansatz (High-Density UI), um die komplexe
|
||||
Datenverwaltung der Turniermeldestelle effizient abzubilden.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Cleanup & Konsolidierung (Das Fundament) ✅ [ABGESCHLOSSEN]
|
||||
|
||||
Bevor wir neue Features bauen, räumen wir die bestehenden Entwürfe auf, um Redundanzen zu vermeiden.
|
||||
|
||||
* [x] **Design-System Refactoring:**
|
||||
* [x] `Buttons.kt` (DenseButton) in `MsButton.kt` überführt.
|
||||
* [x] Einheitliches Naming: Alle Basis-Komponenten erhalten das Präfix `Ms` (z.B. `MsButton.kt`, `MsTextField.kt`).
|
||||
* [x] Redundante Placeholder-Dateien entfernt oder in `core/design-system/models/` bündeln.
|
||||
* [x] **Theme-Check:**
|
||||
* [x] Sicherstellen, dass alle Farben aus `AppColors` kommen und nicht hart codiert sind.
|
||||
* [x] Typografie-Skalen für High-Density optimieren (LabelSmall für Tabellen).
|
||||
* [x] **Build-Fixes:**
|
||||
* [x] Referenzen in `ping-feature` korrigiert.
|
||||
* [x] Referenzen in `profile-feature` korrigiert.
|
||||
|
||||
## Phase 2: Daten-Visualisierungs-Komponenten (Das Herzstück) ✅ [ABGESCHLOSSEN]
|
||||
|
||||
Turniermanagement bedeutet Arbeit mit Listen. Wir benötigen mächtige, aber kompakte Anzeige-Komponenten.
|
||||
|
||||
* [x] **`MsDataTable`:**
|
||||
* [x] KMP-kompatible Tabelle mit Sticky Header.
|
||||
* [x] Generische Spaltendefinition mit Custom Cell Renderern.
|
||||
* [x] Zeilen-Selektion (Einzel-Klick) und gestreiftes Zeilen-Design.
|
||||
* [x] **`MsStatusBadge`:**
|
||||
* [x] Farbliche Kodierung für Nennungsstatus, Lizenzstatus und Prüfungsstatus.
|
||||
* [x] Kompaktes Design für die Nutzung innerhalb von Tabellenzellen.
|
||||
* [x] **`MsFilterBar`:**
|
||||
* [x] Suchfeld mit Debounce-Unterstützung (Pattern-basiert).
|
||||
* [x] Filter-Chips für schnelle Status-Wechsel.
|
||||
* [x] Anzeige der Trefferanzahl (Result Count).
|
||||
|
||||
## Phase 3: Formular- & Eingabe-System (Die Datenerfassung) ✅ [ABGESCHLOSSEN]
|
||||
|
||||
Eingabe von Stammdaten muss schnell und fehlerfrei erfolgen.
|
||||
|
||||
* [x] **`MsEnumDropdown`:** Automatisches Mapping von Backend-Enums (ÖTO) auf UI-Auswahl.
|
||||
* [x] **`MsValidationWrapper`:** Konsistente Anzeige von Fehlern und Warnungen (z.B. ÖTO-Validierungsregeln).
|
||||
* [x] **`MsSearchableSelect`:** Für die Verknüpfung von Reitern/Pferden (Autocomplete-Suche).
|
||||
|
||||
## Phase 4: Layout-Patterns & Navigation ✅ [ABGESCHLOSSEN]
|
||||
|
||||
Hier bringen wir alles zusammen, bevor das finale Routing implementiert wird.
|
||||
|
||||
* [x] **`MsMasterDetailLayout`:** Standard-Layout für alle Stammdaten-Screens (Liste & Editor).
|
||||
* [x] **`MsActionToolbar`:** Einheitliche Platzierung von Hauptaktionen (Neu, Speichern, Drucken).
|
||||
* [x] **`MsDialogShell`:** Standardisierter Rahmen für Modale und Bestätigungsdialoge.
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: Routing & Screen-Komposition ✅ [ABGESCHLOSSEN]
|
||||
|
||||
In dieser Phase werden die Komponenten zu echten Features zusammengebaut.
|
||||
|
||||
* [x] **Reiter-Verwaltung (MVP):** Erster Screen mit `MsMasterDetailLayout`, `MsDataTable` und Editor.
|
||||
* [x] **Pferde-Verwaltung (MVP):** Analog zur Reiter-Verwaltung (Fertiggestellt).
|
||||
* [x] **Layout-Refactoring:** Umstellung auf Event-First Workflow (Login-Skip).
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: Vernetzung & Inter-App Kommunikation 🔵 [IN ARBEIT]
|
||||
|
||||
Nachdem die UI-Bausteine stehen, vernetzen wir die Desktop-Apps im LAN.
|
||||
|
||||
* [x] **Konzept & ADR:** ADR-0020 (LAN-Communication & Isolation) erstellt.
|
||||
* [ ] **Discovery:** mDNS Integration für automatische Gerätefindung.
|
||||
* [ ] **Sync:** WebSocket-basierte Echtzeit-Synchronisation zwischen Meldestelle und Richter.
|
||||
* [ ] **Chat:** Implementierung des veranstaltungsweiten Chat-Fensters.
|
||||
|
||||
---
|
||||
|
||||
## Erfolgs-Metriken
|
||||
|
||||
* **Wiederverwendbarkeit:** > 80% der UI besteht aus `Ms`-Komponenten.
|
||||
* **Density:** Alle relevanten Daten eines Reiters/Pferdes sind ohne Scrollen in der Detailansicht sichtbar.
|
||||
* **Performance:** `MsDataTable` rendert 500+ Zeilen flüssig auf ARM64 (Zora/Mac/Linux).
|
||||
|
||||
---
|
||||
🧹 **[Curator]** | 2026-03-31
|
||||
*Dieses Dokument dient als Single Source of Truth für die Frontend-Entwicklung.*
|
||||
@@ -0,0 +1,53 @@
|
||||
# Roadmap: Online-Nennung & Mail-Service (Phase 5)
|
||||
|
||||
## 🏗️ [Lead Architect] | 14. April 2026
|
||||
|
||||
Dieses Dokument beschreibt die Umsetzung der Online-Nennung für das Turnier in Neumarkt (24. April 2026).
|
||||
Ziel ist ein schlankes Web-Formular, das strukturierte E-Mails an den `Mail-Service` sendet, welcher diese verarbeitet
|
||||
und in der Desktop-Zentrale zur manuellen Übernahme bereitstellt.
|
||||
|
||||
---
|
||||
|
||||
### Phase 1: E-Mail-Infrastruktur (Vorbereitung) ✅
|
||||
|
||||
* [x] Definition des Adress-Schemas: `meldestelle-[Turnier-Nr]@mo-code.at`.
|
||||
* [x] Konfiguration der World4You SMTP/IMAP Zugangsdaten.
|
||||
* [x] Mailpit Integration für lokale Tests (bereits in `dc-ops.yaml`).
|
||||
|
||||
### Phase 2: Das Web-Formular (WasmJS Frontend) ✅
|
||||
|
||||
* [x] **Basis-UI:** Erstellung des Formulars gemäß Spezifikation (Reiter, Pferd, Lizenz, Bewerbe).
|
||||
* [x] **Validierung:** Implementierung der Pflichtfeld-Prüfung (Buttonsperre bis alles ok).
|
||||
* [x] **Mail-Versand:** Integration des API-Calls an das Backend (`mail-service`), um die Nennung zu speichern.
|
||||
* [x] **DSGVO:** Checkbox und Hinweistext eingebaut.
|
||||
|
||||
### Phase 3: Mail-Service (Backend-Verarbeitung) 🏗️
|
||||
|
||||
* [x] **Endpoint:** POST-Endpunkt für direkte Nennungen aus dem Web-Formular implementiert.
|
||||
* [ ] **Polling:** Implementierung des IMAP-Pollers (imap.world4you.com).
|
||||
* [ ] **Parsing:** Extraktion der Turnier-Nummer aus dem `To`-Header und Mapping auf das Datenbank-Schema (Tenant).
|
||||
* [x] **Auto-Reply:** Automatisches Versenden der Eingangsbestätigung (in `MailPollingService` vorbereitet).
|
||||
* [x] **Persistence:** Speichern der eingegangenen "Nennungs-Mails" in einer temporären Tabelle.
|
||||
|
||||
### Phase 4: Desktop-Zentrale Integration ✅
|
||||
|
||||
* [x] **UI-Tab:** Neuer Reiter "Online-Eingang" in der Turnierverwaltung (`TurnierDetailScreen`).
|
||||
* [x] **Vorschau:** Anzeige der eingegangenen Nennungen mit Details (`OnlineNennungEingangTabContent`).
|
||||
* [x] **Übernahme:** "Übernehmen"-Button, der Reiter/Pferd in die Nennung vorausfüllt (`NennungViewModel`).
|
||||
* [ ] **Abschluss:** Manueller "Bestätigen"-Button zum Versenden der finalen Bestätigungsmail.
|
||||
|
||||
### Phase 5: End-to-End Test & Deployment 🚀 (Deadline: 21.04.2026)
|
||||
|
||||
* [ ] Test-Nennung über Web-Formular (Mailpit).
|
||||
* [ ] Verifikation der Schema-Zuordnung im Backend.
|
||||
* [ ] Live-Test mit `online-nennen@mo-code.at`.
|
||||
* [ ] Go-Live für Neumarkt.
|
||||
|
||||
---
|
||||
|
||||
### Meilensteine
|
||||
|
||||
1. **16.04.:** Web-Formular ist funktionsfähig (Senden möglich).
|
||||
2. **18.04.:** Mail-Service verarbeitet Mails und sendet Auto-Antworten.
|
||||
3. **20.04.:** Desktop-UI zur Übernahme ist fertig.
|
||||
4. **24.04.:** Erstes Turnier (Neumarkt) startet mit Online-Nenn-System.
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
type: Roadmap
|
||||
status: ARCHIVED
|
||||
owner: Lead Architect
|
||||
last_update: 2026-01-15
|
||||
---
|
||||
|
||||
# Roadmap: System Hardening & Stability
|
||||
|
||||
**MOVED:** This file has been archived to `_archive/2026-01-15_Roadmap_System_Hardening.md`.
|
||||
Please use `MASTER_ROADMAP_2026_Q1.md` as the Single Source of Truth.
|
||||
@@ -0,0 +1,105 @@
|
||||
---
|
||||
type: Roadmap
|
||||
status: IN_PROGRESS
|
||||
owner: Curator
|
||||
last_update: 2026-03-25
|
||||
---
|
||||
|
||||
# Roadmap: ZNS-Importer (MVP)
|
||||
|
||||
10. **🏗️ [Lead Architect]** | 5. April 2026
|
||||
|
||||
**Kontext:**
|
||||
Der ZNS-Importer wurde für die Verarbeitung der Datei `RICHT01.dat` optimiert. Es wurde klargestellt, dass Richter (
|
||||
SatzID 'X') und Parcoursbauer (SatzID 'Y') gemeinsam in dieser Datei geliefert werden. Eine separate `PARCO01.dat`
|
||||
existiert nicht.
|
||||
Um den `registration-context` und `actor-context` unter realistischen Bedingungen testen zu können, benötigen wir echte
|
||||
Stammdaten (Reiter, Pferde, Vereine, Funktionäre). Diese Daten werden vom ÖPS (Österreichischer Pferdesportverband) in
|
||||
Form einer `ZNS.zip` bereitgestellt.
|
||||
|
||||
**Ziel:**
|
||||
Entwicklung eines asynchronen, robusten Importers für die Legacy-ZNS-Daten (`ZNS.zip`), der über die Compose-Desktop-App
|
||||
gesteuert wird und die Daten persistent im Backend (`actor-context`) ablegt.
|
||||
|
||||
---
|
||||
|
||||
## 1. Spezifikationen & Rahmenbedingungen
|
||||
|
||||
* **Dateiformat:** Fixed-Width ASCII (Feste Spaltenbreiten, keine Trennzeichen).
|
||||
* **Encoding:** Zwingend **Codepage 850 (CP850)**. (Achtung: Umlaute!).
|
||||
* **Architektur-Muster:** Asynchroner Upload & Processing (Job-Pattern).
|
||||
* **Import-Reihenfolge (Abhängigkeiten beachten!):**
|
||||
1. `VEREIN01.dat` (Vereine)
|
||||
2. `LIZENZ01.dat` (Reiter/Lizenzen)
|
||||
3. `PFERDE01.dat` (Pferde - benötigt Vereins-ID)
|
||||
4. `RICHT01.dat` (Richter & Parcoursbauer kombiniert in einer Datei)
|
||||
|
||||
---
|
||||
|
||||
## 2. Phasen & Aufgabenverteilung
|
||||
|
||||
### Phase 1: Backend-Infrastruktur & Parsing (👷 Backend Developer)
|
||||
|
||||
* [x] **API Design:**
|
||||
* `POST /api/v1/import/zns` (Multipart/form-data, nimmt `.zip` oder `.dat` entgegen).
|
||||
* Rückgabe: `202 Accepted` mit einer `JobId` (UUID).
|
||||
* `GET /api/v1/import/zns/{jobId}/status` (Gibt aktuellen Fortschritt und Statusmeldungen zurück).
|
||||
* Implementiert in `backend:services:zns-import:zns-import-service` (`ZnsImportController`). ✅
|
||||
* [x] **Job-Management:**
|
||||
* Thread-sichere In-Memory-Registry (`ImportJobRegistry`, `ConcurrentHashMap`) implementiert.
|
||||
* Status-Enum: `AUSSTEHEND`, `ENTPACKEN`, `LADE_VEREINE`, `LADE_REITER`, `LADE_PFERDE`, `LADE_RICHTER`,
|
||||
`ABGESCHLOSSEN`, `FEHLER`. ✅
|
||||
* [x] **Unzip-Service:**
|
||||
* ZIP-Entpackung in-memory implementiert (`ZnsImportService`).
|
||||
* [x] **Legacy-Parser (CP850 Fixed-Width):**
|
||||
* `ZnsLegacyParsers` in `core:zns-parser` (KMP-Modul) implementiert.
|
||||
* Alle 4 Dateitypen (VEREIN01, LIZENZ01, PFERDE01, RICHT01) bytegenau gemappt. RICHT01 verarbeitet Richter ('X') und
|
||||
Parcoursbauer ('Y'). ✅
|
||||
|
||||
### Phase 2: Domain-Mapping & Persistenz (👷 Backend Developer)
|
||||
|
||||
* [x] **Mapper-Logik:**
|
||||
* `DomVerein`, `DomReiter`, `DomPferd`, `DomFunktionaer` vollständig gemappt.
|
||||
* *Sonderfälle umgesetzt:*
|
||||
* `PFERDE01.dat`: Ausländische Systemnummern werden ignoriert. ✅
|
||||
* `LIZENZ01.dat`: Sperrlisten-Flag (`S`) korrekt auf `DomReiter` gemappt. ✅
|
||||
* [x] **Upsert-Strategie (DB):**
|
||||
* `ZnsImportService` implementiert find + save Logik (Upsert). 7 Unit-Tests grün.
|
||||
* Fehler pro Zeile werden gesammelt (kein Abbruch bei Einzelfehlern). `ZnsImportResult` mit Zählern & Fehlerlisten.
|
||||
|
||||
### Phase 3: Frontend-Integration (🎨 Frontend Expert)
|
||||
|
||||
* [x] **UI-Komponenten (Compose Desktop):**
|
||||
* `StammdatenImportScreen` in `meldestelle-desktop` erstellt. ✅
|
||||
* Nativer File-Picker (`JFileChooser`, nur `.zip`) integriert. ✅
|
||||
* `AppScreen.StammdatenImport` + Nav-Rail-Eintrag "Stammdaten-Import" hinzugefügt. ✅
|
||||
* [x] **Netzwerk & State-Management (KMP):**
|
||||
* `ZnsImportViewModel` mit Ktor Multipart-Upload (`POST /api/v1/import/zns`). ✅
|
||||
* Polling-Mechanismus (alle 2 Sekunden, `GET /api/v1/import/zns/{jobId}/status`). ✅
|
||||
* `ZnsImportViewModel` via Koin `viewModel { }` in `desktopModule` registriert. ✅
|
||||
* [x] **User Feedback:**
|
||||
* `LinearProgressIndicator` mit Live-Prozent + `progressDetail`-Text. ✅
|
||||
* `StatusChip` für alle Job-Zustände (AUSSTEHEND → ABGESCHLOSSEN/FEHLER). ✅
|
||||
* Fehler-Banner + scrollbare Fehler-Liste (max. 50 Einträge). ✅
|
||||
|
||||
### Phase 4: Testing & QA (🧐 QA Specialist)
|
||||
|
||||
* [ ] **Test-Datensatz prüfen:**
|
||||
* Einlesen der `docs/OePS/ZNS.zip` und Überprüfung der Umlaute (CP850 Encoding Test).
|
||||
* [ ] **Abhängigkeits-Test:**
|
||||
* Sicherstellen, dass Pferde korrekt ihren Vereinen zugeordnet werden.
|
||||
* [ ] **Edge-Cases:**
|
||||
* Upload einer fehlerhaften Zip-Datei.
|
||||
* Abbruch des Uploads/Imports.
|
||||
|
||||
---
|
||||
|
||||
## 3. Offene Fragen / Risiken
|
||||
|
||||
* Werden die Legacy-Daten in der Datenbank (PostgreSQL) mit UUIDs oder mit den ZNS-Satznummern als Primary Keys
|
||||
abgelegt?
|
||||
* *Architektur-Beschluss:* Wir sollten interne UUIDs als Primary Keys verwenden und die ZNS-Nummern als eindeutige
|
||||
Business-Keys (`UNIQUE CONSTRAINT`) ablegen.
|
||||
* Wie gehen wir mit gelöschten Datensätzen aus dem ZNS um?
|
||||
* *Vorerst:* Der ZNS-Import ist ein "Add/Update"-Only Vorgang. Löschungen müssen manuell oder in einer späteren Phase
|
||||
synchronisiert werden.
|
||||
Reference in New Issue
Block a user