feat(docs): add detailed session logs and initial architecture plan for Neumarkt 2026

- Included comprehensive documentation addressing the architecture, roadmap, and MVP goals for Neumarkt 2026.
- Added domain-specific definitions, glossary references, and functional breakdowns for both the public Web-App and Desktop-App.
- Clarified MVP deliverables, including Web-App Nennformular, Desktop-App offline-first setup, ZNS data sync, and LAN integration.
- Documented step-by-step onboarding workflow and open decisions for device pairing and security.
- Updated roadmap with sprint goals and technical steps for implementation.

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>

docs/04_Agents/Sessions/2026-03-27_Neumarkt_Public_Web_und_Desktop_Curator_Log.md

@@ -0,0 +1,130 @@
+# 🧹 Curator Log — Neumarkt 2026: Public Web + Desktop (Meldestelle)
+
+Datum: 2026-03-27
+Status: Arbeitsprotokoll (MVP bis 2026-04-07)
+
+## Kontext & Ziel
+
+- Bis Di, 07.04.2026: Öffentlich erreichbare Web-App mit Nennformular pro Turnier (26128, 26129) und Desktop-App (
+  offline-fähig) zur internen Steuerung (Toggles, Hinweise, Datenpflege).
+- Prinzipien: Trennung Fach-Kontexte vs. TechOps/Monitoring; Offline-First; keine Annahmen ohne Rückfrage; Glossar ist
+  Quelle der Wahrheit.
+
+## Begriffe & Quellen
+
+- Glossar/UL: `docs/03_Domain/00_Glossary.md`, `docs/03_Domain/01_Glossary/Ubiquitous_Language.md`.
+- Neumarkt-Referenzen: `docs/Neumarkt2026/*` (Turnierkarten, Dashboard-Skizzen).
+- Kurzdefinitionen (zur Bestätigung):
+  - Veranstalter: Organisation (z. B. Verein Neumarkt).
+  - Veranstaltung: Rahmen (Ort/Zeitraum), fasst Turniere.
+  - Turnier: Einheit mit Bewerben/Prüfungen, Ausschreibung, Nennungen, Start-/Ergebnislisten.
+  - Bewerb/Prüfung: Klasse im Turnier; optional in Abteilungen.
+  - Abteilung: Unterteilung eines Bewerbs mit eigener Liste.
+
+## Web-App — MVP Funktionsumfang
+
+1) Landing www.mo-code.at
+  - Card-Liste der Veranstaltungen (aktuell: Neumarkt) mit Turnier-Cards (26128, 26129).
+  - Je Turnier-Card: Buttons „Ausschreibung (PDF)“, „Nennen“ (sichtbar, wenn `turnier.config.nennenEnabled`),
+    „Start-Ergebnisse“ (sichtbar, wenn `turnier.config.resultsEnabled`).
+  - Hinweis-Text `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“ (geplant/laufend), „Ergebnisliste“ (abgeschlossen), „Live-Ergebnisse“ (Nice-to-have,
+    vorerst verborgen).
+  - Suche/Filter (Reiter/Pferd) Nice-to-have; nur Turnierteilnehmer.
+
+3) Nennformular (pro Turnier generiert)
+  - Abschnitte: Reiter, Pferd, Bewerb, Einverständnisse.
+  - Client- und Server-Validierung; Bestätigungsseite; optional E-Mail-Bestätigung (abhängig Mailserver) oder
+    On-Screen-Referenz.
+
+Pflichtfelder (Vorschlag, final durch 📜 Rulebook Expert):
+
+- Reiter: Vorname, Nachname, Geburtsjahr/-datum, Nationalität, Verein/Club, E-Mail.
+- Lizenz (bewerbsabhängig): Reiter-Lizenznummer (pflichtig, falls Regel verlangt).
+- Pferd: Name, Jahrgang, mind. eines von UELN/Passnummer; Besitzer optional.
+- Bewerbsauswahl (+ Abteilung ggf.), optional Kommentar.
+- Einverständnisse: DSGVO/Teilnahmebedingungen, Tiergesundheit/Impfstatus (Checkboxen).
+
+Öffentliche Minimal-APIs:
+
+- 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
+
+- Offline-First: Lokale DB (z. B. SQLite) + Sync-Queue. Geräte „Meldestelle“ und „Richter-Turm“ im selben LAN.
+- Statusleiste: Indikatoren „Internet erreichbar“ und „Peer verbunden“ (Heartbeat-basiert).
+- Onboarding (Freischalten):
+  1) Gerätename setzen (z. B. „Meldestelle“, „Richter-Turm“).
+  2) Sicherheitsschlüssel setzen (gemeinsam, z. B. „Neumarkt2026“) für verschlüsselte LAN-Kopplung.
+  3) ZNS-Daten laden: automatisch via Internet/LAN oder Offline-Import `ZNS.zip` (Integritäts-/Versionsprüfung, Warnung
+     bei veraltetem Stand).
+- Nach Freischalten: Navigation „Zu den Veranstaltern“ sichtbar.
+- Geräte-Setup: Druckerauswahl (OS-Dialog), Persistenz pro Gerät.
+- LAN-Kopplung: mDNS/Bonjour Discovery; Fallback manuelle IP/QR optional.
+- Optional: Einfacher LAN-Chat zwischen Geräten (Store-and-forward bei kurzzeitigem Offline).
+
+## Veranstalter – Übersicht (neue Präzisierung)
+
+- Nach Freischalten (Name + Schlüssel + ZNS vorhanden) ist „Zu den Veranstaltern“ aktiv.
+- Screen-Inhalte:
+  - Auswahlliste bereits registrierter Veranstalter (online/LAN geladen), z. B. „Verein Neumarkt“.
+  - Aktion „Neuen Veranstalter anlegen“ für Fälle ohne Treffer/Neuanlage.
+- Weiterer Fluss:
+  1) Veranstalter auswählen/neu anlegen.
+  2) Veranstaltung anlegen/auswählen (gemäß Glossar; falls Rahmen explizit geführt wird).
+  3) Turnier innerhalb der Veranstaltung anlegen (26128, 26129) und konfigurieren:
+    - Toggles: `nennenEnabled`, `resultsEnabled`
+    - Hinweis-Text (`notice`)
+    - Bewerbs-Regeln (Pflichtfelder-Flags), Nennstopp-Status
+
+## TechOps-UI (separate Shell)
+
+- Monitoring/Metriken/Logs + 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)
+
+- Modultrennung: Fach-Features getrennt von TechOps/Ping; keine Cross-Imports.
+- Offline-First: Queue/Retry auf allen Netzwerkpfaden; klare UI-States für Offline/Sync.
+- Observability: Traces, Key-Metrics, korrelierbare Request-IDs; keine PII in Logs.
+- Security (MVP): gemeinsamer LAN-Schlüssel ausreichend; später erweiterbar (Pairing/QR).
+- DSGVO: Minimaldatensatz; Einverständnis-Texte durch 📜 Rulebook Expert.
+
+## Offene Punkte (für nächste Session)
+
+1) Bestätigung/Korrektur Glossar-Definitionen.
+2) Finalisierung Pflichtfelder Nennformular inkl. bewerbsabhängiger Regeln.
+3) E-Mail-Bestätigung sofort vs. On-Screen-Only.
+4) Gleich/abweichende Regeln zwischen 26128 und 26129.
+5) LAN-Pairing-Fallback (reicht gemeinsamer Schlüssel vs. zusätzliche IP/QR-Option aktivieren).
+6) UI-Details „Veranstalter – Übersicht“ (Suche/Filter, Minimalfelder Neuanlage).
+
+## Konkrete nächste Schritte (Umsetzung)
+
+- Desktop:
+  - Onboarding-Checklist-Komponente (Gerätename, Schlüssel, ZNS-Status).
+  - Screen „Veranstalter – Übersicht“: Liste (remote/LAN), „Neuen Veranstalter anlegen“.
+  - Formular „Veranstalter neu“: Minimalfelder, Persistenz lokal + Sync.
+- Backend:
+  - Endpunkte Veranstalter-Query (public/internal), PDF-Auslieferung, Nennungs-Persistenz.
+  - Turnier-Config-API (Toggles, Notice), Bewerbs-Regel-Flags.
+- Web-App:
+  - Landing + Turnier-Cards (26128, 26129) mit Toggles/Notice.
+  - Nennformular-Renderer aus Turnier-/Bewerbs-Definition; POST Nennung.
+
+## Go/No-Go Checkliste Neumarkt
+
+- [ ] Desktop: Onboarding (Name, Schlüssel, ZNS geladen)
+- [ ] Desktop: Veranstalter sichtbar/neu anlegbar
+- [ ] Backend: Turnierdaten 26128/26129 vorhanden; PDF-Links ok
+- [ ] Web: Landing online; Turnier-Cards korrekt gesteuert
+- [ ] Web: Nennformular 26128/26129; Validierung & Persistenz ok
+- [ ] Observability: Basis-Metriken aktiv

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

@@ -0,0 +1,808 @@
+🏗️ [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