đŸ—ïž [Lead Architect] Guten Morgen! Datum: 27. MĂ€rz 2026 In den letzten Tagen haben wir am Frontend gebastelt. Jetzt habe ich Angst, dass wir unseren Fokus verlieren. Das Frontend und dessen EntwĂŒrfe sollten uns helfen die einzelnen Workflows praxisnah abzugrenzen. Daraus ergibt sich eine DomĂ€ne/Boundet-Context und dieses Wollen wir als eigenstĂ€ndigen Service entwickeln. Das Ping-Service sollte fĂŒr uns quasi als Vorlage dienen, also komplett von der echten fachlichen Implementierung isoliert. Mittlerweile vermischen wir alles miteinander und das gefĂ€llt mir nicht. Ich will fĂŒr die ganzen technischen Implementierungen mit dessen Monitorings und Metriken ein eigenes isoliertes Frontend in dem dann auch das Ping-Service enthalten sein soll. Aber, dadurch dass wir nicht mehr viel Zeit haben bis zum ersten Einsatz in Neumarkt, will ich die wichtigsten Grundlegende Funktionen bereits einsatzbereit haben, ohne dabei durch schlampiges husch pfusch eine saubere Weiterentwicklung verbauen. Verstehst du meine bedenken? Ich will mit dir jetzt einen Fahrplan durchdiskutieren, was wir jetzt wie genau entwickeln wollen. Bist du damit einverstanden? --- đŸ—ïž [Lead Architect] ### Kurzantwort Ja, ich verstehe deine Bedenken. Wir trennen konsequent die fachlichen Kontexte vom technischen Monitoring, kapseln das `Ping-Service` als reine technische Schablone, und liefern bis Neumarkt ein minimal tragfĂ€higes Set an Kernfunktionen ohne kĂŒnftige Weiterentwicklung zu verbauen. Unten ist ein konkreter, umsetzbarer Fahrplan mit klaren Leitplanken, Architektur-Skizze, Modulschnitt und Sprint-Plan. --- ### Leitplanken (nicht verhandelbar) - Bounded Contexts pro DomĂ€ne: kein Mischen von fachlichen Flows mit technischen Utilities. - Zwei getrennte UIs: - Fach-UI: produktive Workflows (Meldungen etc.). - TechOps-UI: Betrieb, Metriken, Logs, `Ping-Service` (Referenz/Schablone), Admin-Tools. - `Ping-Service` bleibt fachlich neutral: keine DomĂ€nen-Referenzen, dient nur als Vorlage fĂŒr technische Patterns ( Transport, Observability, Resilience, CI/CD). - Offline-First bleibt Prinzip: Sync-Schicht ist eigenstĂ€ndig, nicht in Screens verwoben. - „Saubere Weiterentwicklung“ absichern durch: stabile Contracts (`api`-Module), Consumer-Driven-Contracts, Telemetrie-Standards, Migrationspfade. --- ### Zielbild: Kontext-/Service-Architektur - Fachliche Kontexte (Beispiele – bitte bei Bedarf prĂ€zisieren): - `Meldung-Erfassung` (Form, Validierung, Lokalspeicher, Drafts) - `Meldung-Verwaltung` (Liste, Details, Statuswechsel) - `Sync` (Offline-Queue, Konfliktlösung, Retry) - `Auth/Identity` (Rollen/Permissions, lokale Session) - Technischer Kontext: - `TechOps` (Monitoring-UI, Admin-Funktionen) - `Ping-Service` (Health, Latenz, Transportwege, Resilience-Demo) - Context Map: klare Schnittstellen zwischen `Fach` ↔ `Sync` ↔ `Backend-APIs` sowie `TechOps` isoliert daneben. --- ### Frontend-Aufteilung (KMP/Compose, Beispiele passend zum Repo) - `frontend/shells/meldestelle-desktop` → Fach-UI Shell - `frontend/shells/techops-desktop` → NEU: TechOps-UI Shell (enthĂ€lt `Ping`-Feature, Metriken/Logs) - `frontend/features/*` → Feature-Module pro Kontext: - `features/meldung-erfassung` - `features/meldung-verwaltung` - `features/auth` - `features/sync` - `features/ping-feature` (nur in `techops-desktop` eingebunden) - `frontend/core/*` → Querschnitt (Design-System, Navigation, State, Telemetrie-SDK, Storage-Abstraktion) - Strikte Regel: `features/ping-feature` darf kein fachliches Modul importieren. Fach-Features dĂŒrfen `ping` nicht importieren. --- ### Backend-Aufteilung (Kotlin/Spring Boot als Annahme) - `services/ping` → reine Technik (Health, echo, stream), OpenAPI, OTel, RateLimit, Chaos toggelbar. - `services/meldung` → DomĂ€ne (Erfassung, Verwaltung, Validierung), eigene DB-Schemata. - `services/auth` → Rollen/Claims, Tokens. - `platform/observability` → Zentral: OTel Collector, Metrics, Tracing, Log-Pipeline. --- ### MVP fĂŒr Neumarkt (einsatzbereit, aber erweiterbar) - Fach-UI - `Meldung erfassen`: Basisformular, Pflichtfelder, lokale Drafts, Validierung. - `Meldung verwalten`: Liste, Detailansicht, einfacher Statuswechsel. - `Sync`: Hintergrund-Sync mit Retry, Konflikt-Hinweis-UI (einfacher Merge/Last-Write-Wins als Start, spĂ€ter verfeinern). - `Auth`: Lokale Anmeldung (konfigurierbar), Rollen-Gating auf kritische Aktionen. - TechOps-UI - `Ping`-Dashboard: Latenz/VerfĂŒgbarkeit, einfache Last- und Retry-Demos. - `Metrics`: Service-Health, Build-Infos, Versionen, simple Logs-View. - Nicht-Ziele fĂŒr MVP: komplexe Berichte, granularer Rechtemanager, komplexe Konfliktlösung. --- ### Roadmap bis Neumarkt (Beispiel: 3 Sprints Ă  2 Wochen) - Sprint 1: Struktur & Leitplanken - Module anlegen/aufrĂ€umen: `techops-desktop` Shell, `features/*` Trennung, Contracts. - `Ping-Service` als Referenz: OpenAPI, Health, OTel, Retry/Timeout/CB in Client. - Design-System-HĂ€rtung: Inputs, Layout, Navigations-Rahmen. - CI: Build-Matrix, Tracing/Metrics-Export in Dev. - Sprint 2: Fach-MVP - `meldung-erfassung`: Pflichtfelder, Drafts, Validierungen, Lokalspeicher-API. - `meldung-verwaltung`: Liste/Detail, Statuswechsel. - `sync`: Queue, einfache Konfliktregel, visuelle Indikatoren. - `auth`: Minimal-Login, Rollen-Gates in UI. - Sprint 3: Hardening & TechOps - TechOps-UI: Ping-Dashboard, Metrik-Widgets, einfache Logs. - E2E-Flows offline/online, Lasttests auf `meldung`. - Observability-Standards finalisieren, Feature Flags, Release Candidate. --- ### QualitĂ€ts-Schranken (DoD fĂŒr jedes Inkrement) - API-Contracts versioniert, Mock/CDC-Tests vorhanden. - Observability: Traces, Key-Metrics, korrelierbare Request-IDs. - Offline-First: Jeder Netzwerkpfad hat Queue/Retry, UI-States fĂŒr Offline. - Security: Minimal: Auth-Gates, kein Secret im Client, TLS everywhere. - UX: Leerlauf-States, Fehler-States, Tastatur-Navigation in Kern-Screens. --- ### Risiken & Gegenmaßnahmen - Kontext-Vermischung → Modul-AbhĂ€ngigkeitsregeln, Lints, Reviews gegen Cross-Refs. - Zeitdruck → MVP klar begrenzen, Feature-Flags, hartes „Cut scope, keep quality“. - Offline-KomplexitĂ€t → Start mit einfacher Konfliktstrategie, Telemetrie sammelt reale Konfliktmuster. - TechOps-Overhead → Widgets minimal halten, spĂ€ter ausbauen. --- ### Entscheidungsbedarfe (kurz klĂ€ren) - Verbindliche Liste der Pflichtfelder fĂŒr `Meldung erfassen`. - Rollenmodell fĂŒr MVP (z. B. `User`, `Supervisor`). - Zielplattformen fĂŒr ersten Einsatz (nur Desktop?). - Metrik-Set fĂŒr TechOps-MVP (3–5 Kernmetriken). --- ### NĂ€chste Schritte 1. Ich schreibe eine prĂ€gnante `MASTER_ROADMAP`-Aktualisierung mit obigen Leitplanken und Sprint-Zielen. 2. Aufteilung der Tickets nach Modulen (Fach vs. TechOps) inkl. „no-cross-import“-Regeln. 3. Kickoff-Review der Modulstruktur und Shell-Trennung (30–45 Min). Bist du mit diesem Fahrplan einverstanden, oder sollen wir einzelne Punkte (z. B. MVP-Umfang oder Modulzuschnitt) noch anpassen? --- ### Entscheidungsbedarfe (kurz klĂ€ren) - Verbindliche Liste der Pflichtfelder fĂŒr `Meldung erfassen`. - Rollenmodell fĂŒr MVP (z. B. `User`, `Supervisor`). - Zielplattformen fĂŒr ersten Einsatz (nur Desktop?). - Metrik-Set fĂŒr TechOps-MVP (3–5 Kernmetriken). --- Du bzw. Ihr seid jetzt meine Experten in eurem Fachgebiet. Ich bin jetzt mit unserem 📜 [ÖTO/FEI Rulebook Expert] der mir ĂŒber die Schulter schaut, der Fach-Experte. Ganz wichtige Mindest-Zielvorgabe bis nĂ€chste Woche Dienstag 7. April 2026 ist, dass sich Turnierteilnehmer ĂŒber ein Web-Formular Nennen können. - Nennformular pro Turnier welches sich generiert beim erstellen des Turnieres Okay, wir brauchen fĂŒr die ersten Turniere Neumarkt - Turnier-Nr.: 26128 - Turnier-Nr.: 26129 Eine - Web-App - Desktop-App Nur zur zur KlĂ€rung: Du hast glaube ich schon verstanden was bei uns eine Veranstaltung ist, was ein Veranstalter ist, was ein Turnier, PrĂŒfung/Bewerb/Abteilung ist? Das ist jetzt ganz wichtig, damit Ihr alle versteht wovon ich jetzt reden werde. Und stellt auf gar keinen Fall Vermutungen oder Annahmen, wenn Ihr was nicht wisst, oder irgendwas nicht ganz klar ist, sofort Fragen! Haben wir uns dabei verstanden? Was soll die Web-App können und wofĂŒr brauchen wir diese? Sie muss nicht viel können, nur eine öffentlich erreichbare Internet-Seite "www.mo-code.at" - Willkommensseite mit einer Liste unserer Veranstaltungen in Form einer Card, in unserem Fall ist es nur unser Neumarkt. In dieser Card sind weitere Cards der Reitsportlichen-Veranstaltungen dieser Veranstaltung platziert, in unserem Fall die 2 Turniere aus Neumarkt. In jeder dieser Card sind folgende Buttons und Hinweis-Text: Buttons: - "Ausschreibung" -> beim klick auf diesem Button bekommt man die Ausschreibung des jeweiligen Turniers als PDF - "Nennen" -> dieser Button fĂŒhrt zu unserem Nenn-Formular welches sich beim einrichten des Turniers selber generieren soll. Ob dieser Button angezeigt wird oder nicht will ich ĂŒber meine Desktop-App ein/ausschalten können. - "Start-Ergebnisse" -> damit komme ich zu einer Übersicht aller Bewerbe des Turniers "PrĂŒfungs-Übersicht", auch dieser Button wird ĂŒber die Desktop-App gesteuert, wie werden wir klĂ€ren wenn wir bei der Desktop-App sind. Hinweis-Text: Dieser Hinweis-Text soll alle darĂŒber Informieren: - "Pferdepass-Kontrolle in Bewerb/PrĂŒfung" - "Achtung Nennstop" etc. ich bin mir sicher, dass unser ÖTO-Experte noch weitere Einsatzmöglichkeiten finden wird worĂŒber wir als Meldestelle die Teilnehmer im laufe des Turniers Benachrichtigen mĂŒssten. - "PrĂŒfungs-Übersicht" Auf dieser Seite sollen alle an diesem Turnier stattfindenten Bewerbe/PrĂŒfungen Ordentlich Aufgelistet sein, vorsortiert nach Datum und Uhrzeit, weiter nach Austragungsplatz. In unserem Fall haben wir pro Turnier nur einen Tag und nur einen Austragungs-Platz. Trotzdem wĂ€hre eine Filter und Suchfunktion nicht schlecht. Suchfunktion fĂŒr Reiter und Pferd, nur die Reiter und Pferde welche auf diesem Turnier auf einer Startliste oder Ergenissliste stehen, also nur Turnier-Teilnehmer. Die Suchfunktion ist fĂŒr unsere Turniere Nice-To-Have und nicht Pflicht. Jeder Tag/Platz hat die Bewerbe Aufgelistet ebenfalls als Cards Bewerb-Card -> Bezeichnung usw. In dieser Bewerb-Card fals vorhanen die Abteilungen ebenfalls mit den zusĂ€tzlichen Bezeichnungen etc. "Startliste"-Button zeigt die aktuelle Startliste ist der Bewerb abgeschlossen entfernt sich dieser Button und ein neuer Button. "Ergebnisliste" erscheint, dieser fĂŒhrt zu der Ergebnisliste. Ist der Bewerb gerade "aktive" soll es einen Button "Live-Ergebnisse" geben. "Live-Ergebnisse" -> Nice-To-Have keine Pflicht fĂŒr Neumarkt. So, jetzt habe ich einen Roman geschrieben. Könnt Ihr euch das Vorstellen was ich als Web-App haben will? Ich werde dann noch einen Roman schreiben fĂŒr die Desktop-App, aber was sagt Ihr einmal dazu? --- đŸ—ïž [Lead Architect] ### Zielbild und Sofortfokus (bis Di, 7. April 2026) - Öffentlich erreichbare Web-App unter `www.mo-code.at` mit: - Willkommensseite → Liste `Veranstaltungen` (fĂŒr jetzt: „Neumarkt“) - In jeder `Turnier`-Card: Buttons `Ausschreibung (PDF)`, `Nennen`, `Start-Ergebnisse` + konfigurierbarer Hinweis-Text - `PrĂŒfungs-Übersicht` je Turnier: Liste aller `Bewerbe/PrĂŒfungen` (optional: `Abteilungen`), sortiert nach Datum/Uhrzeit/Platz; Such-/Filter (Nice-to-have) - Desktop-App steuert Sichtbarkeit der Buttons und Hinweis-Texte je Turnier. - Zwei Turniere fĂŒr Neumarkt: `26128`, `26129`. Ich bestĂ€tige: Wir liefern ein funktionsfĂ€higes Nennformular je Turnier (auto-generiert beim Anlegen des Turniers) bis zur genannten Deadline. --- ### BegriffsklĂ€rung (bitte kurz bestĂ€tigen oder korrigieren) - `Veranstalter`: Rechtliche/organisatorische Einheit, die Veranstaltungen ausrichtet. - `Veranstaltung`: Übergeordneter Rahmen an einem Ort/Zeitraum, umfasst eine oder mehrere `reitsportliche Veranstaltungen` (= unsere `Turniere`). - `Turnier`: Fachliche Einheit mit eigenem Zeitplan, Start-/Ergebnislisten, Ausschreibung, Nennungen. EnthĂ€lt `Bewerbe/PrĂŒfungen`. - `PrĂŒfung`/`Bewerb`: Einzelbewerb/Klasse innerhalb des Turniers; optional in `Abteilungen` (Heats) unterteilt. - `Abteilung`: Unterteilung eines Bewerbs mit eigener Start-/Ergebnisliste. Wenn etwas davon abweicht, bitte sofort korrigieren – wir treffen keine stillen Annahmen. --- ### Entscheidungen v1 (Vorschlag zur Abnahme) 1) Pflichtfelder fĂŒr `Meldung erfassen` (Nennung), MVP-konform und ÖTO/FEI-kompatibel (bitte mit 📜 `Rulebook Expert` gegenprĂŒfen): - Reiter - `Vorname`, `Nachname` - `Geburtsjahr` oder `Geburtsdatum` (mindestens Jahr) - `NationalitĂ€t` (LĂ€ndercode) - `Verein`/`Club` (Freitext oder Auswahl) - `Kontakt-E-Mail` (BestĂ€tigung/Änderungsinfo) - Lizenz/Startberechtigung - `Reiter-Lizenznummer` (falls fĂŒr Bewerb nötig) – Feld sichtbar/erforderlich abhĂ€ngig vom Bewerb - Pferd - `Pferdename` - `Lebensnummer/UELN` (falls verfĂŒgbar; mindestens einer von `UELN` oder `Passnummer`) - `Geschlecht` (Stute/Wallach/Hengst) – optional im MVP, falls nicht zwingend - `Jahrgang` (Geburtsjahr) - `Besitzer` (Name) – optional, falls Regelwerk nicht verlangt - Bewerbsauswahl - Auswahl `Bewerb` (und ggf. `Abteilung`, wenn offen) - Optional: `Wunschuhrzeit`/Kommentar an Meldestelle (Freitext, nicht verpflichtend) - EinverstĂ€ndnisse - `Datenschutz/Teilnahmebedingungen` (Checkbox, Pflicht) - `Tiergesundheit/Impfstatus bestĂ€tigt` (Checkbox, Pflicht, genaue Formulierung durch 📜 Expert) Hinweis: Felder werden pro `Bewerb` regelbasiert ein-/ausgeblendet (z. B. Lizenzpflicht). FĂŒr Neumarkt legen wir die Regeln turnierspezifisch in der Desktop-App fest. 2) Rollenmodell MVP - `Owner/Admin` (intern): Vollzugriff, Turniere anlegen/konfigurieren, Buttons und Hinweise steuern. - `Meldestelle` (intern): Einsicht/Moderation von Nennungen, Startlistenpflege. - `Public` (extern): Nur lesen + `Nennen` fĂŒr freigeschaltete Turniere. 3) Zielplattformen erster Einsatz - `Web-App` (öffentlich): Pflicht. - `Desktop-App` (intern, Compose Desktop): Pflicht fĂŒr Konfiguration und Freischaltungen. - Mobile optimiert: Nice-to-have (mindestens responsives Layout fĂŒr Nennformular auf Smartphone). 4) TechOps-MVP: 5 Kernmetriken - `public_http_availability` der Endpunkte `veranstaltungen`, `turniere`, `bewerbe`, `nennungen` (Uptime-Check) - `nennungen_submit_latency_p95` (End-to-End vom Klick bis Server-ACK) - `nennungen_submit_error_rate` (validierungs-/serverseitig) - `nennungen_created_count` pro Turnier (insb. `26128`, `26129`) - `pdf_delivery_success_rate` fĂŒr `Ausschreibung` --- ### Funktionsschnitt (MVP Umfang Web-App) - Landing `www.mo-code.at` - Liste `Veranstaltungen` → Card „Neumarkt“ - In der Veranstaltung-Card: je `Turnier (26128/26129)` eine Card mit: - Button `Ausschreibung` (liefert `application/pdf` aus Turnier-Metadaten) - Button `Nennen` (sichtbar, wenn `turnier.config.nennenEnabled = true`) - Button `Start-Ergebnisse` (sichtbar, wenn `turnier.config.resultsEnabled = true`) - Hinweis-Textblock (Markdown/Plaintext aus `turnier.notice`), Beispiele: `Pferdepass-Kontrolle in Bewerb/PrĂŒfung`, `Achtung Nennstopp`, etc. - `PrĂŒfungs-Übersicht` je Turnier - Liste aller `Bewerbe` (ggf. `Abteilungen` verschachtelt) – sortiert: `datum ASC`, `uhrzeit ASC`, dann `platz` - Buttons je Card: - `Startliste` (wenn Status = `Geplant`/`Laufend`) - `Ergebnisliste` (wenn Status = `Abgeschlossen`) - `Live-Ergebnisse` (Nice-to-have, ausblendbar) - Suche/Filter: Nice-to-have (Reiter/Pferd, nur Teilnehmer in diesem Turnier) - `Nennformular` - Generiert aus Turnier-/Bewerbs-Definition - Validierung clientseitig + serverseitig - BestĂ€tigungsseite + E-Mail-BestĂ€tigung (falls Mailserver verfĂŒgbar; sonst On-Screen-Referenznummer) --- ### Generierungslogik Nennformular (ohne Vermischung der Kontexte) - Backend `services/turnier` stellt `GET /turniere/{id}/bewerbe` inkl. Konfig der pflichtigen Felder/Regeln bereit. - Web-App rendert daraus dynamisch die `Reiter`-, `Pferd`- und `Bewerb`-Sektionen. - Desktop-App pflegt je `Bewerb`: - `erfordertReiterLizenz: boolean` - `erfordertPferdePassnummer: boolean` - `maxTeilnehmer`, `nennStopp`-Status - Sichtbarkeit `Nennen`, `Start-Ergebnisse`, Hinweis-Text --- ### Datenmodell (MVP, fachliches Skelett) - `Veranstaltung { id, name, ort, zeitraum, turniere[] }` - `Turnier { id, name, datum, platz, ausschreibungPdfUrl, config { nennenEnabled, resultsEnabled }, notice }` - `Bewerb { id, name, datumZeit, platz, hatAbteilungen, abteilungen[]?, regeln { lizenzPflicht, passPflicht } }` - `Abteilung { id, name, startzeit }` - `Nennung { id, turnierId, bewerbId, reiter { vorname, nachname, geburtsjahr, lizenzNr?, verein, email }, pferd { name, ueln?, passNr?, jahrgang }, einverstaendnisse { dsgvo, impfstatus }, status }` --- ### APIs (Vorschlag, minimal) - Public (read): - `GET /api/veranstaltungen` - `GET /api/turniere/{turnierId}` (inkl. Buttons/Notice-Config) - `GET /api/turniere/{turnierId}/bewerbe` - `GET /api/turniere/{turnierId}/ausschreibung` (PDF) - `GET /api/bewerbe/{bewerbId}/startliste` | `.../ergebnisliste` - Public (write): - `POST /api/turniere/{turnierId}/nennungen` → 201 + `nennungsId` - Internal (Desktop gesteuert): - `PATCH /api/turniere/{turnierId}/config` (toggle Buttons, Notice, Nennstopp) - `PATCH /api/bewerbe/{bewerbId}/regeln` (Pflichtfelder-Flags) --- ### UX-Skizze (kompakt) - Cards mit klaren PrimĂ€r-CTAs, sekundĂ€re Aktionen als Links. - Deutlicher `Nennstopp`-Banner, wenn aktiv (unterdrĂŒckt CTA `Nennen`). - Formular in 3 Abschnitte: `Reiter`, `Pferd`, `Bewerb` + `EinverstĂ€ndnisse` → eine Seite, progressiv validiert. - BestĂ€tigung zeigt `Turnier`, `Bewerb`, `Reiter`, `Pferd` sowie `Nennungs-ID`. --- ### QualitĂ€t und Compliance (MVP) - Validierung serverseitig verbindlich (Client kann offline/fehlerhaft sein). - Pflicht-Checkbox-Texte durch 📜 `Rulebook Expert` freigegeben. - DSGVO: nur notwendige Daten, klare Datenschutzhinweise auf Formular. - Telemetrie: Nur aggregierte Metriken, keine PII in Logs. --- ### Offene Punkte / Bitte um kurze Antworten 1) BestĂ€tigst du die Definitionen von `Veranstalter`, `Veranstaltung`, `Turnier`, `Bewerb/PrĂŒfung`, `Abteilung`? Falls abweichend: bitte korrigieren. 2) Sind die vorgeschlagenen Pflichtfelder fĂŒr die Nennung ausreichend fĂŒr Neumarkt, oder mĂŒssen wir (laut ÖTO/FEI) weitere Felder als Pflicht aufnehmen (z. B. `Pferderasse`, `Kategorie`, `Leistungsklasse`)? 3) DĂŒrfen wir E-Mail-BestĂ€tigungen verschicken, oder zunĂ€chst nur On-Screen-BestĂ€tigung (abhĂ€ngig von Mailserver)? 4) Werden `26128` und `26129` jeweils den gleichen Bewerbssatz/Regeln nutzen, oder pro Turnier unterschiedlich? 5) Darf `Live-Ergebnisse` im MVP komplett entfallen (Button verborgen), oder möchtest du die Platzhalter-Navigation jetzt schon sehen? --- ### NĂ€chste Schritte (konkret, sofort startbar) - Finalisierung der Pflichtfelder- und Rollenliste mit dir/📜 Expert (heute). - Desktop-App: Masken fĂŒr Turnier-Config (Toggles `Nennen`, `Start-Ergebnisse`, `Notice`, `Nennstopp`) – minimale Persistenz. - Public Web: Landing + Turnier-Cards + Nennformular-Flow fĂŒr `26128`, `26129`. - Backend: schlanke Endpunkte laut oben; PDF-Auslieferung; Persistenz der `Nennungen`. - TechOps: Metrik-Export und einfache Health-Checks. Wenn du die obigen Punkte bestĂ€tigst, planen wir danach die Detailumsetzung und Verprobung mit realen Testnennungen am Montag vor dem Go-Live. --- Jetzt will ich noch nichts finalisieren, hör mir einmal zu was ich will. Wir wollen dann Schritt fĂŒr Schritt eins nach dem anderen gezielt besprechen. Ich will jetzt keinen Husch Pfusch, okay? BezĂŒglich BegriffsklĂ€rung: docs/03_Domain/00_Glossary.md docs/03_Domain/01_Glossary/Ubiquitous_Language.md Informationen ĂŒber die bevorstehenden Turniere in Neumarlt docs/Neumarkt2026 "Desktop-App" Das ist die eigentliche "Meldestelle" vor Ort. Diese muss offline fĂ€hig sein. Wie wird es in Neumarkt sein? Ich sitze in einem kleinen netten HĂ€uschen mit meinem Computer, Drucker und dem Internet-Router. Unsere Desktop-App ist auf meinem Meldestellen-Computer installiert und via LAN-Kabel an dem Router verbunden auf dem auch der Drucker angeschlossen ist. Dann habe ich noch einen Laptop, auf dem ebenfalls unsere Desktop-App installiert ist, dieser wird am Richterturm fĂŒr die Ergebnis-Erfassung eingesetzt werden. Beider PC's sind ĂŒber ein lokales Netzwerk miteinander Verbunden. In meiner Desktop-App will ich unten sehen können, ob - eine Internet-Verbindung haben - eine Verbindung zum nĂ€chsten Rechner haben Auf ein echtes Login via Benutzername und Passwort will ich jetzt einmal verzichten. Das heißt ich will eine Desktop-Seite haben auf der ich alle GerĂ€te auf dieser Veranstaltung einrichten könnte. FĂŒr Neumarkt Pflicht - Drucker - Verbindung zu einer zweiten Desktop-App "Richter-Turm" (in unserem Fall ein und die selbe Desktop-App "Meldestelle" nur auf zwei Laptops) Nice-To-Have eine kleine einfache Chat-Funktion zwischen den GerĂ€ten "Meldestelle" - "Richter-Turm" Vielleicht können wir der Desktop-App welche auf einen Laptop installiert ist einen Namen geben welchen ich als Benutzer geben kann? Schaffen wir das technische umzusetzten? -> kurze Antwort --- đŸ—ïž [Lead Architect] ### Kurzantwort Ja, das schaffen wir. FĂŒr Neumarkt können wir eine offline-fĂ€hige Desktop-App bereitstellen, die ĂŒber das lokale Netzwerk zwischen „Meldestelle“ und „Richter-Turm“ synchronisiert, den Online-/Peer-Status unten anzeigt, Drucker nutzt und optional einen einfachen LAN-Chat bietet – alles ohne Benutzer-Login. ### Technischer Mini-Fahrplan (ohne Husch-Pfusch) - Offline-First Speicher: lokale DB pro GerĂ€t (z. B. SQLite) + Sync-Queue. - LAN-Kopplung: mDNS/Bonjour zur Peer-Findung; verschlĂŒsselte WebSocket-/TCP-Verbindung fĂŒr Sync + Heartbeats. - Status-Anzeige: zwei Indikatoren unten – „Internet erreichbar“ und „Peer verbunden“ (Heartbeat-basiert). - GerĂ€te-Name: frei vergebbar in den App-Einstellungen, in Sync/Chat sichtbar. - Drucker: Nutzung des OS-Druckdialogs/Spoolers; Auswahl und Persistenz pro GerĂ€t. - Optionaler Chat: leichter Text-Chat ĂŒber denselben LAN-Kanal (Store-and-forward, wenn Peer kurz offline). - Sicherheit: LAN-trusted fĂŒr MVP, mit gemeinsamem VeranstaltungsschlĂŒssel/Pairing; keine Passwörter nötig. ### Rahmenbedingungen/Risiken (beherrschbar) - Beide GerĂ€te im selben Subnetz; mDNS/Multicast darf nicht blockiert sein (Firewall-Regel als Checkliste). - Fallback, falls mDNS gesperrt: manuelles Eingeben der Peer-IP/QR-Pairing. - Netzwerkausfall: App arbeitet weiter offline; Sync setzt fort, sobald Peer/Internet wieder da ist. Wenn du zustimmst, gehen wir die Punkte Schritt fĂŒr Schritt konkretisieren (UI der Statusleiste, GerĂ€te-Setup-Seite, Peer-Pairing, Drucker-Setup, Chat als Nice-to-have). --- Sehr gut! Das heißt, wenn ich das jetzt richtig verstanden habe funktioniert es jetzt so: - Ich installiere die Desktop-App auf dem Laptop "Meldestelle" - Beim ersten öffnen dieser App komme ich in die App-Einstellungen und muss zuerst einen - Namen vergeben und - einen jetzt einmal frei wĂ€hlbaren SicherheitsschlĂŒssel vergeben (z.B.: "Neumarkt") dieser dient zur VerschlĂŒsselung fĂŒr die Verbindung zum zweit-GerĂ€t "Richter-Turm" (auf beiden GerĂ€ten muss der selbe SicherheitsschlĂŒssel eingetragen sein) Beispiel: PC-1: Name: "Meldestelle" SicherheitsschlĂŒssel: "Neumarkt2026" PC-2: Name: "Richter-Turm" SicherheitsschlĂŒssel: "Neumarkt2026" erst dann wird die App freigeschalten -> ist das so korrekt? Okay, ich habe die App installiert und sie ist freigeschaltet. - Internet-Verbindung ist da oder eine LAN-Verbindung zu einer "Meldestelle" besteht -> ZNS-Daten werden automatisch synchronisiert und in die Loakle Datenbank geschrieben. - Keine Internet-Verbindung und keine LAN-Verbindung -> Ich muss eine aktuelle ZNS.zip via USB-Stick ĂŒbermitteln fĂŒr die Lokale Datenbank. ist das soweit korrekt. Okay, Name: "Meldestelle" SicherheitsschlĂŒssel: "Neumarkt2026" ZNS-Daten: geladen Jetzt ist die App bereit. "Zu den Veranstaltern"-Button wird freigeschaltet -> Bevor ich ein Turnier erstellen kann, brauche ich einen Veranstalter. Was sagt Ihr dazu? --- đŸ—ïž [Lead Architect] ### KurzbestĂ€tigung Ja, deine Beschreibung ist im Kern korrekt. Mit GerĂ€te-Name und gemeinsamem SicherheitsschlĂŒssel wird die Desktop-App freigeschaltet, ZNS-Daten werden online/LAN automatisch synchronisiert oder offline via `ZNS.zip` importiert. Anschließend ist der Navigationspunkt `Zu den Veranstaltern` verfĂŒgbar. Bevor ein Turnier angelegt wird, legen wir einen `Veranstalter` an. Das passt. ### Kleine PrĂ€zisierungen (sauber, ohne Husch-Pfusch) - Erster Start (Onboarding): 1) `Name` des GerĂ€ts setzen (z. B. `Meldestelle`, `Richter-Turm`). 2) `SicherheitsschlĂŒssel` setzen (z. B. `Neumarkt2026`). 3) App wird freigeschaltet, Statusleiste zeigt zwei Indikatoren: `Internet` und `Peer` (LAN-Partner). - SicherheitsschlĂŒssel: - Dient der verschlĂŒsselten LAN-Kopplung und dem Pairing. Beide GerĂ€te mĂŒssen exakt denselben SchlĂŒssel eingeben. - FĂŒr Neumarkt reicht ein frei wĂ€hlbarer SchlĂŒssel. SpĂ€ter können wir auf GerĂ€te-Pairing/QR ergĂ€nzen. - ZNS-Daten: - Online oder LAN erreichbar → automatische Synchronisierung in die lokale DB. - Kein Netz → manueller Import ĂŒber `ZNS.zip` (USB). UI fĂŒhrt durch den Import, prĂŒft IntegritĂ€t/Version. ### Edge-Cases, die wir abfangen - Unterschiedliche SchlĂŒssel auf den GerĂ€ten → klare Fehlermeldung und Hinweis, den SchlĂŒssel abzugleichen. - TemporĂ€r kein Peer/kein Internet → App bleibt voll bedienbar, Status zeigt `offline`, Sync-Queue puffert. - Veraltete `ZNS.zip` → Warnung und Option, trotzdem zu importieren oder spĂ€ter zu aktualisieren. ### Reihenfolge im Datenmodell (Navigation) 1) `Veranstalter` anlegen (erforderlich). 2) `Veranstaltung` anlegen/auswĂ€hlen (falls benötigt, je nach Glossar-Definition). 3) `Turnier` innerhalb der Veranstaltung anlegen (z. B. 26128, 26129), inkl. Konfiguration (`Nennen`-Toggle, `Start-Ergebnisse`-Toggle, `Notice`). ### Was ich vorschlage (konkret fĂŒr Neumarkt) - Onboarding-Checkliste auf der Startseite, bis alle Pflichtschritte erledigt sind: - `GerĂ€tename gesetzt` - `SicherheitsschlĂŒssel gesetzt` - `ZNS-Daten vorhanden` (Sync OK oder `ZNS.zip` importiert) - `Veranstalter angelegt` - Danach wird die volle Navigation freigeschaltet, u. a. `Zu den Veranstaltern`. ### Offene Mini-Entscheidung (kurz bestĂ€tigen) - Reicht dir fĂŒr Neumarkt ein einheitlicher SicherheitsschlĂŒssel fĂŒr beide GerĂ€te, oder möchtest du optional ein manuelles Peer-Pairing per IP/QR als Fallback anzeigen? Wenn du das so bestĂ€tigst, definieren wir als NĂ€chstes die Eingabemaske fĂŒr `Veranstalter` (Minimalfelder) und den Import-Dialog fĂŒr `ZNS.zip`. --- " Reihenfolge im Datenmodell (Navigation) Veranstalter anlegen (erforderlich). Veranstaltung anlegen/auswĂ€hlen (falls benötigt, je nach Glossar-Definition). Turnier innerhalb der Veranstaltung anlegen (z. B. 26128, 26129), inkl. Konfiguration (Nennen-Toggle, Start-Ergebnisse-Toggle, Notice). " - Hier zu muss ich noch etwas prĂ€zisieren Nachdem ich den GerĂ€tenamen, SicherheitsschlĂŒssel vergeben habe und die ZNS-Daten geladen sind wird der Button "Zu den Veranstaltern" freigeschaltet. -> Auf der Seite/Screen "Veranstalter - Übersicht" habe ich dann - wenn via Online/LAN geladen eine Auswahlliste unserer schon Registrierten Veranstalter (in unserem Fall den Verein Neumarkt) - und/oder die Möglichkeit einen Veranstalter neu anzulegen. Okay, die Zeit lĂ€uft mir schon wieder davon. Ich muss diese Session fĂŒr jetzt unterbrechen. Bitte Schreibe eine umfassbare Dokumentation ĂŒber unsere Arbeit, so detailreich, dass ich heute Abend auf mit euch in einem neuem Chat-Verlauf lĂŒckenlos weiterarbeiten kann. --- đŸ§č [Curator] ### Sitzungsprotokoll — Neumarkt 2026: Public Web + Desktop (Meldestelle) #### Kontext & Ziel (Stand: 27.03.2026) - Ziel bis Di, 07.04.2026: Öffentlich erreichbare Web-App mit Nennformular pro Turnier (26128, 26129) + Desktop-App ( offline-fĂ€hig) zur internen Steuerung (Toggles, Hinweise, Datenpflege). Keine Vermutungen ohne RĂŒckfrage; Glossar als Quelle der Wahrheit. - Architekturprinzip: Strikte Trennung fachlicher Kontexte (Fach-UI, Turnierlogik) von technischen Themen (TechOps-UI, Ping-Service, Observability). Offline-First. --- ### Begriffe & Quellen - Glossar/UL: `docs/03_Domain/00_Glossary.md` und `docs/03_Domain/01_Glossary/Ubiquitous_Language.md` (verbindlich). - Neumarkt-Referenzen: `docs/Neumarkt2026/*` (Turnierkarten, Dashboard-Skizzen). Begriffe (Kurzfassung, zur BestĂ€tigung durch Owner/📜 Expert): - Veranstalter: Organisation (z. B. Verein Neumarkt), unter der Veranstaltungen/Turniere laufen. - Veranstaltung: Rahmen an Ort/Zeitraum, fasst reitsportliche Veranstaltungen (Turniere). - Turnier: Einheit mit Bewerben/PrĂŒfungen, Ausschreibung, Nennungen, Start-/Ergebnislisten. - Bewerb/PrĂŒfung: Klasse innerhalb Turniers; optional in Abteilungen unterteilt. - Abteilung: Unterteilung eines Bewerbs, mit eigener Start-/Ergebnisliste. --- ### Web-App — MVP Funktionsumfang 1) Landing www.mo-code.at - Card-Liste der Veranstaltungen (fĂŒr jetzt: Neumarkt). In jeder Card: Turnier-Cards (26128, 26129). - Je Turnier-Card Buttons: - Ausschreibung (PDF) - Nennen (sichtbar, wenn `turnier.config.nennenEnabled`) - Start-Ergebnisse (sichtbar, wenn `turnier.config.resultsEnabled`) - Hinweis-Textblock je Turnier (`turnier.notice`), z. B. „Pferdepass-Kontrolle“, „Achtung Nennstopp“. 2) PrĂŒfungs-Übersicht je Turnier - Sortierte Liste aller Bewerbe (Datum, Uhrzeit, Platz). Optional: Abteilungen verschachtelt. - Buttons je Card: - Startliste (Status: geplant/laufend) - Ergebnisliste (Status: abgeschlossen) - Live-Ergebnisse (nice-to-have, standardmĂ€ĂŸig verborgen) - Suche/Filter (Reiter/Pferd) nice-to-have; nur Turnierteilnehmer. 3) Nennformular (pro Turnier automatisch generiert) - Abschnitte: Reiter, Pferd, Bewerb, EinverstĂ€ndnisse. - Client- und Server-Validierung; BestĂ€tigungsseite. Optional E-Mail-BestĂ€tigung (abhĂ€ngig von Mailserver), sonst On-Screen-Referenz. Pflichtfelder (Vorschlag, von 📜 Expert zu finalisieren): - Reiter: Vorname, Nachname, Geburtsjahr/‐datum, NationalitĂ€t, Verein/Club, E-Mail. - Lizenz (bewerbsabhĂ€ngig): Reiter-Lizenznummer (pflichtig, falls Regel es verlangt). - Pferd: Name, Jahrgang, mind. eines von UELN/Passnummer; Besitzer optional. - Bewerbsauswahl (+ Abteilung, falls offen), optional Kommentar. - EinverstĂ€ndnisse: DSGVO/Teilnahmebedingungen, Tiergesundheit/Impfstatus (Checkboxen). APIs (öffentlich, minimal): - GET /api/veranstaltungen - GET /api/turniere/{turnierId} - GET /api/turniere/{turnierId}/bewerbe - GET /api/turniere/{turnierId}/ausschreibung (PDF) - POST /api/turniere/{turnierId}/nennungen --- ### Desktop-App (Meldestelle) — MVP Funktionsumfang - Offline-First: Lokale DB (z. B. SQLite) + Sync-Queue. Zwei GerĂ€te: „Meldestelle“ und „Richter-Turm“ im selben LAN. - Statusleiste: Internet erreichbar? Peer verbunden? (Heartbeat-basiert) - Erster Start (Onboarding, Freischalten der App): 1) GerĂ€tename vergeben (z. B. „Meldestelle“, „Richter-Turm“) 2) SicherheitsschlĂŒssel setzen (gemeinsam, z. B. „Neumarkt2026“). Dient zur verschlĂŒsselten LAN-Kopplung. Beide GerĂ€te mĂŒssen ĂŒbereinstimmen. 3) ZNS-Daten laden: automatisch via Internet/LAN; bei Offline-Only Import `ZNS.zip` per USB ( IntegritĂ€ts-/VersionsprĂŒfung, Warnung bei veraltetem Stand). - Nach Freischalten: Navigationseintrag „Zu den Veranstaltern“ wird sichtbar. - GerĂ€te-Setup: Druckerauswahl (OS-Dialog), Speicherung pro GerĂ€t. - LAN-Kopplung: mDNS/Bonjour Discovery; Fallback manuelle IP/QR möglich (Option fĂŒr Neumarkt bei Bedarf). - Optional: Einfacher LAN-Chat zwischen GerĂ€ten (Store-and-forward bei kurzzeitigem Offline). --- ### Veranstalter-Übersicht (PrĂ€zisierung aus dieser Session) - Nach Freischalten (Name + SchlĂŒssel + ZNS vorhanden): Button „Zu den Veranstaltern“ aktiv. - Screen „Veranstalter – Übersicht“ enthĂ€lt: - Auswahlliste registrierter Veranstalter (online/LAN geladen). FĂŒr Neumarkt: „Verein Neumarkt“ sollte erscheinen, wenn bereits vorhanden. - Aktion „Neuen Veranstalter anlegen“, falls nicht vorhanden oder Neuanlage gewĂŒnscht. - NĂ€chste Schritte im Fluss: 1) Veranstalter auswĂ€hlen/neu anlegen 2) Veranstaltung anlegen/auswĂ€hlen (gemĂ€ĂŸ Glossar; falls der Rahmen explizit gefĂŒhrt wird) 3) Turnier innerhalb der Veranstaltung anlegen (26128, 26129) und konfigurieren: - Toggles: `Nennen`, `Start-Ergebnisse` - Hinweis-Text (`Notice`) - Regelsatz pro Bewerb (z. B. Lizenzpflicht, Passpflicht), Nennstopp-Status --- ### TechOps-UI (separat, technisch) - EigenstĂ€ndige Shell fĂŒr Monitoring/Metriken/Logs und Ping-Service-Demo. Keine fachliche Vermischung. - Kernmetriken (MVP): public endpoint availability, nennungen_submit_latency_p95, nennungen_submit_error_rate, nennungen_created_count pro Turnier, pdf_delivery_success_rate. --- ### QualitĂ€tsleitplanken (DoD, MVP) - Strikte Modultrennung: Fach-Features getrennt von TechOps/Ping. Keine Cross-Imports. - Offline-First: Jeder Netzwerkpfad mit Queue/Retry; UI-States fĂŒr Offline/Sync. - Observability: Traces, Key-Metrics, korrelierbare Request-IDs. Keine PII in Logs. - Security (MVP): Gemeinsamer LAN-SchlĂŒssel reicht; spĂ€ter erweiterbar um Pairing/QR. - DSGVO: Minimaldatensatz, EinverstĂ€ndnisse klar formuliert (📜 Expert prĂŒft Texte). --- ### Offene Punkte fĂŒr die nĂ€chste Session 1) BestĂ€tigung/Korrektur der Glossar-Definitionen (Veranstalter/Veranstaltung/Turnier/Bewerb/Abteilung). 2) Finalisierung Pflichtfelder Nennformular mit 📜 Expert (inkl. bewerbsabhĂ€ngiger Regeln). 3) Entscheidung: E-Mail-BestĂ€tigung sofort vs. On-Screen-Only fĂŒr Neumarkt. 4) Gleichheit/Unterschied der Regeln zwischen 26128 und 26129. 5) Fallback-Mechanismus fĂŒr LAN-Pairing (reicht einheitlicher SchlĂŒssel oder zusĂ€tzlich manuelle IP/QR aktivieren?). 6) UI-Details „Veranstalter – Übersicht“: Such-/Filterverhalten bei vielen EintrĂ€gen; Minimalfelder fĂŒr Neuanlage. --- ### Konkrete NĂ€chste Schritte (umsetzungsorientiert) - Desktop - Onboarding-Checklist-Komponente: GerĂ€tename, SchlĂŒssel, ZNS-Status. - Screen „Veranstalter – Übersicht“: Liste (remote/LAN), Button „Neuen Veranstalter anlegen“. - Form „Veranstalter neu“: Minimalfelder gemĂ€ĂŸ Glossar; Persistenz in lokaler DB + Sync. - Backend - Endpunkte fĂŒr Veranstalter-Query (public/internal je nach Sichtbarkeit), PDF-Auslieferung, Nennungs-Persistenz. - Turnier-Config-API (Toggles, Notice), Bewerbs-Regeln (Pflichtfelder-Flags). - Web-App - Landing + Turnier-Cards (26128, 26129) mit Toggles/Notice. - Nennformular-Renderer aus Turnier-/Bewerbs-Definition; POST Nennung. --- ### Checkliste fĂŒr Neumarkt (Go/No-Go) - [ ] Desktop: Onboarding abgeschlossen (Name, SchlĂŒssel, ZNS geladen) - [ ] Desktop: Veranstalter sichtbar/neu anlegbar - [ ] Backend: Turnierdaten 26128/26129 vorhanden, PDF-Links funktionieren - [ ] Web: Landing online; Turnier-Cards mit korrekt gesteuerten Buttons/Notices - [ ] Web: Nennformular fĂŒr 26128/26129, Validierung und Persistenz OK - [ ] Observability: Basis-Metriken aktiv --- ### Anhang — Referenzen im Repo - Agents/Protokoll: `AGENTS.md` (Badges, Workflow, Docs-as-Code) - Domain-Dokumente: `docs/03_Domain/*` - Neumarkt-Assets: `docs/Neumarkt2026/*` Bitte gib kurz Bescheid, ob noch Aspekte aus deiner Sicht fehlen, die wir heute Abend ergĂ€nzen sollen. Ich halte das Protokoll dann fortlaufend aktuell. --- docs/04_Agents/Sessions/2026-03-27_Neumarkt_Public_Web_und_Desktop_Curator_Log.md