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