From 236876a04372fe0b8cadd80aaf9512d34c212c42 Mon Sep 17 00:00:00 2001 From: Stefan Mogeritsch Date: Fri, 3 Apr 2026 09:43:08 +0200 Subject: [PATCH] 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 --- docs/04_Agents/Roadmaps/Architect_Roadmap.md | 73 +++-- docs/04_Agents/Roadmaps/Backend_Roadmap.md | 211 +++++-------- docs/04_Agents/Roadmaps/Curator_Roadmap.md | 104 +++---- docs/04_Agents/Roadmaps/DevOps_Roadmap.md | 87 +++--- docs/04_Agents/Roadmaps/Frontend_Roadmap.md | 202 +++++-------- docs/04_Agents/Roadmaps/QA_Roadmap.md | 105 ++++--- docs/04_Agents/Roadmaps/Rulebook_Roadmap.md | 134 ++++----- .../Roadmaps/SPRINT_EXECUTION_ORDER.md | 284 ++++++------------ docs/04_Agents/Roadmaps/UIUX_Roadmap.md | 167 ++++------ 9 files changed, 541 insertions(+), 826 deletions(-) diff --git a/docs/04_Agents/Roadmaps/Architect_Roadmap.md b/docs/04_Agents/Roadmaps/Architect_Roadmap.md index 44c25b71..49d0c7df 100644 --- a/docs/04_Agents/Roadmaps/Architect_Roadmap.md +++ b/docs/04_Agents/Roadmaps/Architect_Roadmap.md @@ -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. diff --git a/docs/04_Agents/Roadmaps/Backend_Roadmap.md b/docs/04_Agents/Roadmaps/Backend_Roadmap.md index c59365f1..42510baf 100644 --- a/docs/04_Agents/Roadmaps/Backend_Roadmap.md +++ b/docs/04_Agents/Roadmaps/Backend_Roadmap.md @@ -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 ` 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. diff --git a/docs/04_Agents/Roadmaps/Curator_Roadmap.md b/docs/04_Agents/Roadmaps/Curator_Roadmap.md index 004d7bb2..6960edd3 100644 --- a/docs/04_Agents/Roadmaps/Curator_Roadmap.md +++ b/docs/04_Agents/Roadmaps/Curator_Roadmap.md @@ -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. diff --git a/docs/04_Agents/Roadmaps/DevOps_Roadmap.md b/docs/04_Agents/Roadmaps/DevOps_Roadmap.md index 19183f14..1f375caa 100644 --- a/docs/04_Agents/Roadmaps/DevOps_Roadmap.md +++ b/docs/04_Agents/Roadmaps/DevOps_Roadmap.md @@ -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. diff --git a/docs/04_Agents/Roadmaps/Frontend_Roadmap.md b/docs/04_Agents/Roadmaps/Frontend_Roadmap.md index 90d3c81f..4cbe81f3 100644 --- a/docs/04_Agents/Roadmaps/Frontend_Roadmap.md +++ b/docs/04_Agents/Roadmaps/Frontend_Roadmap.md @@ -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 - - 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) +### Sprint A — Abgeschlossen -- [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-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 - 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) +- [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 - 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 (Teilweise) — Abgeschlossene Punkte ---- - -## 🟠 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 ` - - [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` oder `Result` (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. diff --git a/docs/04_Agents/Roadmaps/QA_Roadmap.md b/docs/04_Agents/Roadmaps/QA_Roadmap.md index 37ac339c..5135b43a 100644 --- a/docs/04_Agents/Roadmaps/QA_Roadmap.md +++ b/docs/04_Agents/Roadmaps/QA_Roadmap.md @@ -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. diff --git a/docs/04_Agents/Roadmaps/Rulebook_Roadmap.md b/docs/04_Agents/Roadmaps/Rulebook_Roadmap.md index e459d169..e87ae5d8 100644 --- a/docs/04_Agents/Roadmaps/Rulebook_Roadmap.md +++ b/docs/04_Agents/Roadmaps/Rulebook_Roadmap.md @@ -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. diff --git a/docs/04_Agents/Roadmaps/SPRINT_EXECUTION_ORDER.md b/docs/04_Agents/Roadmaps/SPRINT_EXECUTION_ORDER.md index f0b45290..03fe5d0f 100644 --- a/docs/04_Agents/Roadmaps/SPRINT_EXECUTION_ORDER.md +++ b/docs/04_Agents/Roadmaps/SPRINT_EXECUTION_ORDER.md @@ -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) | diff --git a/docs/04_Agents/Roadmaps/UIUX_Roadmap.md b/docs/04_Agents/Roadmaps/UIUX_Roadmap.md index d35385b3..b214dcfa 100644 --- a/docs/04_Agents/Roadmaps/UIUX_Roadmap.md +++ b/docs/04_Agents/Roadmaps/UIUX_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.