docs: restructure and streamline sprint execution order
- Consolidated and removed redundant steps in `SPRINT_EXECUTION_ORDER.md`. - Simplified descriptions and roadmap formatting for improved clarity. - Updated progress and dependencies to align with Phase 8 objectives. - Adjusted role-specific roadmaps to reflect the latest sprint updates. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
This commit is contained in:
@@ -1,57 +1,68 @@
|
||||
# 🏗️ [Lead Architect] — Schritt-für-Schritt Roadmap
|
||||
# 🏗️ [Lead Architect] — Zwischenstand & Roadmap
|
||||
|
||||
> **Stand:** 2. April 2026
|
||||
> **Stand:** 3. April 2026
|
||||
> **Rolle:** Strategie, Architektur-Entscheidungen (ADRs), Domänen-Modell, Master-Roadmap
|
||||
|
||||
---
|
||||
|
||||
## 🔴 Sprint A — Sofort (diese Woche)
|
||||
## ✅ Erledigte Sprints
|
||||
|
||||
- [x] **A-1** | ADR-0021 schreiben: Tenant-Resolution-Strategie
|
||||
- [x] Optionen analysieren: Schema-per-Tenant vs. Tenant-ID in allen Tabellen
|
||||
- [x] Entscheidung treffen und begründen
|
||||
- [x] ADR-0021 in `docs/01_Architecture/adr/` ablegen
|
||||
- [x] Backend Developer informieren (A-3 ist Blocker)
|
||||
### Sprint A — Abgeschlossen
|
||||
|
||||
- [x] **A-2** | Domänen-Modell formal präzisieren
|
||||
- [x] Hierarchie `Veranstaltung → Turnier → Bewerb → Abteilung` als offizielles Modell festschreiben
|
||||
- [x] `TeilnehmerKonto` auf Veranstaltungsebene (Multi-Turnier) ins Modell aufnehmen
|
||||
- [x] Veranstaltungs-Kassa mit Turnier-übergreifendem Saldo modellieren
|
||||
- [x] Abteilungs-Typen `SEPARATE_SIEGEREHRUNG` (vorläufig) und `ORGANISATORISCH` ins Modell aufnehmen
|
||||
- [x] Curator beauftragen: `Ubiquitous_Language.md` aktualisieren
|
||||
- [x] **A-1** | ADR-0021 Tenant-Resolution-Strategie
|
||||
- [x] Schema-per-Tenant vs. Tenant-ID analysiert → Entscheidung: Eine Veranstaltung = eine Datenbank
|
||||
- [x] ADR-0021 in `docs/01_Architecture/adr/0021-tenant-resolution-strategy-de.md` abgelegt
|
||||
- [x] Backend Developer informiert (Backend A-1 gestartet)
|
||||
|
||||
- [x] **A-2** | Domänen-Modell formal präzisiert
|
||||
- [x] Hierarchie `Veranstaltung → Turnier → Bewerb → Abteilung` festgeschrieben
|
||||
- [x] `TeilnehmerKonto` auf Veranstaltungsebene (Multi-Turnier) ins Modell aufgenommen
|
||||
- [x] Veranstaltungs-Kassa mit Turnier-übergreifendem Saldo modelliert
|
||||
- [x] Abteilungs-Typen `SEPARATE_SIEGEREHRUNG` und `ORGANISATORISCH` definiert
|
||||
- [x] Curator beauftragt: `Ubiquitous_Language.md` aktualisiert
|
||||
|
||||
---
|
||||
|
||||
## 🟠 Sprint B — Kurzfristig (nächste Woche)
|
||||
## ✅ Sprint B — Abgeschlossen
|
||||
|
||||
- [ ] **B-1** | ADR für LAN-Sync-Protokoll schreiben
|
||||
- [ ] Optionen analysieren: Event-Sourcing vs. CRDT vs. Timestamp-Sync
|
||||
- [ ] Entscheidung für Meldestelle ↔ Richter-Turm Sync treffen
|
||||
- [ ] ADR in `docs/01_Architecture/ADRs/` ablegen
|
||||
- [x] **B-1** | ADR für LAN-Sync-Protokoll schreiben
|
||||
- [x] Optionen analysieren: Event-Sourcing vs. CRDT vs. Timestamp-Sync
|
||||
- [x] Entscheidung für Meldestelle ↔ Richter-Turm Sync getroffen: **Event-Sourcing Light mit Lamport-Uhren** (Option
|
||||
D)
|
||||
- [x] ADR-0022 in `docs/01_Architecture/adr/0022-lan-sync-protocol-de.md` abgelegt
|
||||
- [x] Backend Developer und Frontend Expert über Entscheidung informiert (siehe jeweilige Roadmaps)
|
||||
|
||||
> ⏸️ **USB-Stick Fallback** — Separate Besprechung zu einem späteren Zeitpunkt
|
||||
> ⏸️ **USB-Stick Fallback** — Separate Besprechung zu einem späteren Zeitpunkt (Sprint B/C)
|
||||
|
||||
---
|
||||
|
||||
## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
|
||||
## 🟠 Sprint C — Priorität 2 (nächste Woche)
|
||||
|
||||
- [ ] **C-1** | Synchronisations-Protokoll-Konzeption starten
|
||||
- [ ] **C-1** | Synchronisations-Protokoll-Konzeption
|
||||
- [ ] Offline-First-Konzept für Desktop ↔ Backend ausarbeiten
|
||||
- [ ] Conflict-Resolution-Strategie definieren (was passiert bei gleichzeitigen Änderungen?)
|
||||
- [ ] Ergebnis als Konzept-Dokument in `docs/01_Architecture/` ablegen
|
||||
- [ ] Conflict-Resolution-Strategie definieren (gleichzeitige Änderungen)
|
||||
- [ ] Konzept-Dokument in `docs/01_Architecture/` ablegen
|
||||
|
||||
- [ ] **C-2** | MASTER_ROADMAP aktualisieren
|
||||
- [ ] Desktop-App-Fokus eintragen
|
||||
- [ ] Tenant-Isolation-Meilensteine eintragen
|
||||
- [ ] Tenant-Isolation-Meilensteine (Sprint A Ergebnisse) als erledigt markieren
|
||||
- [ ] Offline-Sync-Meilensteine eintragen
|
||||
- [ ] Sprint A/B/C Ergebnisse als "erledigt" markieren
|
||||
- [ ] Phase 8 Fortschritt reflektieren
|
||||
|
||||
---
|
||||
|
||||
## 📌 Abhängigkeiten
|
||||
|
||||
| Meine Aufgabe | Blockiert wen |
|
||||
|----------------------|----------------------------------------------------------|
|
||||
| ADR-0021 (A-1) | 👷 Backend: Tenant-Isolation (Backend Sprint A) |
|
||||
| Domänen-Modell (A-2) | 👷 Backend: Schema-Design; 🎨 Frontend: ViewModel-Design |
|
||||
| LAN-Sync ADR (B-1) | 🎨 Frontend: Sync-UI; 👷 Backend: Sync-Endpunkte |
|
||||
| Meine Aufgabe | Blockiert wen |
|
||||
|--------------------|----------------------------------------------------------|
|
||||
| ADR-0021 ✅ | 👷 Backend: Tenant-Isolation (Backend Sprint A) |
|
||||
| Domänen-Modell ✅ | 👷 Backend: Schema-Design; 🎨 Frontend: ViewModel-Design |
|
||||
| LAN-Sync ADR (B-1) | 🎨 Frontend: Sync-UI; 👷 Backend: Sync-Endpunkte |
|
||||
| Sync-Konzept (C-1) | 🐧 DevOps: mDNS/WebSocket-Infrastruktur |
|
||||
|
||||
---
|
||||
|
||||
## 💡 Empfehlung
|
||||
|
||||
**Sofort starten:** B-1 (LAN-Sync ADR) — Phase 8 der MASTER_ROADMAP wartet auf mDNS/WebSocket-Discovery; ohne ADR können
|
||||
Backend und Frontend nicht parallel implementieren.
|
||||
|
||||
@@ -1,177 +1,104 @@
|
||||
# 👷 [Backend Developer] — Schritt-für-Schritt Roadmap
|
||||
# 👷 [Backend Developer] — Zwischenstand & Roadmap
|
||||
|
||||
> **Stand:** 3. April 2026
|
||||
> **Rolle:** Spring Boot / Ktor, Kotlin, SQL, API-Design, Datenbankschema, Services
|
||||
|
||||
---
|
||||
|
||||
## 🔴 Sprint A — Sofort (diese Woche)
|
||||
## ✅ Erledigte Sprints
|
||||
|
||||
> ✅ ADR-0021 (Tenant-Strategie) liegt vor (2026-04-02) — A-1 gestartet
|
||||
### Sprint A (Teilweise) — Abgeschlossene Punkte
|
||||
|
||||
- [ ] **A-1** | Tenant-Isolation im Datenzugriffs-Layer implementieren
|
||||
- [x] ADR-0021 (Architect) lesen und Strategie übernehmen
|
||||
- [x] Tenant-Resolution-Mechanismus implementieren (wie erkennt das Backend die Ziel-Datenbank?)
|
||||
- Entries Service: `TenantWebFilter` liest `X-Event-Id`/Subdomain; `TenantRegistry` (In-Memory, konfigurierbar)
|
||||
- [x] Alle Datenzugriffe mit Tenant-Kontext absichern
|
||||
- Entries Service (Exposed): `tenantTransaction {}` setzt `SET search_path TO <schema>` pro Request
|
||||
- [x] Sicherstellen: Kein Cross-Tenant-Datenzugriff möglich
|
||||
- Verhindert durch verpflichtenden Tenant-Kontext + `search_path`; Fehlerfälle: 400/404/423
|
||||
- Nächste Schritte (A-1 Ausbau):
|
||||
- [x] `JdbcTenantRegistry` gegen `control.tenants` implementieren (inkl. Migrationen)
|
||||
- [x] Flyway-SQL: `db/control/V1__init_control_and_tenants.sql`
|
||||
- [x] Spring-JDBC `JdbcTenantRegistry` + Konfiguration (`multitenancy.registry.type=jdbc`)
|
||||
- [x] Flyway pro Tenant-Schema (Rollout aktivierter Tenants)
|
||||
- [x] `db/tenant/V1__entries_schema.sql` (Tabellen `nennungen`, `nennungs_transfers`)
|
||||
- [x] `TenantMigrationsRunner` migriert aktive Schemas beim Start (liest `control.tenants` oder `multitenancy.defaultSchemas`)
|
||||
- [ ] Rollout der Absicherung auf weitere Services (Repos/DAOs)
|
||||
- [ ] Folge-PRs für weitere Services (aktuell: Entries Service migriert)
|
||||
- [x] Observability: `tenant_id` in Logs/Metrics/Traces`
|
||||
- [x] `TenantWebFilter` setzt `MDC["tenant_id"]`
|
||||
- [x] Tests: Unit (Resolver/Registry) + E2E (Isolation A/B)
|
||||
- [x] Unit: `JdbcTenantRegistryTest` (H2)
|
||||
- [x] E2E: Isolation A/B mit Testcontainers Postgres
|
||||
- [ ] Aktueller Status: Integrationstest temporär via `@Disabled` deaktiviert, um den Build zu entblocken; Re-Enable nach Stabilisierung der Jackson/Spring-Web-Konverter-Autokonfiguration
|
||||
|
||||
- [ ] **A-2** | Datenbankschema: Domänen-Hierarchie umsetzen
|
||||
- [x] Tabelle `veranstaltungen` anlegen (interne ID, Tenant-Grenze)
|
||||
- [x] Tabelle `turniere` anlegen (FK → `veranstaltung_id`, OEPS-Turniernummer als eigenes Feld)
|
||||
- [x] Tabelle `bewerbe` anlegen (FK → `turnier_id`, Klasse, Höhe, Bezeichnung)
|
||||
- [x] Tabelle `abteilungen` anlegen (FK → `bewerb_id`, `nr`, `bezeichnung`,
|
||||
`typ: SEPARATE_SIEGEREHRUNG | ORGANISATORISCH`)
|
||||
- [x] Tabelle `teilnehmer_konten` anlegen (FK → `veranstaltung_id`, aggregiert Salden über Turniere)
|
||||
- [x] Tabelle `turnier_kassa` anlegen (FK → `turnier_id`, separate Kassa pro Turnier)
|
||||
- [x] Migrations-Skript schreiben und testen (`db/tenant/V2__domain_hierarchy.sql`, Test: `DomainHierarchyMigrationTest`)
|
||||
- [x] Ergänzung V3 (Turnier-Status): Migration `db/tenant/V3__turniere_status.sql`
|
||||
- [x] `ALTER TABLE turniere ADD COLUMN status VARCHAR(16) NOT NULL DEFAULT 'DRAFT'` + CHECK(`status` IN ('DRAFT','PUBLISHED'))
|
||||
- [x] `ALTER TABLE turniere ADD COLUMN published_at TIMESTAMP WITH TIME ZONE NULL`
|
||||
- [x] Backfill: Alle bestehenden Zeilen auf `DRAFT` setzen; Default danach wieder entfernen oder beibehalten (Entscheidung: beibehalten für Insert-Sicherheit)
|
||||
- [x] Indexe: `CREATE INDEX IF NOT EXISTS idx_turniere_status ON turniere(status)`
|
||||
- [x] Folgetasks: Domänenservice-Validierung für Statuswechsel (siehe B-1 Turniere/PATCH)
|
||||
|
||||
- [ ] **A-3** | Validierungs-Grundlage: Turnierkategorie-Limits
|
||||
- [x] Grundlage implementiert: Entkoppelte Policy-Schnittstelle + Bewerb-Descriptor
|
||||
- Events-Domain: `DomTurnier.validateKategorieLimits(bewerbe, policy)` delegiert an `TurnierkategoriePolicy`
|
||||
- Neu: `TurnierBewerbDescriptor`, `TurnierkategoriePolicy`, `NoopTurnierkategoriePolicy`
|
||||
- Test: `DomTurnierKategorieValidationTest` mit Fake-Policy (Verkabelung + Beispielverletzungen)
|
||||
- [x] Konkrete Regeln/Limits gemäß ÖTO umsetzen (eigene Policy-Implementierung)
|
||||
- `OeToTurnierkategoriePolicy`: Harte Max-Limits umgesetzt (CSN: Höhe in cm; CDN: Klassen-Level). Sonderregeln (Pflichtbewerbe, Tageslimits, Genehmigungen) offen.
|
||||
- Tests: `OeToTurnierkategoriePolicyTest` (CSN/C und C-NEU; B vs. 140 cm; CDN/C und C-NEU; B vs. S)
|
||||
- [ ] Voraussetzung: Spezifikation von 📜 Rulebook Expert (A-5) abwarten (zur Ergänzung der Sonderregeln)
|
||||
- [x] **A-2** | Datenbankschema: Domänen-Hierarchie umgesetzt
|
||||
- [x] Tabellen `veranstaltungen`, `turniere`, `bewerbe`, `abteilungen` mit FK-Ketten
|
||||
- [x] `teilnehmer_konten` (Veranstaltungsebene), `turnier_kassa` (Turnierebene)
|
||||
- [x] Flyway-Migrationen V1–V3 (inkl. Turnier-Status `DRAFT`/`PUBLISHED`)
|
||||
- [x] `DomainHierarchyMigrationTest` grün
|
||||
|
||||
---
|
||||
|
||||
## 🟠 Sprint B — Kurzfristig (nächste Woche)
|
||||
## 🔴 Sprint A — Offen (höchste Priorität)
|
||||
|
||||
- [ ] **B-1** | CRUD-Endpunkte für alle Stammdaten-Entitäten (überarbeitet)
|
||||
- Multitenancy: Alle Endpunkte laufen im Tenant-Schema (Erkennung via `X-Event-Id` oder Subdomain; siehe A-1). IDs sind UUIDs. Fehlercodes: 400 (Bad Request), 404 (Not Found), 409 (Conflict), 422 (Validation), 423 (Locked – Tenant/Status).
|
||||
- Konventionen:
|
||||
- POST → 201 + `Location`-Header; GET (Liste) ist paginiert (`page`, `size`) + einfache Filter (`q`, spezifische Felder).
|
||||
- PUT = Voll-Update; PATCH = Teil-Update für Status/kleine Änderungen, wo sinnvoll.
|
||||
- Lösch-Strategie: Hard-Delete nur für Stammdaten ohne Referenzen; sonst 409 bei FK-Verletzung.
|
||||
- Standard-HTTP-Codes: `GET` 200, `POST` 201, `PUT` 200, `PATCH` 200, `DELETE` 204; Fehler gemäß obiger Liste.
|
||||
- [ ] **A-1** | Tenant-Isolation vollständig ausrollen ⚠️ BLOCKER
|
||||
- [x] ADR-0021 übernommen; `TenantWebFilter`, `TenantRegistry` (JDBC) implementiert
|
||||
- [x] Entries Service: `JdbcTenantRegistry`, `TenantMigrationsRunner`, MDC-Logging
|
||||
- [x] Flyway pro Tenant-Schema; Unit-Tests (`JdbcTenantRegistryTest`) grün
|
||||
- [ ] **Rollout auf weitere Services** (aktuell nur Entries Service migriert)
|
||||
- [ ] E2E-Isolationstest re-enablen (`@Disabled` wegen Jackson/Spring-Web-Autokonfiguration)
|
||||
|
||||
- Veranstaltung (Singleton pro Tenant)
|
||||
- [x] `GET /veranstaltung` — aktuelle Veranstaltung lesen
|
||||
- [x] `PUT /veranstaltung` — Veranstaltung aktualisieren
|
||||
- Hinweis: Erstellen/Löschen einer Veranstaltung erfolgt im Control-Plane (außerhalb des Tenant-Services); daher kein `POST/DELETE` hier.
|
||||
- [ ] **A-3** | Validierungs-Grundlage: Turnierkategorie-Limits
|
||||
- [x] Entkoppelte Policy-Schnittstelle + Bewerb-Descriptor implementiert
|
||||
- [x] Konkrete ÖTO-Regeln/Limits umgesetzt (eigene Policy-Implementierung)
|
||||
- [ ] Sonderregeln aus 📜 Rulebook B-2 Spezifikation einarbeiten (wartet auf Übergabe)
|
||||
|
||||
- Turniere
|
||||
- [x] `POST /turniere` — Turnier anlegen (Felder: `veranstaltungId` implizit aus Tenant, `oepsTurniernummer`, optional `bezeichnung`, `datumVon/Bis`, optional `status`—Default `DRAFT`)
|
||||
- [x] `GET /turniere` — Liste (Filter: `oepsTurniernummer`, Zeitraum, `status`; Paging)
|
||||
- [x] `GET /turniere/{id}` — Detail
|
||||
- [x] `PUT /turniere/{id}` — Voll-Update (ohne Status-Übergang)
|
||||
- Regeln: Bei `PUBLISHED` nur Metadaten änderbar, keine strukturellen Felder (z. B. `oepsTurniernummer`) → sonst `423 Locked`.
|
||||
- [x] `DELETE /turniere/{id}` — löschen (409, falls abhängige Bewerbe existieren; bei `PUBLISHED` grundsätzlich gesperrt → `423 Locked`)
|
||||
- Status-Management (neues Feld, Migration `V3__turniere_status.sql`): `DRAFT | PUBLISHED`
|
||||
- [x] `PATCH /turniere/{id}/status` — Statuswechsel mit Validierung
|
||||
- Erlaubt: `DRAFT → PUBLISHED` (setzt `publishedAt`-Timestamp serverseitig)
|
||||
- `PUBLISHED → DRAFT` nur erlaubt, wenn keine Nennungen/Zahlungen verbucht sind (sonst `409 Conflict`)
|
||||
- Unerlaubte Übergänge → `422 Validation` (inkl. Begründung im `problem+json`-Body)
|
||||
---
|
||||
|
||||
- Bewerbe (FK → Turnier)
|
||||
- [x] `POST /turniere/{turnierId}/bewerbe` — anlegen
|
||||
- [x] `GET /turniere/{turnierId}/bewerbe` — Liste im Turnier
|
||||
- [x] `GET /bewerbe/{id}` — Detail
|
||||
- [x] `PUT /bewerbe/{id}` — aktualisieren
|
||||
- [x] `DELETE /bewerbe/{id}` — löschen (409 bei existierenden Abteilungen/Nennungen; gesperrt falls zu `PUBLISHED` Turnier → `423 Locked`)
|
||||
## 🟠 Sprint B — Priorität 2 (diese Woche)
|
||||
|
||||
- Abteilungen (FK → Bewerb)
|
||||
- [x] `POST /bewerbe/{bewerbId}/abteilungen` — anlegen (Felder: `nr`, `bezeichnung`, `typ: SEPARATE_SIEGEREHRUNG | ORGANISATORISCH`)
|
||||
- [x] `GET /bewerbe/{bewerbId}/abteilungen` — Liste
|
||||
- [x] `GET /abteilungen/{id}` — Detail
|
||||
- [x] `PUT /abteilungen/{id}` — aktualisieren
|
||||
- [x] `DELETE /abteilungen/{id}` — löschen (gesperrt falls zu `PUBLISHED` Turnier → `423 Locked`)
|
||||
|
||||
- Hinweis: Filter `q` (LIKE/ILIKE) bei Bewerbe-Liste ist vorerst ausgelassen und kann nachgezogen werden.
|
||||
|
||||
- Reiter (Athleten-Stammdaten)
|
||||
- [ ] `POST/GET/GET{id}/PUT/DELETE /reiter` — Suche über `q` (Name, Lizenznr.), Filter: `lizenzKlasse`, `vereinId`
|
||||
|
||||
- Pferde (Pferde-Stammdaten)
|
||||
- [ ] `POST/GET/GET{id}/PUT/DELETE /pferde` — Suche `q` (Name, Lebensnr.), Filter: `jahrgang`, `besitzerId`
|
||||
|
||||
- Vereine
|
||||
- [ ] `POST/GET/GET{id}/PUT/DELETE /vereine` — Suche `q` (Name, Kürzel), Filter: `verband`
|
||||
|
||||
- Funktionäre
|
||||
- [ ] `POST/GET/GET{id}/PUT/DELETE /funktionaere` — Suche `q` (Name, Lizenznr.), Filter: `rolle`
|
||||
|
||||
- Technische Notizen
|
||||
- [ ] API-Doku per OpenAPI (Springdoc) veröffentlichen; Beispiel-Payloads für POST/PUT/PATCH (Statuswechsel)
|
||||
- [x] Konsistentes Error-Format (`problem+json`)
|
||||
- [ ] E2E-Tests: CRUD-Flows für Turnier → Bewerb → Abteilung inkl. FK-Constraints
|
||||
- [x] Migration `V3__turniere_status.sql` in Flyway integrieren und gegen H2/Postgres testen (Back/Forward kompatibel)
|
||||
- [x] Guardrails: Service-Ebene erzwingt Locks für `PUBLISHED` (PUT/DELETE) und valide Status-Transitions (PATCH)
|
||||
- [x] Problem+JSON-Details: `type`, `title`, `status`, `detail`, `instance` befüllen; bei `422` Begründung/Violations je Feld mitschicken.
|
||||
- [ ] **B-1** | CRUD-Endpunkte vervollständigen
|
||||
- [x] `Veranstaltung`: GET, PUT
|
||||
- [x] `Turniere`: POST, GET, GET{id}, PUT, DELETE, PATCH /status
|
||||
- [x] `Bewerbe`: POST, GET, GET{id}, PUT, DELETE
|
||||
- [x] `Abteilungen`: POST, GET, GET{id}, PUT, DELETE
|
||||
- [x] Konsistentes Error-Format (`problem+json`); Service-Guardrails für `PUBLISHED`-Lock
|
||||
- [ ] **`Reiter`**: POST/GET/GET{id}/PUT/DELETE (Suche `q`, Filter `lizenzKlasse`, `vereinId`)
|
||||
- [ ] **`Pferde`**: POST/GET/GET{id}/PUT/DELETE (Suche `q`, Filter `jahrgang`, `besitzerId`)
|
||||
- [ ] **`Vereine`**: POST/GET/GET{id}/PUT/DELETE (Suche `q`, Filter `verband`)
|
||||
- [ ] **`Funktionäre`**: POST/GET/GET{id}/PUT/DELETE (Suche `q`, Filter `rolle`)
|
||||
- [ ] OpenAPI-Dokumentation (Springdoc) veröffentlichen
|
||||
- [ ] E2E-Tests: CRUD-Flows Turnier → Bewerb → Abteilung inkl. FK-Constraints
|
||||
|
||||
- [ ] **B-2** | Kassa-Service implementieren
|
||||
- [ ] `TeilnehmerKonto`-Service: Saldo aus mehreren Turnieren aggregieren
|
||||
- [ ] `Zahlvorgang`-Service: Eine Zahlung auf Veranstaltungs-Ebene buchen
|
||||
- [ ] `Zahlvorgang`-Service: Zahlung auf Veranstaltungs-Ebene buchen
|
||||
- [ ] Rechnungs-Generierung: Separate Rechnung je Turnier aus einem Zahlvorgang
|
||||
- [ ] Endpunkte: `GET /veranstaltungen/{id}/kassa/saldo`, `POST /veranstaltungen/{id}/zahlvorgaenge`
|
||||
|
||||
- [ ] **B-3** | ÖTO-Validierung serverseitig absichern
|
||||
- [ ] Spezifikation von 📜 Rulebook Expert (Sprint A-5) umsetzen
|
||||
- [ ] OEPS-Nummern-Format validieren
|
||||
- [ ] FEI-ID-Format validieren
|
||||
- [ ] Spezifikation von 📜 Rulebook B-2 umsetzen (wartet auf Übergabe)
|
||||
- [ ] OEPS-Nummern-Format, FEI-ID-Format validieren
|
||||
- [ ] Lizenzklassen-Validierung (R1–R4, LZF)
|
||||
- [ ] Altersklassen-Kompatibilität Pferd × Bewerb validieren
|
||||
- [ ] Abteilungs-Zwangsteilung im CSN-C-NEU durchsetzen (Bewerb ≤95cm: ohne/mit Lizenz; ≥100cm: R1/R2+)
|
||||
|
||||
- [ ] **B-4** | Nennungs-Service (Grundstruktur)
|
||||
- [ ] Tabelle `nennungen` anlegen (FK → `abteilung_id`, Status: `NEU | GEPRÜFT | BESTÄTIGT | ABGELEHNT`)
|
||||
- [ ] `POST /turniere/{id}/nennungen` — Nennungs-Eingang vom Web-Formular
|
||||
- [ ] `GET /turniere/{id}/nennungen` — Postfach für Desktop-App (Meldestelle)
|
||||
- [ ] `PATCH /nennungen/{id}/status` — Bestätigen / Ablehnen
|
||||
- [ ] Altersklassen-Kompatibilität Pferd × Bewerb
|
||||
- [ ] Abteilungs-Zwangsteilung CSN-C-NEU (≤95cm: ohne/mit Lizenz; ≥100cm: R1/R2+)
|
||||
|
||||
---
|
||||
|
||||
## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
|
||||
## 🟡 Sprint C — Priorität 3 (nächste Woche)
|
||||
|
||||
- [ ] **C-1** | Testdaten-Seeder implementieren
|
||||
- [ ] Reproduzierbare Veranstaltung mit 2 Turnieren (Neumarkt-Szenario)
|
||||
- [ ] Bewerbe mit korrekten Abteilungen (inkl. CSN-C-NEU Pflicht-Teilung)
|
||||
- [ ] Reiter, Pferde, Vereine als Stammdaten
|
||||
- [ ] Nennungen in verschiedenen Status-Stufen
|
||||
- [ ] Seeder via Gradle-Task ausführbar
|
||||
- [ ] **C-1** | Nennungs-Service (Grundstruktur)
|
||||
- [ ] Tabelle `nennungen` anlegen (FK → `abteilung_id`, Status-Automat)
|
||||
- [ ] `NennungsService`: Erstellen, Prüfen, Bestätigen, Ablehnen
|
||||
- [ ] Nennungs-Workflow-Endpunkte
|
||||
|
||||
- [ ] **C-2** | Statistik-Endpunkte
|
||||
- [ ] `GET /turniere/{id}/statistiken` — Statistiken pro Turnier
|
||||
- [ ] `GET /veranstaltungen/{id}/statistiken` — Aggregierte Statistiken über alle Turniere
|
||||
- [ ] **C-2** | Stammdaten-Seeder
|
||||
- [ ] Initiale Testdaten (Reiter, Pferde, Vereine) für Entwicklungsumgebung
|
||||
- [ ] Seed-Skript in `config/scripts/` ablegen
|
||||
|
||||
- [ ] **C-3** | LAN-Sync-Endpunkte (ADR-0022 ✅ freigegeben)
|
||||
- [ ] `SyncEvent`-Datenmodell in `core`-Modul definieren (KMP-shared, Phase 1)
|
||||
- [ ] SQLDelight-Tabellen `sync_events`, `sync_snapshots` anlegen
|
||||
- [ ] `LamportClock`-Implementierung (thread-safe, persistent)
|
||||
- [ ] WebSocket-Server auf Meldestelle-Desk (Ktor): HELLO/HELLO_ACK/SYNC_DELTA/SYNC_PUSH
|
||||
- [ ] mDNS-Discovery-Service integrieren (gemäß ADR-0020)
|
||||
- [ ] Domänen-Mastership-Validierung im Event-Handler
|
||||
- [ ] Reconnect-Logik mit Delta-Sync (`lastKnownSeq`)
|
||||
|
||||
---
|
||||
|
||||
## 📌 Abhängigkeiten
|
||||
|
||||
| Warte auf | Von wem |
|
||||
|------------------------------------------------|--------------------|
|
||||
| ADR-0021 (Tenant-Strategie) | 🏗️ Architect |
|
||||
| Validierungs-Spezifikation (OEPS, FEI, Lizenz) | 📜 Rulebook Expert |
|
||||
| Domänen-Modell final | 🏗️ Architect |
|
||||
| Warte auf | Von wem | Betrifft |
|
||||
|----------------------------------------|-------------|-----------------|
|
||||
| Rulebook B-2 Spezifikation | 📜 Rulebook | A-3, B-3 |
|
||||
| ~~ADR-0022 (LAN-Sync)~~ | ✅ Erledigt | C-3 freigegeben |
|
||||
| QA: E2E-Test-Umgebung Port-Binding Fix | 🧐 QA | A-1 @Disabled |
|
||||
|
||||
| Meine Aufgabe | Ermöglicht wem |
|
||||
|------------------------|--------------------------------|
|
||||
| CRUD-Endpunkte (B-1) | 🎨 Frontend: Backend-Anbindung |
|
||||
| Kassa-Service (B-2) | 🎨 Frontend: Kassa-Screen |
|
||||
| Nennungs-Service (B-4) | 🎨 Frontend: Nennungs-Postfach |
|
||||
---
|
||||
|
||||
## 💡 Empfehlungen (nach Priorität)
|
||||
|
||||
1. **A-1 Rollout** — Tenant-Isolation auf alle verbleibenden Services ausweiten; `@Disabled` E2E-Test re-enablen sobald
|
||||
Jackson-Fix vorliegt.
|
||||
2. **B-1 Reiter/Pferde/Vereine/Funktionäre** — Frontend wartet auf diese Endpunkte für ViewModel-Anbindung.
|
||||
3. **B-3 ÖTO-Validierung** — Erst nach Rulebook-Übergabe starten, aber Grundstruktur (Validator-Interface) schon
|
||||
vorbereiten.
|
||||
|
||||
@@ -1,96 +1,82 @@
|
||||
# 🧹 [Curator] — Schritt-für-Schritt Roadmap
|
||||
# 🧹 [Curator] — Zwischenstand & Roadmap
|
||||
|
||||
> **Stand:** 2. April 2026
|
||||
> **Rolle:** Dokumentation, Session-Logs, Reports, Aufräumen, Wissens-Management
|
||||
> **Stand:** 3. April 2026
|
||||
> **Rolle:** Dokumentation, Session-Logs, Ubiquitous Language, Ordnung in `docs/`
|
||||
|
||||
---
|
||||
|
||||
## 🔴 Sprint A — Sofort (diese Woche)
|
||||
## ✅ Erledigte Sprints
|
||||
|
||||
- [x] **A-1** | `Ubiquitous_Language.md` aktualisieren (nach Domänen-Modell vom Architect)
|
||||
- [x] Hierarchie `Veranstaltung → Turnier → Bewerb → Abteilung` eintragen
|
||||
- [x] `Abteilung` als eigenständigen Begriff definieren (kleinste ausführbare Einheit)
|
||||
- [x] `SEPARATE_SIEGEREHRUNG` und `ORGANISATORISCH` als Abteilungs-Typen definieren
|
||||
- [x] `TeilnehmerKonto` auf Veranstaltungsebene (Multi-Turnier-Aggregation) eintragen
|
||||
- [x] `Veranstaltungs-Kassa` und `TurnierKassa` als separate Begriffe definieren
|
||||
- [x] `Zahlvorgang` (eine Zahlung, mehrere Rechnungen) definieren
|
||||
### Sprint A — Abgeschlossen
|
||||
|
||||
- [x] **A-2** | Event-First-Workflow dokumentieren
|
||||
- [x] Ablauf: Veranstaltung anlegen → Turnier anlegen → Bewerbe anlegen → Abteilungen → Startliste
|
||||
- [x] Dokument in `docs/01_Architecture/` oder `docs/02_Guides/` ablegen → `docs/02_Guides/Event-First-Workflow.md`
|
||||
- [x] **A-1** | `Ubiquitous_Language.md` aktualisiert (nach Domänen-Modell vom Architect)
|
||||
- [x] **A-2** | Event-First-Workflow dokumentiert → `docs/02_Guides/Event-First-Workflow.md`
|
||||
- [x] **A-3** | Navigation-V3 dokumentiert → `docs/06_Frontend/Navigation_V3_Screen-Baum_und_Back-Stack.md`
|
||||
- [x] **A-4** | Tenant-Konzept dokumentiert →
|
||||
`docs/01_Architecture/Reference/Tenant-Konzept_Eine-Veranstaltung-eine-Datenbank.md`
|
||||
- [x] **A-5** | Session-Log Meldestelle-Besprechung (02.04.2026) →
|
||||
`docs/99_Journal/2026-04-02_Meldestelle_Besprechung_Session-Log.md`
|
||||
|
||||
- [x] **A-3** | Navigation-V3 dokumentieren
|
||||
- [x] Aktuellen Screen-Baum und Back-Stack-Verhalten beschreiben
|
||||
- [x] Dokument in `docs/06_Frontend/` ablegen → `docs/06_Frontend/Navigation_V3_Screen-Baum_und_Back-Stack.md`
|
||||
### Sprint B (Teilweise) — Abgeschlossen
|
||||
|
||||
- [x] **A-4** | Tenant-Konzept dokumentieren (nach ADR-0021 vom Architect)
|
||||
- [x] ADR-0021 in `docs/01_Architecture/ADRs/` verlinken → `docs/01_Architecture/adr/0021-tenant-resolution-strategy-de.md`
|
||||
- [x] Konzept "eine Veranstaltung = eine Datenbank (Tenant)" in Laien-Sprache erklären
|
||||
- [x] Auswirkungen auf Schema, API und Frontend zusammenfassen → `docs/01_Architecture/Reference/Tenant-Konzept_Eine-Veranstaltung-eine-Datenbank.md`
|
||||
|
||||
- [x] **A-5** | Session-Log für heutige Besprechung (2. April 2026) erstellen
|
||||
- [x] Alle Beschlüsse der Meldestelle-Besprechung eintragen
|
||||
- [x] Domänen-Korrekturen (Abteilung, Kassa, Veranstaltungs-Hierarchie) festhalten
|
||||
- [x] Zurückgestellte Themen (USB-Fallback, Web-App, Nenn-System) als ⏸️ markieren
|
||||
- [x] Log in `docs/99_Journal/` ablegen → `docs/99_Journal/2026-04-02_Meldestelle_Besprechung_Session-Log.md`
|
||||
- [x] **B-0** | Rulebook-Session (03.04.2026) dokumentiert →
|
||||
`docs/99_Journal/2026-04-03_Rulebook_B1_Validierung_Frontend.md`
|
||||
|
||||
---
|
||||
|
||||
## 🟠 Sprint B — Kurzfristig (nächste Woche)
|
||||
## 🔴 Sprint B — Offen (höchste Priorität)
|
||||
|
||||
- [ ] **B-1** | Roadmaps-Verzeichnis pflegen
|
||||
- [ ] Alle 8 Roadmap-Dateien in `docs/04_Agents/Roadmaps/` auf Vollständigkeit prüfen
|
||||
- [ ] Abgeschlossene Aufgaben in den Roadmaps als `[x]` markieren (nach Rückmeldung der Teams)
|
||||
- [ ] Alle 9 Roadmap-Dateien in `docs/04_Agents/Roadmaps/` auf Vollständigkeit prüfen ← *diese Session*
|
||||
- [ ] Abgeschlossene Aufgaben als `[x]` markieren (nach Rückmeldung der Teams)
|
||||
|
||||
- [ ] **B-2** | `docs/05_Backend/` aktualisieren
|
||||
- [ ] Neues Datenbankschema (Tabellen: veranstaltungen, turniere, bewerbe, abteilungen) dokumentieren
|
||||
- [ ] Neues Datenbankschema (Tabellen: `veranstaltungen`, `turniere`, `bewerbe`, `abteilungen`) dokumentieren
|
||||
- [ ] API-Endpunkte-Übersicht aktualisieren sobald Backend Sprint B abgeschlossen
|
||||
|
||||
- [ ] **B-3** | `docs/06_Frontend/` aktualisieren
|
||||
- [ ] ViewModel-Architektur-Muster (MVVM/UDF) dokumentieren (nach Frontend Sprint A)
|
||||
- [ ] Verweis auf `VeranstalterViewModel` als Referenz-Implementierung
|
||||
- [ ] ViewModel-Architektur-Muster (MVVM/UDF) verlinken
|
||||
- [ ] Verweis auf `VeranstalterViewModel` als Referenz-Implementierung eintragen
|
||||
|
||||
---
|
||||
|
||||
## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
|
||||
## 🟠 Sprint C — Priorität 2 (nächste Woche)
|
||||
|
||||
- [ ] **C-1** | `README.md` aktualisieren
|
||||
- [ ] Desktop-App als primären Fokus hervorheben
|
||||
- [ ] Schnellstart-Anleitung für lokale Entwicklungsumgebung prüfen und aktualisieren
|
||||
- [ ] Veraltete Abschnitte (V1-Referenzen) entfernen oder als deprecated markieren
|
||||
- [ ] Schnellstart-Anleitung für lokale Entwicklungsumgebung prüfen
|
||||
- [ ] Veraltete V1-Abschnitte entfernen oder als deprecated markieren
|
||||
|
||||
- [ ] **C-2** | Setup-Guide aktualisieren
|
||||
- [ ] Schritt-für-Schritt-Anleitung: Projekt klonen → Docker starten → Desktop-App starten
|
||||
- [ ] Voraussetzungen (JDK, Gradle, Docker) mit genauen Versionen dokumentieren
|
||||
- [ ] Schritt-für-Schritt: Projekt klonen → Docker starten → Desktop-App starten
|
||||
- [ ] Voraussetzungen (JDK, Gradle, Docker) mit exakten Versionen dokumentieren
|
||||
- [ ] Dokument in `docs/02_Guides/` ablegen
|
||||
|
||||
- [ ] **C-3** | Unterordner-Struktur in `docs/` einführen (falls erforderlich)
|
||||
- [ ] Aktuelle Struktur analysieren: Gibt es überladene Verzeichnisse?
|
||||
- [ ] Vorschlag für saubere Unterordner-Struktur erstellen
|
||||
- [ ] Mit Architect abstimmen und umsetzen
|
||||
- [ ] **C-3** | Unterordner-Struktur in `docs/` prüfen
|
||||
- [ ] Überladene Verzeichnisse identifizieren
|
||||
- [ ] Strukturvorschlag mit Architect abstimmen
|
||||
|
||||
- [ ] **C-4** | V1-Code-Bereinigung koordinieren
|
||||
- [ ] Alle V1-Dateien und -Module identifizieren (gemeinsam mit Frontend + Backend)
|
||||
- [ ] Bereinigungsplan erstellen: Was kann gelöscht werden, was muss migriert werden?
|
||||
- [ ] Bereinigung koordinieren und dokumentieren
|
||||
- [ ] V1-Dateien und -Module zusammen mit Frontend + Backend identifizieren
|
||||
- [ ] Bereinigungsplan erstellen und koordinieren
|
||||
|
||||
- [ ] **C-5** | Reports-Verzeichnis pflegen
|
||||
- [ ] Nach Sprint A, B, C: Kurzberichte von allen Entwicklern einsammeln
|
||||
- [ ] In `docs/90_Reports/` archivieren
|
||||
- [ ] **C-5** | Sprint-Reports archivieren
|
||||
- [ ] Kurzberichte von allen Teams nach Sprint A/B/C einsammeln
|
||||
- [ ] In `docs/90_Reports/` ablegen
|
||||
|
||||
---
|
||||
|
||||
## 📌 Abhängigkeiten
|
||||
|
||||
| Warte auf | Von wem |
|
||||
|-----------------------------|-------------------------|
|
||||
| ADR-0021 (Tenant-Strategie) | 🏗️ Architect — für A-4 |
|
||||
| Domänen-Modell final | 🏗️ Architect — für A-1 |
|
||||
| ViewModel-Referenz | 🎨 Frontend — für B-3 |
|
||||
| Neues DB-Schema | 👷 Backend — für B-2 |
|
||||
| Warte auf | Von wem | Betrifft |
|
||||
|------------------------------------|-------------|-------------------|
|
||||
| Backend CRUD-Endpunkte fertig | 👷 Backend | B-2 API-Übersicht |
|
||||
| Frontend B-1 ViewModel-Architektur | 🎨 Frontend | B-3 Frontend-Docs |
|
||||
|
||||
| Meine Aufgabe | Ermöglicht wem |
|
||||
|--------------------------------|---------------------------------------------------|
|
||||
| `Ubiquitous_Language.md` (A-1) | Alle: gemeinsames Vokabular, kein Missverständnis |
|
||||
| Session-Log (A-5) | Alle: Nachvollziehbarkeit der Beschlüsse |
|
||||
| README + Setup-Guide (C-1/C-2) | Neue Entwickler: sofortiger Einstieg ins Projekt |
|
||||
---
|
||||
|
||||
## 💡 Empfehlungen (nach Priorität)
|
||||
|
||||
1. **B-1 Roadmaps** — Wird gerade in dieser Session erledigt (03.04.2026).
|
||||
2. **B-2 Backend-Doku** — Sobald Backend B-1 (Reiter/Pferde-APIs) abgeschlossen ist, Endpunkte-Übersicht erstellen.
|
||||
3. **C-1 README** — Wichtig für neue Entwickler; Desktop-App ist primärer Fokus, aber README ist noch veraltet.
|
||||
|
||||
@@ -1,50 +1,36 @@
|
||||
# 🐧 [DevOps Engineer] — Schritt-für-Schritt Roadmap
|
||||
# 🐧 [DevOps Engineer] — Zwischenstand & Roadmap
|
||||
|
||||
> **Stand:** 3. April 2026
|
||||
> **Rolle:** Docker, CI/CD, Gradle, Security, Desktop-Packaging, Infrastruktur
|
||||
|
||||
---
|
||||
|
||||
## 🔴 Sprint A — Sofort (diese Woche)
|
||||
## ✅ Erledigte Sprints
|
||||
|
||||
- [x] **A-1** | Docker-Compose-Setup auf aktuellen Stand bringen
|
||||
- [x] Alle Services (Backend, DB, Infra) in `docker-compose.yaml` / `dc-*.yaml` prüfen
|
||||
- [x] Sicherstellen: Lokale Entwicklungsumgebung startet mit einem einzigen Befehl
|
||||
- [x] Healthchecks für alle Services definieren
|
||||
### Sprint A — Abgeschlossen
|
||||
|
||||
Hinweise:
|
||||
- Ein-Kommando-Start (alle Profile):
|
||||
```bash
|
||||
docker compose --profile all up -d
|
||||
```
|
||||
- Healthchecks ergänzt für: `api-gateway`, `ping-service`, `web-app`, `zipkin`.
|
||||
- `depends_on` vereinheitlicht: Keycloak wird von Backend-Services mit `service_healthy` abgewartet.
|
||||
- [x] **A-1** | Docker-Compose-Setup auf aktuellen Stand gebracht
|
||||
- [x] Alle Services in `docker-compose.yaml` / `dc-*.yaml` geprüft
|
||||
- [x] Lokale Entwicklungsumgebung startet mit einem einzigen Befehl
|
||||
- [x] Healthchecks für alle Services definiert
|
||||
|
||||
---
|
||||
|
||||
## 🟠 Sprint B — Kurzfristig (nächste Woche)
|
||||
### Sprint B — Abgeschlossen
|
||||
|
||||
- [x] **B-1** | CI/CD Pipeline für Compose Desktop Tests (headless)
|
||||
- [x] Gitea Actions Workflow angelegt: `.gitea/workflows/desktop-tests.yml`
|
||||
- [x] Headless-Umgebung: `xvfb-run` (1920x1080x24) für Compose Desktop Tests
|
||||
- [x] Gradle-Task integriert: `:frontend:shells:meldestelle-desktop:jvmTest`
|
||||
- [x] Build-Artefakte gespeichert: `frontend/shells/meldestelle-desktop/build/**` (JARs und Compose-Distributables)
|
||||
- [x] Fehlgeschlagene Tests brechen Build ab (Default-Verhalten von Gradle `jvmTest`)
|
||||
|
||||
Hinweise:
|
||||
- CI nutzt JDK 21 (Temurin), Gradle-Cache (`actions/cache`).
|
||||
- Artefakte: Upload via `actions/upload-artifact`. Pfade siehe Workflow.
|
||||
- Siehe: `docs/01_Architecture/Gitea/Enable_Gitea_Actions_Cache_to_Accelerate_CI_CD.md` für Runner-Cache.
|
||||
- [x] Gitea Actions Workflow: `.gitea/workflows/desktop-tests.yml`
|
||||
- [x] Headless-Umgebung: `xvfb-run` (1920×1080×24) für Compose Desktop Tests
|
||||
- [x] Gradle-Task: `:frontend:shells:meldestelle-desktop:jvmTest`
|
||||
- [x] Build-Artefakte gespeichert (JARs, Compose-Distributables)
|
||||
|
||||
- [x] **B-2** | Gradle-Build-Optimierungen
|
||||
- [x] Build-Cache aktiv: `org.gradle.caching=true` (in `gradle.properties`)
|
||||
- [x] Parallele Builds aktiv: `org.gradle.parallel=true` (in `gradle.properties`)
|
||||
- [x] Headless-Flag gesetzt: `-Djava.awt.headless=true` (in `org.gradle.jvmargs`)
|
||||
- [x] Wrapper aktualisiert: Gradle `9.4.0` (kompatibel mit aktuellem Setup)
|
||||
- [x] Build-Cache aktiv: `org.gradle.caching=true`
|
||||
- [x] Parallele Builds aktiv: `org.gradle.parallel=true`
|
||||
- [x] Headless-Flag: `-Djava.awt.headless=true`
|
||||
- [x] Gradle Wrapper auf `9.4.0` aktualisiert
|
||||
|
||||
---
|
||||
|
||||
## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
|
||||
## 🔴 Sprint C — Priorität 1 (diese Woche)
|
||||
|
||||
- [ ] **C-1** | Desktop-App Packaging konfigurieren
|
||||
- [ ] `compose.desktop.nativeDistributions` in `build.gradle.kts` konfigurieren
|
||||
@@ -56,10 +42,10 @@
|
||||
|
||||
- [ ] **C-2** | Semantic Versioning einführen
|
||||
- [ ] Versionierungsschema definieren: `MAJOR.MINOR.PATCH`
|
||||
- [ ] Gemeinsame Versions-Quelle für Client (Frontend) und Server (Backend) festlegen
|
||||
- [ ] Gemeinsame Versions-Quelle für Frontend und Backend festlegen
|
||||
- [ ] Git-Tagging-Strategie definieren (`v1.0.0`, `v1.0.0-backend`, etc.)
|
||||
- [ ] Release-Tagging in CI/CD-Pipeline integrieren
|
||||
- [ ] `CHANGELOG.md` Vorlage anlegen
|
||||
- [ ] `CHANGELOG.md`-Vorlage anlegen
|
||||
|
||||
- [ ] **C-3** | Produktions-Deployment vorbereiten
|
||||
- [ ] Reverse-Proxy-Konfiguration (Nginx / Traefik) für Backend prüfen
|
||||
@@ -68,21 +54,34 @@
|
||||
|
||||
---
|
||||
|
||||
## ⏸️ Zurückgestellt
|
||||
## 🟠 Sprint D — Priorität 2 (nächste Woche)
|
||||
|
||||
> ⏸️ **USB-Stick Fallback** — Separate Besprechung zu einem späteren Zeitpunkt
|
||||
> ⏸️ **Web-App Deployment** — Wird erst nach Desktop-App (Sprint A+B) gestartet
|
||||
- [ ] **D-1** | Multi-Tenant Datenbankinfrastruktur absichern
|
||||
- [ ] Sicherstellen: Pro-Tenant-Schema in Postgres korrekt isoliert
|
||||
- [ ] Monitoring: Tenant-Schemas in Grafana-Dashboard sichtbar
|
||||
- [ ] Backup: Pro-Tenant-Backup-Strategie definieren
|
||||
|
||||
- [ ] **D-2** | mDNS / LAN-Discovery Infrastruktur (nach ADR-0022)
|
||||
- [ ] mDNS-Dienst (Avahi o. ä.) in Docker-Compose für lokale Entwicklung bereitstellen
|
||||
- [ ] WebSocket-Endpunkt in Nginx/Traefik-Konfiguration durchreichen
|
||||
|
||||
> ⏸️ **Pangolin / externer Zugriff** — Nur für Remote-Support-Szenarien; kein MVP-Blocker
|
||||
|
||||
---
|
||||
|
||||
## 📌 Abhängigkeiten
|
||||
|
||||
| Warte auf | Von wem |
|
||||
|-------------------------|------------------|
|
||||
| Headless-Test-Strategie | 🧐 QA Specialist |
|
||||
| Warte auf | Von wem | Betrifft |
|
||||
|----------------------------|-------------------|---------------------|
|
||||
| ADR-0022 LAN-Sync | 🏗️ Architect B-1 | D-2 mDNS-Infra |
|
||||
| QA: Test-Integration in CI | 🧐 QA C-4 | C-1 Packaging-Tests |
|
||||
|
||||
| Meine Aufgabe | Ermöglicht wem |
|
||||
|---------------------------|----------------------------------------|
|
||||
| CI/CD Pipeline (B-1) | 🧐 QA: Automatisierte Test-Ausführung |
|
||||
| Desktop-Packaging (C-1) | Alle: Auslieferbare Desktop-App |
|
||||
| Semantic Versioning (C-2) | Alle: Koordiniertes Release-Management |
|
||||
---
|
||||
|
||||
## 💡 Empfehlungen (nach Priorität)
|
||||
|
||||
1. **C-1 Desktop-Packaging** — Für erste echte Auslieferung an Endnutzer zwingend notwendig; `.msi`/`.deb` sollten vor
|
||||
dem ersten Beta-Test bereitstehen.
|
||||
2. **C-2 Semantic Versioning** — Ohne klare Versionierung ist kein koordiniertes Release möglich; einfach zu
|
||||
implementieren, hoher Nutzen.
|
||||
3. **D-1 Tenant-Backup** — Wenn eine Veranstaltung = eine Datenbank, muss jeder Tenant einzeln gesichert werden können.
|
||||
|
||||
@@ -1,163 +1,117 @@
|
||||
# 🎨 [Frontend Expert] — Schritt-für-Schritt Roadmap
|
||||
# 🎨 [Frontend Expert] — Zwischenstand & Roadmap
|
||||
|
||||
> **Stand:** 3. April 2026
|
||||
> **Rolle:** KMP, Compose Desktop, State-Management, MVVM/UDF, Backend-Anbindung
|
||||
> **Rolle:** KMP, Compose Desktop, State-Management, Navigation, Backend-Anbindung
|
||||
|
||||
---
|
||||
|
||||
## 🔴 Sprint A — Sofort (diese Woche)
|
||||
## ✅ Erledigte Sprints
|
||||
|
||||
- [x] **A-1** | ViewModel-Architektur definieren und Referenz-Implementierung umsetzen
|
||||
- [x] MVVM mit UDF (Unidirectional Data Flow) als verbindliches Muster festlegen
|
||||
- [x] `Intent`- und `State`-Klassen-Struktur definieren (Vorlage für alle anderen ViewModels)
|
||||
- [x] `VeranstalterViewModel` als vollständige Referenz-Implementierung umsetzen
|
||||
- [x] `State`-Klasse definieren
|
||||
- [x] `Intent`-Klasse (Sealed Class) definieren
|
||||
- [x] Business-Logik aus Composables herausziehen (keine `StoreV2`-Aufrufe mehr direkt in `onSaved`)
|
||||
- [x] Lokalen `remember`-State durch ViewModel-State ersetzen
|
||||
- [x] Ergebnis als Muster-Dokument in `docs/06_Frontend/` ablegen
|
||||
### Sprint A — Abgeschlossen
|
||||
|
||||
Referenzen:
|
||||
- docs/06_Frontend/MVVM_UDF_Pattern.md (Regeln, Vorlage, Referenz-Code)
|
||||
- frontend/features/veranstalter-feature/src/commonMain/.../VeranstalterViewModel.kt
|
||||
- frontend/features/veranstalter-feature/src/jvmMain/kotlin/at/mocode/frontend/features/veranstalter/data/remote/DefaultVeranstalterRepository.kt
|
||||
- frontend/features/veranstalter-feature/src/jvmMain/.../VeranstalterAuswahlScreen.kt (nutzt ViewModel/Intents)
|
||||
- [x] **A-1** | ViewModel-Architektur definieren & Referenz-Implementierung
|
||||
- [x] MVVM mit UDF als verbindliches Muster festgelegt
|
||||
- [x] `Intent`/`State`-Struktur definiert (Sealed Classes)
|
||||
- [x] `VeranstalterViewModel` als vollständige Referenz-Implementierung
|
||||
- [x] Muster-Dokument in `docs/06_Frontend/` abgelegt
|
||||
|
||||
- [x] **A-2** | Abteilungs-Logik im Bewerb-Dialog berücksichtigen
|
||||
- [x] Dialog enthält Abteilungs-Auswahl als Teil des „Bewerb anlegen“-Flows (im selben Modal)
|
||||
- [x] CSN-C-NEU: Automatischer Vorschlag der Pflicht-Teilung mit 4 Abteilungen:
|
||||
- [x] Ohne Lizenz · R1
|
||||
- [x] Ohne Lizenz · R2+
|
||||
- [x] Mit Lizenz · R1
|
||||
- [x] Mit Lizenz · R2+
|
||||
- [x] Beim Auto-Vorschlag Default-Setzung des Abteilungs-Typs auf `SEPARATE_SIEGEREHRUNG`
|
||||
- [x] Manuelle Umschaltung des Abteilungs-Typs möglich: `SEPARATE_SIEGEREHRUNG` oder `ORGANISATORISCH`
|
||||
- [x] UX: Bei erkanntem Typ „CSN-C-NEU“ wird ein AssistChip „Pflicht-Teilung vorgeschlagen“ angezeigt
|
||||
- [x] **A-2** | Abteilungs-Logik im Bewerb-Dialog
|
||||
- [x] CSN-C-NEU: Automatischer Vorschlag der Pflicht-Teilung mit 4 Abteilungen
|
||||
- [x] AssistChip „Pflicht-Teilung vorgeschlagen" bei erkanntem Typ
|
||||
- [x] Abteilungs-Typen `SEPARATE_SIEGEREHRUNG` / `ORGANISATORISCH` in UI
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- [x] Der „Bewerb anlegen“-Dialog zeigt ein Eingabefeld „Bewerbs-Typ“ und eine Auswahl für den Abteilungs-Typ (zwei Chips)
|
||||
- [x] Bei Eingabe „CSN-C-NEU“ wird automatisch die oben definierte 4er-Teilung in der Abteilungs-Liste angezeigt
|
||||
- [x] Die Auto-Teilung kann angezeigt werden, ohne dass der Dialog neu geöffnet werden muss (Live-Reaktion auf Eingabe)
|
||||
- [x] Der gesetzte Abteilungs-Typ ist im State sichtbar und wird vom Dialog korrekt reflektiert
|
||||
- [x] Kein Vorschlag für andere Typen; Liste bleibt leer bis manuell hinzugefügt/implementiert (aktuell out-of-scope)
|
||||
### Sprint B (Teilweise) — Abgeschlossene Punkte
|
||||
|
||||
Referenzen (konkret):
|
||||
- frontend/features/turnier-feature/src/commonMain/kotlin/at/mocode/turnier/feature/presentation/BewerbAnlegenViewModel.kt
|
||||
- `BewerbAnlegenState`, `BewerbAnlegenIntent`, `applySuggestion()` (Auto-Vorschlag + Default-AbteilungsTyp)
|
||||
- frontend/features/turnier-feature/src/jvmMain/kotlin/at/mocode/turnier/feature/presentation/TurnierBewerbeTab.kt
|
||||
- `BewerbAnlegenDialog(...)`: Eingabe „Bewerbs-Typ“, AssistChip, Auswahl Abteilungs-Typ, Anzeige der vorgeschlagenen Abteilungen
|
||||
|
||||
---
|
||||
|
||||
## 🟠 Sprint B — Kurzfristig (nächste Woche)
|
||||
|
||||
- [x] **B-1** | ViewModels für alle V3-Screens umsetzen
|
||||
- [x] `TurnierViewModel`
|
||||
- [x] `BewerbViewModel` (inkl. Abteilungs-Logik via Dialog-VM)
|
||||
- [x] `PferdProfilViewModel`
|
||||
- [x] `ReiterProfilViewModel`
|
||||
- [x] `VereinsViewModel`
|
||||
- [x] `FunktionaerViewModel`
|
||||
- [x] **B-1** | ViewModels für alle V3-Screens
|
||||
- [x] `TurnierViewModel`, `BewerbViewModel`, `PferdProfilViewModel`
|
||||
- [x] `ReiterProfilViewModel`, `VereinsViewModel`, `FunktionaerViewModel`
|
||||
- [x] `AbteilungViewModel` (Startliste, Ergebnisse)
|
||||
|
||||
- [ ] **B-2** | Ktor-Clients und Repositories für Backend-Anbindung vorbereiten (V3-ready)
|
||||
- [x] KMP-Ktor-Client zentral konfigurieren (BaseURL, Auth, Timeout, JSON, Logging)
|
||||
- [x] BaseURL per `PlatformConfig.resolveApiBaseUrl()` (SSoT; JS: `globalThis.API_BASE_URL`/`window.location.origin`, JVM: `.env`/Systemprop) → frontend/core/network
|
||||
- [x] Auth: Bearer Token über Interceptor; Token-Quelle: core/auth (`AuthApiClient`) bzw. Session-Store → Header `Authorization: Bearer <token>`
|
||||
- [x] Timeouts: connect = 5s, request = 15s, socket = 30s (prod); dev je 2× höher; Retry-Policy max 2 Versuche bei 5xx/Network
|
||||
- [x] JSON: `kotlinx.serialization` mit `ignoreUnknownKeys=true`, `explicitNulls=false`, `coerceInputValues=true`
|
||||
- [x] Logging: `LogLevel.HEADERS` in dev, `LogLevel.NONE` in prod; PII nie loggen
|
||||
- [x] Engines: JVM=CIO, JS=fetch (ktor-client-js), WASM=js (vorbereitet)
|
||||
### Zusätzlich erledigt (Session 02.04.2026)
|
||||
|
||||
- [ ] Repository-Schnittstellen je Domäne definieren (Mock ↔ Real austauschbar)
|
||||
- [ ] Pakete/Orte (commonMain):
|
||||
- [x] `at.mocode.frontend.features.veranstalter.domain.VeranstalterRepository`
|
||||
- [x] `at.mocode.turnier.feature.domain.TurnierRepository`
|
||||
- [ ] `at.mocode.turnier.feature.domain.BewerbRepository`
|
||||
- [ ] `at.mocode.turnier.feature.domain.AbteilungRepository`
|
||||
- [ ] Operationen V3-Minimum: `list`, `getById`, `create`, `update`, `delete` (suspend)
|
||||
- [ ] Rückgabetypen: Domain-Modelle (nicht DTOs); Fehler als `Either<DomainError, T>` oder `Result<T>` (einheitlich festlegen)
|
||||
- [x] Navigation V2 / Back-Stack-System implementiert
|
||||
- [x] Profil-Cards mit Edit-Dialog (Veranstalter, Pferd, Reiter, Verein, Funktionär)
|
||||
- [x] Onboarding: State-Lift via `rememberSaveable` (Gerätename, Sicherheitsschlüssel)
|
||||
- [x] Veranstaltungs-Wizard: Bestätigungs-Dialog mit Daten-Vorschau vor finalem Anlegen
|
||||
- [x] Breadcrumbs und Zurück-Navigation korrigiert
|
||||
|
||||
- [ ] HTTP-Clients + DTOs + Mapper (jvmMain/jsMain)
|
||||
- [x] DTOs pro Feature in `.../data/remote/dto` mit `@Serializable` (Veranstalter)
|
||||
- [x] Mapper: `Dto ↔ Domain` in `.../data/mapper` (reine Funktionen) (Veranstalter)
|
||||
- [x] Client-Implementierungen in `.../data/remote/Default*Repository` mit Ktor (Veranstalter)
|
||||
- [x] Fehlerbehandlung: Mapping HTTP 401→`AuthError.Expired`, 403→`AuthError.Forbidden`, 404→`NotFound`, 409→`Conflict`, 5xx→`ServerError`
|
||||
---
|
||||
|
||||
- [ ] Koin-DI-Module
|
||||
- [x] `core/network`: `HttpClient`-Factory als `single { provideHttpClient(env) }`
|
||||
- [ ] Feature-Module binden `Repository`-Interfaces auf Default-Impl
|
||||
- [ ] `AuthApiClient` (core/auth) integrieren, Token-Provider injizierbar (z. B. `() -> String?`)
|
||||
## 🔴 Sprint B — Offen (höchste Priorität)
|
||||
|
||||
- [ ] Backend-Endpunkte verdrahten (gemäß contracts/ oder Backend-Services)
|
||||
- [x] Veranstalter: GET `/api/v3/veranstalter`, POST `/api/v3/veranstalter` ...
|
||||
- [ ] Turniere: GET `/api/v3/turniere`, ...
|
||||
- [ ] Bewerbe: GET `/api/v3/turniere/{id}/bewerbe`, ...
|
||||
- [ ] Abteilungen: GET `/api/v3/bewerbe/{id}/abteilungen`, ...
|
||||
- [ ] Versionierung: Präfix `/api/v3` zentral in `ApiRoutes`
|
||||
|
||||
- [ ] Migration: `StoreV2` schrittweise ablösen
|
||||
- [ ] ViewModels von `StoreV2` auf Repositories umschalten (Feature für Feature)
|
||||
- [ ] Parallelbetrieb per Toggle: `useRealBackend=true/false` (Konfig/DI)
|
||||
- [ ] Entfernen von `StoreV2`, sobald Feature vollständig migriert und stabil
|
||||
|
||||
- [ ] Qualität & DX
|
||||
- [ ] Akzeptanztests per Fake-Server (Mock Engine) gegen Repos (happy + error paths)
|
||||
- [ ] Network-Error-UX: Einheitliche Fehlermeldungen/Retry in ViewModels (UDF)
|
||||
- [ ] Dokumentation in `docs/06_Frontend/Networking.md` (Beispiele, Guidelines)
|
||||
|
||||
Referenzen (bestehend):
|
||||
- frontend/core/network/src/commonMain/.../PlatformConfig.kt (expect) und js/jvm actuals
|
||||
- frontend/core/auth/src/commonMain/.../AuthApiClient.kt (Keycloak/PKCE, Token-Erhalt)
|
||||
- frontend/core/network/build.gradle.kts (Ktor- und Engine-Dependencies)
|
||||
- frontend/core/network/src/commonMain/.../NetworkModule.kt (HttpClient-Setup, Retry/Timeout, Token-Inject)
|
||||
- frontend/features/veranstalter-feature/src/jvmMain/kotlin/at/mocode/frontend/features/veranstalter/data/remote/DefaultVeranstalterRepository.kt
|
||||
|
||||
Akzeptanzkriterien (B-2 abgeschlossen):
|
||||
- [x] `HttpClient`-Factory vorhanden, konfiguriert und via Koin injizierbar
|
||||
- [x] Repository-Interfaces existieren in commonMain, mit Domain-Typen und suspend-APIs (Veranstalter, Turnier vorbereitet)
|
||||
- [x] Mindestens `VeranstalterRepository` nutzt echten Backend-Client und liefert Daten
|
||||
- [x] Fehler werden einheitlich modelliert und bis ins ViewModel propagiert
|
||||
- [x] Ein Feature-ViewModel (z. B. Veranstalter) läuft ohne `StoreV2`
|
||||
- [ ] **B-2** | Ktor-Clients & Repositories für Backend-Anbindung
|
||||
- [x] `HttpClient`-Factory zentral konfiguriert (Auth, Timeout, JSON, Logging, Retry)
|
||||
- [x] `VeranstalterRepository` (Interface + Default-Impl mit Ktor) vollständig
|
||||
- [x] `TurnierRepository` Interface in commonMain vorbereitet
|
||||
- [x] Fehler-Mapping HTTP → Domain-Errors einheitlich
|
||||
- [ ] `BewerbRepository` und `AbteilungRepository` anlegen
|
||||
- [ ] Koin Feature-Module: Repository-Interfaces auf Default-Impl binden
|
||||
- [ ] `AuthApiClient`-Integration: Token-Provider injizierbar
|
||||
- [ ] Turnier/Bewerb/Abteilung Backend-Endpunkte verdrahten
|
||||
- [ ] `StoreV2` schrittweise ablösen (Feature-für-Feature, Toggle `useRealBackend`)
|
||||
- [ ] Akzeptanz-Tests per Fake-Server (Mock Engine, happy + error paths)
|
||||
- [ ] Dokumentation `docs/06_Frontend/Networking.md`
|
||||
|
||||
- [ ] **B-3** | Validierungs-Live-Feedback in Edit-Dialogen
|
||||
- [ ] Spezifikation von 📜 Rulebook Expert (Sprint A-5) als Basis nutzen
|
||||
- [ ] `MsValidationWrapper`: `Error.short` inline, `Error.long` als Tooltip
|
||||
- [ ] `isValid` im ViewModel für Speichern-Button-State nutzen
|
||||
- [ ] OEPS-Nummer: Inline-Validierung beim Tippen
|
||||
- [ ] FEI-ID: Inline-Validierung beim Tippen
|
||||
- [ ] Lizenzklasse × Bewerbs-Klasse: Warnung wenn nicht erlaubt
|
||||
- [ ] Altersklasse Pferd: Warnung wenn nicht kompatibel
|
||||
- [ ] Basis: `OetoValidatorsTest.kt`-Grenzfälle als Akzeptanzkriterien
|
||||
|
||||
- [ ] **B-4** | Kassa-Screen: Veranstaltungs-Kassa implementieren
|
||||
- [ ] **B-4** | Kassa-Screen: Veranstaltungs-Kassa
|
||||
- [ ] Gesamt-Saldo-Ansicht (Salden aus allen Turnieren der Veranstaltung)
|
||||
- [ ] Turnier-übergreifender Zahlvorgang (eine Zahlung, mehrere Rechnungen)
|
||||
- [ ] Rechnungsvorschau je Turnier
|
||||
|
||||
---
|
||||
|
||||
## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
|
||||
## 🟠 Sprint C — Priorität 2 (nächste Woche)
|
||||
|
||||
- [ ] **C-1** | Mock-Store (`StoreV2`) vollständig ablösen
|
||||
- [ ] **C-1** | `StoreV2` vollständig ablösen
|
||||
- [ ] Alle verbleibenden `StoreV2`-Referenzen durch echte Repositories ersetzen
|
||||
- [ ] `StoreV2` nach vollständiger Ablösung entfernen oder als `@Deprecated` markieren
|
||||
- [ ] `StoreV2` entfernen nach vollständiger Migration
|
||||
|
||||
- [ ] **C-2** | LAN-Sync-UI vorbereiten (nach ADR von Architect)
|
||||
- [ ] Verbindungsstatus-Anzeige (Online/Offline/LAN)
|
||||
- [ ] Sync-Trigger manuell und automatisch
|
||||
- [ ] **C-2** | VeranstalterNeu: Vereinssuche & Daten-Übernahme
|
||||
- [ ] Vereins-Suche implementieren (Suche, Auswahl, Mapping)
|
||||
- [ ] Validierung und Fehleranzeigen
|
||||
|
||||
> ⏸️ **USB-Stick Fallback (Export/Import UI)** — Separate Besprechung zu einem späteren Zeitpunkt
|
||||
- [ ] **C-3** | LAN-Sync-UI vorbereiten (ADR-0022 ✅ freigegeben)
|
||||
- [ ] `SyncEvent`-Datenmodell aus `core`-Modul einbinden (KMP-shared)
|
||||
- [ ] `originNodeId`-Generierung und -Persistierung beim App-Start
|
||||
- [ ] WebSocket-Client auf Richter-Turm-Desk (Ktor-Client/KMP): HELLO/SYNC_PUSH/SYNC_ACK
|
||||
- [ ] Geräte-Discovery-UI (gefundene Geräte im LAN via mDNS anzeigen)
|
||||
- [ ] Sync-Status-Indicator in der Hauptnavigation (verbunden / getrennt / ausstehende Events)
|
||||
- [ ] Offline-Indikator: ausstehende lokale Events sichtbar machen
|
||||
- [ ] Domänen-Mastership beachten: Richter-Turm schreibt nur Bewertungen/Ergebnisse
|
||||
|
||||
- [ ] **C-4** | Lint-Bereinigung & Code-Qualität
|
||||
- [ ] Ungenutzte Imports/Parameter entfernen
|
||||
- [ ] `Long → Duration`-Konvertierungen modernisieren
|
||||
- [ ] Redundante Not-null-Calls vereinfachen
|
||||
|
||||
> ⏸️ **USB-Stick Fallback (Export/Import UI)** — Separate Besprechung (Sprint B/C)
|
||||
|
||||
---
|
||||
|
||||
## 📌 Abhängigkeiten
|
||||
|
||||
| Warte auf | Von wem |
|
||||
|----------------------------------|--------------------|
|
||||
| Domänen-Modell final (Abteilung) | 🏗️ Architect |
|
||||
| CRUD-Endpunkte | 👷 Backend |
|
||||
| Validierungs-Spezifikation | 📜 Rulebook Expert |
|
||||
| Wireframes Edit-Formulare | 🖌️ UI/UX Designer |
|
||||
| Warte auf | Von wem | Betrifft |
|
||||
|----------------------------------------|-------------------|----------------------------|
|
||||
| Reiter/Pferde/Vereine/Funktionäre APIs | 👷 Backend B-1 | B-2 Repository-Verdrahtung |
|
||||
| Rulebook Validierungs-Spezifikation | 📜 Rulebook B-2 | B-3 Live-Validierung |
|
||||
| Kassa-Service API | 👷 Backend B-2 | B-4 Kassa-Screen |
|
||||
| ~~ADR-0022 LAN-Sync~~ | ✅ Erledigt | C-3 Sync-UI freigegeben |
|
||||
| Wireframes Edit-Dialoge / Kassa | 🖌️ UI/UX B-1/B-3 | B-3, B-4 Implementierung |
|
||||
|
||||
| Meine Aufgabe | Ermöglicht wem |
|
||||
|--------------------------|-----------------------------------------------|
|
||||
| ViewModel-Referenz (A-1) | Alle anderen ViewModels folgen diesem Muster |
|
||||
| Ktor-Repositories (B-2) | Ablösung von StoreV2, echte Daten im Frontend |
|
||||
---
|
||||
|
||||
## 💡 Empfehlungen (nach Priorität)
|
||||
|
||||
1. **B-2 Repository-Verdrahtung** — Bewerb/Abteilung-Repos und StoreV2-Ablösung sind der kritische Pfad für echte Daten
|
||||
im Frontend.
|
||||
2. **B-3 Live-Validierung** — Rulebook hat Spezifikation übergeben (Sprint B-1 ✅); Frontend kann sofort mit
|
||||
`OetoValidators` loslegen.
|
||||
3. **C-2 VeranstalterNeu** — Offener Punkt aus Session 02.04; Vereinssuche fehlt noch für vollständigen Onboarding-Flow.
|
||||
|
||||
@@ -1,89 +1,94 @@
|
||||
# 🧐 [QA Specialist] — Schritt-für-Schritt Roadmap
|
||||
# 🧐 [QA Specialist] — Zwischenstand & Roadmap
|
||||
|
||||
> **Stand:** 2. April 2026
|
||||
> **Rolle:** Test-Strategie, Edge-Cases, Regressions-Tests, Qualitätssicherung
|
||||
> **Stand:** 3. April 2026
|
||||
> **Rolle:** Test-Strategie, Edge-Cases, Integrationstests, Regressionssicherung
|
||||
|
||||
---
|
||||
|
||||
## 🔴 Sprint A — Sofort (diese Woche)
|
||||
## ✅ Erledigte Sprints
|
||||
|
||||
- [x] **A-1** | Test-Strategie für Desktop-App definieren — siehe „QA Test-Strategie — Compose Desktop App“
|
||||
- [x] Testpyramide für Compose Desktop festlegen (Unit / Integration / UI-Tests)
|
||||
- [x] Tooling entscheiden: `kotlin.test`, Compose UI Test, Mockk
|
||||
- [x] Test-Konventionen dokumentieren (Namensschema, Ordnerstruktur, Arrange-Act-Assert)
|
||||
- [x] Dokument in `docs/06_Frontend/` oder `docs/07_Infrastructure/` ablegen
|
||||
- 📄 Dokument: [`docs/06_Frontend/Teststrategie_Desktop.md`](../../06_Frontend/Teststrategie_Desktop.md)
|
||||
### Sprint A — Abgeschlossen
|
||||
|
||||
- [x] **A-1** | Test-Strategie für Desktop-App definiert
|
||||
- [x] Testpyramide für Compose Desktop festgelegt (Unit / Integration / UI-Tests)
|
||||
- [x] Tooling entschieden: `kotlin.test`, Compose UI Test, Mockk
|
||||
- [x] Test-Konventionen dokumentiert (Namensschema, Ordnerstruktur, Arrange-Act-Assert)
|
||||
- [x] `IdempotencyPluginTest` stabilisiert (Unit-Test GRÜN)
|
||||
- [x] `OetoValidatorsTest.kt` als Basis für Grenzfall-Abdeckung etabliert
|
||||
|
||||
---
|
||||
|
||||
## 🟠 Sprint B — Kurzfristig (nächste Woche)
|
||||
## 🔴 Sprint B — Offen (höchste Priorität)
|
||||
|
||||
- [ ] **B-1** | Test-Suite: V2-Navigation und Back-Stack
|
||||
- [ ] Navigations-Flows für alle V2-Screens abdecken (vorwärts + zurück)
|
||||
- [ ] Back-Stack-Verhalten testen (korrekter Zustand nach Zurück-Navigation)
|
||||
- [ ] Deep-Link / direkter Screen-Aufruf testen (falls implementiert)
|
||||
- [ ] **B-1** | Test-Suite: Navigation & Back-Stack (V2/V3)
|
||||
- [ ] Navigations-Flows für alle Screens (vorwärts + zurück)
|
||||
- [ ] Back-Stack-Verhalten nach Zurück-Navigation (korrekter Zustand)
|
||||
- [ ] SingleTop-Tabs: kein doppelter Stack-Eintrag bei Tab-Wechsel
|
||||
- [ ] Logout poppt MainShell komplett (keine Screens im Back-Stack)
|
||||
|
||||
- [ ] **B-2** | Test-Suite: Onboarding-Wizard Edge-Cases
|
||||
- [ ] Leere Pflichtfelder → Button bleibt deaktiviert
|
||||
- [ ] Schnelles wiederholtes Klicken auf „Weiter" / „Speichern" → kein doppelter Submit
|
||||
- [ ] Leere Pflichtfelder → Speichern-Button bleibt deaktiviert
|
||||
- [ ] Schnelles Doppelklick auf „Weiter" / „Speichern" → kein doppelter Submit
|
||||
- [ ] Abbrechen mitten im Wizard → kein inkonsistenter Zustand
|
||||
- [ ] Ungültige Eingaben (z.B. falsches OEPS-Nummern-Format) → Fehlermeldung sichtbar
|
||||
- [ ] Zurück-Navigation: Gerätename und Sicherheitsschlüssel bleiben erhalten (`rememberSaveable`)
|
||||
- [ ] Ungültige OEPS-Nummer → Fehlermeldung sichtbar, Submit gesperrt
|
||||
|
||||
- [ ] **B-3** | Test-Suite: Abteilungs-Logik
|
||||
- [ ] CSN-C-NEU Bewerb ≤95cm: Pflicht-Teilung `ohne Lizenz` / `mit Lizenz` wird erzwungen
|
||||
- [ ] CSN-C-NEU Bewerb ≥100cm: Pflicht-Teilung `R1` / `R2+` wird erzwungen
|
||||
- [ ] Organisatorische Abteilung: Gesamtrangliste wird korrekt zusammengeführt
|
||||
- [ ] Separate Siegerehrung: Abteilungen werden nicht zusammengeführt
|
||||
- [ ] CSN-C-NEU ≤95cm: Pflicht-Teilung `ohne Lizenz` / `mit Lizenz` wird vorgeschlagen
|
||||
- [ ] CSN-C-NEU ≥100cm: Pflicht-Teilung `R1` / `R2+` wird vorgeschlagen
|
||||
- [ ] `ORGANISATORISCH`: Gesamtrangliste korrekt zusammengeführt
|
||||
- [ ] `SEPARATE_SIEGEREHRUNG`: Abteilungen werden nicht zusammengeführt
|
||||
- [ ] Basis: `OetoValidatorsTest.kt`-Grenzfälle aus Rulebook B-1
|
||||
|
||||
- [ ] **B-4** | Test-Suite: ViewModel-Verhalten (nach Frontend Sprint A)
|
||||
- [ ] State-Initialisierung korrekt
|
||||
- [ ] Intent → State-Transition für alle definierten Intents
|
||||
- [ ] Fehler-State bei Backend-Fehler korrekt gesetzt
|
||||
- [ ] Loading-State während asynchroner Operationen
|
||||
- [ ] **B-4** | Test-Suite: ViewModel-Verhalten
|
||||
- [ ] State-Initialisierung korrekt (Loading-State beim Start)
|
||||
- [ ] Intent → State-Transition für alle Sealed-Class-Intents
|
||||
- [ ] Fehler-State bei simuliertem Backend-Fehler korrekt gesetzt
|
||||
- [ ] Loading-State während asynchroner Operationen (nicht flackern)
|
||||
|
||||
---
|
||||
|
||||
## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
|
||||
## 🟠 Sprint C — Priorität 2 (nächste Woche)
|
||||
|
||||
- [ ] **C-1** | Test-Suite: Mandanten-Isolation
|
||||
- [ ] **C-1** | Test-Suite: Mandanten-Isolation (nach Backend A-1)
|
||||
- [ ] Veranstaltung A kann keine Daten von Veranstaltung B lesen
|
||||
- [ ] Veranstaltung A kann keine Daten in Veranstaltung B schreiben
|
||||
- [ ] Turnier-übergreifender Kassa-Zugriff nur innerhalb derselben Veranstaltung möglich
|
||||
- [ ] Kassa-Zugriff nur innerhalb derselben Veranstaltung möglich
|
||||
- [ ] Basis: Backend E2E-Isolationstest re-enablen (aktuell `@Disabled`)
|
||||
|
||||
- [ ] **C-2** | Test-Suite: Kassa und Zahlvorgang
|
||||
- [ ] Teilnehmer an 2 Turnieren → 1 Zahlvorgang → 2 korrekte separate Rechnungen
|
||||
- [ ] Saldo-Berechnung korrekt (Summe aus beiden Turnier-Kassas)
|
||||
- [ ] Bereits bezahlte Beträge werden nicht doppelt verrechnet
|
||||
|
||||
- [ ] **C-3** | Test-Suite: ÖTO-Validierung (nach Rulebook Sprint A-5)
|
||||
- [ ] **C-3** | Test-Suite: ÖTO-Validierung (nach Rulebook C-1)
|
||||
- [ ] OEPS-Nummer: Gültige und ungültige Formate testen
|
||||
- [ ] FEI-ID: Gültige und ungültige Formate testen
|
||||
- [ ] Lizenzklasse × Bewerbs-Klasse: Alle erlaubten und verbotenen Kombinationen
|
||||
- [ ] Altersklasse Pferd × Bewerb: Grenzfälle (genau im Grenzjahr)
|
||||
- [ ] Altersklasse Pferd × Bewerb: Grenzfälle (genau im Grenzjahr, Stichtag)
|
||||
|
||||
- [ ] **C-4** | Regressions-Test-Suite aufbauen
|
||||
- [ ] **C-4** | Regressions-Test-Suite & CI-Integration
|
||||
- [ ] Kritische User-Flows als automatisierte Tests abdecken
|
||||
- [ ] Tests in CI/CD-Pipeline integrieren (gemeinsam mit 🐧 DevOps)
|
||||
|
||||
---
|
||||
|
||||
## ⏸️ Zurückgestellt
|
||||
|
||||
> ⏸️ **USB-Stick Fallback Tests** — Separate Besprechung zu einem späteren Zeitpunkt
|
||||
> ⏸️ **Nennungs-Workflow End-to-End Test (Web → Backend → Desktop)** — Nach Web-App Besprechung
|
||||
- [ ] `IdempotencyApiIntegrationTest` re-enablen (Port-Binding/Server-Lifecycle-Fix)
|
||||
|
||||
---
|
||||
|
||||
## 📌 Abhängigkeiten
|
||||
|
||||
| Warte auf | Von wem |
|
||||
|------------------------------------|--------------------|
|
||||
| ViewModel-Referenz-Implementierung | 🎨 Frontend |
|
||||
| Validierungs-Spezifikation | 📜 Rulebook Expert |
|
||||
| CI/CD Pipeline (headless) | 🐧 DevOps |
|
||||
| Testdaten-Seeder | 👷 Backend |
|
||||
| Warte auf | Von wem | Betrifft |
|
||||
|------------------------------------|---------------|-----------------------------|
|
||||
| Backend A-1 Rollout + E2E-Test-Fix | 👷 Backend | C-1 Isolations-Tests |
|
||||
| Rulebook C-1 AltersklasseRechner | 📜 Rulebook | C-3 Validierungs-Tests |
|
||||
| Backend B-2 Kassa-Service | 👷 Backend | C-2 Kassa-Tests |
|
||||
| DevOps CI/CD Pipeline | 🐧 DevOps C-1 | C-4 Regressions-Integration |
|
||||
|
||||
| Meine Aufgabe | Ermöglicht wem |
|
||||
|----------------------|-------------------------------------------------|
|
||||
| Test-Strategie (A-1) | 🐧 DevOps: korrekte Pipeline-Konfiguration |
|
||||
| Alle Test-Suites | Alle: Vertrauen in Codequalität und Korrektheit |
|
||||
---
|
||||
|
||||
## 💡 Empfehlungen (nach Priorität)
|
||||
|
||||
1. **B-2 Onboarding-Tests** — Zurück-Navigation mit `rememberSaveable` zeigte früher Inkonsistenzen;
|
||||
Regressionssicherung ist dringend.
|
||||
2. **B-3 Abteilungs-Tests** — Die CSN-C-NEU Pflicht-Teilungslogik ist fachlich kritisch; Grenzfälle aus
|
||||
`OetoValidatorsTest.kt` direkt wiederverwenden.
|
||||
3. **C-1 Mandanten-Isolation** — Sicherheitskritisch; sobald Backend A-1 Rollout abgeschlossen, sofort testen.
|
||||
|
||||
@@ -1,101 +1,81 @@
|
||||
# 📜 [ÖTO/FEI Rulebook Expert] — Schritt-für-Schritt Roadmap
|
||||
# 📜 [ÖTO/FEI Rulebook Expert] — Zwischenstand & Roadmap
|
||||
|
||||
> **Stand:** 3. April 2026
|
||||
> **Rolle:** Regelwerks-Wächter, Validierungs-Spezialist, ÖTO/FEI Compliance
|
||||
> **Rolle:** Regelwerks-Wächter, Validierungs-Spezialist, Compliance (ÖTO, FEI)
|
||||
|
||||
---
|
||||
|
||||
## 🔴 Sprint A — Sofort (diese Woche)
|
||||
## ✅ Erledigte Sprints
|
||||
|
||||
- [x] **A-1** | Validierungsregeln schriftlich spezifizieren — Grundlage für alle anderen Teams
|
||||
- [x] **OEPS-Mitgliedsnummer**
|
||||
- [x] Gültiges Format definieren (Länge, erlaubte Zeichen, Präfixe)
|
||||
- [x] Ungültige Beispiele dokumentieren
|
||||
- Ergebnis: siehe `docs/03_Domain/02_Reference/Validierungsregeln.md` Abschnitt „OEPS‑Mitgliedsnummer“
|
||||
- [x] **FEI-ID**
|
||||
- [x] Gültiges Format definieren (numerisch 7–8 stellig + Legacy‑Code `NNNAA NN`)
|
||||
- [x] Pflichtregel national/international festhalten (Turnierkategorie‑abhängig)
|
||||
- [x] Ungültige Beispiele dokumentieren
|
||||
- Ergebnis: siehe `docs/03_Domain/02_Reference/Validierungsregeln.md` Abschnitt „FEI‑ID“
|
||||
- Backend‑Lookup: `GET /api/fei/resolve/{id}` (Masterdata‑SCS), Mapping‑Quelle `data/fei-id-mapping.json` — dokumentiert in Validierungsregeln 2.9
|
||||
- [x] **Lizenzklassen (R1–R4, RD1–RD3, LZF)**
|
||||
- [x] Vollständige Liste aller gültigen Lizenzklassen
|
||||
- [x] Erste Lizenz‑Zuordnungstabellen (Springen + Dressur) als DRAFT mit Paragraphen‑Platzhaltern
|
||||
- Ergebnis: siehe `docs/03_Domain/02_Reference/Validierungsregeln.md` Abschnitt „Lizenzklassen“
|
||||
- [x] **Altersklassen Pferd**
|
||||
- [x] Mindestalter je Disziplin/Klasse als DRAFT‑Tabellen (ÖTO/FEI) ergänzt
|
||||
- [x] Berechnungsregel: Stichtag 1. Jänner des Geburtsjahres
|
||||
- Ergebnis: siehe `docs/03_Domain/02_Reference/Validierungsregeln.md` Abschnitt „Altersklassen Pferd“
|
||||
- [x] Ergebnis als Dokument `docs/03_Domain/02_Reference/Validierungsregeln.md` ablegen (Status: DRAFT v0.3)
|
||||
### Sprint A — Abgeschlossen
|
||||
|
||||
- [x] **A-2** | Abteilungs-Zwangsteilungsregeln vollständig spezifizieren
|
||||
- [x] CSN-C-NEU: Bewerb ≤95cm → `ohne Lizenz` | `mit Lizenz` (§ 231 ÖTO, Platzhalter) — spezifiziert
|
||||
- [x] CSN-C-NEU: Bewerb ≥100cm → `R1` | `R2 und höher` (§ 231 ÖTO, Platzhalter) — spezifiziert
|
||||
- [x] Weitere Pflicht-Teilungsregeln geprüft: CDN, CCN — derzeit keine generische Zwangsteilung wie CSN-C-NEU identifiziert (Platzhalter‑Paragraphen nachtragen)
|
||||
- [x] Ergebnis dokumentiert in `docs/03_Domain/02_Reference/TURNIER_KLASSEN.md`
|
||||
- [x] Paragraphen‑Pins ergänzt (Springen § 231, Dressur § 103, CCN Kap. §§3xx) und einheitliche Label‑Konventionen definiert ("ohne Lizenz", "mit Lizenz", "R2 und höher"; Keys: `LZF_ONLY`, `R1_PLUS`, `R1_ONLY`, `R2_PLUS`).
|
||||
- [x] Optionale Jugend-/Jahrgangsteilungen als Regel‑Modell (Regulation‑as‑Data) ergänzt, keine systemweite Pflicht.
|
||||
- [x] **A-1** | Validierungs-Spezifikation erstellen (v0.3 DRAFT)
|
||||
- [x] Paragraphen-Pins ergänzt (Springen § 231, Dressur § 103, CCN §§ 3xx)
|
||||
- [x] Einheitliche Label-Konventionen: `ohne Lizenz`, `mit Lizenz`, `R2 und höher`; Keys: `LZF_ONLY`, `R1_PLUS`,
|
||||
`R1_ONLY`, `R2_PLUS`
|
||||
- [x] Optionale Jugend-/Jahrgangsteilungen als Regulation-as-Data modelliert (keine systemweite Pflicht)
|
||||
- [x] Abteilungs-Trennungs-Schwellenwerte dokumentiert →
|
||||
`docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md`
|
||||
- [x] Warn-Logik-Spezifikation →
|
||||
`docs/03_Domain/02_Reference/OETO_Regelwerk/Warn-Logik-Spezifikation-competition-context.md`
|
||||
- [x] CVN (Voltigieren): § 39 Abs. 2 als Fallback; eigene OEPS-CVN-Regeln gelten
|
||||
- [x] CAN (Fahren): § 39 Abs. 2 als Fallback; § 850 Abs. 9 für F1+ Fahrertreffen
|
||||
- [x] `OetoValidators` (KMP) implementiert; `OetoValidatorsTest.kt` grün
|
||||
|
||||
---
|
||||
|
||||
## 🟠 Sprint B — Kurzfristig (nächste Woche)
|
||||
### Sprint B (Teilweise) — Abgeschlossen
|
||||
|
||||
- [x] **B-1** | Validierungs-Implementierung Frontend begleiten
|
||||
- [x] Spezifikation aus Sprint A-1 (v0.3 DRAFT) an 🎨 Frontend übergeben
|
||||
- [x] Implementierung prüfen: Entspricht die Live-Validierung den Regelwerks-Anforderungen?
|
||||
- Ergebnis: `OetoValidators.kt` in `frontend/core/domain` implementiert (OEPS, FEI-ID, Lizenzklasse, Pferd-Alter)
|
||||
- `ReiterProfilViewModel` + `PferdProfilViewModel` mit Live-Validierung (typisierte `ValidationResult`) erweitert
|
||||
- Mock-Daten in `Stores.kt` + `NennungModels.kt` auf regelkonforme Formate korrigiert (OEPS, Lizenzklassen)
|
||||
- [x] Fehlermeldungs-Texte auf Korrektheit und Verständlichkeit prüfen
|
||||
- Ergebnis: Alle Fehlertexte zweistufig (`short` für Inline-Hint, `long` für Tooltip/Dialog), regelwerkskonform
|
||||
- 30 Unit-Tests in `OetoValidatorsTest.kt` — alle grün (BUILD SUCCESSFUL)
|
||||
- [x] Spezifikation v0.3 DRAFT an 🎨 Frontend übergeben
|
||||
- [x] Implementierung geprüft: Live-Validierung entspricht Regelwerks-Anforderungen
|
||||
- [x] Fehlermeldungs-Texte auf Korrektheit und Verständlichkeit geprüft
|
||||
- [x] Session-Log → `docs/99_Journal/2026-04-03_Rulebook_B1_Validierung_Frontend.md`
|
||||
|
||||
---
|
||||
|
||||
## 🔴 Sprint B — Offen (höchste Priorität)
|
||||
|
||||
- [ ] **B-2** | Validierungs-Implementierung Backend begleiten
|
||||
- [x] FEI Legacy→Numeric Resolver implementiert (`/api/fei/resolve/{id}`) — erste Version in Masterdata‑SCS
|
||||
- [ ] Spezifikation aus Sprint A-1 an 👷 Backend übergeben (Lizenz-/Altersmatrix als Regulation‑as‑Data)
|
||||
- [x] FEI Legacy→Numeric Resolver implementiert (`/api/fei/resolve/{id}`) — erste Version in Masterdata-SCS
|
||||
- [ ] Lizenz-/Altersmatrix als Regulation-as-Data an 👷 Backend übergeben
|
||||
- [ ] Serverseitige Validierung prüfen: Werden alle Regeln korrekt durchgesetzt?
|
||||
- [ ] Grenzfälle definieren und an 🧐 QA weitergeben
|
||||
|
||||
- [ ] **B-3** | Bewerbs-Typen und Bewertungslogik dokumentieren
|
||||
- [ ] Stilspringen: Berechnungsformel Grundnote − Abzüge dokumentieren (§ 204 ÖTO)
|
||||
- [ ] Dressurreiterprüfung: Bewertungskriterien dokumentieren (§ 103 ÖTO)
|
||||
- [ ] Reihungsregeln bei Punktgleichheit dokumentieren
|
||||
- [ ] Ergebnis: `REITER_PRUEFUNGEN.md` aktualisieren / vervollständigen
|
||||
- [ ] Abweichungen Backend ↔ Frontend-Validierung dokumentieren und klären
|
||||
- [ ] Lizenz×Bewerb-Tabellen (Springen + Dressur) von DRAFT auf STABLE anheben (nach Fachfreigabe)
|
||||
|
||||
---
|
||||
|
||||
## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
|
||||
## 🟠 Sprint C — Priorität 2 (nächste Woche)
|
||||
|
||||
- [ ] **C-1** | `AltersklasseRechner` vollständig gegen ÖTO 2026 testen
|
||||
- [ ] Alle Altersklassen-Grenzen aus dem Regelwerk extrahieren
|
||||
- [ ] Testfälle für Grenzjahre definieren (z.B. Pferd born Jan vs. Dez)
|
||||
- [ ] Testfälle an 🧐 QA übergeben
|
||||
- [ ] **C-1** | `AltersklasseRechner` implementieren und testen
|
||||
- [ ] Altersklassen-Berechnung für Pferd (Jahrgang → Kategorie) umsetzen
|
||||
- [ ] Grenzfälle: Pferd im Geburtsjahr, Jahreswechsel, Stichtag-Regeln
|
||||
- [ ] Unit-Tests mit `OetoValidatorsTest.kt`-Grenzfällen als Basis
|
||||
|
||||
- [ ] **C-2** | Funktionärs-Qualifikationen als Enum spezifizieren
|
||||
- [ ] Alle Funktionärs-Typen auflisten (Richter, Parcourschef, Veterinär, etc.)
|
||||
- [ ] Qualifikationsstufen je Typ definieren (z.B. Richter: Regional, National, International)
|
||||
- [ ] Zuordnung: Welche Qualifikation ist für welche Turnierkategorie Pflicht?
|
||||
- [ ] Ergebnis als Enum-Vorlage für 👷 Backend bereitstellen
|
||||
- [ ] **C-2** | Regelwerk-Enums vervollständigen
|
||||
- [ ] Alle Lizenzklassen-Übergänge formal prüfen (R1→R2→R3→R4, LZF-Sonderfall)
|
||||
- [ ] FEI-Kategorien-Mapping auf ÖTO-Lizenzklassen vervollständigen
|
||||
- [ ] Enums in KMP-Modul `core:domain` als SSoT festlegen
|
||||
|
||||
- [ ] **C-3** | ZNS-Export-Compliance prüfen
|
||||
- [ ] ZNS-Dateiformat auf Aktualität (ÖTO 2026) prüfen
|
||||
- [ ] Prüfungsart-Codes (`DR`, `ST`, etc.) im `zns-parser` validieren
|
||||
- [ ] Fehlende oder veraltete Codes identifizieren und dokumentieren
|
||||
|
||||
---
|
||||
|
||||
## ⏸️ Zurückgestellt
|
||||
|
||||
> ⏸️ **Nenn-Formular Validierungsregeln (Lizenz × Klasse × Alter für Web-Formular)** — Nach Web-App Besprechung
|
||||
- [ ] **C-3** | Compliance-Dokumentation: Series-Context vorbereiten
|
||||
- [ ] Regelwerk-Grundlagen für Cups/Serien/Meisterschaften recherchieren
|
||||
- [ ] Anforderungen an konfigurierbare Reglements (Phase 2+) dokumentieren
|
||||
|
||||
---
|
||||
|
||||
## 📌 Abhängigkeiten
|
||||
|
||||
| Meine Aufgabe | Blockiert / Ermöglicht wen |
|
||||
|---------------------------------------|--------------------------------------------------|
|
||||
| Validierungs-Spezifikation (A-1) v0.3 | 👷 Backend: serverseitige Validierung (Blocker) |
|
||||
| Validierungs-Spezifikation (A-1) v0.3 | 🎨 Frontend: Live-Feedback in Dialogen (Blocker) |
|
||||
| Validierungs-Spezifikation (A-1) v0.3 | 🧐 QA: Testfälle für Validierung |
|
||||
| Abteilungs-Zwangsteilungsregeln (A-2) | 👷 Backend: `Bewerb.validate()` (Blocker) |
|
||||
| Funktionärs-Qualifikationen (C-2) | 👷 Backend: Enum-Implementierung |
|
||||
| Meine Aufgabe | Blockiert wen |
|
||||
|-------------------------|---------------------------------------------------|
|
||||
| B-2 Spec an Backend | 👷 Backend: A-3 Sonderregeln, B-3 ÖTO-Validierung |
|
||||
| B-1 ✅ Spec an Frontend | 🎨 Frontend: B-3 Live-Validierung |
|
||||
| C-1 AltersklasseRechner | 🧐 QA: C-3 Validierungs-Tests |
|
||||
|
||||
---
|
||||
|
||||
## 💡 Empfehlungen (nach Priorität)
|
||||
|
||||
1. **B-2 Backend-Übergabe** — Lizenz-/Altersmatrix als Regulation-as-Data an Backend übergeben; Backend wartet auf diese
|
||||
Spezifikation für A-3 und B-3.
|
||||
2. **Lizenz×Bewerb DRAFT → STABLE** — Fachfreigabe einholen, damit Backend und Frontend auf stabiler Basis arbeiten
|
||||
können.
|
||||
3. **C-1 AltersklasseRechner** — Grenzfälle (Jahrgang, Stichtag) sind komplex und müssen vor Backend-Implementierung
|
||||
spezifiziert sein.
|
||||
|
||||
@@ -1,214 +1,122 @@
|
||||
# 🗓️ Sprint Execution Order — Entwickler-übergreifende Reihenfolge
|
||||
# 🗂️ Sprint Execution Order — Meldestelle-Biest
|
||||
|
||||
> **Stand:** 2. April 2026
|
||||
> **Autor:** 🏗️ Lead Architect
|
||||
> **Zweck:** Verbindliche, entwickler-übergreifende Ausführungsreihenfolge aller Sprint-Schritte.
|
||||
> Dieses Dokument ist die **Single Source of Truth** für „Wer macht was, in welcher Reihenfolge".
|
||||
> **Stand:** 3. April 2026 | **Phase:** 8 — Bewerbe-Management & Startlisten
|
||||
> **Erstellt von:** 🏗️ Lead Architect
|
||||
> **Strategisches Ziel:** Desktop-MVP mit Event-First-Workflow, Offline-First, ÖTO-Konformität
|
||||
|
||||
---
|
||||
|
||||
## 📐 Legende
|
||||
## 📊 Gesamtfortschritt
|
||||
|
||||
| Symbol | Bedeutung |
|
||||
|--------|----------------------------------------------------------------|
|
||||
| 🔴 | Blocker — muss abgeschlossen sein bevor Folgeschritte beginnen |
|
||||
| 🟡 | Kann parallel gestartet werden, sobald Voraussetzung erfüllt |
|
||||
| 🟢 | Kann sofort und unabhängig gestartet werden |
|
||||
| ⏳ | Wartet auf eine andere Aufgabe |
|
||||
| ✅ | Abgeschlossen |
|
||||
| ⏸️ | Zurückgestellt — separate Besprechung |
|
||||
| `→` | „ermöglicht" / „blockiert" |
|
||||
| Agent | Sprint A | Sprint B | Sprint C | Nächste Aktion |
|
||||
|---------------|------------------|----------------------|-------------------|---------------------------------------------|
|
||||
| 🏗️ Architect | ✅ Abgeschlossen | 🔴 B-1 offen | ⬜ Nicht gestartet | ADR-0022 LAN-Sync schreiben |
|
||||
| 👷 Backend | ⚠️ A-1/A-3 offen | 🔴 B-1 teilweise | ⬜ Nicht gestartet | A-1 Rollout + Reiter/Pferde-APIs |
|
||||
| 🎨 Frontend | ✅ Abgeschlossen | 🔴 B-2/B-3/B-4 offen | ⬜ Nicht gestartet | B-2 BewerbRepository + StoreV2-Ablösung |
|
||||
| 📜 Rulebook | ✅ Abgeschlossen | 🔴 B-2 offen | ⬜ Nicht gestartet | B-2 Spec an Backend übergeben |
|
||||
| 🐧 DevOps | ✅ Abgeschlossen | ✅ Abgeschlossen | 🔴 C-1 offen | C-1 Desktop-Packaging (.msi/.deb) |
|
||||
| 🧐 QA | ✅ Abgeschlossen | 🔴 B-1..B-4 offen | ⬜ Nicht gestartet | B-2 Onboarding-Tests + B-3 Abteilungs-Tests |
|
||||
| 🖌️ UI/UX | ✅ Abgeschlossen | 🔴 B-1/B-4 offen | ⬜ Nicht gestartet | B-1 Finale Entscheidung Editier-Formulare |
|
||||
| 🧹 Curator | ✅ Abgeschlossen | 🔴 B-1..B-3 offen | ⬜ Nicht gestartet | B-1 Roadmaps pflegen ← *diese Session* |
|
||||
|
||||
---
|
||||
|
||||
## 🔴 PHASE 1 — Fundament legen (Woche 1, Sprint A)
|
||||
## 🔴 SOFORT — Kritischer Pfad (Blocker)
|
||||
|
||||
> **Ziel:** Alle Grundlagen schaffen, auf denen alle anderen aufbauen.
|
||||
> Diese Phase darf nicht übersprungen werden — sie blockiert fast alles andere.
|
||||
Diese Aufgaben blockieren andere Agenten und müssen zuerst erledigt werden:
|
||||
|
||||
### Schritt 1 — Startet sofort, gleichzeitig (Tag 1)
|
||||
|
||||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||||
|-----------|---------------|--------------------------------------------------------------------------------------------|-------------------------------------------------|
|
||||
| 🔴 | 🏗️ Architect | **A-1** ADR-0021 schreiben: Tenant-Resolution-Strategie | → Freischalten von Schritt 2 (Backend A-1) |
|
||||
| 🔴 | 🏗️ Architect | **A-2** Domänen-Modell formal präzisieren (`Veranstaltung → Turnier → Bewerb → Abteilung`) | → Freischalten von Backend A-2 und Frontend A-2 |
|
||||
| 🔴 | 📜 Rulebook | **A-1** Validierungsregeln schriftlich spezifizieren (OEPS, FEI-ID, Lizenz, Alter) | → Freischalten von Backend A-3, Frontend B-3 |
|
||||
| 🔴 | 📜 Rulebook | **A-2** Abteilungs-Zwangsteilungsregeln vollständig spezifizieren (CSN-C-NEU) | → Freischalten von Backend A-3, Frontend A-2 |
|
||||
| 🟢 | 🧐 QA | **A-1** Test-Strategie für Desktop-App definieren (Testpyramide, Tooling, Konventionen) | → Grundlage für alle QA-Schritte |
|
||||
| 🟢 | 🐧 DevOps | **A-1** Docker-Compose-Setup auf aktuellen Stand bringen | → Stabile lokale Dev-Umgebung für alle |
|
||||
| 🟢 | 🧹 Curator | **A-5** Session-Log für heutige Besprechung erstellen | → Nachvollziehbarkeit der Beschlüsse |
|
||||
| Priorität | Agent | Aufgabe | Blockiert |
|
||||
|-----------|---------------|-----------------------------------------------|---------------------------------------------------|
|
||||
| 🔴 P1 | 👷 Backend | A-1: Tenant-Isolation Rollout (alle Services) | 🧐 QA: C-1 Isolations-Tests |
|
||||
| 🔴 P1 | 👷 Backend | B-1: Reiter/Pferde/Vereine/Funktionäre APIs | 🎨 Frontend: B-2 Repository-Verdrahtung |
|
||||
| 🔴 P1 | 📜 Rulebook | B-2: Lizenz-/Altersmatrix Spec an Backend | 👷 Backend: A-3, B-3 ÖTO-Validierung |
|
||||
| 🔴 P1 | 🏗️ Architect | B-1: ADR-0022 LAN-Sync | 🎨 Frontend: C-3; 👷 Backend: C-3; 🐧 DevOps: D-2 |
|
||||
| 🔴 P1 | 🖌️ UI/UX | B-1: Finale Entscheidung Editier-Formulare | 🎨 Frontend: B-3 Live-Validierung |
|
||||
|
||||
---
|
||||
|
||||
### Schritt 2 — Startet sobald Schritt 1 (Architect A-1 + A-2) abgeschlossen ist
|
||||
## 🟠 DIESE WOCHE — Sprint B parallel ausführen
|
||||
|
||||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||||
|-----------|-------------|---------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------|
|
||||
| 🔴 | 👷 Backend | **A-1** Tenant-Isolation im Datenzugriffs-Layer implementieren (basiert auf ADR-0021) | → Sichere Tenant-Grenze; Grundlage für alle weiteren Backend-Schritte |
|
||||
| 🔴 | 👷 Backend | **A-2** Datenbankschema umsetzen: `veranstaltungen`, `turniere`, `bewerbe`, `abteilungen`, `teilnehmer_konten`, `turnier_kassa` | → Freischalten von Backend B-1, B-2 |
|
||||
| 🟡 | 🎨 Frontend | **A-1** ViewModel-Architektur definieren + `VeranstalterViewModel` als Referenz-Implementierung umsetzen (MVVM/UDF) | → Muster für alle anderen ViewModels |
|
||||
| 🟡 | 🧹 Curator | **A-1** `Ubiquitous_Language.md` aktualisieren (nach Domänen-Modell vom Architect) | → Gemeinsames Vokabular für alle Teams |
|
||||
| 🟡 | 🧹 Curator | **A-2** Event-First-Workflow dokumentieren | → Onboarding neuer Entwickler |
|
||||
### 🏗️ Architect
|
||||
|
||||
1. **B-1** ADR-0022 LAN-Sync-Protokoll (Event-Sourcing vs. CRDT vs. Timestamp)
|
||||
|
||||
### 👷 Backend Developer
|
||||
|
||||
1. **A-1** Tenant-Isolation Rollout auf alle Services + E2E-Test re-enablen
|
||||
2. **B-1** Reiter/Pferde/Vereine/Funktionäre CRUD-APIs implementieren
|
||||
3. **A-3** Sonderregeln einarbeiten (nach Rulebook B-2 Übergabe)
|
||||
|
||||
### 🎨 Frontend Expert
|
||||
|
||||
1. **B-2** `BewerbRepository` + `AbteilungRepository` anlegen
|
||||
2. **B-2** Koin Feature-Module binden; Turnier/Bewerb-Endpunkte verdrahten
|
||||
3. **B-3** Live-Validierung mit `OetoValidators` in Edit-Dialogen einbauen
|
||||
|
||||
### 📜 Rulebook Expert
|
||||
|
||||
1. **B-2** Lizenz-/Altersmatrix als Regulation-as-Data an Backend übergeben
|
||||
2. **B-2** Lizenz×Bewerb-Tabellen Fachfreigabe einholen → DRAFT → STABLE
|
||||
|
||||
### 🐧 DevOps Engineer
|
||||
|
||||
1. **C-1** Desktop-Packaging (`.msi` / `.deb`) konfigurieren
|
||||
2. **C-2** Semantic Versioning + Git-Tagging einführen
|
||||
|
||||
### 🧐 QA Specialist
|
||||
|
||||
1. **B-2** Onboarding-Wizard Edge-Case Tests (rememberSaveable Rücknavigation)
|
||||
2. **B-3** Abteilungs-Logik Tests (CSN-C-NEU Pflicht-Teilung)
|
||||
|
||||
### 🖌️ UI/UX Designer
|
||||
|
||||
1. **B-1** Finale Entscheidung Editier-Formulare (Review mit Frontend)
|
||||
2. **B-4** Empty States für alle Listenansichten definieren
|
||||
|
||||
### 🧹 Curator
|
||||
|
||||
1. **B-1** Roadmaps-Verzeichnis aktualisieren ← *diese Session*
|
||||
2. **B-2** `docs/05_Backend/` nach Backend-API-Abschluss aktualisieren
|
||||
|
||||
---
|
||||
|
||||
### Schritt 3 — Startet sobald Schritt 2 (Backend A-2 + Rulebook A-1/A-2) abgeschlossen ist
|
||||
## 🟡 NÄCHSTE WOCHE — Sprint C
|
||||
|
||||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||||
|-----------|-------------|---------------------------------------------------------------------------------------------------|--------------------------------------------|
|
||||
| 🔴 | 👷 Backend | **A-3** Turnierkategorie-Limits validieren (`Turnier.validate()`, `Bewerb.validate()`) | → ÖTO-konforme Dateneingabe gesichert |
|
||||
| 🟡 | 🎨 Frontend | **A-2** Abteilungs-Logik im Bewerb-Dialog (CSN-C-NEU Pflicht-Teilung als Vorschlag + Validierung) | → Korrekte Abteilungsanlage durch Benutzer |
|
||||
| 🟡 | 🧹 Curator | **A-3** Navigation-V2 dokumentieren (Screen-Baum, Back-Stack) | → |
|
||||
| 🟡 | 🧹 Curator | **A-4** Tenant-Konzept dokumentieren (nach ADR-0021) | → |
|
||||
| Agent | Aufgabe |
|
||||
|---------------|------------------------------------------------------------------------|
|
||||
| 🏗️ Architect | C-1 Sync-Konzept; C-2 MASTER_ROADMAP aktualisieren |
|
||||
| 👷 Backend | B-2 Kassa-Service; B-3 ÖTO-Validierung; C-1 Nennungs-Service |
|
||||
| 🎨 Frontend | B-4 Kassa-Screen; C-1 StoreV2 vollständig ablösen; C-2 VeranstalterNeu |
|
||||
| 📜 Rulebook | C-1 AltersklasseRechner; C-2 Regelwerk-Enums |
|
||||
| 🐧 DevOps | C-3 Produktions-Deployment; D-1 Tenant-Backup-Strategie |
|
||||
| 🧐 QA | B-1 Navigation-Tests; B-4 ViewModel-Tests; C-1 Isolations-Tests |
|
||||
| 🖌️ UI/UX | C-1 Wireframes in Compose umsetzen; C-2 Design-System konsolidieren |
|
||||
| 🧹 Curator | C-1 README aktualisieren; C-2 Setup-Guide |
|
||||
|
||||
---
|
||||
|
||||
## 🟠 PHASE 2 — Verbinden & Implementieren (Woche 2, Sprint B)
|
||||
## ⏸️ Zurückgestellte Themen (kein MVP-Blocker)
|
||||
|
||||
> **Ziel:** Frontend und Backend verbinden. Validierungslogik aktiv. Kassa-Service lauffähig.
|
||||
> **Voraussetzung:** Phase 1 vollständig abgeschlossen.
|
||||
|
||||
### Schritt 4 — Startet parallel, sobald Phase 1 abgeschlossen ist
|
||||
|
||||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||||
|-----------|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------|
|
||||
| 🔴 | 👷 Backend | **B-1** CRUD-Endpunkte für alle Stammdaten-Entitäten (`veranstaltungen`, `turniere`, `bewerbe`, `abteilungen`, `reiter`, `pferde`, `vereine`, `funktionaere`) | → Freischalten von Frontend B-2 |
|
||||
| 🟡 | 🎨 Frontend | **B-1** ViewModels für alle V2-Screens umsetzen (`TurnierViewModel`, `BewerbViewModel`, `PferdProfilViewModel`, etc.) | → Echte Datenbindung in allen Screens |
|
||||
| 🟡 | 🖌️ UI/UX | **B-1** Wireframes: Edit-Formulare (AlertDialog vs. dedizierter Screen / Sliding-Panel) | → Grundlage für Frontend-Umsetzung der Formulare |
|
||||
| 🟡 | 🖌️ UI/UX | **B-2** Wireframes: Bewerb + Abteilung anlegen (Abteilungs-Auswahl inkl. Pflicht-Felder) | → |
|
||||
| 🟡 | 🖌️ UI/UX | **B-3** Wireframes: Kassa-Screen (Gesamt-Saldo + Zahlvorgang + Rechnungsvorschau) | → |
|
||||
| 🟡 | 🐧 DevOps | **B-1** CI/CD Pipeline für Compose Desktop Tests headless konfigurieren | → Automatisierte Qualitätssicherung |
|
||||
| 🟡 | 🐧 DevOps | **B-2** Gradle-Build-Optimierungen (Cache, parallele Builds, Wrapper-Update) | → Schnellere Build-Zeiten für alle |
|
||||
| Thema | Zuständig | Wann |
|
||||
|------------------------------|-----------|-----------------------------------|
|
||||
| USB-Stick Fallback (Sync) | 🏗️ + 🐧 | Sprint B/C — separate Besprechung |
|
||||
| Web-App / PWA | 🎨 + 🖌️ | Nach Desktop-MVP |
|
||||
| ZNS Live-Sync (Echtzeit) | 👷 + 🎨 | Nach Stammdaten-Stabilisierung |
|
||||
| Series-Context (Cups/Serien) | Alle | Phase 9 (Phase 2+) |
|
||||
| Mobile (Android/iOS) | 🎨 | Phase 9+ |
|
||||
|
||||
---
|
||||
|
||||
### Schritt 5 — Startet sobald Backend B-1 (CRUD-Endpunkte) abgeschlossen ist
|
||||
## 🔗 Roadmap-Verweise
|
||||
|
||||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||||
|-----------|-------------|--------------------------------------------------------------------------------------------|--------------------------------------------------------------|
|
||||
| 🔴 | 🎨 Frontend | **B-2** Ktor-Clients + Repositories für Backend-Anbindung; `StoreV2` schrittweise ersetzen | → Echte Daten statt Mock; Freischalten von Frontend B-3, B-4 |
|
||||
| 🟡 | 🧹 Curator | **B-1** Roadmaps-Verzeichnis pflegen (abgeschlossene Tasks markieren) | → Transparenz über Fortschritt |
|
||||
| 🟡 | 🧹 Curator | **B-2** `docs/05_Backend/` aktualisieren (neues DB-Schema, API-Endpunkte-Übersicht) | → |
|
||||
|
||||
---
|
||||
|
||||
### Schritt 6 — Startet sobald Schritt 5 (Frontend B-2) abgeschlossen ist UND Rulebook A-1 vorliegt
|
||||
|
||||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||||
|-----------|-------------|----------------------------------------------------------------------------------------------------------------|------------------------------------------------|
|
||||
| 🔴 | 👷 Backend | **B-3** ÖTO-Validierung serverseitig absichern (OEPS, FEI-ID, Lizenz, Altersklassen, Abteilungs-Zwangsteilung) | → Daten-Integrität auf Server-Ebene gesichert |
|
||||
| 🟡 | 🎨 Frontend | **B-3** Validierungs-Live-Feedback in Edit-Dialogen (OEPS, FEI-ID, Lizenz × Klasse, Altersklasse) | → Benutzer sieht Fehler sofort |
|
||||
| 🟡 | 📜 Rulebook | **B-1** Validierungs-Implementierung Frontend begleiten + prüfen | → Qualitätssicherung der Regelwerks-Compliance |
|
||||
| 🟡 | 📜 Rulebook | **B-2** Validierungs-Implementierung Backend begleiten + prüfen | → |
|
||||
| 🟡 | 🧐 QA | **B-1** Test-Suite: V2-Navigation und Back-Stack | → |
|
||||
| 🟡 | 🧐 QA | **B-2** Test-Suite: Onboarding-Wizard Edge-Cases | → |
|
||||
| 🟡 | 🧐 QA | **B-3** Test-Suite: Abteilungs-Logik (CSN-C-NEU Pflicht-Teilungen) | → |
|
||||
|
||||
---
|
||||
|
||||
### Schritt 7 — Startet sobald Backend B-1 + B-3 abgeschlossen sind
|
||||
|
||||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||||
|-----------|-------------|-----------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
|
||||
| 🔴 | 👷 Backend | **B-2** Kassa-Service implementieren (`TeilnehmerKonto`, `Zahlvorgang`, Rechnungs-Generierung je Turnier) | → Freischalten von Frontend B-4 |
|
||||
| 🟡 | 👷 Backend | **B-4** Nennungs-Service (Grundstruktur: Eingang, Status-Workflow, Postfach-Endpunkt) | → Freischalten von Frontend-Nennungs-Postfach (Sprint C) |
|
||||
| 🟡 | 🧐 QA | **B-4** Test-Suite: ViewModel-Verhalten (State-Initialisierung, Intent → Transition, Error-State) | → |
|
||||
| 🟡 | 📜 Rulebook | **B-3** Bewerbs-Typen und Bewertungslogik dokumentieren (Stilspringen, Dressurreiter, Reihungsregeln) | → |
|
||||
|
||||
---
|
||||
|
||||
### Schritt 8 — Startet sobald Backend B-2 (Kassa-Service) + UI/UX Wireframes abgeschlossen sind
|
||||
|
||||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||||
|-----------|-------------|---------------------------------------------------------------------------------------------------------------|-----------------------------------------------|
|
||||
| 🟡 | 🎨 Frontend | **B-4** Kassa-Screen: Gesamt-Saldo-Ansicht, Zahlvorgang, Rechnungsvorschau je Turnier | → Vollständige Kassa-Funktion für Meldestelle |
|
||||
| 🟡 | 🧹 Curator | **B-3** `docs/06_Frontend/` aktualisieren (ViewModel-Architektur-Muster, Verweis auf `VeranstalterViewModel`) | → |
|
||||
|
||||
---
|
||||
|
||||
## 🟡 PHASE 3 — Ausliefern & Aufräumen (Woche 3–4, Sprint C)
|
||||
|
||||
> **Ziel:** Stabilisieren, testen, ausliefern, dokumentieren.
|
||||
> **Voraussetzung:** Phase 2 vollständig abgeschlossen.
|
||||
|
||||
### Schritt 9 — Startet parallel sobald Phase 2 abgeschlossen ist
|
||||
|
||||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||||
|-----------|-------------|----------------------------------------------------------------------------------------------------------|--------------------------------------------|
|
||||
| 🟡 | 🎨 Frontend | **C-1** `StoreV2` vollständig ablösen und entfernen / als `@Deprecated` markieren | → Saubere Architektur, kein Tech-Debt mehr |
|
||||
| 🟡 | 👷 Backend | **C-1** Testdaten-Seeder implementieren (Neumarkt-Szenario: 2 Turniere, Bewerbe, Abteilungen, Nennungen) | → Reproduzierbare Testbasis für QA |
|
||||
| 🟡 | 🧐 QA | **C-1** Test-Suite: Mandanten-Isolation (Veranstaltung A kann keine Daten von B lesen/schreiben) | → |
|
||||
| 🟡 | 🧐 QA | **C-2** Test-Suite: Kassa und Zahlvorgang (1 Zahlung → 2 korrekte Rechnungen) | → |
|
||||
| 🟡 | 📜 Rulebook | **C-1** `AltersklasseRechner` vollständig gegen ÖTO 2026 testen; Testfälle an QA übergeben | → |
|
||||
| 🟡 | 🐧 DevOps | **C-1** Desktop-App Packaging (`.msi`, `.deb`, `.dmg`) | → Auslieferbare Desktop-App |
|
||||
| 🟡 | 🖌️ UI/UX | **C-1** Wireframes aus Sprint B implementieren (Edit-Formulare + Sliding-Panel) | → |
|
||||
| 🟡 | 🖌️ UI/UX | **C-2** Empty States für alle Listenansichten designen und umsetzen | → |
|
||||
| 🟡 | 🧹 Curator | **C-1** `README.md` aktualisieren (Desktop-App Fokus, Schnellstart, V1-Referenzen entfernen) | → |
|
||||
| 🟡 | 🧹 Curator | **C-2** Setup-Guide aktualisieren (`docs/02_Guides/`) | → |
|
||||
|
||||
---
|
||||
|
||||
### Schritt 10 — Startet sobald Schritt 9 abgeschlossen ist
|
||||
|
||||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||||
|-----------|-------------|---------------------------------------------------------------------------------------------------------|-----------------------|
|
||||
| 🟡 | 🧐 QA | **C-3** Test-Suite: ÖTO-Validierung (alle OEPS/FEI-ID/Lizenz-Kombinationen) | → |
|
||||
| 🟡 | 👷 Backend | **C-2** Statistik-Endpunkte (`GET /turniere/{id}/statistiken`, `GET /veranstaltungen/{id}/statistiken`) | → |
|
||||
| 🟡 | 📜 Rulebook | **C-2** Funktionärs-Qualifikationen auf Enum umstellen | → |
|
||||
| 🟡 | 🐧 DevOps | **C-2** Semantic Versioning einführen + Release-Tagging in CI/CD | → |
|
||||
| 🟡 | 🧹 Curator | **C-3** Unterordner-Struktur in `docs/` einführen (nach Abstimmung mit Architect) | → |
|
||||
| 🟡 | 🧹 Curator | **C-4** V1-Code-Bereinigung koordinieren (gemeinsam mit Frontend + Backend) | → |
|
||||
|
||||
---
|
||||
|
||||
### Schritt 11 — Abschluss Sprint C (nach Schritt 10)
|
||||
|
||||
| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht |
|
||||
|-----------|---------------|--------------------------------------------------------------------------------------------------------|-------------------------------------|
|
||||
| 🟡 | 🏗️ Architect | **C-1** Synchronisations-Protokoll-Konzeption starten (Offline-First Desktop ↔ Backend) | → Grundlage für LAN-Sync (Sprint D) |
|
||||
| 🟡 | 🏗️ Architect | **C-2** `MASTER_ROADMAP.md` aktualisieren (Desktop-Fokus, Tenant-Isolation, Offline-Sync-Meilensteine) | → Aktueller Überblick für alle |
|
||||
| 🟡 | 🐧 DevOps | **C-3** Produktions-Deployment vorbereiten | → |
|
||||
| 🟡 | 🧹 Curator | **C-5** Reports-Verzeichnis pflegen (Kurzberichte Sprint A, B, C einsammeln + archivieren) | → |
|
||||
|
||||
---
|
||||
|
||||
## ⏸️ Zurückgestellte Themen (eigene Besprechungen)
|
||||
|
||||
| Thema | Status | Notiz |
|
||||
|----------------------------------------------------------|-------------------------|------------------------------------------------------------------|
|
||||
| USB-Stick Fallback (Export/Import bei LAN-Ausfall) | ⏸️ Separate Besprechung | Konzept liegt vor (JSON + Versionierung + Checksum) |
|
||||
| Web-App Präsentation (Veranstaltung → Turnier → Inhalte) | ⏸️ Separate Besprechung | Hierarchie noch nicht final besprochen |
|
||||
| Nenn-System (Web-Formular, dynamisch aus Turnier-Daten) | ⏸️ Separate Besprechung | Konzept liegt vor, Priorisierung nach Desktop-App-Fertigstellung |
|
||||
| Live-Ergebnisse Web-App (SSE/WebSocket) | ⏸️ Separate Besprechung | Konzept liegt vor, nach Nenn-System |
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Kritischer Pfad (Blocker-Kette)
|
||||
|
||||
Das ist die längste abhängige Kette — Verzögerung hier verzögert alles:
|
||||
|
||||
```
|
||||
🏗️ ADR-0021
|
||||
└─→ 👷 Tenant-Isolation (Backend A-1)
|
||||
└─→ 👷 DB-Schema (Backend A-2)
|
||||
└─→ 👷 CRUD-Endpunkte (Backend B-1)
|
||||
└─→ 🎨 Ktor-Repositories (Frontend B-2)
|
||||
└─→ 🎨 Live-Validierung (Frontend B-3)
|
||||
└─→ 🎨 Kassa-Screen (Frontend B-4)
|
||||
└─→ 🧐 Kassa-Tests (QA C-2)
|
||||
|
||||
📜 Validierungs-Spezifikation (Rulebook A-1)
|
||||
└─→ 👷 ÖTO-Validierung Backend (Backend B-3)
|
||||
└─→ 🎨 Live-Validierung Frontend (Frontend B-3)
|
||||
└─→ 🧐 Validierungs-Tests (QA C-3)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📊 Gesamtübersicht: Wer ist wann aktiv?
|
||||
|
||||
| Phase / Woche | 🏗️ Architect | 👷 Backend | 🎨 Frontend | 📜 Rulebook | 🐧 DevOps | 🧐 QA | 🖌️ UI/UX | 🧹 Curator |
|
||||
|--------------------------|------------------------------|---------------------------------------|----------------------------------------------------------|--------------------------------------|-----------------------|------------------------------------|-----------------------------------|-------------------------------------|
|
||||
| **Woche 1 (Sprint A)** | ADR-0021, Domänen-Modell | ⏳ (wartet auf ADR) | ViewModel-Referenz | Validierungsregeln, Abteilungsregeln | Docker-Setup | Test-Strategie | (Start Wireframes) | Session-Log, Ubiquitous_Language |
|
||||
| **Woche 2 (Sprint B)** | LAN-Sync ADR | CRUD-APIs, Kassa-Service, Validierung | ViewModels, Repositories, Live-Validierung, Kassa-Screen | Implementierung begleiten | CI/CD, Gradle | Navigation-Tests, Abteilungs-Tests | Wireframes | Docs aktualisieren |
|
||||
| **Woche 3–4 (Sprint C)** | Sync-Konzept, Roadmap-Update | Seeder, Statistiken | StoreV2-Ablösung | AltersklasseRechner, Enums | Packaging, Versioning | Isolation-Tests, Kassa-Tests | Empty States, Wireframes umsetzen | README, Setup-Guide, V1-Bereinigung |
|
||||
| Agent | Roadmap |
|
||||
|---------------|--------------------------------------------------------------|
|
||||
| 🏗️ Architect | [Architect_Roadmap.md](./Architect_Roadmap.md) |
|
||||
| 👷 Backend | [Backend_Roadmap.md](./Backend_Roadmap.md) |
|
||||
| 🎨 Frontend | [Frontend_Roadmap.md](./Frontend_Roadmap.md) |
|
||||
| 📜 Rulebook | [Rulebook_Roadmap.md](./Rulebook_Roadmap.md) |
|
||||
| 🐧 DevOps | [DevOps_Roadmap.md](./DevOps_Roadmap.md) |
|
||||
| 🧐 QA | [QA_Roadmap.md](./QA_Roadmap.md) |
|
||||
| 🖌️ UI/UX | [UIUX_Roadmap.md](./UIUX_Roadmap.md) |
|
||||
| 🧹 Curator | [Curator_Roadmap.md](./Curator_Roadmap.md) |
|
||||
| 📐 Master | [MASTER_ROADMAP.md](../../01_Architecture/MASTER_ROADMAP.md) |
|
||||
|
||||
@@ -1,148 +1,93 @@
|
||||
# 🖌️ [UI/UX Designer] — Schritt-für-Schritt Roadmap
|
||||
# 🖌️ [UI/UX Designer] — Zwischenstand & Roadmap
|
||||
|
||||
> **Stand:** 2. April 2026
|
||||
> **Rolle:** High-Density Design, Wireframes, Usability, Compose Desktop UX
|
||||
> **Stand:** 3. April 2026
|
||||
> **Rolle:** High-Density Design, Wireframes, Usability, Design-System, Empty States
|
||||
|
||||
---
|
||||
|
||||
## 🔴 Sprint A — Sofort (diese Woche)
|
||||
## ✅ Erledigte Sprints
|
||||
|
||||
- [x] **A-1** | Design-Inventur: Bestehende V2-Screens analysieren
|
||||
- [x] Alle vorhandenen V2-Screens katalogisieren (Screenshots in `docs/ScreenShots/` bzw. `docs/06_Frontend/Screenshots/`)
|
||||
- [x] Inkonsistenzen in Spacing, Typografie und Farbgebung identifizieren
|
||||
- [x] Offene UX-Probleme und fehlende Empty States dokumentieren
|
||||
- [x] Ergebnis als kurze Issue-Liste für Sprint B vorbereiten
|
||||
### Sprint A — Abgeschlossen
|
||||
|
||||
### Ergebnis A-1 — Design-Inventur V2 (Stand V3 abgeglichen)
|
||||
- [x] **A-1** | Design-Inventur: Bestehende V3-Screens analysiert
|
||||
- [x] Alle vorhandenen V3-Screens katalogisiert (Screenshots in `docs/06_Frontend/Screenshots/`)
|
||||
- [x] Inkonsistenzen in Spacing, Typografie und Farbgebung identifiziert
|
||||
- [x] Offene UX-Probleme und fehlende Empty States dokumentiert
|
||||
- [x] Issue-Liste für Sprint B vorbereitet
|
||||
|
||||
Quellen:
|
||||
- V3 Navigation: `docs/06_Frontend/Navigation_V3_Screen-Baum_und_Back-Stack.md`
|
||||
- Archiv/Referenz V2: `docs/_archive/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md`
|
||||
- Screenshots: `docs/06_Frontend/Screenshots/` und `docs/ScreenShots/archive/`
|
||||
### Sprint B (Teilweise) — Wireframes erstellt
|
||||
|
||||
1) Katalog der relevanten V2-Screens (gemappt auf V3-Begriffe)
|
||||
- Veranstaltungen (Liste) — V3: „Veranstaltungen (Tab‑Root)“
|
||||
- Veranstaltung.Detail — V3 gleichlautend
|
||||
- Turnier.Detail — V3 gleichlautend
|
||||
- Belege: `docs/06_Frontend/Screenshots/Turnier-Stammdaten_01_entwurf-01.png`, `.../Turnier-Stammdaten_02_entwurf01.png`
|
||||
- Bewerb.Detail — V3 gleichlautend
|
||||
- Abteilung.Detail — V3 gleichlautend
|
||||
- Startliste innerhalb Abteilung — V3: „Startliste(divisionId)“
|
||||
- Kassa für Turnier — V3: „Kassa.Turnier(tournamentId)“
|
||||
- Kassa für Veranstaltung — V3: „Kassa.Veranstaltung(eventId)“
|
||||
- Status‑Anzeige/Listenkarte — Beleg: `docs/06_Frontend/Screenshots/Veranstaltungen-Status-Anzeige_entwurf-01.png`
|
||||
- Tab‑Root Platzhalter: Reiter, Pferde, Funktionaere, Meisterschaften, Cups (V3 vorhanden, in V2 teils rudimentär)
|
||||
- [x] **B-1 Wireframes** | Editier-Formulare (AlertDialog vs. dedizierter Screen)
|
||||
- [x] Entscheidungsgrundlage erarbeitet: Wann AlertDialog, wann Fullscreen-Edit?
|
||||
- [x] Wireframes für beide Varianten erstellt (Reiter-Edit, Pferd-Edit als Beispiele)
|
||||
- [x] Ergebnis: `docs/06_Frontend/Guidelines/Editier-Formulare_Dialog-vs-Fullscreen_v1.md`
|
||||
- [ ] **Finale Entscheidung dokumentieren und als Design-Richtlinie festschreiben** (Review durch 🎨 Frontend
|
||||
ausstehend)
|
||||
|
||||
2) Gefundene Inkonsistenzen (V2 UI vs. V3 Vorgabe/Figma Vision_03)
|
||||
- Spacing
|
||||
- Uneinheitliche Außenabstände (8/12/16/20 px gemischt). Vorschlag: 8‑pt Grid; Außen 16, Innen 8/12 je Dichte.
|
||||
- Vertikaler Rhythmus bei Karten uneinheitlich (Header ↔ Body ↔ Footer). Vereinheitlichen: 12/8/12.
|
||||
- Typografie
|
||||
- Unterschiedliche Größen/Weights für vergleichbare Überschriftenebenen (z. B. Screen‑Title vs. Section‑Title).
|
||||
- Fehlende definierte Caption/Overline‑Stile für Badges/Status.
|
||||
- Farben
|
||||
- Primärfarbe variiert zwischen Blau‑Tönen; Sekundär/Info vs. Accent unscharf. MaterialTheme Tokens konsolidieren (V3 C‑Palette).
|
||||
- Statusfarben (OK/Warn/Error) ohne konsistente Kontraststufen und ohne Dark‑Mode‑Fallbacks.
|
||||
- Komponenten
|
||||
- Heterogene Kartenrahmen (Elevation vs. Border). Einheitliche „MeldestelleCard“ definieren.
|
||||
- Uneinheitliche „SectionHeader“ (Icon/Spacing/Divider). Standard‑Composable nötig.
|
||||
|
||||
3) Fehlende/ungenügende Empty States (Beispiele, nicht abschließend)
|
||||
- Veranstaltungen (keine Veranstaltungen) — Call‑to‑Action „Neue Veranstaltung anlegen“ + kurzer Hilfetext.
|
||||
- Turnierliste einer Veranstaltung (0 Turniere) — CTA „Turnier anlegen“ + Link zu Import.
|
||||
- Bewerbe eines Turniers (0 Bewerbe) — CTA „Bewerb anlegen“ + Hinweis auf Abteilungslogik.
|
||||
- Abteilungen eines Bewerbs (0 Abteilungen) — CTA „Abteilungen generieren/teilen“.
|
||||
- Kassa (keine offenen Posten) — freundlicher Hinweis + Link zur Teilnehmerliste.
|
||||
|
||||
4) Optimierungen in Bezug auf V3 Navigation/Regeln
|
||||
- Breadcrumb in TopBar konsistent anzeigen (Eltern klickbar; keine Logout‑Aktion im MVP).
|
||||
- Kassa‑Screens als Push über Detail beibehalten (Back kehrt korrekt zurück; kein eigener Tab).
|
||||
- Dialoge/Sheets nicht im Back‑Stack verewigen; Schließen führt zum Ursprungs‑Screen.
|
||||
|
||||
5) Abgeleitete Issue‑Liste für Sprint B (konkret, klein schneidbar)
|
||||
- B-0: Design‑Tokens konsolidieren
|
||||
- Farben: Primär/Secondary/Info/Warning/Error gemäß V3 Palette in `Theme.kt` vereinheitlichen.
|
||||
- Typo: Headline/Title/Body/Label/Caption Skala festlegen und dokumentieren.
|
||||
- Spacing: 8‑pt Grid als Standard definieren (Außen 16, Innen 8/12).
|
||||
- B-1a: „MeldestelleCard“ Standard‑Composable erstellen (Padding, Border/Elevation, Title‑Slot, Actions‑Slot).
|
||||
- B-1b: „SectionHeader“ Standard‑Composable (Icon optional, Title, Subline, Divider‑Option, Standard‑Spacings).
|
||||
- B-4a: Empty‑State Vorlage erstellen (Icon/Illustration + Title + Body + Primary‑CTA + Secondary‑Link) und für 5 Listen anwenden.
|
||||
- B-2a: Wireframe „Bewerb anlegen“ inkl. Abteilungs‑Vorschlag (CSN‑C‑NEU Pflicht‑Teilung klar visualisieren).
|
||||
- B-3a: Wireframe „Kassa Turnier/Veranstaltung“ inkl. Zahlungsaufteilung und Rechnungsvorschau (Tabs oder Side‑by‑Side) verfeinern.
|
||||
- B-1c: Entscheidungsrichtlinie Dialog vs. Fullscreen‑Edit als kurze Guideline in `docs/06_Frontend/` publizieren.
|
||||
|
||||
Hinweise zur Ablage
|
||||
- Wireframes und UI‑Guidelines bitte unter `docs/06_Frontend/` versionieren; Screenshots ergänzen unter `docs/06_Frontend/Screenshots/`.
|
||||
- V2‑Verweise in Docs auf V3 aktualisieren; V2 bleibt nur im Archiv referenziert.
|
||||
|
||||
---
|
||||
|
||||
## 🟠 Sprint B — Kurzfristig (nächste Woche)
|
||||
|
||||
- [ ] **B-1** | Wireframes: Editier-Formulare (AlertDialog vs. dedizierter Screen)
|
||||
- [x] Entscheidungsgrundlage erarbeiten: Wann AlertDialog, wann Fullscreen-Edit, wann Sliding-Panel?
|
||||
- [x] Kriterien definieren: Anzahl der Felder, Komplexität, Kontext-Erhalt
|
||||
- [x] Wireframes für beide Varianten erstellen (am Beispiel Reiter-Edit und Pferd-Edit)
|
||||
- [ ] Entscheidung final treffen und als Design-Richtlinie dokumentieren (Review durch 🎨 Frontend)
|
||||
- [x] Ergebnis in `docs/06_Frontend/` ablegen → `docs/06_Frontend/Guidelines/Editier-Formulare_Dialog-vs-Fullscreen_v1.md`
|
||||
|
||||
- [ ] **B-2** | Wireframes: Bewerb anlegen mit Abteilungs-Logik
|
||||
- [x] **B-2 Wireframes** | Bewerb anlegen mit Abteilungs-Logik
|
||||
- [x] Dialog-Flow: Bewerb-Grunddaten → Abteilungs-Vorschlag → Bestätigung
|
||||
- [x] CSN-C-NEU Pflicht-Teilung: Visuelle Darstellung der automatischen Vorschläge
|
||||
- [x] Abteilungs-Typ-Auswahl: `SEPARATE_SIEGEREHRUNG` vs. `ORGANISATORISCH` verständlich gestalten
|
||||
- [x] Ergebnis in `docs/06_Frontend/` ablegen → `docs/06_Frontend/Wireframes/Bewerb_anlegen_Abteilungs-Logik_v1.md`
|
||||
- [x] Abteilungs-Typ-Auswahl: `SEPARATE_SIEGEREHRUNG` vs. `ORGANISATORISCH` verständlich gestaltet
|
||||
- [x] Ergebnis: `docs/06_Frontend/Wireframes/Bewerb_anlegen_Abteilungs-Logik_v1.md`
|
||||
|
||||
- [ ] **B-3** | Wireframes: Veranstaltungs-Kassa
|
||||
- [x] **B-3 Wireframes** | Veranstaltungs-Kassa
|
||||
- [x] Gesamt-Saldo-Ansicht: Teilnehmer mit offenen Beträgen aus mehreren Turnieren
|
||||
- [x] Zahlvorgang-Dialog: Eine Zahlung, Aufteilung auf Turniere sichtbar
|
||||
- [x] Rechnungsvorschau: Zwei separate Rechnungen je Turnier nebeneinander oder als Tab
|
||||
- [x] Ergebnis in `docs/06_Frontend/` ablegen → `docs/06_Frontend/Wireframes/Kassa_Veranstaltung_v1.md`
|
||||
- [x] Rechnungsvorschau: Zwei separate Rechnungen je Turnier als Tab
|
||||
- [x] Ergebnis: `docs/06_Frontend/Wireframes/Kassa_Veranstaltung_v1.md`
|
||||
|
||||
---
|
||||
|
||||
## 🔴 Sprint B — Offen (höchste Priorität)
|
||||
|
||||
- [ ] **B-1 Abschluss** | Finale Design-Entscheidung Editier-Formulare
|
||||
- [ ] Review durch 🎨 Frontend Expert durchführen
|
||||
- [ ] Entscheidung (AlertDialog vs. Fullscreen) als verbindliche Richtlinie dokumentieren
|
||||
|
||||
- [ ] **B-4** | Empty States für alle Listenansichten
|
||||
- [ ] Liste aller Screens mit möglichen leeren Zuständen erstellen
|
||||
- [ ] Illustrations-Konzept oder Icon + Text für Empty States definieren
|
||||
- [ ] Konsistente Vorlage für alle Empty States umsetzen
|
||||
- [ ] Konsistente Vorlage als Composable umsetzen (z. B. `MsEmptyState`)
|
||||
|
||||
---
|
||||
|
||||
## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
|
||||
## 🟠 Sprint C — Priorität 2 (nächste Woche)
|
||||
|
||||
- [ ] **C-1** | Wireframes aus Sprint B implementieren
|
||||
- [ ] Editier-Dialog / Fullscreen-Edit gemäß Entscheidung aus B-1 in Compose umsetzen
|
||||
- [ ] Bewerb-Anlegen-Dialog mit Abteilungs-Logik gemäß B-2 umsetzen
|
||||
- [ ] Kassa-Screen gemäß B-3 umsetzen
|
||||
- [ ] **C-1** | Wireframes aus Sprint B in Compose umsetzen
|
||||
- [ ] Editier-Dialog / Fullscreen-Edit gemäß finaler Entscheidung (B-1)
|
||||
- [ ] Bewerb-Anlegen-Dialog mit Abteilungs-Logik (B-2)
|
||||
- [ ] Kassa-Screen (B-3)
|
||||
|
||||
- [ ] **C-2** | Design-System konsolidieren
|
||||
- [ ] Farb-Palette in `MaterialTheme` / `Theme.kt` vereinheitlichen
|
||||
- [ ] Typografie-Skala definieren (Überschriften, Body, Labels, Captions)
|
||||
- [ ] Wiederverwendbare Komponenten identifizieren und als Composables extrahieren
|
||||
(z.B. `MeldestelleCard`, `SectionHeader`, `StatusBadge`)
|
||||
- [ ] Wiederverwendbare Komponenten als Composables extrahieren (Cards, Badges, Chips)
|
||||
|
||||
- [ ] **C-3** | Abteilungs-Ansicht: Startliste und Ergebnisliste
|
||||
- [ ] Wireframe: Startliste einer Abteilung (Startnummer, Reiter, Pferd, Verein)
|
||||
- [ ] Wireframe: Ergebnisliste einer Abteilung (Platz, Reiter, Pferd, Ergebnis)
|
||||
- [ ] Wireframe: Gesamtrangliste Bewerb (organisatorische Abteilungen zusammengeführt)
|
||||
- [ ] Wireframe: Separate Siegerehrungsliste (CSN-C-NEU, getrennt nach Lizenzklasse)
|
||||
- [ ] Wireframe: Ranglisten-Zusammenführung bei `ORGANISATORISCH`
|
||||
|
||||
---
|
||||
|
||||
## ⏸️ Zurückgestellt
|
||||
|
||||
> ⏸️ **Web-App Präsentation (Veranstaltungs-Seite, Turnier-Seite)** — Separate Besprechung zu einem späteren Zeitpunkt
|
||||
> ⏸️ **Nenn-Formular (Web)** — Separate Besprechung zu einem späteren Zeitpunkt
|
||||
> ⏸️ **Live-Ergebnis-Seite (Web)** — Separate Besprechung zu einem späteren Zeitpunkt
|
||||
> ⏸️ **Web-App / PWA Design** — Nach Desktop-MVP; Anforderungen noch nicht definiert
|
||||
|
||||
---
|
||||
|
||||
## 📌 Abhängigkeiten
|
||||
|
||||
| Warte auf | Von wem |
|
||||
|---------------------------------------------|---------------|
|
||||
| Domänen-Modell final (Abteilung, Kassa) | 🏗️ Architect |
|
||||
| ViewModel-Struktur (welche States gibt es?) | 🎨 Frontend |
|
||||
| Warte auf | Von wem | Betrifft |
|
||||
|-------------------------------------|---------------|--------------------------|
|
||||
| Domänen-Modell (Kassa, Abteilung) ✅ | 🏗️ Architect | B-3 Kassa-Wireframes ✅ |
|
||||
| ViewModel-Struktur ✅ | 🎨 Frontend | B-1 Finale Entscheidung |
|
||||
| Meine Wireframes (B-1, B-3) | 🎨 Frontend | B-3, B-4 Implementierung |
|
||||
| Meine Wireframes (B-2) | 🎨 Frontend | Bewerb-Anlegen-Dialog |
|
||||
|
||||
| Meine Aufgabe | Ermöglicht wem |
|
||||
|------------------------------------|-----------------------------------------------|
|
||||
| Wireframes Editier-Formulare (B-1) | 🎨 Frontend: Implementierung der Edit-Dialoge |
|
||||
| Wireframes Kassa (B-3) | 🎨 Frontend: Kassa-Screen-Implementierung |
|
||||
| Design-System (C-2) | Alle: konsistentes UI ohne Nacharbeit |
|
||||
---
|
||||
|
||||
## 💡 Empfehlungen (nach Priorität)
|
||||
|
||||
1. **B-1 Finale Entscheidung** — Frontend wartet auf die Richtlinie für Editier-Formulare; ohne sie können keine
|
||||
konsistenten Edit-Dialoge implementiert werden.
|
||||
2. **B-4 Empty States** — Alle Listenansichten zeigen aktuell nichts bei leerem Zustand; schlechte UX für neue Nutzer
|
||||
und beim ersten Start.
|
||||
3. **C-2 Design-System** — Frühzeitige Konsolidierung verhindert kostspielige Nacharbeit; am besten parallel zu C-1
|
||||
erledigen.
|
||||
|
||||
Reference in New Issue
Block a user