air work test
This commit is contained in:
@@ -1,36 +0,0 @@
|
||||
---
|
||||
type: Log
|
||||
agent: Curator
|
||||
date: 2026-02-07
|
||||
status: COMPLETED
|
||||
---
|
||||
|
||||
# 🧹 Session Log: 07. Februar 2026
|
||||
|
||||
## Zusammenfassung
|
||||
Heute wurde der neue Home-Server (Minisforum MS-R1) in Betrieb genommen. Der Fokus lag auf der Einrichtung des Host-Betriebssystems (Debian 12 ARM64) und der Virtualisierungs-Plattform (Incus).
|
||||
|
||||
## Erreichte Meilensteine
|
||||
1. **Hardware-Integration:**
|
||||
* Dokumentation für Minisforum MS-R1 erstellt (Handbuch, Specs).
|
||||
* Roadmap aktualisiert (Hardware-Status: GELIEFERT).
|
||||
2. **Host-Setup:**
|
||||
* SSH-Zugang und Basic Hardening (User, Firewall) durchgeführt.
|
||||
* **Incus Installation:** Erfolgreich auf dem Vendor-Kernel (`6.6.10-cix-build-generic`) installiert.
|
||||
* **Netzwerk-Fix:** Da dem Vendor-Kernel Module für Bridges fehlen, wurde erfolgreich auf **Macvlan** umgestellt. Container erhalten nun IPs direkt aus dem Heimnetz (`10.0.0.x`).
|
||||
3. **Infrastructure Services:**
|
||||
* `infra-gitea` (LXC Container) wurde erstellt und gestartet.
|
||||
* Gitea Binary installiert.
|
||||
|
||||
## Offene Punkte / Blocker
|
||||
* **Gitea Service:** Der `gitea.service` startet nicht sauber (`exit-code 1`). Es gibt Probleme mit der Konfiguration (`app.ini`) oder Dateirechten, speziell im Zusammenhang mit Pfaden (`/usr/local/bin/data` vs `/var/lib/gitea`).
|
||||
* *Nächster Schritt:* Manuelles Debugging im Vordergrund (`su - git -c ...`), um die genaue Fehlermeldung zu sehen.
|
||||
* **Docker Host:** Die VM `docker-host-prod` wurde noch nicht erstellt. Dies ist der nächste logische Schritt nach dem Gitea-Fix.
|
||||
|
||||
## Dokumentation
|
||||
* Neu: `docs/01_Architecture/Minisforum-MS-R1/Setup_Guide_Host_OS.md` (Fertig)
|
||||
* Neu: `docs/01_Architecture/Minisforum-MS-R1/Setup_Guide_Services.md` (In Arbeit)
|
||||
* Update: `docs/01_Architecture/MASTER_ROADMAP_2026_Q1.md`
|
||||
|
||||
## Ausblick
|
||||
Die nächste Session sollte sich auf die Stabilisierung von Gitea und die Einrichtung der Docker-VM konzentrieren, um die Plattform für die Meldestelle-App bereit zu machen.
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
type: Log
|
||||
agent: DevOps Engineer
|
||||
date: 2026-02-07
|
||||
status: IN_PROGRESS
|
||||
---
|
||||
|
||||
# 🐧 Log: Hardware Setup Minisforum MS-R1
|
||||
|
||||
## Kontext
|
||||
Der neue Home-Server (Minisforum MS-R1) ist eingetroffen. Dies ist die Ziel-Hardware für den "Offline-First" Betrieb der Meldestelle.
|
||||
Wir haben die Dokumentation (Handbuch & Specs) erhalten und beginnen mit der Integration in die Architektur-Dokumentation.
|
||||
|
||||
## Hardware Specs (Zusammenfassung)
|
||||
* **Modell:** Minisforum MS-R1
|
||||
* **CPU:** CP8180 (12 Cores / 12 Threads, 2.6 GHz) - ARM64 Architektur? (Muss verifiziert werden, Specs sagen "Arm Immortalis-G720" GPU, deutet auf ARM SoC hin).
|
||||
* **RAM:** Max 64GB LPDDR5 5500MHz (ECC Supported).
|
||||
* **Storage:** 1x M.2 NVMe (PCIe 4.0 x4).
|
||||
* **Network:** 2x 10G LAN (SFP+ via RTL8127?). *Korrektur aus Specs:* "10G LAN(RJ45)(RTL8127) x 2".
|
||||
* **OS Support:** Debian 12 (Vendor Image vorhanden).
|
||||
|
||||
## Actions
|
||||
1. [x] Dokumentation (Handbuch, Specs) gesichtet.
|
||||
2. [ ] `MASTER_ROADMAP` aktualisieren (Hardware-Details bestätigen).
|
||||
3. [ ] Systemabbild sichern (bereits vom User erledigt).
|
||||
|
||||
## Nächste Schritte
|
||||
* Verifizierung der CPU-Architektur (ARM64 vs x86). Die Roadmap ging von ARM64 aus. Die Specs nennen "CP8180" und "Arm Immortalis", was dies bestätigt.
|
||||
* Planung der Virtualisierung (Incus auf Debian 12).
|
||||
@@ -1,81 +0,0 @@
|
||||
---
|
||||
type: Log
|
||||
agent: Curator
|
||||
date: 2026-03-21
|
||||
status: COMPLETED
|
||||
---
|
||||
|
||||
# 🧹 Session Log: 21. März 2026
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
Diese Session hatte zwei Schwerpunkte: (1) Etablierung eines neuen **Figma → Repo → Compose**-Workflows für die
|
||||
UI-Entwicklung und (2) Implementierung der ersten vollständigen Feature-Maske der **Master Desktop-App** – die
|
||||
`NennungsMaske`.
|
||||
|
||||
## Erreichte Meilensteine
|
||||
|
||||
### 1. Figma-Workflow etabliert
|
||||
|
||||
- Stefan hat in **Figma Make** einen interaktiven Prototyp der Desktop-Nennungs-Maske erstellt.
|
||||
- Der Export (React/TypeScript-Code + Assets) wurde direkt ins Repo unter `docs/06_Frontend/FIGMA/` kopiert.
|
||||
- Dieser "brutale aber geniale" Workflow ermöglicht es, Figma-Exports als **direkte Blaupause** für die
|
||||
Compose-Implementierung zu nutzen.
|
||||
- Neuer Standard-Workflow: `Figma Make (Stefan) → Export ins Repo → Compose-Implementierung (Agent)`
|
||||
|
||||
### 2. Neues Feature-Modul: `nennung-feature`
|
||||
|
||||
- Neues KMP-Modul erstellt: `frontend/features/nennung-feature`
|
||||
- Enthält:
|
||||
- `NennungModels.kt` – Domain-Modelle (Pferd, Reiter, Bewerb, Nennung, VerkaufsArtikel)
|
||||
- `NennungViewModel.kt` – State-Management mit Koin DI
|
||||
- `NennungsMaske.kt` – Vollständige 3-Spalten-Composable (Pferd/Reiter-Suche | Aktions-Hub | Verkauf/Buchungen +
|
||||
Bewerbsliste)
|
||||
- Mock-Daten aus dem Figma-Export übernommen (echte Preise: Boxenpauschale 115€, Heu 13€, etc.)
|
||||
|
||||
### 3. Navigation & Shell-Integration
|
||||
|
||||
- `AppScreen.Nennung` in der Navigation registriert (`AppScreen.kt`)
|
||||
- `expect/actual`-Pattern für `NennungScreenContent` implementiert (JVM: vollständige Maske, JS: Placeholder)
|
||||
- `main.kt`: `nennungFeatureModule` in Koin registriert
|
||||
- `MainApp.kt`: Dashboard-Button "Nennungs-Maske öffnen" + Nennung-Branch in der Navigation
|
||||
|
||||
## Fachlicher Kontext: Nennungs-Maske
|
||||
|
||||
Die Nennungs-Maske ist das **Herzstück der Desktop-App**. Sie basiert auf dem Altsystem SuDo und wurde analysiert anhand
|
||||
von:
|
||||
|
||||
- `docs/80_Assets/frontend/sudo/Nennungen.PNG`
|
||||
- `docs/80_Assets/frontend/sudo/Nennungen-Buchungen.PNG`
|
||||
- `docs/80_Assets/frontend/sudo/NennungsTausch.PNG`
|
||||
- Screenshot „Desktop‑Nennmaske (2026‑03‑21_11‑53)“ — aktuell nicht im Repo verfügbar. Hinweis: Umbenennung laut Mapping vorgesehen (`docs/06_Frontend/Screenshots/_mapping_alt-zu-neu.md`).
|
||||
|
||||
Layout: 3 Spalten
|
||||
|
||||
- **Links:** Pferd- und Reiter-Suche + Nennungstabelle (Tabs: Reiter | Pferd | Bewerbe)
|
||||
- **Mitte:** Aktions-Hub (Nennung durchführen, Stornieren, Startliste, Ergebnisse, Abrechnung)
|
||||
- **Rechts:** Verkauf/Buchungen (Tabs) + Bewerbsliste mit Filter
|
||||
|
||||
## Offene Punkte / Nächste Schritte
|
||||
|
||||
- **Nennungstausch-Dialog** – eigene Maske/Modal (3-teilig: Quell-Nennung | Tausch-Optionen | Ziel-Nennung)
|
||||
- **Keyboard-Shortcuts** – F5 (Nennung), F6 (Stornieren), F7 (Startliste), F8 (Ergebnisse), Escape (Leeren)
|
||||
- **Lizenz-Badge** – grün/rot bei Reiter-Metadaten (nach Auswahl)
|
||||
- **Konto-Saldo** – rot wenn negativ, bei Reiter-Info
|
||||
- **Offline-Indikator** – Badge in der Titelleiste
|
||||
- **Weitere Masken** – Ergebnis-Erfassung, Startlisten-Erstellung (nächste Figma-Exports von Stefan)
|
||||
|
||||
## Dokumentation
|
||||
|
||||
- Neu: `frontend/features/nennung-feature/` (vollständiges KMP-Modul)
|
||||
- Neu: `docs/06_Frontend/FIGMA/` (Figma Make Export – React/TypeScript Blaupause)
|
||||
- Hinweis: Screenshot „Desktop‑Nennmaske (2026‑03‑21_11‑53)“ fehlt aktuell; Wiederherstellung/Neuverlinkung ausstehend
|
||||
- Update: `frontend/core/navigation/src/commonMain/kotlin/at/mocode/frontend/core/navigation/AppScreen.kt`
|
||||
- Update: `frontend/shells/meldestelle-portal/src/commonMain/kotlin/MainApp.kt`
|
||||
- Update: `frontend/shells/meldestelle-portal/src/jvmMain/kotlin/main.kt`
|
||||
|
||||
## Build-Status
|
||||
|
||||
- ✅ `./gradlew :frontend:features:nennung-feature:compileKotlinJvm` → BUILD SUCCESSFUL
|
||||
- ✅ `./gradlew :frontend:shells:meldestelle-portal:compileKotlinJvm` → BUILD SUCCESSFUL
|
||||
- ✅ Desktop-App startet erfolgreich (Koin initialisiert, lokale DB erstellt)
|
||||
@@ -1,261 +0,0 @@
|
||||
---
|
||||
type: Log
|
||||
agent: Curator
|
||||
date: 2026-03-23
|
||||
status: COMPLETED
|
||||
topics:
|
||||
- ZNS-Importer
|
||||
- Backend-Services
|
||||
- Dev-Seeder
|
||||
- Testdaten
|
||||
---
|
||||
|
||||
# 🧹 Session Log: 23. März 2026 – ZNS-Importer & Backend-Services
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
Diese Session hatte das Ziel, **echte Testdaten aus dem ZNS-System (Zentrales Nennsystem des OEPS)** für die
|
||||
Frontend-Entwicklung bereitzustellen. Dazu wurden vier Backend-Services aufgebaut, die die ZNS-Rohdaten
|
||||
(Fixbreiten-Flat-Files) in eine lokale PostgreSQL-Datenbank importieren.
|
||||
|
||||
---
|
||||
|
||||
## Kontext: Was ist ZNS?
|
||||
|
||||
Das **ZNS (Zentrales Nennsystem)** ist das Stammdaten-System des OEPS (Österreichischer Pferdesport-Verband).
|
||||
Es liefert Rohdaten als **Fixbreiten-Flat-Files** (`.dat`) – ein klassisches Format älterer Verbandssysteme.
|
||||
|
||||
Die Rohdaten liegen unter: `docs/OePS/ZNS/`
|
||||
|
||||
| Datei | Inhalt | Datensätze |
|
||||
|----------------------|-----------------------------------|------------|
|
||||
| `PFERDE01.dat` | Pferde-Stammdaten | ~tausende |
|
||||
| `LIZENZ01.dat` | Reiter / Personen / Lizenzen | ~tausende |
|
||||
| `VEREIN01.dat` | Vereine / Clubs | ~hunderte |
|
||||
| `RICHT01.dat` | Richter / Offizielle | ~hunderte |
|
||||
| `ISLANDPFERDE01.dat` | Islandpferde (separates Register) | – |
|
||||
| `VOLT01.dat` | Voltigier-Daten | – |
|
||||
|
||||
---
|
||||
|
||||
## Was wurde gebaut?
|
||||
|
||||
### Strategische Entscheidung: Dev-Seeder, kein Produktions-Importer
|
||||
|
||||
Es wurde bewusst **kein produktiver Import-Service** gebaut, sondern ein **Dev-Seeder** (`@Profile("dev")`).
|
||||
Das bedeutet:
|
||||
|
||||
- Der Seeder läuft **nur im `dev`-Profil** – nie in Produktion
|
||||
- Die Tabellen tragen das Präfix `zns_` – klar erkennbar als Import-Rohdaten
|
||||
- Der Seeder ist **wegwerfbar** – der saubere Produktions-Importer folgt in Phase 3
|
||||
|
||||
### Vier neue Backend-Services
|
||||
|
||||
Alle Services folgen der gleichen Struktur wie der bestehende `horses`-Service:
|
||||
|
||||
```
|
||||
backend/services/
|
||||
├── horses/ ✅ Pferde (PFERDE01.dat → zns_horses)
|
||||
├── persons/ ✅ Personen (LIZENZ01.dat → zns_persons)
|
||||
├── clubs/ ✅ Vereine (VEREIN01.dat → zns_clubs)
|
||||
└── officials/ ✅ Richter (RICHT01.dat → zns_officials)
|
||||
```
|
||||
|
||||
Jeder Service besteht aus drei Modulen:
|
||||
|
||||
| Modul | Inhalt |
|
||||
|--------------------|-------------------------------------------------------------------|
|
||||
| `*-domain` | Domain-Modell (`DomPferd`, `DomPerson`, `DomClub`, `DomOfficial`) |
|
||||
| `*-infrastructure` | Datenbank-Tabelle (`ZnsHorseTable`, `ZnsPersonTable`, etc.) |
|
||||
| `*-service` | Spring Boot App + `DatabaseConfiguration` + `ZnsXxxSeeder` |
|
||||
|
||||
### Datenbank-Tabellen (ZNS-Präfix)
|
||||
|
||||
| Service | Tabelle | Quelle |
|
||||
|---------------------|-----------------|----------------|
|
||||
| `horses-service` | `zns_horses` | `PFERDE01.dat` |
|
||||
| `persons-service` | `zns_persons` | `LIZENZ01.dat` |
|
||||
| `clubs-service` | `zns_clubs` | `VEREIN01.dat` |
|
||||
| `officials-service` | `zns_officials` | `RICHT01.dat` |
|
||||
|
||||
Das `zns_`-Präfix macht sofort klar: **Diese Daten kommen aus dem ZNS-Import** und sind noch nicht das
|
||||
saubere Domain-Modell.
|
||||
|
||||
### Fixbreiten-Parser
|
||||
|
||||
Jeder Seeder enthält einen eigenen Fixbreiten-Parser für das jeweilige `.dat`-Format.
|
||||
Beispiel `LIZENZ01.dat` (220 Zeichen pro Zeile):
|
||||
|
||||
```
|
||||
[0-5] LizenzNr
|
||||
[6-55] Nachname
|
||||
[56-80] Vorname
|
||||
[81-83] VereinsNr
|
||||
[84-133] VereinsName
|
||||
[134-136] Nation
|
||||
[137-143] LizenzKlasse (R1, R2, RD2, ...)
|
||||
[144-156] MitgliedsNr
|
||||
[170] Geschlecht (M/W)
|
||||
[171-178] Geburtsdatum (YYYYMMDD)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Betriebsanleitung: So startest du die Services
|
||||
|
||||
### Voraussetzungen
|
||||
|
||||
1. **PostgreSQL läuft lokal** (via Docker Compose):
|
||||
```bash
|
||||
docker compose -f dc-infra.yaml up -d
|
||||
```
|
||||
Standard-Verbindung: `jdbc:postgresql://localhost:5432/meldestelle` (User/PW: `meldestelle`)
|
||||
|
||||
2. **ZNS-Dateien sind vorhanden** unter `docs/OePS/ZNS/`
|
||||
```
|
||||
docs/OePS/ZNS/
|
||||
├── PFERDE01.dat
|
||||
├── LIZENZ01.dat
|
||||
├── VEREIN01.dat
|
||||
└── RICHT01.dat
|
||||
```
|
||||
|
||||
### Service starten & Daten importieren
|
||||
|
||||
Jeden Service **einmalig** mit dem `dev`-Profil starten. Der Seeder läuft automatisch beim Start.
|
||||
|
||||
```bash
|
||||
# Pferde importieren (PFERDE01.dat → zns_horses)
|
||||
ZNS_DATA_DIR=$(pwd)/docs/OePS/ZNS \
|
||||
./gradlew :horses:horses-service:bootRun \
|
||||
--args='--spring.profiles.active=dev'
|
||||
|
||||
# Personen/Reiter importieren (LIZENZ01.dat → zns_persons)
|
||||
ZNS_DATA_DIR=$(pwd)/docs/OePS/ZNS \
|
||||
./gradlew :persons:persons-service:bootRun \
|
||||
--args='--spring.profiles.active=dev'
|
||||
|
||||
# Vereine importieren (VEREIN01.dat → zns_clubs)
|
||||
ZNS_DATA_DIR=$(pwd)/docs/OePS/ZNS \
|
||||
./gradlew :clubs:clubs-service:bootRun \
|
||||
--args='--spring.profiles.active=dev'
|
||||
|
||||
# Richter importieren (RICHT01.dat → zns_officials)
|
||||
ZNS_DATA_DIR=$(pwd)/docs/OePS/ZNS \
|
||||
./gradlew :officials:officials-service:bootRun \
|
||||
--args='--spring.profiles.active=dev'
|
||||
```
|
||||
|
||||
> **Hinweis:** Die Services können nach dem Import wieder gestoppt werden (`Ctrl+C`).
|
||||
> Die Daten bleiben in der PostgreSQL-Datenbank erhalten.
|
||||
|
||||
### Datenbank-Verbindung prüfen (optional)
|
||||
|
||||
```bash
|
||||
# Direkt via psql
|
||||
psql -h localhost -U meldestelle -d meldestelle -c "SELECT COUNT(*) FROM zns_horses;"
|
||||
psql -h localhost -U meldestelle -d meldestelle -c "SELECT COUNT(*) FROM zns_persons;"
|
||||
psql -h localhost -U meldestelle -d meldestelle -c "SELECT COUNT(*) FROM zns_clubs;"
|
||||
psql -h localhost -U meldestelle -d meldestelle -c "SELECT COUNT(*) FROM zns_officials;"
|
||||
```
|
||||
|
||||
### Datenbank zurücksetzen (neu seeden)
|
||||
|
||||
Falls die DB neu aufgesetzt werden muss (z.B. nach Schema-Änderungen):
|
||||
|
||||
```bash
|
||||
# Tabellen droppen (in psql)
|
||||
psql -h localhost -U meldestelle -d meldestelle -c "
|
||||
DROP TABLE IF EXISTS zns_horses, zns_persons, zns_clubs, zns_officials;
|
||||
"
|
||||
# Dann Services neu starten (siehe oben) – Tabellen werden automatisch neu angelegt
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Für das Frontend: Wie kommen die Daten an?
|
||||
|
||||
### Aktueller Stand (Dev-Phase)
|
||||
|
||||
Die Daten liegen in der **lokalen PostgreSQL-DB**. Das Frontend kann sie über die jeweiligen
|
||||
Service-APIs abrufen – sobald die REST-Endpoints implementiert sind.
|
||||
|
||||
> **Nächster Schritt für das Frontend-Team:**
|
||||
> Die Services haben noch **keine REST-API** (kein `-api`-Modul aktiv).
|
||||
> Für schnellen Datenzugriff kann das Frontend direkt die DB abfragen (via Backend-Gateway)
|
||||
> oder die API-Module werden als nächstes aktiviert.
|
||||
|
||||
### Empfohlene Reihenfolge für die nächsten Schritte
|
||||
|
||||
| Priorität | Aufgabe | Service |
|
||||
|-----------|--------------------------------|--------------------------------------|
|
||||
| 🔴 Hoch | REST-API für Pferde-Abfrage | `horses-api` aktivieren |
|
||||
| 🔴 Hoch | REST-API für Personen-Abfrage | `persons-api` bauen |
|
||||
| 🟡 Mittel | REST-API für Vereine | `clubs-api` bauen |
|
||||
| 🟡 Mittel | REST-API für Richter | `officials-api` bauen |
|
||||
| 🟢 Später | Produktions-Importer (Phase 3) | `ZnsImportService` mit REST-Endpoint |
|
||||
|
||||
---
|
||||
|
||||
## Technische Details
|
||||
|
||||
### Gradle-Module (settings.gradle.kts)
|
||||
|
||||
```kotlin
|
||||
// Alle vier Services sind registriert:
|
||||
include(":horses:horses-domain")
|
||||
include(":horses:horses-infrastructure")
|
||||
include(":horses:horses-service")
|
||||
|
||||
include(":persons:persons-domain")
|
||||
include(":persons:persons-infrastructure")
|
||||
include(":persons:persons-service")
|
||||
|
||||
include(":clubs:clubs-domain")
|
||||
include(":clubs:clubs-infrastructure")
|
||||
include(":clubs:clubs-service")
|
||||
|
||||
include(":officials:officials-domain")
|
||||
include(":officials:officials-infrastructure")
|
||||
include(":officials:officials-service")
|
||||
```
|
||||
|
||||
### Build-Verifikation
|
||||
|
||||
```bash
|
||||
./gradlew \
|
||||
:horses:horses-service:compileKotlin \
|
||||
:horses:horses-infrastructure:compileKotlin \
|
||||
:horses:horses-domain:compileKotlinJvm \
|
||||
:persons:persons-domain:compileKotlinJvm \
|
||||
:persons:persons-infrastructure:compileKotlin \
|
||||
:persons:persons-service:compileKotlin \
|
||||
:clubs:clubs-domain:compileKotlinJvm \
|
||||
:clubs:clubs-infrastructure:compileKotlin \
|
||||
:clubs:clubs-service:compileKotlin \
|
||||
:officials:officials-domain:compileKotlinJvm \
|
||||
:officials:officials-infrastructure:compileKotlin \
|
||||
:officials:officials-service:compileKotlin
|
||||
# → BUILD SUCCESSFUL ✅
|
||||
```
|
||||
|
||||
### Bekannte Einschränkungen / ON HOLD
|
||||
|
||||
| Modul | Status | Grund |
|
||||
|----------------------|---------|----------------------------------------|
|
||||
| `horses-api` | ON HOLD | Ktor-basiert, wird separat aktiviert |
|
||||
| `horses-common` | ON HOLD | Veraltete API-Referenzen |
|
||||
| `entries-service` | ON HOLD | Pausiert bis Domain-Workshop (Phase 3) |
|
||||
| Produktions-Importer | GEPLANT | Phase 3 – nach Domain-Workshop |
|
||||
|
||||
---
|
||||
|
||||
## Erreichte Meilensteine dieser Session
|
||||
|
||||
- ✅ `ZnsDataSeeder` für `horses` gebaut (PFERDE01.dat → `zns_horses`)
|
||||
- ✅ `ZnsPersonSeeder` für `persons` gebaut (LIZENZ01.dat → `zns_persons`)
|
||||
- ✅ `ZnsClubSeeder` für `clubs` gebaut (VEREIN01.dat → `zns_clubs`)
|
||||
- ✅ `ZnsOfficialSeeder` für `officials` gebaut (RICHT01.dat → `zns_officials`)
|
||||
- ✅ Alle Tabellen einheitlich mit `zns_`-Präfix benannt
|
||||
- ✅ Alle vier Services kompilieren erfolgreich (BUILD SUCCESSFUL)
|
||||
- ✅ `settings.gradle.kts` vollständig aktualisiert
|
||||
@@ -1,38 +0,0 @@
|
||||
# Curator Log: Abschluss Phase 9 & Zeitplan-Optimierung
|
||||
|
||||
**Datum:** 11. April 2026
|
||||
**Agent:** 🧹 [Curator]
|
||||
**Status:** ✅ PHASE 9 ABGESCHLOSSEN
|
||||
|
||||
## Zusammenfassung
|
||||
Die Phase 9 der Master-Roadmap (Zeitplan-Optimierung & Protokollierung) wurde erfolgreich abgeschlossen. Alle Kernfunktionalitäten für die dynamische Turnier-Planung und die Schnittstelle zum ZNS (Zentrales Nennungs-System) sind implementiert und verifiziert.
|
||||
|
||||
## Durchgeführte Arbeiten
|
||||
|
||||
### 1. Zeitplan-Frontend (Desktop)
|
||||
- **Drag & Drop:** Implementierung eines interaktiven Zeitstrahls (07:00 - 20:00) mit 5-Minuten-Snapping.
|
||||
- **Konflikt-Management:** Visuelle Kennzeichnung von Zeitplan-Konflikten (Überlappungen, Richter-Doppelbelegungen) basierend auf dem ÖTO-Regelwerk.
|
||||
- **Toolbar:** Zentrale Steuerung für Filter, Historie und Export.
|
||||
|
||||
### 2. Audit-Log & Protokollierung
|
||||
- **Backend:** Einführung der `audit_log` Tabelle und Hooks im `BewerbService`.
|
||||
- **Frontend:** Dedizierte Historien-Sektion zur Visualisierung von Änderungen pro Bewerb (Wer hat wann was verschoben?).
|
||||
- **Stabilität:** Behebung von Initialisierungs-Problemen im Test-Scope.
|
||||
|
||||
### 3. ZNS B-Satz Export
|
||||
- **Parser:** Erweiterung des `ZnsBewerbParser` um die Generierung von Festbreiten-Strings (`FixedWidthLineBuilder`).
|
||||
- **Export-API:** REST-Endpunkt zur Bereitstellung der `BBEWERBE` Datensätze.
|
||||
- **Vorschau:** Integrierter Dialog im Frontend zur schnellen Übernahme der Daten in `.n2` Dateien.
|
||||
|
||||
### 4. Technisches Hardening
|
||||
- **Deprecation Fixes:** Umstellung auf `suspendTransaction` in `DatabaseFactory.kt`.
|
||||
- **Typ-Sicherheit:** Harmonierung der Zeit-Modelle (`kotlin.time.Instant`, `LocalDate`, `LocalTime`).
|
||||
|
||||
## Nächste Schritte
|
||||
Der Fokus verlagert sich nun auf **Phase 10: Series-Context**.
|
||||
- Analyse der Reglements für Cups und Meisterschaften.
|
||||
- Entwurf eines konfigurierbaren Berechnungsmodells für Punktesysteme.
|
||||
- Vorbereitung der Web-Plattform Integration.
|
||||
|
||||
---
|
||||
*Gez. Curator*
|
||||
@@ -1,37 +0,0 @@
|
||||
# Curator Log: Stammdaten-Integration & Nennungs-Management
|
||||
|
||||
**Datum:** 11. April 2026
|
||||
**Status:** In Progress (Phase 10)
|
||||
**Beteiligte Agenten:** 🏗️ [Lead Architect], 👷 [Backend Developer], 🎨 [Frontend Expert], 🧹 [Curator]
|
||||
|
||||
## 🎯 Zielsetzung
|
||||
Integration der Stammdaten (Reiter, Pferde, Funktionäre, Vereine) in das Turnier-Feature des Frontends und Funktionalisierung des Nennungs-Managements.
|
||||
|
||||
## 🛠️ Technische Änderungen
|
||||
### Frontend (turnier-feature)
|
||||
- **Domain:** Einführung von `Nennung` und `Masterdata` Domänenmodellen.
|
||||
- **Data:** Implementierung von `DefaultNennungRepository` und `DefaultMasterdataRepository` zur Kommunikation mit Backend-Services.
|
||||
- **DTOs:** Anlage von REST-spezifischen Datenklassen für Nennungen und Stammdaten-Suchen.
|
||||
- **ViewModel:** `NennungViewModel` zur Steuerung der Suche und Status-Verwaltung von Nennungen.
|
||||
- **UI:**
|
||||
- `TurnierNennungenTab.kt`: Vollständige Anbindung an das ViewModel, Suchfunktionalität für Nennungen integriert.
|
||||
- `TurnierOrganisationTab.kt`: Vorbereitung für Funktionärs-Verwaltung.
|
||||
- `TurnierStammdatenTab.kt`: Zentraler Einstiegspunkt für die Stammdaten-Suche.
|
||||
- **Dependency Injection:** Registrierung der neuen Repositories und ViewModels im `TurnierFeatureModule.kt`.
|
||||
|
||||
### Core & Infrastructure
|
||||
- **Network:** `ApiRoutes` um Endpunkte für `Reiter`, `Pferde`, `Funktionäre` und `Nennungen` erweitert.
|
||||
- **Previews:** Aktualisierung der `ScreenPreviews.kt` zur Berücksichtigung der neuen ViewModel-Abhängigkeiten.
|
||||
|
||||
## ✅ Verifizierung
|
||||
- Erfolgreicher Build des Moduls `:frontend:shells:meldestelle-desktop` via Gradle.
|
||||
- Manueller Code-Review der Datenfluss-Architektur (Repository -> ViewModel -> UI).
|
||||
- Prüfung der Koin-Injektions-Kette.
|
||||
|
||||
## 📝 Notizen & Next Steps
|
||||
- Implementierung der Detail-Editoren für Reiter und Pferde (Phase 10.2).
|
||||
- Anbindung des `Organisation`-Tabs an den `FunktionaerController` des Backends.
|
||||
- Erweiterung der Nennungs-Logik um Prüfungen auf Startberechtigung (ÖTO-Check).
|
||||
|
||||
---
|
||||
*Dokumentiert durch den Curator.*
|
||||
@@ -1,34 +0,0 @@
|
||||
# Curator Log: Start Phase 10 & Turnier-Hardening
|
||||
|
||||
**Datum:** 11. April 2026
|
||||
**Agent:** 🧹 [Curator]
|
||||
**Status:** 🔵 PHASE 10 GESTARTET
|
||||
|
||||
## Zusammenfassung
|
||||
Diese Session markiert den Übergang von Phase 9 (Zeitplan) zu Phase 10 (Series-Context). Der Fokus lag auf dem "Hardening" der bestehenden Turnier-Tabs und der Grundsteinlegung für Cups und Meisterschaften im Frontend.
|
||||
|
||||
## Durchgeführte Arbeiten
|
||||
|
||||
### 1. Tab-Funktionalisierung (Start- & Ergebnislisten)
|
||||
- **Daten-Anbindung:** Die Tabs `STARTLISTEN` und `ERGEBNISLISTEN` wurden vollständig an das `BewerbViewModel` angebunden.
|
||||
- **Bewerbs-Auswahl:** Die Tabs nutzen nun die echten Bewerbe des Turniers (inkl. Name und Tag) anstelle von Platzhaltern.
|
||||
- **Startlisten-UI:** Erste Implementierung der Starter-Liste (LazyColumn) zur Visualisierung generierter Startlisten.
|
||||
- **ViewModel-Fix:** `generateStartliste()` wurde public gemacht, um die interaktive Generierung aus der UI zu ermöglichen.
|
||||
|
||||
### 2. Series-Context Vorbereitung (Phase 10)
|
||||
- **Neuer Screen:** `SeriesScreen.kt` implementiert (Placeholder-UI für Cups/Meisterschaften).
|
||||
- **Navigation:** Globale Breadcrumb-Navigation und Routing für `AppScreen.Meisterschaften` und `AppScreen.Cups` hinzugefügt.
|
||||
- **Cockpit-Integration:** Der `AdminUebersichtScreen` (Zentrale) wurde um KPI-Kacheln erweitert, die als Direkt-Links zu den neuen Series-Bereichen dienen.
|
||||
|
||||
### 3. Stabilität & Qualität
|
||||
- **Build-Check:** Erfolgreiche Kompilation des Moduls `:frontend:shells:meldestelle-desktop`.
|
||||
- **Changelog:** Dokumentation der Änderungen im globalen Changelog.
|
||||
|
||||
## Nächste Schritte
|
||||
Der Fokus verbleibt in **Phase 10: Series-Context**.
|
||||
- Analyse und Implementierung der Reglement-Strukturen (Punktetabellen, Wertungsmodi).
|
||||
- Integration des `series-context` in das Backend.
|
||||
- Verknüpfung von Bewerb-Ergebnissen mit Cup-Punkteständen.
|
||||
|
||||
---
|
||||
*Gez. Curator*
|
||||
@@ -1,29 +0,0 @@
|
||||
# 🧹 Curator Log - 2026-04-11 (Spätschicht)
|
||||
|
||||
## 📅 Session Info
|
||||
- **Datum:** 2026-04-11
|
||||
- **Agenten:** 🏗️ Lead Architect, 👷 Backend Developer, 🎨 Frontend Expert, 🧹 Curator, 📜 Rulebook Expert
|
||||
- **Fokus:** Zeitplan-Konfliktprüfung & Audit-Log
|
||||
|
||||
## 🏗️ Architektur-Entscheidungen
|
||||
- **Audit-Log (UC-4):** Einführung einer zentralen `audit_log` Tabelle im `entries-service`. Zeitplan-Änderungen werden nun mit Vorher-Nachher-Vergleich (JSON) und Zeitstempel protokolliert.
|
||||
- **Konfliktprüfung:** Erweiterung des `CompetitionWarningService` im Domain-Layer um Turnier-weite Prüfungen.
|
||||
- **Datenfluss:** Warnungen werden nun dynamisch bei jeder Zeitplan-Änderung vom Backend neu berechnet und im Frontend-DTO mitgeliefert.
|
||||
|
||||
## 👷 Backend/Integration
|
||||
- **Audit-Log:** Implementierung in `BewerbService.updateZeitplan`. Protokollierung erfolgt transaktional via `tenantTransaction`.
|
||||
- **Warn-Logik:** Neue Regeln für Platz-Überlappung und Richter-Doppelbelegung (UC-3) implementiert.
|
||||
- **Typen:** Umstellung auf `kotlin.time` für Konsistenz mit dem restlichen System (Behebung von Deprecation-Issues).
|
||||
|
||||
## 🎨 Frontend (Details)
|
||||
- **UI-Anpassung:** `TurnierZeitplanTab.kt` zeigt nun spezifische Fehlermeldungen (z.B. "Richter-Doppelbelegung mit Bewerb 5") direkt am Bewerbs-Block an.
|
||||
- **Mapping:** Mapper und DTOs wurden um das Feld `warnungen` erweitert, um die detaillierten Informationen vom Backend zu visualisieren.
|
||||
|
||||
## 🧹 Curator Status & Cleanup
|
||||
- ✅ Audit-Log Tabelle und Repository-Integration abgeschlossen.
|
||||
- ✅ Zeitplan-Konfliktregeln (Platz & Richter) im Domain-Service aktiv.
|
||||
- ✅ Frontend-Visualisierung der spezifischen Warnungen implementiert.
|
||||
- 📂 Nächster Schritt: Implementierung der automatischen Startnummern-Generierung basierend auf der Zeitplan-Reihenfolge (Phase 11).
|
||||
|
||||
---
|
||||
*Erstellt durch den Curator.*
|
||||
@@ -1,29 +0,0 @@
|
||||
# 🧹 Curator Log - 2026-04-11
|
||||
|
||||
## 📅 Session Info
|
||||
- **Datum:** 2026-04-11
|
||||
- **Agenten:** 🏗️ Lead Architect, 👷 Backend Developer, 🎨 Frontend Expert, 🧹 Curator
|
||||
- **Fokus:** Integration Zeitplan-Optimierung & Datenanbindung
|
||||
|
||||
## 🏗️ Architektur-Entscheidungen
|
||||
- **Datenfluss:** `TurnierZeitplanTab.kt` wurde erfolgreich an das `BewerbViewModel` angebunden.
|
||||
- **DI:** Das `BewerbViewModel` wird nun zentral im `TurnierDetailScreen` via Koin injiziert und an die Tabs (Bewerbe & Zeitplan) verteilt, um State-Konsistenz zu gewährleisten.
|
||||
- **Domäne:** Das Domänenmodell `Bewerb` im Frontend wurde um Zeitplan-Felder (`beginnZeit`, `geplantesDatum`, etc.) erweitert, um das Mapping zum Backend zu vervollständigen.
|
||||
|
||||
## 👷 Backend/Integration
|
||||
- **API:** Unterstützung für `PATCH /bewerbe/{id}/zeitplan` im `DefaultBewerbRepository` implementiert.
|
||||
- **ViewModel:** Neuer Intent `BewerbIntent.UpdateZeitplan` zur persistierung von Zeitänderungen.
|
||||
|
||||
## 🎨 Frontend (Details)
|
||||
- **Mapping:** Automatisches Mapping von `Bewerb` (Domain) auf `ZeitplanItemUi` (Visual) inkl. dynamischer Farbwahl nach Sparte.
|
||||
- **Interaktion:** Drag & Drop Änderungen triggern nun echte API-Calls und laden den State neu.
|
||||
- **UI:** Integration des "Bewerbe"-Tabs im `TurnierDetailScreen` vervollständigt (war vorher ein Platzhalter).
|
||||
|
||||
## 🧹 Curator Status & Cleanup
|
||||
- ✅ Datenmodelle und Mapper erweitert.
|
||||
- ✅ Repository-Anbindung vervollständigt.
|
||||
- ✅ ViewModel-Integration im UI-Layer abgeschlossen.
|
||||
- 📂 Nächster Schritt: Implementierung der automatischen Konfliktprüfung im Zeitplan (Rulebook-Validierung).
|
||||
|
||||
---
|
||||
*Erstellt durch den Curator.*
|
||||
@@ -1,35 +0,0 @@
|
||||
# Curator Log: Phase 12 - Abrechnung (Billing) & Infrastruktur-Fixes
|
||||
**Datum:** 2026-04-12
|
||||
**Status:** In Arbeit / Integration abgeschlossen
|
||||
|
||||
## 🏗️ Infrastruktur-Updates
|
||||
- **Billing Service:**
|
||||
- Dockerfile für `billing-service` erstellt (Multi-Stage Build mit JRE 25).
|
||||
- Service in `dc-backend.yaml` integriert (Port 8087, Debug 5012).
|
||||
- Gateway-Routing in `GatewayConfig.kt` für `/api/v1/billing/**` konfiguriert.
|
||||
- Spring Cloud Consul Discovery im `billing-service` aktiviert und Abhängigkeiten in `build.gradle.kts` ergänzt.
|
||||
|
||||
## 🎨 Frontend-Integration (Billing Context)
|
||||
- **Domain & Data:**
|
||||
- `BillingRepository` Interface definiert für Kontenverwaltung und Buchungshistorie.
|
||||
- `DefaultBillingRepository` implementiert mit Ktor-Client.
|
||||
- `ApiRoutes` um Billing-Konstanten erweitert.
|
||||
- **UI & State:**
|
||||
- `BillingViewModel` auf das reale Repository umgestellt (Mocks entfernt).
|
||||
- `BillingModule` (Koin) um Repository-Injektion erweitert.
|
||||
- `TurnierAbrechnungTab` im Turnier-Feature nutzt nun den funktionalen `BillingScreen`.
|
||||
|
||||
## 🧹 Fixes & Aufräumarbeiten
|
||||
- Behebung von `Unresolved reference` Fehlern in der DI-Konfiguration des `billing-service`.
|
||||
- Konsolidierung der Koin-Module im `billing-feature`.
|
||||
- **Series Service Hardening:**
|
||||
- JPA-Entitäten `Serie` und `SeriePunkt` stabilisiert und gegen JPA-Warnings optimiert.
|
||||
- Flyway-Migration `V1__Create_Series_Tables.sql` für Persistenz-Layer erstellt.
|
||||
- `DataSource` und `Consul` Konfigurationen in allen neuen Services (`results`, `series`, `events`) validiert.
|
||||
|
||||
## 🛤️ Roadmap-Status
|
||||
- Phase 12 (Billing) von "Geplant" auf "In Arbeit" gesetzt.
|
||||
- Backend-Kommunikation für Konten und Buchungen ist verifiziert.
|
||||
|
||||
---
|
||||
*Dokumentiert durch den Curator am 12.04.2026*
|
||||
@@ -1,27 +0,0 @@
|
||||
# 🧹 Curator Log - 12.04.2026
|
||||
|
||||
## 🎯 Fokus: Teilnehmer-Abrechnung & Buchungs-Logik (Phase 12)
|
||||
|
||||
Heute wurden wesentliche Fortschritte in der Billing-Infrastruktur erzielt, um die Abrechnung von Teilnehmern (Reiter/Besitzer) während der Veranstaltung zu ermöglichen.
|
||||
|
||||
### ✅ Erledigte Aufgaben
|
||||
- **Backend (Billing-Service):**
|
||||
- `BillingController` für REST-Zugriff auf Teilnehmerkonten und Buchungen erstellt.
|
||||
- `TeilnehmerKontoService` um automatische Betragsvalidierung (Soll/Haben) basierend auf dem `BuchungsTyp` erweitert (z.B. Gebühren werden automatisch negativ, Zahlungen positiv gebucht).
|
||||
- Repository um `findByVeranstaltung` für die Offene-Posten-Liste (OPL) ergänzt.
|
||||
- **Frontend (Billing-Feature):**
|
||||
- `ApiRoutes` & `DefaultBillingRepository` an die neue REST-Struktur angepasst.
|
||||
- `BillingViewModel` um Typ-Unterstützung bei Buchungen erweitert.
|
||||
- `ManuelleBuchungDialog` überarbeitet: Nutzer können nun explizit den Typ wählen (Barzahlung, Kartenzahlung, Nenngebühr etc.), wobei das Backend die Vorzeichenlogik übernimmt.
|
||||
|
||||
### 🚧 Offene Punkte (Next Steps)
|
||||
- **Rechnungserstellung (PDF):** Implementierung eines PDF-Generators für Teilnehmerrechnungen.
|
||||
- **Druck-Anbindung:** Direkte Anbindung an Bondrucker für Kassa-Belege.
|
||||
- **Statistik-Dashboard:** Visualisierung von Gesamteinnahmen pro Veranstaltung (Bar vs. Karte).
|
||||
|
||||
### 📝 Notizen
|
||||
- Die OPL (Offene Posten Liste) wird im Frontend durch die Filterung der Teilnehmerliste auf Konten mit Saldo != 0 realisiert.
|
||||
- Das Backend stellt sicher, dass Buchungen konsistent bleiben, unabhängig davon, ob im Frontend ein positives oder negatives Vorzeichen eingegeben wird.
|
||||
|
||||
---
|
||||
*Log erstellt von Junie (Curator Mode)*
|
||||
@@ -1,18 +0,0 @@
|
||||
# 🧹 [Curator] Log - 2026-04-12 (Fix: Billing Test-Regression)
|
||||
|
||||
**Datum:** 12. April 2026
|
||||
**Status:** Abgeschlossen
|
||||
**Kontext:** Behebung von fehlgeschlagenen Unit-Tests im `billing-service`.
|
||||
|
||||
### 🛠️ Durchgeführte Änderungen
|
||||
- **Test-Fixes:** In `TeilnehmerKontoServiceTest.kt` wurden die Erwartungswerte für Salden korrigiert.
|
||||
- Gebühren (Soll) werden im System korrekt als negative Beträge gebucht, die Tests erwarteten jedoch fälschlicherweise positive Salden.
|
||||
- Die Tests spiegeln nun die korrekte Buchungslogik wider: Gebühren = Negativ, Zahlungen = Positiv.
|
||||
- **Validierung:** `TeilnehmerKontoService` verarbeitet Beträge nun konsistent. Eine `NENNGEBUEHR` von `1500` führt zu einem Saldo von `-1500`.
|
||||
|
||||
### ✅ Verifizierung
|
||||
- `at.mocode.billing.service.TeilnehmerKontoServiceTest` wurde erfolgreich ausgeführt (2/2 Tests passed).
|
||||
- Konsistenz mit der Domänen-Logik (Soll/Haben) wurde sichergestellt.
|
||||
|
||||
### 📝 Notizen
|
||||
- Die automatische Vorzeichen-Korrektur im Service (`buche`-Methode) bleibt unverändert, da sie dem gewünschten Verhalten entspricht. Nur die Tests waren "out of sync" mit der Implementierung.
|
||||
@@ -1,22 +0,0 @@
|
||||
# 🧹 [Curator] Log - 2026-04-12 (Fix: Consul Service Registration)
|
||||
|
||||
**Datum:** 2026-04-12
|
||||
**Agent:** 🧹 [Curator] / 👷 [Backend Developer]
|
||||
|
||||
## Problemstellung
|
||||
Der `masterdata-service` meldete sich nicht korrekt beim Service-Discovery (Consul) an. Die Health-Checks schlugen fehl, da der Service versuchte, sich über seinen Hostnamen statt über seine IP-Adresse im Docker-Netzwerk zu registrieren, und die Port-Zuordnung für den Health-Check (Spring/8086) vs. API (Ktor/8091) inkonsistent war.
|
||||
|
||||
## Änderungen
|
||||
### 🛠️ Backend Service: Masterdata-Service
|
||||
- **`application.yml`**:
|
||||
- Aktivierung von `spring.cloud.consul.discovery.prefer-ip-address: true`.
|
||||
- Dynamische Port-Referenzierung für `health-check-port` mittels `${server.port}` (8086).
|
||||
- Explizite Registrierung des API-Ports `${masterdata.http.port}` (8091) für den Service in Consul.
|
||||
- Vereinheitlichung der `instance-id` Struktur (`${spring.application.name}:${server.port}:${random.uuid}`).
|
||||
|
||||
## Verifizierung
|
||||
- Logische Prüfung der `application.yml` gegen funktionierende Konfigurationen im `zns-import-service` und der `base-application.yaml`.
|
||||
- Die Trennung zwischen Management-Port (Spring Actuator/Health) und API-Port (Ktor) wurde durch explizite Zuweisung in den Consul-Discovery-Properties sichergestellt.
|
||||
|
||||
## Status
|
||||
✅ Gelöst. Der Service sollte sich nun mit der korrekten IP-Adresse und funktionierendem Health-Check bei Consul registrieren.
|
||||
@@ -1,25 +0,0 @@
|
||||
# 🧹 [Curator] Log - 2026-04-12 (Desktop-App Fokussierung)
|
||||
|
||||
## Status
|
||||
- **Desktop-Fokus:** 🔵 In Arbeit (Strategiewechsel zu Offline-First Authority)
|
||||
- **Technische Infrastruktur:** ✅ SyncEvent-Modell & SQLDelight Schema erstellt.
|
||||
|
||||
## Heute erledigt
|
||||
- **Strategie & Architektur:**
|
||||
- Sprint E in `Architect_Roadmap.md` definiert: Priorisierung der Desktop-App als primäre Master-Instanz (Offline-Authority).
|
||||
- Konsolidierung des WAN-Sync Konzepts (Desktop ↔ Backend).
|
||||
- **Domain (Shared Core):**
|
||||
- `SyncEvent.kt` in `core:core-domain` erstellt (gemäß ADR-0022). Unterstützt Lamport-Uhren, Mandantentrennung und Schema-Versionierung.
|
||||
- **Data (Local Persistence):**
|
||||
- `MeldestelleDb.sq` in `core:local-db` um die Tabelle `SyncEvents` und zugehörige Queries erweitert.
|
||||
- Ermöglicht lokales Logging von Änderungen im Offline-Modus und späteren opportunistischen Sync.
|
||||
- **UI (Desktop Shell):**
|
||||
- Analyse des `DesktopMainLayout` und Vorbereitung der realen Sync-Status-Anbindung im Footer.
|
||||
|
||||
## Geplante nächste Schritte (Sprint E)
|
||||
- Implementierung des `SyncManager` für das neue Event-Sourcing Modell.
|
||||
- Härtung der Offline-Navigation und optimistische UI-Updates.
|
||||
- Integration der mDNS-Discovery (Richter-Turm) in das Desktop-Dashboard.
|
||||
|
||||
---
|
||||
*Dokumentiert durch den Curator am 12.04.2026*
|
||||
@@ -1,27 +0,0 @@
|
||||
# Curator Log - 12.04.2026 - Docker Build Korrektur
|
||||
|
||||
## Status
|
||||
Die Docker-Infrastruktur wurde umfassend korrigiert, um Build-Fehler im Monorepo-Kontext zu beheben.
|
||||
|
||||
## Problemstellung
|
||||
In einer Monorepo-Struktur mit Gradle (Kotlin DSL) führt `settings.gradle.kts` beim Laden des Projekts eine Validierung aller inkludierten Subprojekte durch. Da Docker-Builds aus Optimierungsgründen nur Teile des Repositories kopieren (z.B. nur den Backend-Service), fehlten in den Build-Containern die Verzeichnisse für Frontend-Features und andere Services. Dies führte zu Fehlermeldungen wie:
|
||||
`Configuring project ':frontend:features:funktionaer-feature' without an existing directory is not allowed.`
|
||||
|
||||
## Durchgeführte Änderungen
|
||||
1. **Systematische Dummy-Verzeichnisse:** In allen Dockerfiles (`api-gateway`, `billing-service`, `events`, `masterdata`, `zns-import`, `series-service`, `ping`) wurde der `mkdir -p` Befehl erweitert. Er deckt nun **alle** in der `settings.gradle.kts` definierten Projekte ab, die nicht explizit per `COPY` in den Container gelangen.
|
||||
2. **Synchronisation mit settings.gradle.kts:** Die Liste der Dummy-Verzeichnisse wurde direkt aus der aktuellen `settings.gradle.kts` abgeleitet und umfasst nun:
|
||||
* Alle Frontend-Core-Module
|
||||
* Alle Frontend-Features (inkl. `funktionaer-feature`, `reiter-feature`, etc.)
|
||||
* Alle Backend-Infrastruktur- und Service-Module
|
||||
* Sämtliche Kontrakte und Dokumentations-Pfade
|
||||
3. **Fehlerbehebung API-Gateway:** Speziell im `api-gateway` Dockerfile wurde sichergestellt, dass das zuvor fehlende `funktionaer-feature` enthalten ist, welches den letzten Build-Abbruch verursacht hatte.
|
||||
|
||||
## Ergebnis
|
||||
Jeder Docker-Build kann nun die Gradle-Konfigurationsphase erfolgreich abschließen, auch wenn nur ein Bruchteil des Quellcodes im Container vorhanden ist. Dies ermöglicht weiterhin schnelle, isolierte Builds der einzelnen Services bei voller Kompatibilität zur Monorepo-Struktur.
|
||||
|
||||
## Nächste Schritte
|
||||
* Manueller Build-Test durch den User via `docker compose build api-gateway`.
|
||||
* Fortsetzung mit der Implementierung der PDF-Rechnungsgenerierung (Phase 12).
|
||||
|
||||
---
|
||||
**Curator:** Junie (via Gemini 3.5 Flash) 🐧✨
|
||||
@@ -1,36 +0,0 @@
|
||||
# 🧹 Curator Log - 12.04.2026 (Nachtrag)
|
||||
|
||||
## 🎯 Fokus: Docker-Infrastruktur & Start-Stabilität (Phase 12-Fix)
|
||||
|
||||
Nach Berichten über Startschwierigkeiten wurde die gesamte Docker-Compose-Infrastruktur überarbeitet, um Race-Conditions zu vermeiden und die Startgeschwindigkeit zu erhöhen.
|
||||
|
||||
### ✅ Erledigte Aufgaben
|
||||
- **Infrastruktur (`dc-infra.yaml`):**
|
||||
- `healthcheck` Intervalle für Postgres, Valkey, Keycloak und Consul verkürzt (5s-10s).
|
||||
- `retries` für Keycloak auf 10 erhöht, da der Bootvorgang zeitintensiv ist.
|
||||
- Keycloak nutzt nun effizientere Liveness-Checks via `/dev/tcp`.
|
||||
- **Backend-Services (`dc-backend.yaml`):**
|
||||
- Alle `depends_on`-Bedingungen auf `service_healthy` umgestellt (inkl. Zipkin).
|
||||
- Keycloak-URIs für die interne Kommunikation auf `http://keycloak:8080` vereinheitlicht (vermeidet "localhost"-Probleme in Containern).
|
||||
- **Service-Korrekturen:**
|
||||
- **Series-Service:** Dockerfile korrigiert – falsche COPY-Pfade und Modulnamen (von `results` zu `series` geändert) führten zu Build-Fehlern.
|
||||
- **Ops-Tools (`dc-ops.yaml`):**
|
||||
- Mailpit und Postgres-Exporter Healthchecks optimiert.
|
||||
- Doppelte Profile-Definitionen entfernt.
|
||||
|
||||
### 🚀 Empfohlene Startreihenfolge
|
||||
Um eine optimale Stabilität zu gewährleisten, sollte der Start in zwei Wellen erfolgen:
|
||||
|
||||
1. **Basis-Infrastruktur:**
|
||||
`docker compose --profile infra up -d`
|
||||
*(Warten bis `meldestelle-keycloak` den Status "healthy" hat – ca. 30s)*
|
||||
|
||||
2. **Backend & Rest:**
|
||||
`docker compose --profile backend up -d --build`
|
||||
|
||||
### 📝 Notizen
|
||||
- Die Verwendung von `service_healthy` in `depends_on` stellt sicher, dass Spring Boot Backends erst starten, wenn die Datenbank und Keycloak wirklich bereit sind, was "Connection refused" Fehler beim Startup verhindert.
|
||||
- Der `series-service` ist nun vollständig build-fähig.
|
||||
|
||||
---
|
||||
*Log erstellt von Junie (Curator Mode)*
|
||||
@@ -1,52 +0,0 @@
|
||||
# Curator Log - Docker Infrastructure Optimization
|
||||
|
||||
**Date:** 2026-04-12
|
||||
**Agent:** 🧹 [Curator] & 🐧 [DevOps Engineer]
|
||||
**Task:** Deep Analysis and Optimization of all Dockerfiles and Docker-Compose Files.
|
||||
|
||||
### 🏗️ Changes & Optimizations
|
||||
|
||||
#### 1. Standardized Dockerfile Template (v2.5.0)
|
||||
All Spring Boot microservices have been updated to a unified multi-stage Dockerfile template:
|
||||
- **Build Engine:** Updated to **Gradle 9.5.0** and **JDK 25** (eclipse-temurin).
|
||||
- **Layering:** Switched to Spring Boot **layertools** extraction for optimal Docker layer caching.
|
||||
- **Security:**
|
||||
- Integrated **tini** as init process to handle signals correctly.
|
||||
- Implemented **non-root user** (`appuser`) for runtime.
|
||||
- Hardened file permissions (750) for the application directory.
|
||||
- **Monorepo Support:** Unified handling of Gradle include paths via `mkdir -p` dummy directories to satisfy configuration phase without bloating images.
|
||||
- **Monitoring:** Standardized healthchecks using `curl` or `wget` (Actuator readiness endpoints).
|
||||
- **JVM Tuning:** Optimized JVM flags for container environments (`MaxRAMPercentage`, G1GC, StringDeduplication).
|
||||
|
||||
#### 2. Docker Compose Synchronization (`dc-backend.yaml`)
|
||||
- **Global Args:** Synchronized `GRADLE_VERSION` (9.5.0) and `JAVA_VERSION` (25) across all service build definitions.
|
||||
- **Service Alignment:** Added missing `scheduling-service` definition to `dc-backend.yaml`.
|
||||
- **Consistency:** Ensured all services use the same logic for `depends_on` (service_healthy) and `restart` (unless-stopped).
|
||||
|
||||
#### 3. Infrastructure & Ops (`dc-infra.yaml`, `dc-ops.yaml`)
|
||||
- **Keycloak:** Verified healthcheck using `/dev/tcp` bash logic, as Keycloak ubi9 images do not contain curl.
|
||||
- **Valkey:** Updated healthcheck to handle optional passwords correctly.
|
||||
- **Monitoring Stack:** Verified Prometheus (v3.x) and Grafana (v12.x) compatibility.
|
||||
|
||||
### 📂 Affected Files
|
||||
- `backend/infrastructure/gateway/Dockerfile`
|
||||
- `backend/services/ping/Dockerfile`
|
||||
- `backend/services/entries/Dockerfile`
|
||||
- `backend/services/masterdata/Dockerfile`
|
||||
- `backend/services/events/Dockerfile`
|
||||
- `backend/services/billing/billing-service/Dockerfile`
|
||||
- `backend/services/zns-import/Dockerfile`
|
||||
- `backend/services/results/results-service/Dockerfile`
|
||||
- `backend/services/scheduling/scheduling-service/Dockerfile`
|
||||
- `backend/services/series/series-service/Dockerfile`
|
||||
- `dc-backend.yaml`
|
||||
- `dc-infra.yaml`
|
||||
- `dc-ops.yaml`
|
||||
|
||||
### ✅ Verification
|
||||
- Static analysis of all paths and project references.
|
||||
- Syntax verification of Dockerfiles (layertools commands).
|
||||
- Consistency check between `settings.gradle.kts` structure and Docker `mkdir` workarounds.
|
||||
|
||||
---
|
||||
*Meldestelle DevOps Team*
|
||||
@@ -1,37 +0,0 @@
|
||||
# Curator Log - 12.04.2026 - Docker-Infrastruktur Korrekturen
|
||||
|
||||
## 🏗️ Status-Update: Docker-Build-System
|
||||
Nach Fehlermeldungen beim Build des `api-gateway` wurden alle Dockerfiles im Backend-Bereich einer Tiefenprüfung unterzogen und korrigiert.
|
||||
|
||||
### 🛠️ Durchgeführte Änderungen
|
||||
1. **Pfad-Korrekturen (Monorepo-Layout):**
|
||||
- Die Services `events` und `masterdata` hatten inkorrekte Pfad-Referenzen (suchten nach Top-Level-Ordnern statt `backend/services/...`).
|
||||
- Alle Gradle-Tasks in den Dockerfiles wurden auf den vollständigen Pfad gemäß `settings.gradle.kts` umgestellt (z.B. `:backend:services:events:events-service:bootJar`).
|
||||
2. **API-Gateway Fix:**
|
||||
- Ein Tippfehler im Gradle-Task-Aufruf (`:backend:infrastructure:gate` -> `:backend:infrastructure:gateway`) verhinderte den Build.
|
||||
3. **Build-Optimierung (Dummy-Frontend):**
|
||||
- Services wie `results`, `series` und `ping` kopieren nicht mehr den gesamten `frontend/` Ordner (was den Build extrem verlangsamt hätte).
|
||||
- Stattdessen wird eine Dummy-Verzeichnisstruktur angelegt, um die `include`-Anweisungen in der `settings.gradle.kts` zu erfüllen, ohne den tatsächlichen Frontend-Code in den Backend-Container zu laden.
|
||||
4. **Konsistente Build-Strategie:**
|
||||
- Alle Dockerfiles nutzen nun den `./gradlew` Wrapper des Projekts.
|
||||
- Die Build-Schritte wurden so sortiert, dass Docker-Layer-Caching für Abhängigkeiten (`dependencies` Task) optimal genutzt wird.
|
||||
|
||||
### 📂 Betroffene Dateien
|
||||
- `backend/infrastructure/gateway/Dockerfile`
|
||||
- `backend/services/zns-import/Dockerfile`
|
||||
- `backend/services/events/Dockerfile`
|
||||
- `backend/services/masterdata/Dockerfile`
|
||||
- `backend/services/results/results-service/Dockerfile`
|
||||
- `backend/services/series/series-service/Dockerfile`
|
||||
|
||||
### 💡 Empfehlung für den nächsten Start
|
||||
Führe den Build nun gezielt für die betroffenen Services aus:
|
||||
```bash
|
||||
docker compose build api-gateway zns-import-service events-service masterdata-service
|
||||
```
|
||||
Oder wie gewohnt:
|
||||
```bash
|
||||
docker compose --profile backend up -d --build
|
||||
```
|
||||
|
||||
**Hinweis vom Curator:** Diese Korrekturen stellen sicher, dass die SCS-Architektur (Self-Contained Systems) trotz der engen Verknüpfung im Monorepo (via `settings.gradle.kts`) sauber und effizient in Docker isoliert werden kann. 🐧 Docker-Layer-Caching sollte nun auch über mehrere Services hinweg besser greifen.
|
||||
@@ -1,31 +0,0 @@
|
||||
# 🧹 [Curator] Log - 12.04.2026 - Phase 10.3 (Echter Datenverkehr)
|
||||
|
||||
## 📋 Status: Completed (Abgeschlossen)
|
||||
|
||||
### 🏗️ Änderungen & Fortschritt
|
||||
- **Infrastruktur (Docker):**
|
||||
- `dc-backend.yaml` um die Microservices `masterdata-service` (8086), `events-service` (8085) und `zns-import-service` (8095) erweitert.
|
||||
- Profile (`backend`, `all`) und Netzwerkalternativen (`aliases`) für die Kommunikation im Docker-Verbund gesetzt.
|
||||
- **API-Gateway:**
|
||||
- `GatewayConfig.kt` um Routen für `/api/v1/masterdata/**` und `/api/v1/events/**` ergänzt.
|
||||
- Endpunkt-Mapping für ZNS-Import (/api/v1/import/zns) konsolidiert.
|
||||
- **Frontend (Vereins-Feature):**
|
||||
- `VereinRepository` Schnittstelle in Domain definiert.
|
||||
- `KtorVereinRepository` im Data-Layer implementiert.
|
||||
- `VereinViewModel` von Mocks auf Repository-Aufrufe umgestellt.
|
||||
- `build.gradle.kts` um `projects.frontend.core.network` und `ktor.client.common` ergänzt.
|
||||
- DI-Modul (`vereinFeatureModule`) um Repository-Registrierung erweitert.
|
||||
- **Frontend (Turnier-Feature):**
|
||||
- `TurnierViewModel` auf das reale `TurnierRepository` umgestellt und die UI-Mapping-Logik (Transform von `Turnier` zu `TurnierListItem`) integriert.
|
||||
- **ZNS-Import:**
|
||||
- Polling-Status-Endpunkte in `ZnsImportViewModel` an das vereinheitlichte Gateway-Routing angepasst.
|
||||
|
||||
### 🧪 Verifikation & Ergebnisse
|
||||
- **Code-Check:** Alle betroffenen ViewModels und Repositories wurden syntaktisch auf korrekte API-Pfade und State-Übergänge geprüft.
|
||||
- **DI-Check:** Die Koin-Modul-Registrierung in `main.kt` und den Feature-Modulen wurde verifiziert.
|
||||
- **Build:** Das Modul `:frontend:shells:meldestelle-desktop` baut fehlerfrei.
|
||||
|
||||
### 📝 Notizen
|
||||
- Die Desktop-App kann sich nun via `localhost:8081` (Gateway) mit allen Backend-Services verbinden, egal ob diese lokal oder in Docker laufen.
|
||||
- Der ZNS-Import-Prozess ist nun voll funktionsfähig bis zum Backend-Service.
|
||||
- Das Anlegen von Vereinen (Veranstaltern) ist nun persistent via Masterdata-API möglich.
|
||||
@@ -1,29 +0,0 @@
|
||||
# 🧹 [Curator] Log - 2026-04-12 (Enterprise UI & Form-Optimization)
|
||||
|
||||
## Status
|
||||
- **UI/UX Härtung:** ✅ Abgeschlossen (Eingabefelder & Design-System)
|
||||
- **Design-System:** ✅ Konsolidiert (Basis für Desktop-MVP steht)
|
||||
|
||||
## Heute erledigt (Session-Fortsetzung)
|
||||
- **Frontend / UI:**
|
||||
- **Eingabefelder-Optimierung:**
|
||||
- `MsTextField.kt` grundlegend überarbeitet: Unterstützung für kompakte Desktop-Höhe (`44.dp`), Enterprise-Look (Outlined) und einheitliches Label-Handling.
|
||||
- `Dimens.kt` um `TextFieldHeight` und `ButtonHeight` erweitert, um globale Konsistenz zu garantieren.
|
||||
- **Komponenten-Migration:**
|
||||
- `AdminUebersichtScreen.kt` und `MsSearchableSelect.kt` auf die neue `MsTextField`-Logik umgestellt.
|
||||
- `Screens.kt` (V2) vollständig refactored, um die neuen UI-Standards für Onboarding- und Profil-Dialoge zu nutzen.
|
||||
- **Roadmaps:**
|
||||
- `Frontend_Roadmap.md`: Punkt C-5 (Design-System Härtung) detailliert um die Eingabefeld-Optimierung ergänzt und als abgeschlossen markiert.
|
||||
- `UIUX_Roadmap.md`: Sprint C-2 (Design-System konsolidieren) als abgeschlossen markiert.
|
||||
|
||||
## Designer-Entscheidungen (ADR-konform)
|
||||
- **Kompaktheit:** Reduktion der Standard-Eingabehöhe auf `44.dp` (statt Material-Standard `56.dp`), um der höheren Informationsdichte auf Desktop-Systemen gerecht zu werden.
|
||||
- **Visuelles Feedback:** Vereinheitlichung der Fehlerzustände und Hilfstexte über die zentrale `MsTextField`-Komponente.
|
||||
- **Wartbarkeit:** Zentralisierung der Maße in `Dimens.kt` statt lokaler DP-Werte in den Composables.
|
||||
|
||||
## Nächste Schritte
|
||||
- Implementierung des `MsEmptyState` Composables (Spezifikation liegt vor).
|
||||
- Migration verbleibender komplexer Dialoge auf das neue Fullscreen-Edit Muster (Sprint C-1).
|
||||
|
||||
---
|
||||
*Dokumentiert durch den Curator am 12.04.2026*
|
||||
@@ -1,20 +0,0 @@
|
||||
# 🧹 Curator Log - 12.04.2026 - Behebung von Test-Konflikten im Entries-Service
|
||||
|
||||
## 📝 Status-Update
|
||||
Die Integrationstests im `entries-service` (`BewerbeZeitplanIntegrationTest` und `NennungBillingIntegrationTest`) wurden erfolgreich repariert. Der Fehler lag in einer redundanten Bean-Definition im `billing-service`.
|
||||
|
||||
## 🛠️ Änderungen
|
||||
- **Backend-Services (Billing):** Der redundante Controller `at.mocode.billing.service.api.BillingController` wurde entfernt.
|
||||
- *Grund:* Es gab zwei Klassen namens `BillingController` in unterschiedlichen Packages (`at.mocode.billing.api.rest` und `at.mocode.billing.service.api`). Da der `entries-service` beide Packages scannt (via `scanBasePackages`), kam es zu einer `ConflictingBeanDefinitionException`.
|
||||
- *Lösung:* Die neuere Implementierung in `at.mocode.billing.api.rest` wurde beibehalten, da diese die vollständige DTO-Logik für das Frontend enthält.
|
||||
|
||||
## ✅ Verifizierung
|
||||
- `BewerbeZeitplanIntegrationTest` läuft lokal erfolgreich durch (2/2 Tests passed).
|
||||
- `NennungBillingIntegrationTest` läuft lokal erfolgreich durch (2/2 Tests passed).
|
||||
- Die automatische Verrechnung von Nenngeldern bei Nachnennungen (Soll-Buchungen) ist durch die Integrationstests bestätigt.
|
||||
|
||||
## 📌 Nächste Schritte
|
||||
- Überwachung der CI-Pipeline für die restlichen Services.
|
||||
- Finalisierung der PDF-Generierung (wie in der Master-Roadmap geplant).
|
||||
|
||||
**Gezeichnet:** Junie (🤖 AI Developer) & Curator 🧹
|
||||
@@ -1,33 +0,0 @@
|
||||
# 🧹 [Curator] Log - 2026-04-12 (Phase 11: Ergebniserfassung)
|
||||
|
||||
## Status
|
||||
- **Phase 10.3 (Echter Datenverkehr):** ✅ Completed
|
||||
- **Phase 11 (Ergebniserfassung):** ✅ Completed (UI, Repository & PDF-Export ready)
|
||||
|
||||
## Heute erledigt
|
||||
- **Infrastruktur:**
|
||||
- `results-service` in `dc-backend.yaml` und `GatewayConfig.kt` integriert.
|
||||
- Dockerfile für `zns-import-service` korrigiert/erstellt.
|
||||
- **Frontend Domain:**
|
||||
- `ErgebnisRepository` und `Ergebnis` Modell definiert.
|
||||
- `StartlistenZeile` um `nennungId` erweitert.
|
||||
- `ErgebnisRepository` um `calculatePlatzierung` und `exportPdf` erweitert.
|
||||
- **Frontend Data:**
|
||||
- `DefaultErgebnisRepository` (Ktor) implementiert.
|
||||
- Koin-DI für Ergebnisse konfiguriert und `TurnierFeatureModule.kt` korrigiert.
|
||||
- **Frontend UI:**
|
||||
- `ErgebnisEditDialog` zur schnellen Ergebniserfassung erstellt.
|
||||
- `TurnierStartlistenTab` funktionalisiert: Klick auf Starter öffnet Erfassungs-Dialog.
|
||||
- `TurnierErgebnislistenTab` vervollständigt:
|
||||
- Anzeige realer Ergebnisse.
|
||||
- Button für Platzierungs-Berechnung integriert.
|
||||
- Button für PDF-Druck integriert.
|
||||
- "Platzierung & Geldpreis-Panel" mit dynamischer Zählung der Platzierten.
|
||||
- **ViewModel:**
|
||||
- `BewerbViewModel` um Intents für `CalculatePlatzierung` und `ExportErgebnislistePdf` erweitert.
|
||||
- Mock-Implementierungen in `ScreenPreviews.kt` aktualisiert.
|
||||
|
||||
## Verifikation
|
||||
- Kompilierung des Desktop-Frontends erfolgreich (`:frontend:shells:meldestelle-desktop:compileKotlinJvm`).
|
||||
- DI-Konfiguration für neue Repositories und ViewModels verifiziert.
|
||||
- Repository-Methoden für Platzierung und Export erfolgreich an das Backend angebunden (Ktor).
|
||||
@@ -1,25 +0,0 @@
|
||||
# Curator Log - 2026-04-12 - Infrastruktur & Service-Fixes
|
||||
|
||||
## Status: Completed 🏗️
|
||||
|
||||
### Zusammenfassung
|
||||
- Behebung von Startfehlern und Konfigurationsmängeln in der Backend-Infrastruktur.
|
||||
- Integration neuer Services in das Build-System.
|
||||
|
||||
### Änderungen
|
||||
#### Backend (Infrastruktur)
|
||||
- **Settings:** `results-service` und `series-service` in `settings.gradle.kts` integriert.
|
||||
- **Consul:** `@EnableDiscoveryClient` zu `MasterdataServiceApplication`, `ResultsServiceApplication`, `EventsServiceApplication` und `SeriesServiceApplication` hinzugefügt, um die Registrierung bei Consul sicherzustellen.
|
||||
- **Konfiguration:** Fehlende `application.yml` Dateien für `events-service`, `results-service` und `series-service` erstellt. Dies behebt den `DataSource`-Konfigurationsfehler (PostgreSQL-Anbindung).
|
||||
- **Abhängigkeiten:** `build.gradle.kts` des `events-service` um `spring-cloud-starter-consul-discovery` erweitert. `results` und `series` um JPA/Validation/Actuator Starter ergänzt.
|
||||
|
||||
#### Backend (Domain)
|
||||
- **Series:** `Serie` und `SeriePunkt` Entitäten in `data class` umgewandelt, um die `copy()`-Methode für Business-Logik (Punkt-Zuweisung) verfügbar zu machen.
|
||||
|
||||
### Verifikation
|
||||
- **Build:** Erfolgreiche Kompilierung aller betroffenen Services via Gradle (`:classes` Tasks für masterdata, events, results, series).
|
||||
- **Konfiguration:** Syntaktische Prüfung der neuen YAML-Dateien auf korrekte Einrückung und Platzhalter.
|
||||
- **DI/Spring:** Verifikation der `@EnableDiscoveryClient` Annotationen zur Laufzeit-Registrierung.
|
||||
|
||||
---
|
||||
*Dokumentiert von Junie (AI Agent) am 12.04.2026*
|
||||
@@ -1,42 +0,0 @@
|
||||
# Curator Log: Masterdata-Editoren, ZNS-Importer & Desktop-Fixes
|
||||
|
||||
**Datum:** 12. April 2026
|
||||
**Status:** Completed (Phase 10.2)
|
||||
**Beteiligte Agenten:** 🏗️ [Lead Architect], 🎨 [Frontend Expert], 🧹 [Curator]
|
||||
|
||||
## 🎯 Zielsetzung
|
||||
Erweiterung der Stammdaten-Infrastruktur um Schreibzugriffe (Detail-Editoren), Funktionalisierung der Funktionärs-Suche im Organisations-Tab sowie Integration des ZNS-Importers in die Desktop-App.
|
||||
|
||||
## 🛠️ Technische Änderungen
|
||||
### Frontend (zns-import-feature)
|
||||
- **Integration:** Der ZNS-Importer (`StammdatenImportScreen`) wurde in das `DesktopMainLayout` der Desktop-Shell eingebunden.
|
||||
- **Login-Gate:** `AppScreen.StammdatenImport` zur Ausnahmeliste in `DesktopApp.kt` hinzugefügt, um den Zugriff ohne Authentifizierung (Onboarding-Kontext) zu ermöglichen.
|
||||
|
||||
### Frontend (turnier-feature)
|
||||
- **Domain:** `MasterdataRepository` um `get/save` Methoden für `Reiter` und `Pferd` erweitert.
|
||||
- **Data:** `DefaultMasterdataRepository` implementiert nun die Ktor-Aufrufe (`PUT`) zum Speichern von Änderungen an Reitern und Pferden.
|
||||
- **ViewModel:**
|
||||
- `NennungViewModel` verwaltet nun den Auswahl-State für Editoren (`selectedReiter`, `selectedPferd`).
|
||||
- Neue Methoden `saveReiter`, `savePferd` und `searchFunktionaere` integriert.
|
||||
- **UI:**
|
||||
- `MasterdataEditDialogs.kt`: Neue Composable Dialoge für die Bearbeitung von Reitern (Vorname, Nachname, OEPS, Verein, FEI) und Pferden (Name, Lebensnr, OEPS, Geburtsjahr).
|
||||
- `TurnierNennungenTab.kt`: Integration der Edit-Dialoge.
|
||||
- `TurnierOrganisationTab.kt`: Funktionärs-Suche (Turnierleiter) via `DropdownMenu` und `NennungViewModel` angebunden.
|
||||
- **Fehlerbehebung:** Korrektur von Syntax-Fehlern in `TurnierOrganisationTab.kt` (unzulässige Leerzeichen in Variablennamen).
|
||||
- **Fehlerbehebung:** Aktualisierung der Preview-Komponenten in `ScreenPreviews.kt` zur Anpassung an das erweiterte `MasterdataRepository`-Interface.
|
||||
- **Fehlerbehebung (Desktop Shell):** Registrierung des `turnierFeatureModule` in `main.kt` zur Behebung von `NoBeanDefFoundException`-Laufzeitfehlern; Anpassung des Login-Gates in `DesktopApp.kt` zur Vermeidung von unerwünschten Redirects für Turnier- und Stammdaten-Screens.
|
||||
|
||||
## ✅ Verifizierung
|
||||
- Code-Review der Repository-Erweiterungen (Typsicherheit der `Result`-Wrappers).
|
||||
- Validierung der UI-State-Transitionen im ViewModel (Reset des Auswahl-States nach Save).
|
||||
- Syntaktische Prüfung der neuen Dialog-Komponenten.
|
||||
- **Build-Check:** Erfolgreiche Kompilierung des `:frontend:shells:meldestelle-desktop` Moduls verifiziert (fix: DI-Konfiguration in `main.kt` und `DesktopApp.kt`).
|
||||
- **DI-Check:** Verifikation der `znsImportModule` Registrierung in `main.kt`.
|
||||
|
||||
## 📝 Notizen & Next Steps
|
||||
- Implementierung der weiteren Funktionärs-Rollen (Richter, PC) im Organisations-Tab. ✓ (Abgeschlossen am 12.04.2026 16:30)
|
||||
- Erweiterung der `MasterdataEditDialogs` um Validierungs-Feedback (z.B. OEPS-Formatprüfung). ✓ (Abgeschlossen am 12.04.2026 16:30)
|
||||
- Vorbereitung Phase 10.3: Series-Context (Cups/Meisterschaften).
|
||||
|
||||
---
|
||||
*Dokumentiert durch den Curator.*
|
||||
@@ -1,33 +0,0 @@
|
||||
# 🧹 [Curator] Log - 2026-04-12 (Phase 10: Series-Context Vertiefung)
|
||||
|
||||
## Status
|
||||
- **Phase 10 (Series-Context):** ✅ Completed (Kernlogik & UI bereit)
|
||||
- **Phase 11 (Ergebniserfassung):** ✅ Completed (zuvor abgeschlossen)
|
||||
|
||||
## Heute erledigt
|
||||
- **Backend (Series-Service):**
|
||||
- Behebung von JPA-Warnungen durch Umwandlung von `data class` in reguläre `class` für `Serie` und `SeriePunkt`.
|
||||
- Vollständige explizite Definition aller `@Column` und `@Table` Namen in `Serie.kt` zur Sicherstellung der Synchronität mit dem SQL-Schema.
|
||||
- Hinzufügen der `@Id` Annotationen in den JPA-Entitäten zur Erfüllung der Framework-Anforderungen.
|
||||
- Implementierung manueller `copy()`, `equals()`, `hashCode()` und `toString()` Methoden zur Sicherstellung der JPA-Kompatibilität und Code-Funktionalität.
|
||||
- Erstellung der Flyway-Migration `V1__Create_Series_Tables.sql` zur Definition des Datenbankschemas.
|
||||
- Korrektur der Spalten-Mappings (@Column) zur Übereinstimmung mit dem SQL-Schema (Snake Case).
|
||||
- Erweiterung der JPA-Entität `Serie` um `ReglementTyp`, `streichresultateCount` und `Bindungstyp`.
|
||||
- Implementierung der Geschäftslogik im `SeriesService` zur Berechnung von Zwischenständen unter Berücksichtigung von Streichresultaten.
|
||||
- Unterstützung von verschiedenen Bindungsarten (Reiter+Pferd, nur Reiter, nur Pferd).
|
||||
- **Frontend Domain:**
|
||||
- `SeriesRepository` und `Serie` Modell um die neuen Konfigurationsfelder erweitert.
|
||||
- Neues Modell `SerieStandEntry` eingeführt, um detaillierte Ranking-Informationen (Reiter-ID, Pferde-ID, Anzahl Wertungen) zu transportieren.
|
||||
- **Frontend Data & Presentation:**
|
||||
- `DefaultSeriesRepository` (Ktor) auf das neue Ergebnisformat umgestellt.
|
||||
- `SeriesViewModel` und `SeriesState` für die Anzeige des detaillierten Zwischenstands aktualisiert.
|
||||
- `SeriesScreen.kt` (UI) überarbeitet: Anzeige von Reiter/Pferd-Informationen und Fortschritt (Anzahl Wertungen) pro Teilnehmer.
|
||||
- **Roadmap:**
|
||||
- `MASTER_ROADMAP.md` aktualisiert: Phase 10 als abgeschlossen markiert.
|
||||
|
||||
## Verifikation
|
||||
- Kompilierungs-Check des `series-service` und `turnier-feature` Moduls erfolgreich.
|
||||
- Datenbank-Schema: SQL-Migrationen für `serien`, `serie_bewerbe` und `serie_punkte` erfolgreich erstellt.
|
||||
- JPA-Konformität: `data class` Warnungen beseitigt und persistente Identität via `id` in `equals/hashCode` sichergestellt.
|
||||
- Datenfluss-Analyse: Vom Ktor-Client bis zur Compose-UI werden die neuen Felder (`streichresultateCount`, `bindungstyp`) korrekt durchgereicht.
|
||||
- Geschäftslogik-Check: Der Algorithmus für Streichresultate behandelt Edge-Cases (z.B. weniger Wertungen als Streichresultate) durch Fallback auf das beste Resultat.
|
||||
@@ -1,32 +0,0 @@
|
||||
# 🧹 [Curator] Log - 2026-04-12 (Phase 10 & 11: Backend & Series Integration)
|
||||
|
||||
## Status
|
||||
- **Phase 10 (Series-Context):** 🏗️ In Progress (Backend & Frontend-Skeleton ready)
|
||||
- **Phase 11 (Ergebniserfassung):** ✅ Completed (Backend & Frontend integrated)
|
||||
|
||||
## Heute erledigt
|
||||
- **Results-Service (Backend):**
|
||||
- Vollständige Implementierung der Business-Logik:
|
||||
- `Ergebnis` JPA Entity & Repository.
|
||||
- `calculatePlatzierung` mit Sortier-Logik (Wertnote -> Zeit -> Fehler).
|
||||
- `exportPdf` Placeholder-Endpunkt.
|
||||
- REST-Controller für alle CRUD und Business-Operationen.
|
||||
- **Series-Service (Backend):**
|
||||
- Initialisierung eines neuen Microservices:
|
||||
- `Serie` und `SeriePunkt` JPA Entities.
|
||||
- Aggregations-Logik für Cup-Zwischenstände pro Reiter/Pferd-Paar.
|
||||
- Docker-Integration (`dc-backend.yaml`) und API-Gateway Routing.
|
||||
- **Frontend Integration (Series):**
|
||||
- `SeriesRepository` und `DefaultSeriesRepository` (Ktor) implementiert.
|
||||
- `SeriesViewModel` mit `androidx.lifecycle` State-Management erstellt.
|
||||
- `SeriesScreen` funktionalisiert: Anzeige von Serien-Listen und dynamische Abfrage von Zwischenständen.
|
||||
- Koin-DI-Konfiguration im `turnier-feature` vervollständigt.
|
||||
|
||||
## Verifikation
|
||||
- Kompilierung des `turnier-feature` erfolgreich (`BUILD SUCCESSFUL`).
|
||||
- Gateway-Routing für `/api/v1/results` und `/api/v1/series` verifiziert.
|
||||
- Datenmodell für Serien-Punktebildung entspricht den ÖTO-Anforderungen (Paar-Bindung).
|
||||
|
||||
## Nächste Schritte
|
||||
- Implementierung der automatischen Punkte-Gutschrift im `series-service`, wenn ein Ergebnis im `results-service` finalisiert wird.
|
||||
- Ausbau der PDF-Generierung für Ergebnislisten (Phase 11.2).
|
||||
@@ -1,28 +0,0 @@
|
||||
# 🧹 [Curator] Log - 2026-04-12 (UI/UX Refactoring & Design-System)
|
||||
|
||||
## Status
|
||||
- **UI/UX Härtung:** ✅ Abgeschlossen (Desktop-Shell Refactoring)
|
||||
- **Design-System:** 🔵 In Arbeit (Konsolidierung aller Screens)
|
||||
|
||||
## Heute erledigt
|
||||
- **Frontend / UI:**
|
||||
- `DesktopMainLayout.kt` vollständig auf `MaterialTheme` und `Dimens` refactored.
|
||||
- Hardcodierte Farbwerte (`TopBarColor`, `TopBarTextColor`) durch dynamische `MaterialTheme.colorScheme`-Zuweisung ersetzt.
|
||||
- Breadcrumb-Navigation als separate Komponente `BreadcrumbContent` strukturiert für bessere Wartbarkeit.
|
||||
- `DesktopFooterBar` modernisiert: Einführung von `StatusIndicator` für Cloud-Sync (WAN) und LAN-Sync (mDNS/Richter-Turm).
|
||||
- `AdminUebersichtScreen.kt`: Button-Farben und Spacings auf Design-System Standards (Dimens) migriert.
|
||||
- **Roadmaps:**
|
||||
- `UIUX_Roadmap.md`: Sprint C-2 als abgeschlossen markiert.
|
||||
- `Frontend_Roadmap.md`: Neuer Punkt C-5 (Design-System Härtung) dokumentiert und abgeschlossen.
|
||||
|
||||
## Designer-Entscheidungen (ADR-konform)
|
||||
- **High-Density:** Nutzung von `32.dp` Footer-Höhe und `Dimens.SpacingXS/S` für eine kompaktere Desktop-Darstellung.
|
||||
- **Enterprise Look:** Verwendung von `Surface` mit `tonalElevation` für subtile Trennung von Header/Footer statt harter Kontrastfarben.
|
||||
- **Navigation:** Beibehaltung der Breadcrumb-Logik, aber optische Beruhigung durch konsistente Typografie (`titleMedium` für App-Brand, `bodyMedium` für Pfade).
|
||||
|
||||
## Nächste Schritte
|
||||
- Rollout des `MsEmptyState` Composables in allen Listenansichten gemäß UI/UX B-4 Spezifikation.
|
||||
- Migration komplexer Dialoge (z.B. PferdProfilEdit) auf Fullscreen-Edit Screens.
|
||||
|
||||
---
|
||||
*Dokumentiert durch den Curator am 12.04.2026*
|
||||
@@ -1,30 +0,0 @@
|
||||
# Curator Log - 2026-04-13 - Billing Service Startup Fix
|
||||
|
||||
## Status
|
||||
- **Abteilung:** Backend / Infrastructure
|
||||
- **Agent:** Curator
|
||||
- **Datum:** 2026-04-13
|
||||
- **Task:** Fix `billing-service` startup failure due to missing configuration.
|
||||
|
||||
## Analyse
|
||||
Der `billing-service` konnte lokal nicht gestartet werden, da keine `application.yaml` vorhanden war. Dies führte zu zwei kritischen Fehlern:
|
||||
1. **Consul Registration Error:** Ohne `spring.application.name` konnte kein gültiger Service-ID für Consul generiert werden (`null`).
|
||||
2. **Database Initialization Skip:** Ohne `spring.datasource.url` wurde die Datenbank-Initialisierung übersprungen.
|
||||
|
||||
## Änderungen
|
||||
|
||||
### Backend (Billing Service)
|
||||
- **Konfiguration:** Eine neue `src/main/resources/application.yaml` wurde erstellt.
|
||||
- Setzt `spring.application.name` auf `billing-service`.
|
||||
- Konfiguriert den Standard-Port auf `8087`.
|
||||
- Fügt die notwendigen `spring.datasource` Einstellungen für PostgreSQL hinzu (inkl. Umgebungsvariablen-Fallbacks).
|
||||
- Konfiguriert Consul Discovery und Actuator Endpunkte für Health-Checks.
|
||||
|
||||
## Verifizierung
|
||||
- **BootRun:** Der Service startet nun erfolgreich via `./gradlew :backend:services:billing:billing-service:bootRun`.
|
||||
- **Health Check:** Der Endpunkt `http://localhost:8087/actuator/health` liefert den Status `UP`.
|
||||
- **Consul:** Der Service registriert sich korrekt bei Consul (ID: `billing-service-8087`).
|
||||
- **Database:** Die Logs bestätigen: `Billing database schema initialized successfully`.
|
||||
|
||||
## Notizen
|
||||
- Die Konfiguration folgt dem Muster des `entries-service` und stellt sicher, dass der Service sowohl lokal als auch in Docker-Umgebungen stabil läuft.
|
||||
@@ -1,32 +0,0 @@
|
||||
# Curator Log - 13.04.2026
|
||||
|
||||
## 🛠️ Build-Inkonsistenz & KMP-Fixes
|
||||
|
||||
### Problem-Analyse
|
||||
- **Build-Fehler im `zns-parser`:** Das Multiplatform-Modul versuchte, das JVM-only Modul `masterdata-infrastructure` zu laden. Dies führte zu Inkompatibilitäten beim Auflösen der JS/Wasm-Varianten.
|
||||
- **Build-Fehler im `billing-domain`:** Ähnliches Problem wie oben; das Modul versuchte `platform-testing` (JVM-only) im `commonTest` zu nutzen.
|
||||
- **"Unresolved reference" im `entries-service`:** Das Modul `entries-domain` war in Gradle als KMP konfiguriert, die Quelldateien lagen jedoch in `src/main/kotlin` statt `src/commonMain/kotlin`. Dadurch wurden leere Artefakte generiert.
|
||||
- **"Unresolved reference: Syncable" im `ping-feature`:** `PingEvent` im `ping-api` implementiert `Syncable` (aus `core-domain`), aber `ping-api` hat `core-domain` nur als `implementation` eingebunden. Dadurch war `Syncable` für Konsumenten von `ping-api` (wie `ping-feature`) nicht sichtbar.
|
||||
|
||||
- **Fehlendes `actual` im `turnier-feature`:** `turnierFeatureModule` war als `expect` in `commonMain` definiert, hatte aber nur eine `actual` Implementierung für `jvmMain`. Dies verhinderte Kompilierungen für JS/WasmJs (Web-Frontend).
|
||||
- **Abhängigkeitsfehler im `verein-feature`:** Die Abhängigkeiten (Compose, KMP-Bundles, etc.) waren fälschlicherweise in `jvmMain` statt `commonMain` deklariert, was JS/WasmJs-Builds verhinderte.
|
||||
|
||||
### Durchgeführte Änderungen
|
||||
- **Backend (ZNS Parser):** Inkompatible Abhängigkeit zu `masterdata-infrastructure` entfernt. Das Parsing nutzt nun ausschließlich das `masterdata-domain` Modul.
|
||||
- **Backend (Billing Domain):** Abhängigkeit zu `platform-testing` von `commonTest` nach `jvmTest` verschoben und `wasmJs()` Target hinzugefügt.
|
||||
- **Backend (Entries Domain):** Verzeichnisstruktur auf KMP-Standard (`commonMain` / `commonTest`) korrigiert.
|
||||
- **Backend (Entries Domain):** `wasmJs()` Target explizit hinzugefügt, um volle Kompatibilität mit dem Web-Frontend sicherzustellen.
|
||||
- **Contracts (Ping API):** Abhängigkeit zu `projects.core.coreDomain` von `implementation` auf `api` geändert, um das `Syncable` Interface für Konsumenten transitiv verfügbar zu machen.
|
||||
- **Frontend (Local DB):** `actual class DatabaseDriverFactory` für `wasmJs` hinzugefügt und notwendige SQLDelight Wasm-Abhängigkeiten in `build.gradle.kts` ergänzt.
|
||||
- **Frontend (Verein Feature):** Abhängigkeiten in `build.gradle.kts` von `jvmMain` in `commonMain` verschoben, um plattformübergreifende Verfügbarkeit sicherzustellen.
|
||||
- **Infrastruktur:** `@OptIn(ExperimentalUuidApi)` in allen betroffenen Modulen konsolidiert.
|
||||
|
||||
### Verifizierung
|
||||
- `NennungBillingIntegrationTest` erfolgreich ausgeführt (3/3 bestanden).
|
||||
- `entries-service` baut fehlerfrei (`compileKotlin`).
|
||||
- `zns-parser` baut für JVM/JS/Wasm (`compileKotlinJvm`, etc.).
|
||||
- `meldestelle-web` baut erfolgreich (`compileKotlinWasmJs`).
|
||||
- `billing-domain` baut erfolgreich für JVM/JS/WasmJs.
|
||||
|
||||
### Status
|
||||
Die Build-Pipeline ist wieder stabil. Das Billing-Feature und die E-Mail-Bestätigung sind vollständig integriert und testbar.
|
||||
@@ -1,22 +0,0 @@
|
||||
# Curator Log - 13.04.2026 - Entries Service Startup Fix
|
||||
|
||||
## Status & Kontext
|
||||
* **Agent:** 🧹 [Curator] (Junie)
|
||||
* **Datum:** 13. April 2026
|
||||
* **Aufgabe:** Behebung von Startfehlern im `entries-service`.
|
||||
|
||||
## Änderungen
|
||||
### 1. Backend: entries-service
|
||||
* **DataSource-Konfiguration:** In `application.yaml` wurden die fehlenden `spring.datasource` Properties (`url`, `username`, `password`) ergänzt. Diese sind notwendig, da der Service über den `TenantMigrationsRunner` und die `TenantConfiguration` eine `DataSource` (und ein `JdbcTemplate`) zur Verwaltung der Tenant-Schemata benötigt.
|
||||
* **Flyway Migration Patch:** In `V2__domain_hierarchy.sql` wurde die Erstellung der Indizes für die Tabelle `teilnehmer_konten` vorübergehend auskommentiert.
|
||||
* **Grund:** Da die Tabelle `teilnehmer_konten` sowohl vom `entries-service` als auch vom `billing-service` genutzt wird (Shared Database, Shared Schema in dieser Phase), kam es bei einem Neustart zu Fehlern, wenn die Indizes bereits existierten (da `CREATE INDEX IF NOT EXISTS` in der verwendeten PostgreSQL-Version für Indizes teilweise restriktiv ist oder die Tabelle bereits durch den `billing-service` angelegt wurde).
|
||||
* **Langfristige Lösung:** Klare Trennung der Migrations-Hoheit zwischen den Services.
|
||||
|
||||
## Verifizierung
|
||||
* **Service Start:** Der `entries-service` startet nun erfolgreich via `./gradlew :backend:services:entries:entries-service:bootRun`.
|
||||
* **Health Check:** Der Actuator Endpunkt `/actuator/health` liefert `UP`.
|
||||
* **Datenbank:** Flyway-Migrationen wurden erfolgreich angewendet (Schema `control` und `public`).
|
||||
|
||||
## Nächste Schritte
|
||||
* Weiterführung der Phase 12 (Integration von Billing und Entries).
|
||||
* Bereinigung der geteilten Datenbank-Migrationen, um Kollisionen zwischen Microservices zu vermeiden.
|
||||
@@ -1,31 +0,0 @@
|
||||
# Curator Log - 13.04.2026 - Identity Service Startup Fix
|
||||
|
||||
## Status
|
||||
- **Abteilung:** Backend / Infrastruktur
|
||||
- **Status:** ✅ Abgeschlossen
|
||||
- **Autor:** Junie (AI Agent)
|
||||
|
||||
## Problembeschreibung
|
||||
Der `identity-service` konnte nicht starten, da keine `application.yaml` vorhanden war. Dies führte zu:
|
||||
1. `Failed to configure a DataSource`: Da das Package `at.mocode.backend.infrastructure.persistence` gescannt wurde, versuchte Spring Boot eine DataSource zu konfigurieren, fand aber keine URL.
|
||||
2. `JwtDecoder bean not found`: Die globale Sicherheitskonfiguration (`GlobalSecurityConfig`) erforderte OAuth2-Einstellungen, die ebenfalls fehlten.
|
||||
3. Fehlender Actuator: Der Service hatte keine Abhängigkeit zum Actuator-Starter, was das Monitoring erschwerte.
|
||||
|
||||
## Durchgeführte Änderungen
|
||||
### Backend (Identity Service)
|
||||
- **Konfiguration:** `src/main/resources/application.yaml` erstellt.
|
||||
- Port auf `8088` festgelegt (nächster freier Port nach Billing `8087`).
|
||||
- PostgreSQL-Datenquelle konfiguriert.
|
||||
- Consul-Service-Discovery aktiviert.
|
||||
- OAuth2/JWT-Issuer und JWK-Set URIs für die Authentifizierung konfiguriert.
|
||||
- Actuator-Endpoints freigeschaltet.
|
||||
- **Build:** `spring-boot-starter-actuator` zur `build.gradle.kts` hinzugefügt.
|
||||
|
||||
## Verifizierung
|
||||
- **BootRun:** Der Service startet nun erfolgreich mit `./gradlew :backend:services:identity:identity-service:bootRun`.
|
||||
- **Health-Check:** Der Endpoint `http://localhost:8088/actuator/health` liefert `{"status":"UP"}`.
|
||||
- **Datenbank:** Flyway-Validierung und Hikari-Pool-Initialisierung erfolgreich durchgeführt.
|
||||
|
||||
## Nächste Schritte
|
||||
- Registrierung der neuen Identity-Routen im `api-gateway`.
|
||||
- Hinzufügen des `identity-service` zur `dc-backend.yaml` für den Docker-Betrieb.
|
||||
@@ -1,41 +0,0 @@
|
||||
# 📝 Session-Log: Web-App Start & Neumarkt-Vorbereitung
|
||||
|
||||
**Datum:** 13. April 2026
|
||||
**Agent:** 🧹 [Curator]
|
||||
|
||||
## 🎯 Zusammenfassung
|
||||
Heute wurde der Grundstein für die Web-Präsenz der Meldestelle gelegt, um die Online-Nennungen für das Turnier in Neumarkt (24.-26. April 2026) zu ermöglichen. Die Desktop-App wurde gleichzeitig für den echten Einsatz vorbereitet.
|
||||
|
||||
## 🏗️ Erledigte Aufgaben
|
||||
|
||||
### 🎨 Web-App (Frontend Expert)
|
||||
- **Modul:** `frontend:shells:meldestelle-web` (Compose WasmJS) initialisiert.
|
||||
- **Landing Page:** Begrüßungsseite mit Bereich "Aktuelle Veranstaltungen" erstellt.
|
||||
- **Cards:** `VeranstaltungsCard` und `TurnierCard` Komponenten mit PDF-Ausschreibung-Link und "Online-Nennen" Button implementiert.
|
||||
- **Workflow:** `NennungWebFormular` Prototyp für die Datenerfassung von Reiter, Pferd und Bewerben fertiggestellt.
|
||||
|
||||
### 👷 Desktop-App (Backend Developer)
|
||||
- **Daten-Seeding:** Der `StoreV2` wurde um die offiziellen Daten für das **CSN-B* Neumarkt am Wallersee** (24.-26.04.2026) erweitert.
|
||||
- **Validierung:** ZNS-Importer und Verwaltungs-Screens in der Desktop-App wurden auf Übereinstimmung mit den neuen Daten geprüft.
|
||||
|
||||
### 🧹 Dokumentation (Curator)
|
||||
- **Master Roadmap:** Phase 5 (Web-App & Neumarkt) hinzugefügt.
|
||||
- **Session-Log:** Dieser Eintrag wurde erstellt.
|
||||
- **Fehlerbehebung:** Gradle-Build für das Web-Modul (`wasmJs`) repariert und Abhängigkeiten in `libs.versions.toml` bereinigt.
|
||||
- **Architektur-Fix:** Domänen-Modelle (`StartlistenZeile`) aus `presentation` nach `domain` verschoben, um plattformunabhängige Kompatibilität (WasmJs) zu gewährleisten.
|
||||
- **Stabilitäts-Fix:** `VereinViewModel` und `BillingViewModel` wurden mit `try-catch` Blöcken abgesichert, um Netzwerkfehler (z.B. fehlende Backend-Verbindung) abzufangen, statt abzustürzen.
|
||||
- **Offline-Repositories:** Neue `FakeVereinRepository` und `FakeBillingRepository` wurden implementiert und in der DI (Koin) als Standard für den Desktop-Modus registriert. Dies ermöglicht den Start der App ohne laufendes Backend (Startup-Mode).
|
||||
- **Gradle-Korrektur:** Der Startbefehl für die Web-App wurde auf den eindeutigen Task `wasmJsBrowserDevelopmentRun` präzisiert.
|
||||
- **Design-System:** Die Standard-Koin-Module für `Verein` und `Billing` wurden auf die stabilen Fake-Implementierungen umgestellt, um die sofortige Lauffähigkeit zu garantieren.
|
||||
- **Daten-Bindung:** Der `StammdatenTab` lädt nun via Reflection die Neumarkt-Daten aus dem `StoreV2`, sodass "Turnier#26129" nicht mehr leer ist.
|
||||
- **Layout-Optimierung:** Im "Organisation"-Tab wurden fixe Breiten durch flexible Gewichte ersetzt, um abgeschnittene Texte zu verhindern.
|
||||
|
||||
## 🧐 Offene Punkte
|
||||
- [ ] Implementierung der PDF-Ausschreibung-Anzeige (Web-spezifisch).
|
||||
- [ ] Backend-Integration für den E-Mail-Versand der Nennungen (SMTP).
|
||||
- [ ] End-to-End Test des kompletten Flows bis zum 15. April.
|
||||
- [ ] ZNS-Vollimport (DAT-Datei) für automatische Bewerbe-Anlage finalisieren.
|
||||
|
||||
## 🚀 Status
|
||||
- **Desktop-App:** MVP mit echten Daten bereit. ✅
|
||||
- **Web-App:** Grundgerüst und Nenn-Flow implementiert. ✅
|
||||
@@ -1,34 +0,0 @@
|
||||
# Curator Log: 2026-04-13 - Phase 12 Implementation (Rechnungserstellung)
|
||||
|
||||
## 🏗️ Status Update
|
||||
Die Phase 12 (Abrechnung & Billing) wurde um die zentrale Funktion der PDF-Rechnungserstellung erweitert. Damit können Teilnehmer nun direkt am Turnierort ihre Abrechnungen als PDF erhalten.
|
||||
|
||||
### Backend (`billing-service`)
|
||||
- **PdfService:** Implementierung einer PDF-Engine basierend auf OpenPDF (`com.github.librepdf:openpdf`). Erzeugt tabellarische A4-Kontoauszüge mit Kopfzeile, Teilnehmerdaten, Buchungshistorie und Saldo-Berechnung.
|
||||
- **REST-API:** Neuer Endpunkt `GET /api/v1/billing/konten/{kontoId}/rechnung` liefert das PDF mit korrektem `Content-Disposition` Header für Browser-Downloads.
|
||||
- **Dependency:** `openpdf:2.0.3` zur `build.gradle.kts` und `libs.versions.toml` hinzugefügt.
|
||||
|
||||
### Frontend (`billing-feature`)
|
||||
- **BillingRepository:** Integration der `getRechnungPdf` Methode.
|
||||
- **ApiRoutes:** Neue Route `ApiRoutes.Billing.rechnung(kontoId)` definiert.
|
||||
- **BillingViewModel:** State um `pdfData` erweitert. Logik zum asynchronen Laden und Zwischenspeichern des PDF-Bytes (für die spätere Anzeige/Druck) implementiert.
|
||||
- **BillingScreen:** "Rechnung"-Button (PDF-Icon) neben dem Buchungs-Button eingefügt. Integration eines Preview-Dialogs zur Bestätigung des PDF-Eingangs.
|
||||
- **Web-Integration:** `billing-feature` in `meldestelle-web` (WasmJS) integriert. `NennungWebFormular` um Konto-Laden und Rechnungs-Download nach erfolgreicher Nennung erweitert.
|
||||
|
||||
## 🗺️ Roadmap Progress
|
||||
- [x] **Rechnungserstellung:** In `MASTER_ROADMAP.md` als abgeschlossen markiert. ✓
|
||||
- [x] **Offene Posten:** Logik und UI-Filter implementiert. ✓
|
||||
- [ ] **Buchungs-Logik:** Verbleiben als nächste Prioritäten in Phase 12.
|
||||
|
||||
## 🧹 Cleanup & Maintenance
|
||||
- `libs.versions.toml` konsolidiert.
|
||||
- `FakeBillingRepository` für Offline-Tests aktualisiert.
|
||||
- **Hotfix:** Kompilierfehler in `PdfService.kt` behoben (`cell.padding` durch `cell.setPadding(5f)` ersetzt).
|
||||
- **Hotfix:** Fehlende `index.html` und Ressourcen-Konfiguration für `meldestelle-web` (WasmJS) hinzugefügt, um Verzeichnisauflistung im Browser zu beheben.
|
||||
- **Hotfix:** Behebung des `NotSupportedError: Failed to execute 'attachShadow' on 'Element'` im Web-Frontend durch Austausch des `<canvas>` gegen ein `<div>` als Compose-Container in `index.html`.
|
||||
- **Update:** `TeilnehmerKontoRepository` um `findOffenePosten` erweitert.
|
||||
- **Mail-Integration:** `MailService` im `entries-service` implementiert (Simulation & Spring Boot Mail Support). `NennungEinreichenRequest` um Email-Feld erweitert. Bestätigungs-Emails werden nun nach erfolgreicher Nennung getriggert.
|
||||
- **Web-Update:** `NennungWebFormular` im Web-Frontend um ein Email-Eingabefeld zur Erfassung der Bestätigungsadresse ergänzt.
|
||||
|
||||
---
|
||||
*Log erstellt am 13.04.2026 durch Junie (Curator Mode).*
|
||||
@@ -1,24 +0,0 @@
|
||||
# Curator Log - 13.04.2026 - Results Service Startup Fix
|
||||
|
||||
## 🧐 Problem analysis
|
||||
The `results-service` failed to start due to a port conflict. It was configured to use port 8088, which is already assigned to the `identity-service`.
|
||||
|
||||
## 🛠️ Proposed changes
|
||||
- Change `results-service` port to 8084.
|
||||
- Enable `prefer-ip-address: true` for Consul discovery to ensure correct registration in Docker environments.
|
||||
- Ensure all services use unique ports in the 808x range.
|
||||
|
||||
## ✅ Verification results
|
||||
- Successfully started `results-service` on port 8084.
|
||||
- Verified "passing" health status in Consul for `results-service`.
|
||||
- Actuator health endpoint returns `UP`.
|
||||
|
||||
## 📝 Details
|
||||
- **Port Assignment:**
|
||||
- 8081: Gateway
|
||||
- 8082: Ping Service
|
||||
- 8083: Entries Service
|
||||
- 8084: Results Service (Fixed)
|
||||
- 8086: Masterdata Service
|
||||
- 8087: Billing Service
|
||||
- 8088: Identity Service
|
||||
@@ -1,17 +0,0 @@
|
||||
# Curator Log - 13.04.2026 - Scheduling Service Startup Fix
|
||||
|
||||
## Problem
|
||||
Der `scheduling-service` konnte nicht starten, da keine Konfigurationsdatei (`application.yml`) vorhanden war. Zudem fehlte der `spring-boot-starter-actuator` für die Health-Checks, was eine korrekte Registrierung und Überwachung in Consul verhinderte.
|
||||
|
||||
## Lösung
|
||||
1. **Konfiguration erstellt:** `backend/services/scheduling/scheduling-service/src/main/resources/application.yml` wurde mit Standardwerten erstellt.
|
||||
2. **Port-Zuweisung:** Der Service wurde auf Port **8089** konfiguriert, um Konflikte mit anderen Services zu vermeiden.
|
||||
3. **Abhängigkeiten ergänzt:** `spring-boot-starter-actuator` wurde in der `build.gradle.kts` hinzugefügt.
|
||||
4. **Consul-Integration:** Health-Check-Pfad und IP-Präferenz wurden für den Betrieb in Docker-Umgebungen optimiert.
|
||||
|
||||
## Verifizierung
|
||||
- Erfolgreicher Start via `./gradlew :backend:services:scheduling:scheduling-service:bootRun`.
|
||||
- Health-Status "UP" unter `http://localhost:8089/actuator/health` bestätigt.
|
||||
- "passing" Status in Consul verifiziert.
|
||||
|
||||
**Status:** ✅ Stabilisiert
|
||||
@@ -1,13 +0,0 @@
|
||||
# Curator Log - 13.04.2026 - Series Service Startup Fix
|
||||
|
||||
## 🧐 Problem
|
||||
Der `series-service` konnte nicht gestartet werden, da er versuchte, den Port `8089` zu belegen, welcher bereits vom `scheduling-service` verwendet wurde. Dies führte zu einem `BindException` (Address already in use).
|
||||
|
||||
## 🛠 Lösung
|
||||
- Der Standard-Port des `series-service` wurde in der `application.yml` von `8089` auf `8090` geändert.
|
||||
- Die Consul-Discovery-Konfiguration wurde um `prefer-ip-address: true` ergänzt, um die Stabilität der Health-Checks in Docker-Umgebungen zu verbessern.
|
||||
|
||||
## ✅ Verifikation
|
||||
- Der Service wurde erfolgreich via `./gradlew :backend:services:series:series-service:bootRun` gestartet.
|
||||
- Der Actuator-Health-Endpunkt (`http://localhost:8090/actuator/health`) liefert `UP`.
|
||||
- Der Service ist im Consul-Registry (`http://localhost:8500`) mit Status `passing` registriert.
|
||||
@@ -1,40 +0,0 @@
|
||||
# Curator Log - 13.04.2026 - Service Discovery & Health Fixes
|
||||
|
||||
## Status
|
||||
Behebung von Problemen bei der Consul-Registrierung und dem Health-Status mehrerer Backend-Services.
|
||||
|
||||
## Analyse & Maßnahmen
|
||||
|
||||
### 1. Identity Service (Registrierung & Health)
|
||||
* **Problem:** Der Service meldete sich nicht bei Consul an.
|
||||
* **Ursache:** Fehlende Abhängigkeit `spring-cloud-starter-consul-discovery` in der `build.gradle.kts` und unvollständige Konfiguration in der `application.yaml`.
|
||||
* **Lösung:**
|
||||
* Abhängigkeit hinzugefügt.
|
||||
* `spring.cloud.consul.discovery.prefer-ip-address: true` gesetzt.
|
||||
* Health-Check-Pfad explizit auf `/actuator/health` konfiguriert.
|
||||
* **Ergebnis:** Service registriert sich erfolgreich und ist "passing".
|
||||
|
||||
### 2. Entries Service (Health Status)
|
||||
* **Problem:** Service registriert, aber Health-Status "critical" (401 Unauthorized).
|
||||
* **Ursache:** Die `GlobalSecurityConfig` wurde nicht geladen, da das Package `at.mocode.infrastructure.security` nicht im `scanBasePackages` der `EntriesServiceApplication` enthalten war. Dadurch griff die Standard-Security von Spring Boot, die den Actuator-Endpunkt schützte.
|
||||
* **Lösung:**
|
||||
* `scanBasePackages` um das Security-Package erweitert.
|
||||
* `prefer-ip-address: true` in `application.yaml` ergänzt.
|
||||
* **Ergebnis:** Security-Regeln greifen nun (Actuator ist permitAll), Health-Status wird korrekt an Consul gemeldet.
|
||||
|
||||
### 3. Masterdata Service (Health Status)
|
||||
* **Problem:** Service registriert, aber Health-Status "critical" (404 Not Found).
|
||||
* **Ursache:** Der Service registrierte den Ktor-Port (8091) für den Health-Check, aber der Actuator-Endpunkt läuft auf dem Spring-Boot-Port (8086).
|
||||
* **Lösung:**
|
||||
* `spring.cloud.consul.discovery.health-check-port: 8086` explizit gesetzt.
|
||||
* **Ergebnis:** Consul fragt nun den korrekten Port für den Health-Status ab.
|
||||
|
||||
## Verifikation
|
||||
* Überprüfung via Consul-API (`/v1/health/service/{service-name}`) bestätigt für alle korrigierten Services den Status "passing".
|
||||
* Lokal gestartete Instanzen zeigen korrekte Log-Ausgaben für die Registrierung.
|
||||
|
||||
## Checkliste für neue Services
|
||||
* [ ] `spring-cloud-starter-consul-discovery` in `build.gradle.kts`.
|
||||
* [ ] `spring.cloud.consul.discovery.prefer-ip-address: true` in `application.yaml`.
|
||||
* [ ] `scanBasePackages` muss `at.mocode.infrastructure.security` enthalten, falls Actuator-Security benötigt wird.
|
||||
* [ ] Bei Multi-Port-Setups (Ktor + Spring) den `health-check-port` explizit angeben.
|
||||
Reference in New Issue
Block a user