meldestelle/docs/temp/Caht-Verlauf_2026-03-27.md

🏗️ [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