docs: add class diagram for core entities in C4 architecture

- Created `class_diagram_core.drawio` to visualize core domain entities (`Veranstaltung`, `Platz`, `Turnier`, etc.).
- Included relationships and associations between entities such as 1:N and reference mappings.
- Structured diagram to align with Clean Architecture principles for better domain comprehension.

docs/01_Architecture/c4/Kernentitaeten_Umbenennung.puml

@@ -0,0 +1,158 @@
+@startuml
+skinparam handwritten false
+skinparam monochrome false
+skinparam packageStyle rectangle
+skinparam shadowing false
+hide empty members
+
+title Domain Model: Umbenennung & Erweiterung (Soll-Zustand)
+
+package "Event Management Context" {
+    class Veranstaltung <<Tenant Boundary>> {
+        + id: UUID
+        + name: String
+        + ort: String
+        + startDatum: LocalDate
+        + endDatum: LocalDate
+        -- ZNS.zip Upload (Stammdaten) --
+    }
+
+    class Austragungsplatz {
+        + id: UUID
+        + name: String (z.B. "Waldarena")
+        + typ: String ("Austragungsplatz", "Vorbereitungsplatz")
+        + sparte: SparteE [0..1]
+    }
+
+    class Turnier {
+        + id: UUID
+        + turnierNummer: String (z.B. "26128")
+        + sparte: SparteE
+        + kategorie: TurnierkategorieE
+        + nennschluss: DateTime
+        + einschraenkungen: List<TeilnehmerKreisE>
+        -- n2-xxxxx.dat Upload --
+        + turnierbeauftragterId: UUID
+    }
+
+    class Ausschreibung {
+        + id: UUID
+        + titel: String
+        + status: AusschreibungsStatusE
+    }
+}
+
+package "Billing Context" {
+    class TurnierArtikel {
+        + id: UUID
+        + name: String (z.B. "Ansage", "Heu")
+        + preis: Money
+        + typ: String ("AUTOMATISCH", "MANUELL")
+    }
+
+    class Konto {
+        + id: UUID
+        + saldo: Money
+    }
+}
+
+package "Competition Context" {
+    class Bewerb {
+        + id: UUID
+        + bewerbNummer: Int (z.B. 14)
+        + bezeichnung: String (z.B. "Standardspringprüfung")
+        + beschreibung: String (z.B. "Pony Einsteiger Cup")
+        + klasse: String (z.B. "LM")
+        + richtverfahren: PruefungsTypE
+        + aufgabe: String (z.B. "R1")
+        + geldpreisAusbezahlt: Boolean
+        + reitdauerMinuten: Int
+        + umbauMinuten: Int
+        + besichtigungMinuten: Int
+        --
+        + teilungsTyp: AbteilungsTeilungsTypE (+ MANUELL)
+    }
+
+    class RichterEinsatz {
+        + funktionaerId: UUID
+        + position: String (z.B. "C", "Aufsicht")
+    }
+
+    class Abteilung {
+        + id: UUID
+        + abteilungsNummer: Int
+        + bezeichnung: String
+    }
+}
+
+package "Registration Context" {
+    class Nennung {
+        + id: UUID
+        + status: NennStatusE
+        + istNachnennung: Boolean
+        + reiterId: UUID
+        + pferdId: UUID
+    }
+
+    class NennungsTransfer {
+        + id: UUID
+        + ursprungsNennungId: UUID
+        + neueNennungId: UUID
+    }
+}
+
+package "Actor Context (Masterdata)" {
+    class Reiter {
+        + id: UUID
+        + name: String
+    }
+    class Pferd {
+        + id: UUID
+        + name: String
+    }
+    class Funktionaer {
+        + id: UUID
+        + name: String
+    }
+}
+
+Veranstaltung "1" *-- "N" Austragungsplatz
+Veranstaltung "1" *-- "N" TurnierArtikel
+Veranstaltung "1" *-- "N" Turnier
+
+Turnier "1" *-- "1" Ausschreibung
+
+Turnier "1" *-- "N" Bewerb
+Bewerb "1" *-- "N" Abteilung
+Bewerb "1" *-- "N" RichterEinsatz
+
+Bewerb "N" --> "1" Austragungsplatz : "findet statt auf"
+
+Abteilung "1" <-- "N" Nennung : "teilt zu"
+Bewerb "1" <.. "N" Nennung : "meldet für (Denormalisiert)"
+
+Nennung "1" <-- "N" NennungsTransfer : "dokumentiert Storno/Umbuchung"
+
+TurnierArtikel "1" <-- "N" Konto : "bucht"
+
+
+note right of Bewerb
+  **Namens-Konvention (Das "Dom"-Präfix):**
+  Aktuell heißt diese Klasse im Code z.B. `DomBewerb` (in entries-domain)
+  und `Bewerb` (in entries-service/Repository).
+  Der Prefix `Dom` wurde zur Unterscheidung
+  von DTOs (Data Transfer Objects) und
+  DB-Entities genutzt.
+
+  Ist es clever das zu ändern?
+  -> Ja! In Clean Architecture sollte die
+  Kern-Domäne den "sauberen" Namen tragen
+  (`Bewerb`). Die DB-Klasse heißt dann `BewerbEntity`
+  bzw. `BewerbTable` und das Transfer-Objekt `BewerbDto`.
+  Das gleiche gilt für `DomVeranstaltung` -> `Veranstaltung`,
+  `DomTurnier` -> `Turnier`, `DomAusschreibung` -> `Ausschreibung`,
+  `DomAbteilung` -> `Abteilung`, `DomNennung` -> `Nennung`
+  und `DomNennungsTransfer` -> `NennungsTransfer`.
+end note
+
+@enduml

docs/01_Architecture/c4/class_diagram_core.drawio

@@ -0,0 +1,92 @@
+<mxfile host="Electron" modified="2026-04-07T12:00:00.000Z" agent="Lead Architect" version="21.0.0" type="device">
+  <diagram id="class_diagram" name="Core Class Diagram">
+    <mxGraphModel dx="1600" dy="1200" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="1169" pageHeight="827" math="0" shadow="0">
+      <root>
+        <mxCell id="0" />
+        <mxCell id="1" parent="0" />
+
+        <!-- Veranstaltung -->
+        <mxCell id="class_veranstaltung" value="&lt;b&gt;Veranstaltung&lt;/b&gt;&lt;hr&gt;+ id: UUID&lt;br&gt;+ name: String&lt;br&gt;+ ort: String&lt;br&gt;+ startDatum: LocalDate&lt;br&gt;+ endDatum: LocalDate&lt;br&gt;+ nennschluss: DateTime&lt;br&gt;+ status: Enum" style="shape=swimlane;fontStyle=1;align=center;verticalAlign=top;childLayout=stackLayout;horizontal=1;startSize=30;horizontalStack=0;resizeParent=1;resizeParentMax=0;resizeLast=0;collapsible=1;marginBottom=0;fillColor=#ffe6cc;strokeColor=#d79b00;" vertex="1" parent="1">
+          <mxGeometry x="40" y="40" width="220" height="150" as="geometry" />
+        </mxCell>
+
+        <!-- Austragungsplatz -->
+        <mxCell id="class_platz" value="&lt;b&gt;Austragungsplatz&lt;/b&gt;&lt;hr&gt;+ id: UUID&lt;br&gt;+ bezeichnung: String (z.B. Waldarena)&lt;br&gt;+ typ: Enum (Austragung, Vorbereitung)&lt;br&gt;+ sparte: Enum? (optional)&lt;br&gt;+ masse: String" style="shape=swimlane;fontStyle=1;align=center;verticalAlign=top;childLayout=stackLayout;horizontal=1;startSize=30;horizontalStack=0;resizeParent=1;resizeParentMax=0;resizeLast=0;collapsible=1;marginBottom=0;fillColor=#ffe6cc;strokeColor=#d79b00;" vertex="1" parent="1">
+          <mxGeometry x="340" y="40" width="260" height="130" as="geometry" />
+        </mxCell>
+
+        <!-- TurnierArtikel -->
+        <mxCell id="class_artikel" value="&lt;b&gt;TurnierArtikel&lt;/b&gt;&lt;hr&gt;+ id: UUID&lt;br&gt;+ bezeichnung: String (z.B. Heu, Ansage)&lt;br&gt;+ preisCent: Int&lt;br&gt;+ typ: Enum (Automatisch, Manuell)" style="shape=swimlane;fontStyle=1;align=center;verticalAlign=top;childLayout=stackLayout;horizontal=1;startSize=30;horizontalStack=0;resizeParent=1;resizeParentMax=0;resizeLast=0;collapsible=1;marginBottom=0;fillColor=#dae8fc;strokeColor=#6c8ebf;" vertex="1" parent="1">
+          <mxGeometry x="660" y="40" width="240" height="110" as="geometry" />
+        </mxCell>
+
+        <!-- Turnier -->
+        <mxCell id="class_turnier" value="&lt;b&gt;Turnier&lt;/b&gt;&lt;hr&gt;+ id: UUID&lt;br&gt;+ turnierNummer: String (26128)&lt;br&gt;+ sparte: Enum&lt;br&gt;+ kategorie: Enum (C-NEU)&lt;br&gt;+ einschraenkungen: List&amp;lt;Enum&amp;gt;&lt;br&gt;+ turnierbeauftragterId: UUID" style="shape=swimlane;fontStyle=1;align=center;verticalAlign=top;childLayout=stackLayout;horizontal=1;startSize=30;horizontalStack=0;resizeParent=1;resizeParentMax=0;resizeLast=0;collapsible=1;marginBottom=0;fillColor=#ffe6cc;strokeColor=#d79b00;" vertex="1" parent="1">
+          <mxGeometry x="40" y="260" width="220" height="150" as="geometry" />
+        </mxCell>
+
+        <!-- Bewerb -->
+        <mxCell id="class_bewerb" value="&lt;b&gt;Bewerb&lt;/b&gt;&lt;hr&gt;&lt;b&gt;Identifikation:&lt;/b&gt;&lt;br&gt;+ bewerbNummer: String (z.B. 14a)&lt;br&gt;+ bezeichnung: String&lt;br&gt;+ beschreibung: String?&lt;br&gt;&lt;b&gt;Sportliches:&lt;/b&gt;&lt;br&gt;+ klasse / hoeheCm: String / Int&lt;br&gt;+ pruefungsTyp: Enum&lt;br&gt;+ aufgabe / aufgabenNummer: String?&lt;br&gt;+ paraGrade: String?&lt;br&gt;&lt;b&gt;Zeitplan &amp;amp; Ort:&lt;/b&gt;&lt;br&gt;+ austragungsplatzId: UUID?&lt;br&gt;+ geplantesDatum: LocalDate&lt;br&gt;+ beginnZeitTyp: Enum (FIX, ANSCHL)&lt;br&gt;+ beginnZeit: Time?&lt;br&gt;+ reitdauerMin / umbauMin: Int&lt;br&gt;+ besichtigungMin: Int&lt;br&gt;+ stechenGeplant: Boolean&lt;br&gt;&lt;b&gt;Finanzen &amp;amp; Orga:&lt;/b&gt;&lt;br&gt;+ startgeldCent: Int&lt;br&gt;+ geldpreisAusbezahlt: Boolean&lt;br&gt;+ teilungsTyp: Enum (inkl. MANUELL)" style="shape=swimlane;fontStyle=1;align=center;verticalAlign=top;childLayout=stackLayout;horizontal=1;startSize=30;horizontalStack=0;resizeParent=1;resizeParentMax=0;resizeLast=0;collapsible=1;marginBottom=0;fillColor=#dae8fc;strokeColor=#6c8ebf;" vertex="1" parent="1">
+          <mxGeometry x="340" y="260" width="280" height="340" as="geometry" />
+        </mxCell>
+
+        <!-- RichterEinsatz -->
+        <mxCell id="class_richter" value="&lt;b&gt;RichterEinsatz&lt;/b&gt;&lt;hr&gt;+ funktionaerId: UUID&lt;br&gt;+ position: String (z.B. 'C', 'Abreiteplatz')" style="shape=swimlane;fontStyle=1;align=center;verticalAlign=top;childLayout=stackLayout;horizontal=1;startSize=30;horizontalStack=0;resizeParent=1;resizeParentMax=0;resizeLast=0;collapsible=1;marginBottom=0;fillColor=#dae8fc;strokeColor=#6c8ebf;" vertex="1" parent="1">
+          <mxGeometry x="700" y="260" width="240" height="80" as="geometry" />
+        </mxCell>
+
+        <!-- Abteilung -->
+        <mxCell id="class_abteilung" value="&lt;b&gt;Abteilung&lt;/b&gt;&lt;hr&gt;+ id: UUID&lt;br&gt;+ abteilungsNummer: Int&lt;br&gt;+ bezeichnung: String (z.B. R1)&lt;br&gt;+ teilungsTyp: Enum&lt;br&gt;+ starterAnzahl: Int" style="shape=swimlane;fontStyle=1;align=center;verticalAlign=top;childLayout=stackLayout;horizontal=1;startSize=30;horizontalStack=0;resizeParent=1;resizeParentMax=0;resizeLast=0;collapsible=1;marginBottom=0;fillColor=#dae8fc;strokeColor=#6c8ebf;" vertex="1" parent="1">
+          <mxGeometry x="340" y="660" width="220" height="130" as="geometry" />
+        </mxCell>
+
+        <!-- Nennung -->
+        <mxCell id="class_nennung" value="&lt;b&gt;Nennung&lt;/b&gt;&lt;hr&gt;+ id: UUID&lt;br&gt;+ reiterId: UUID&lt;br&gt;+ pferdId: UUID&lt;br&gt;+ zahlerId: UUID&lt;br&gt;+ status: Enum&lt;br&gt;+ istNachnennung: Boolean" style="shape=swimlane;fontStyle=1;align=center;verticalAlign=top;childLayout=stackLayout;horizontal=1;startSize=30;horizontalStack=0;resizeParent=1;resizeParentMax=0;resizeLast=0;collapsible=1;marginBottom=0;fillColor=#d5e8d4;strokeColor=#82b366;" vertex="1" parent="1">
+          <mxGeometry x="660" y="660" width="220" height="130" as="geometry" />
+        </mxCell>
+
+        <!-- Relationen -->
+        <!-- Veranstaltung -> Platz -->
+        <mxCell id="rel_ver_platz" value="1 : N" style="endArrow=classic;html=1;exitX=1;exitY=0.25;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="class_veranstaltung" target="class_platz">
+          <mxGeometry width="50" height="50" relative="1" as="geometry" />
+        </mxCell>
+
+        <!-- Veranstaltung -> Artikel -->
+        <mxCell id="rel_ver_artikel" value="1 : N" style="endArrow=classic;html=1;exitX=1;exitY=0.75;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="class_veranstaltung" target="class_artikel">
+          <mxGeometry width="50" height="50" relative="1" as="geometry" />
+        </mxCell>
+
+        <!-- Veranstaltung -> Turnier -->
+        <mxCell id="rel_ver_tur" value="1 : N" style="endArrow=classic;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="class_veranstaltung" target="class_turnier">
+          <mxGeometry width="50" height="50" relative="1" as="geometry" />
+        </mxCell>
+
+        <!-- Turnier -> Bewerb -->
+        <mxCell id="rel_tur_bew" value="1 : N" style="endArrow=classic;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.25;entryDx=0;entryDy=0;" edge="1" parent="1" source="class_turnier" target="class_bewerb">
+          <mxGeometry width="50" height="50" relative="1" as="geometry" />
+        </mxCell>
+
+        <!-- Bewerb -> Richter -->
+        <mxCell id="rel_bew_richter" value="1 : N" style="endArrow=classic;html=1;exitX=1;exitY=0.1;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="class_bewerb" target="class_richter">
+          <mxGeometry width="50" height="50" relative="1" as="geometry" />
+        </mxCell>
+
+        <!-- Bewerb -> Platz (Referenz) -->
+        <mxCell id="rel_bew_platz" value="Ref" style="endArrow=dashed;html=1;exitX=0.5;exitY=0;exitDx=0;exitDy=0;entryX=0.5;entryY=1;entryDx=0;entryDy=0;" edge="1" parent="1" source="class_bewerb" target="class_platz">
+          <mxGeometry width="50" height="50" relative="1" as="geometry" />
+        </mxCell>
+
+        <!-- Bewerb -> Abteilung -->
+        <mxCell id="rel_bew_abt" value="1 : N" style="endArrow=classic;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="class_bewerb" target="class_abteilung">
+          <mxGeometry width="50" height="50" relative="1" as="geometry" />
+        </mxCell>
+
+        <!-- Abteilung -> Nennung -->
+        <mxCell id="rel_abt_nen" value="1 : N" style="endArrow=classic;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="class_abteilung" target="class_nennung">
+          <mxGeometry width="50" height="50" relative="1" as="geometry" />
+        </mxCell>
+
+      </root>
+    </mxGraphModel>
+  </diagram>
+</mxfile>

docs/temp/Chat-Verlauf-Gemini_2026-04-07.md

@@ -3,7 +3,9 @@
 Chat-Verlauf mit Gemini 
 Datum: 7. April 2026
 
---- Ich ---
+---
+Ich 
+---
 
 Guten Tag!
 Datum: 7. April 2026
@@ -28,7 +30,9 @@ Und so weiter
 
 Also kannst du mir dabei helfen wieder Ordung zu schaffen, in dem wir aus einem Abstrakteren Blickwinkel einen Überblick verschaffen? 
 
---- Gemini ---
+--- 
+Gemini 
+---
 
 Guten Tag. Ja, absolut. Es ist eine ausgezeichnete Idee, regelmäßig einen Schritt zurückzutreten und das große Ganze zu betrachten. Eine klare und konsistente Domänen-Sprache ist das Fundament für saubere Software-Architektur und verhindert genau die von Ihnen beschriebenen Probleme wie Inkonsistenzen und "Fetzen".
 
@@ -65,7 +69,9 @@ Mein Vorschlag für das weitere Vorgehen:
 
 Sind Sie mit diesem Vorgehen einverstanden? Und spiegelt diese erste Zusammenfassung Ihr Verständnis der Domäne wider?
 
---- Ich ---
+--- 
+Ich 
+---
 
 Bezüglich C4-Diagramm, kannst du es in draw.io generieren?
 Ich habe PlantUML und Mermaid ausprobiert, bin aber mit diesen nicht wirklich zufrieden. Jetzt will ich draw.io ausprobieren und hoffe das ich damit besser und leichter umgehen kann.
@@ -75,7 +81,9 @@ Ich habe PlantUML und Mermaid ausprobiert, bin aber mit diesen nicht wirklich zu
 
 Um einen großen Überblick zu bekommen, glaube ich ist ein C4-Modell besser geeignet. Was sagst du?
 
---- Gemini ---
+--- 
+Gemini 
+---
 
 🏗️ [Lead Architect]
 
@@ -95,7 +103,9 @@ Ich habe direkt zwei .drawio Dateien für Sie generiert, um sowohl die Architekt
 
 **Nächster Schritt:** Öffnen Sie bitte das `domain_model.drawio`. Ist diese grundlegende Kaskade (`Veranstaltung` -> `Turnier` -> `Bewerb` -> `Nennung`/`Abteilung`) exakt das, was wir im Code abbilden wollen und müssen? Wenn wir uns auf dieses Bild geeinigt haben, können wir anfangen, den Code (die "Fetzen") daraufhin zu untersuchen, wo die Benennungen oder Relationen aktuell noch abweichen.
 
---- Ich ---
+--- 
+Ich 
+---
 
 draw.io ist gut, dass gefällt mir.
 
@@ -106,7 +116,9 @@ Die Ausstellung der Nutzungs-Lizenz für Veranstaltung/Turnier etc.
 Veranstaltungen/Turniere vorkonfigurieren für Kunden/Veranstalter, so das dieser einen Link zugeschickt bekommt mit der vorkonfigurierten Desktop-App und Aktivierungs-Schlüssel für seine Veranstaltung/Turnier.
 Verstehst du was ich meine? 
 
---- Gemini ---
+--- 
+Gemini 
+---
 
 🏗️ [Lead Architect]
 
@@ -140,7 +152,9 @@ Hier ist die logische Kette, die wir nun abbilden:
 
 Spiegelt das Ihre Vision für das Vermietungsmodell wider? Wenn ja, haben wir jetzt das vollständige Bild: Vom kaufmännischen Rahmen (SaaS) bis hinunter zur einzelnen Nennung (Core Domain).
 
---- Ich ---
+--- 
+Ich 
+---
 
 Ja das sieht schlüssig aus. Aber diese "B2B SaaS (Software as a Service)" ist noch Zukunftsmusik.
 Mein jetztiges Ziel sind die Neumarkt Turniere
@@ -153,7 +167,9 @@ Nennung:
 Ja, als Reiter nenne ich für ein Turnier und wähle mir Prüfungen/Bewerbe aus an denen ich mit meinem Pferd starten/teilnehmen will aus.
 Das heißt eigentlich, das die Nennung dem Turnier gehört, oder nicht? 
 
---- Gemini ---
+--- 
+Gemini 
+---
 
 🏗️ [Lead Architect]
 
@@ -181,7 +197,9 @@ Warum haben wir das technisch so tief angesiedelt?
 
 Macht diese technische Granularität (jede Prüfung ist eine eigene Nennungs-Zeile in der Datenbank, die aber ihr Turnier kennt) für Sie Sinn, oder fehlt Ihnen im Tagesgeschäft zwingend ein "Nennungs-Kopfblatt" (eine Art Akte, die alle Einzelnennungen eines Reiters für ein Turnier zusammenfasst)?
 
---- Ich ---
+--- 
+Ich 
+---
 
 Das gefällt mir so, danke.
 Okay, jedes Turnier beginnt mit der offizellen Turnier-Ausschreibung welche die vom Verband ausgestellte Tunier-Nr beinhaltet.
@@ -201,7 +219,9 @@ Mit diesem Veranstalter möchte ich jetzt die Möglichkeit haben:
 Dann komme ich zum Konfigurieren des Turniers.
 Das besprechen wir im nächsten Stint
 
---- Gemini ---
+--- 
+Gemini 
+---
 
 🏗️ [Lead Architect]
 
@@ -225,7 +245,9 @@ Lassen Sie uns Ihren Flow kurz mit unserem Domain-Modell abgleichen, damit Sie s
 
 Geben Sie mir Bescheid, sobald Sie bereit sind. Dann stürzen wir uns im nächsten Stint auf die **Konfiguration des Turniers (Ausschreibung, Bewerbe, Nenngelder)**!
 
---- Ich ---
+--- 
+Ich 
+---
 
 Okay, "Turnier anlegen"
 Ich habe die Ausschreibung.
@@ -255,33 +277,42 @@ Dem entsprechend haben wir bis jetzt folgendes für dieses Turnier festgehalten
 ÖTO § 3 "Gliederung der Turniere und Bewerbe"
 
 Weiter müssen wir eingränzen:
---- ÖTO § 3 "Gliederung der Turniere und Bewerbe" ---
+
+### ÖTO § 3 "Gliederung der Turniere und Bewerbe" 
+
 Einschränkungen des Teilnehmerkreises für Turniere oder
 einzelne Bewerbe auf die folgenden Reiter oder Pferde durch
 die Ausschreibung sind in der Bezeichnung durch Anhängen
 des angegebenen Buchstaben zu berücksichtigen:
- • JG, JN und/oder YR .......................................... J
+
- • Ponys ................................................................ P
+ - JG, JN und/oder YR .................................. J
- • Noriker ............................................................... N
+ - Ponys ........................................................ P
- • Haflinger ............................................................ H
+ - Noriker ...................................................... N
- • Ländliche Reiter auf Warmblutpferden ............. L
+ - Haflinger ................................................... H
- • Vollblutaraberbewerbe ...................................... A
+ - Ländliche Reiter auf Warmblutpferden ..... L
- • Kaltblut .............................................................. K
+ - Vollblutaraberbewerbe .............................. A
- • Damensattel ...................................................... D 
+ - Kaltblut ...................................................... K
+ - Damensattel .............................................. D 
+
 ---
 
 Weiter geht es mit
---- ÖTO § 3 "Gliederung der Turniere und Bewerbe" ---
+
+### ÖTO § 3 "Gliederung der Turniere und Bewerbe"
+
 Zur Gliederung nach den Anforderungen werden nationale Turniere in die Kategorien A*, A, B*, B, C und C-NEU eingeteilt. Der
 Kurzbezeichnung gemäß Abs. 2 und 3 ist zur Kennzeichnung
 entweder -A*, -A, -B*, -B, -C oder -C-NEU anzuhängen. 
+
 ---
 
 Wenn ich dies alles ordnungsgemäs nach Turnier-Ausschreibung aufgewählt habe, kommen wir zum anlegen der einzelnen Profungen/Bewerben.
 nächster Stint
 
 
---- Gemini ---
+--- 
+Gemini 
+---
 
 🏗️ [Lead Architect]
 
@@ -318,13 +349,17 @@ Bevor wir in die einzelnen Bewerbe abtauchen, sollten wir unser Fundament repari
 
 Damit wäre der Kopf Ihres Turniers 100% ÖTO-konform, bevor wir den ersten Bewerb anlegen!
 
---- Ich ---
+--- 
+Ich 
+---
 
 Schreibe mir einen genauen Prompt für:
 - 🏗️ [Lead Architect] & 👷 [Backend Developer]
 Dann werde ich es gleich veranlassen.
 
----- Gemini ---
+---- 
+Gemini 
+---
 
 Hier ist der exakte, detaillierte Prompt, den Sie 1:1 kopieren und im nächsten Chat (oder direkt hier) abschicken können.
 Er richtet sich genau an die beiden Agenten und enthält alle Dateipfade und fachlichen Regeln aus der ÖTO, damit der Code auf Anhieb sitzt:
@@ -372,12 +407,15 @@ Bitte führt diese Schritte nacheinander aus und bestätigt den erfolgreichen Bu
 
 Tipp: Wenn Sie diesen Prompt abschicken, wird der Backend Developer die Datenbank, das Modell und die Schnittstelle exakt so vorbereiten, dass Ihr zukünftiges Frontend (der Wizard) einfach die Nummer "26128" und die Checkbox "Haflinger" an das Backend schicken kann und alles automatisch validiert wird.
 
---- Ich ---
+--- 
+Ich 
+---
 
 Okay, dass sollte erledigt sein.
-===
+
+```markdown
 ### Summary
-- 🏗️👷 Das Turnier-Fundament wurde gemäß ÖTO § 3 erweitert: `Turniernummer` (5-stellig) und optionale `Teilnehmerkreis-Einschränkungen` sind jetzt in Domain, Persistenz, Migration und API verfügbar.
+- Das Turnier-Fundament wurde gemäß ÖTO § 3 erweitert: `Turniernummer` (5-stellig) und optionale `Teilnehmerkreis-Einschränkungen` sind jetzt in Domain, Persistenz, Migration und API verfügbar.
 - Der Projekt-Build läuft erfolgreich durch.
 
 ### Changes
@@ -390,9 +428,11 @@ Okay, dass sollte erledigt sein.
 ### Verification
 - Projektweiter Build erfolgreich: `build`-Tool meldet `Build completed successfully`.
 - Zusätzlicher Check: `lint` auf `TurniereController.kt` ohne Fehler/Warnungen.
-===
+```
 
---- Gemini ---
+--- 
+Gemini 
+---
 
 🏗️ [Lead Architect]
 
@@ -450,7 +490,9 @@ Was häufig am Turnier verkauft wird ist Heu, Späne (Holzspäne zum einstreuen
 
 Okay, aber jetzt sollten wir alle nötigen Eckdaten haben um die Bewerbe anlegen zu können, oder fällt dir noch was ein?
 
---- Gemini ---
+--- 
+Gemini 
+---
 
 🏗️ [Lead Architect]
 
@@ -482,11 +524,13 @@ Wenn wir diese Basis haben (Nummer, Reglement, Funktionäre, Plätze, Preisliste
 
 Fazit: Ihr "Vor-Bewerbs-Flow" (Funktionäre -> Plätze -> Artikel -> Nennschluss) ist wasserdicht. Sind Sie einverstanden, dass wir diese vier Säulen als abgeschlossen betrachten? Dann hätten wir das perfekte Fundament, um im nächsten Stint endlich die Bewerbe (Prüfungen) darauf aufzubauen!
 
---- Ich ---
+--- 
+Ich 
+---
 
-"2. Austragungsplätze (Die "Waldarena")" - Ja, aber optional, wenn keine Auswahl getroffen wurde könnte ich troztdem Dressur und Springen auf einem Platz durchführen lassen.
+2. Austragungsplätze (Die "Waldarena") - Ja, aber optional, wenn keine Auswahl getroffen wurde könnte ich troztdem Dressur und Springen auf einem Platz durchführen lassen.
 
-"Der Nennschluss (Datum & Uhrzeit)"
+Der Nennschluss (Datum & Uhrzeit)
 - Du hast Recht. Meine Idee/Vision von unserem Nenn-System ist ja, dass wenn das Turnier inkl. seiner Prüfungen/Bewerbe eingerichtet ist, unser System 
 - Diese Veranstaltung und dessen Turniere auf unserer Web-Seite prässentiert werden und bei der Präsentation des Turniers sind Buttons, für die Ausschreibung, damit Interessierte sich die offizelle Ausschreibung ansehen können via PDF zum Beispiel, ein Button Nennen der zu einem Web-Formular leitet mit diesem man sich für dieses Turnier einfach nennen kann, diese Nennung wird validiert und anschließend an unser System geschickt. Das heißt für unser System, jedes Turnier hat einen Post-Eingang indem die Nennungen landen und darauf warten weiter bearbeitet zu werden. Warum so? Weil wir Datenschutzkonform bleiben müssen und um den jenigen die Möglichkeit zum nennen zu geben welche noch nicht in den ZNS-Daten vorkommen. Beispiel hierfür sind Lizenzfreie Teilnehmer, diese sind nicht in LIZENZ01.dat enthalten und Pferde die nicht Turnierpferderegistriet sind kommen auch nicht in PFERDE01.dat vor. An Turnieren wie C-NEU gibt es viele kleine Bewerbe an denen man ohne Reiterlizenz und ohne Turnierpferderegistrierung teilnehmen darf.
 
@@ -514,7 +558,9 @@ Wir laden die ZNS-Daten eine Etage höher bei Veranstaltung und jedes Turnier di
 Die n2-xxxxx.dat ist klar auf Turnier-Ebene, denn diese Daten gehen die anderen Turniere nichts an.
 Zum archivieren brauchen wir nur die Daten der tatsächlichen Teilnehmer Reiter, Pferde usw. 
 
---- Gemini ---
+--- 
+Gemini 
+---
 
 🏗️ [Lead Architect]
 
@@ -567,7 +613,9 @@ Wir haben jetzt das absolute Profi-Setup für das Backend definiert:
 
 Wenn Sie mit dieser Struktur einverstanden sind, können wir gedanklich (und architektonisch) zum Erstellen der Bewerbe und deren Abteilungs-Regeln übergehen! Passt das so für Sie?
 
---- Ich ---
+--- 
+Ich 
+---
 
 Du hast mit dem Thema "Austragungsplätze", gehören der Veranstaltung wieder eine Frage eröffnet.
 "Richter-Einteilung"
@@ -592,7 +640,9 @@ Was heist das für uns? Bei größeren Veranstaltungen müssen wir die Richter-E
 "2. Turnier (Das Sport-Event): Hat die Nummer (26128), das Reglement (ÖTO), den Nennschluss, den TB (Turnierbeauftragten). Hier wird die n2-26128.dat hochgeladen."
 - n2-26128.dat wenn vorhanden und notwendig
 
---- Gemini ---
+--- 
+Gemini 
+---
 
 🏗️ [Lead Architect]
 
@@ -636,7 +686,9 @@ Ich schlage folgende Optionen vor, die das System "verstehen" muss:
 
 Passt diese Einteilung für Sie? Oder gibt es noch exotischere Teilungsregeln, die wir beim Anlegen des Bewerbs unbedingt vorsehen müssen (wie z.B. "Separate Siegerehrung für den besten Ländlichen Reiter", auch wenn alle zusammen reiten)?
 
---- Ich ---
+--- 
+Ich 
+---
 
 "3. Richter-Einsatz (Bewerbsebene): Jeder Bewerb (Prüfung) pickt sich aus dem Veranstaltungs-Pool die Richter heraus, die am Richtertisch sitzen."
 - Die Richter, die die nötige Qualifikation haben stehen zur Auswahl, aber weil wir ja flexibel sind und am Turnier der TB Regeln, sagen wir flexibel auslegen darf, stehen auch die Richter zur Auswahl, dessen Qualifikation nicht dieser Proüfung entsprechen aber ausgegraut, also optisch sichtbar, dass diese nicht die erste Wahl sein sollten bzw. eine Bestätigung des TB erfordert.  
@@ -693,8 +745,204 @@ Du merkst, für einen ausgereiften und durchdachten Zeitplan ist viel zu kalkuli
 Wenn ich den Bewerb eingeichtet habe und laut Ausschreibung sonst keine Abteilungstrennung notwendig ist, haben wir eine Prüfung/Bewerb-Abteilung in einem
 Sonst klicke ich auf Prüfung/Bewerb-Teilen und wir kommen zu einer Übersicht in dieser ich diese Prüfung/Bewerb in verschiedene Vorlagen Teilen kann, auch eine Manuelle Teilung muss machbar sein, so dass ich jedem eizelnen Starter selber eine Abteilungsnummer vergeben kann und die Abteilungen selber bezeichnen/benennen kann. Wir sind ja felxibel ;-)
 
---- Gemini ---
+--- 
+Gemini 
+---
 
-The server encountered a resource exhausted error. This is likely due to the number of requests issued reaching your quota.
+🏗️ [Lead Architect]
 
-----
+Exzellent! Das ist genau die Art von detailliertem Praxis-Input, die eine Software von "funktioniert" zu "ist eine echte Hilfe" hebt. Sie haben mit der Richter-Einteilung und dem Zeitplan zwei der komplexesten Herausforderungen einer Meldestelle auf den Punkt gebracht.
+Lassen Sie uns das sofort architektonisch sauber verankern.
+Analyse Ihrer Punkte & Architekturentscheidungen
+1. Richter-Einteilung (Qualifikation vs. Flexibilität):
+    - Ihre Anforderung: Das System soll qualifizierte Richter vorschlagen, aber dem TB erlauben, diese Regel zu überstimmen (z.B. Richter mit niedrigerer Qualifikation bei einem Ausfall einsetzen).
+    - Architektur-Lösung: Das ist ein perfekter Anwendungsfall für unsere "Warn-Logik statt harter Fehler" (ADR-0007).
+  - Datenmodell: Ein Bewerb bekommt eine Liste von zugewiesenen Richtern (List<RichterEinsatz>). Ein RichterEinsatz speichert die ID des Funktionärs und seine Position (z.B. "Richter bei C").
+  - UI-Logik: Wenn Sie einen Richter zuweisen, prüft das System im Hintergrund dessen Qualifikation. Passt sie nicht, wird der Richter in der Auswahlliste ausgegraut und beim Auswählen erscheint eine Warnung: "Richter X hat nicht die empfohlene Qualifikation. TB-Bestätigung erforderlich." Die Zuweisung wird aber trotzdem erlaubt.
+2. Austragungsplätze ("Waldarena"):
+    - Ihre Anforderung: Optional Plätze anlegen und optional auf eine Sparte einschränken.
+    - Architektur-Lösung: Wir verankern die Plätze bei der Veranstaltung, da sie zum Gelände gehören.
+  - DomVeranstaltung bekommt eine Liste austragungsplaetze: List<DomAustragungsplatz>.
+  - Ein DomAustragungsplatz hat name und erlaubteSparte: SparteE? (nullable, also optional).
+  - Der DomBewerb bekommt dann eine Referenz austragungsplatzId. Der Wizard filtert die Auswahl basierend auf der Sparte des Bewerbs, wenn eine Sparte am Platz hinterlegt ist.
+3. Preisliste & Artikel ("Ansage", "Heu"):
+    - Ihre Anforderung: ÖTO-Gebühren als flexible Defaults und manuelle Artikel.
+    - Architektur-Lösung: Das billing-context wird genau das tun. Wir legen eine Entität VeranstaltungsArtikel an, die an die Veranstaltung gebunden ist. Diese hat einen Typ (AUTOMATISCH vs. MANUELL), einen Namen und einen Preis. Das gibt Ihnen die volle Flexibilität.
+4. Zeitplan ("fix um", "anschliessend", Reitdauer, Pausen):
+    - Das ist ein eigenes, komplexes Sub-System. Für den Moment halten wir fest: Die Parameter (reitdauer, umbauMinuten, besichtigungMinuten) gehören als Stammdaten an den Bewerb. Ein zukünftiger "Zeitplan-Service" wird diese Daten nutzen, um den gesamten Tagesablauf dynamisch zu berechnen.
+5. ZNS-Daten (ZNS.zip vs. n2-xxxxx.dat):
+    - Ihre Trennung ist goldrichtig.
+    - ZNS.zip (Stammdaten): Gehört zur Veranstaltung. Sie lädt den Pool an Reitern, Pferden und Funktionären, auf den alle Turniere dieser Veranstaltung zugreifen.
+    - n2-xxxxx.dat (Nenndaten): Gehört zum Turnier. Sie importiert die Nennungen für genau dieses eine Turnier.
+---
+
+Finales Fundament vor dem Anlegen der Bewerbe
+
+Basierend auf unserer Diskussion haben wir jetzt ein extrem solides Fundament. Bevor wir den "+ Neuer Bewerb" Button drücken, sind im System folgende Daten für das Turnier "26128" erfasst:
+
+  - An der Veranstaltung "Pferdesporttage Neumarkt":
+  - Ein Pool an Funktionären (aus der ZNS.zip geladen).
+  - Eine Liste von Austragungsplätzen (z.B. "Springplatz", "Dressurviereck").
+  - Eine Preisliste mit Standard- (Nenngeld) und Zusatzartikeln ("Ansage", "Heu").
+- Am Turnier "CSN-C Neumarkt" (Nr. 26128):
+  - Die offizielle Turniernummer "26128".
+  - Das Reglement (ÖTO).
+  - Die Sparte (Springen) und Kategorie (C-NEU).
+  - Der Turnierbeauftragte (aus dem Funktionärs-Pool ausgewählt).
+  - Der Nennschluss (Datum/Uhrzeit).
+  - Flags für Nachnenngebühr und Nenntauschbörse.
+  - Die n2-26128.dat wurde (optional) hochgeladen.
+
+Das ist eine perfekte Ausgangslage. Wir sind jetzt bereit für den nächsten Stint: Das Anlegen und Konfigurieren der Bewerbe.
+
+Sind Sie bereit, in die Details des "Bewerb anlegen"-Wizards einzutauchen?
+
+---
+Ich
+---
+
+### Richter-Einteilung (Qualifikation vs. Flexibilität)
+
+Perfekt
+
+### Austragungsplätze ("Waldarena") 
+
+Das muss ich päzessieren. Bei Turnieren gibt es immer mindestens einen Austragungsplatz. Die Option ist
+
+- Ich könnte diesem eine "Bezeichung" geben - Default="Austragungsplatz"
+- diesen "Austragungsplatz" kann ich optional eine Sparte zuweisen, wenn es ein kombiniertes Turnier ist.
+
+- "Platz-Nr" - "Typ" - "Bezeichnung" - "Sparte"
+  Unter "Typ" verstehe ich "Austragungsplatz", "Vorbereitungsplatz".
+  Warum Vorbereitungsplatz wichtig ist? Auf Turnieren werden Richter/Steward zur "Aufsicht am Abreiteplatz" eigeteilt und diese Informationen sind spätestens zur Turnier-Statistik bzw. zur Verreichnung interressant. Welcher Richter/Steward war wie lange/oft zur Aufsicht eingeteilt?
+  Diese Einteilung sollten wir beim erstellen der Prüfung/Bewerb einbauen, aber auch nur optional. 
+
+### Preisliste & Artikel ("Ansage", "Heu")
+
+Hierfür hätte ich gerne eine Tabelle in dieser Ich einfach X-beliebige Artikel hinzufügen kann inkl. dessen Preise.
+
+### Zeitplan ("fix um", "anschliessend", Reitdauer, Pausen)
+
+Ich glaube, dass ist die beste Lösung ein eigenes `Zeiplan-System` zu entwickeln, dies ist auch sehr Sparten-spezifisch.
+
+### ZNS-Daten (ZNS.zip vs. n2-xxxxx.dat)
+
+Okay, dies müssen wir noch entwickeln, aber jetzt im Moment ist dies nicht erste Priorität. Wir sollten uns erstmal auf die Grundfunktionalität konzentrieren.
+
+```markdown
+- An der Veranstaltung "Pferdesporttage Neumarkt":
+  - Ein Pool an Funktionären (aus der ZNS.zip geladen).
+  - Eine Liste von Austragungsplätzen (z.B. "Springplatz", "Dressurviereck").
+  - Eine Preisliste mit Standard- (Nenngeld) und Zusatzartikeln ("Ansage", "Heu").
+```
+
+Naja nicht ganz
+
+- Preisliste der Zusatzartikel ja, aber Nenngeld, Startgeld usw. ist Turnier-spezifisch und sollte nur in der Turnierartikel-Liste erscheinen.
+
+
+Du hast Teilnehmer-Kreis vergessen
+
+- Am Turnier "CSN-C Neumarkt" (Nr. 26128):
+  - Die offizielle Turniernummer "26128".
+  - Das Reglement (ÖTO).
+  - Die Sparte (Springen)
+  - Teilnehmer-Kreis, siehe ÖTO § 3 Abs 3.
+  - Kategorie, siehe ÖTO § 3 Abs 4.
+  - Der Turnierbeauftragte (aus dem Funktionärs-Pool ausgewählt) und weitere Funktionäre.
+  - Der Nennschluss (Datum/Uhrzeit).
+  - Flags für Nachnenngebühr und Nenntauschbörse. (nicht notwendig für C-NEU und C)
+  - Die n2-26128.dat wurde (optional) hochgeladen. (nicht notwendig für C-NEU und C)
+
+---
+
+## ÖTO § 3 "Gliederung der Turniere und Bewerbe"
+
+3. Die Einschränkungen des Teilnehmerkreises für Turniere oder einzelne Bewerbe auf die folgenden Reiter oder Pferde durch die Ausschreibung sind in der Bezeichnung durch Anhängen des angegebenen Buchstaben zu berücksichtigen:
+  - JG, JN und/oder YR .......................................... J
+  - Ponys ................................................................ P
+  - Noriker ............................................................... N
+  - Haflinger ............................................................ H
+  - Ländliche Reiter auf Warmblutpferden ............. L
+  - Vollblutaraberbewerbe ...................................... A
+  - Kaltblut .............................................................. K
+  - Damensattel ...................................................... D
+
+4. Zur Gliederung nach den Anforderungen werden nationale Turniere in die Kategorien 
+  - `A*`, 
+  - `A`, 
+  - `B*`, 
+  - `B`, 
+  - `C` und 
+  - `C-NEU` 
+eingeteilt. Der Kurzbezeichnung gemäß `Abs. 2` und `Abs. 3` ist zur Kennzeichnung entweder 
+  - `-A*`, 
+  - `-A`, 
+  - `-B*`, 
+  - `-B`, 
+  - `-C` oder 
+  - `-C-NEU` 
+anzuhängen. Die auf den Turnieren der einzelnen Kategorien zulässigen Bewerbe für die verschiedenen Sparten sind in den `Besonderen Bestimmungen` (Teil B) geregelt. 
+`Österreichische Meisterschaften` und `Staatsmeisterschaften` dürfen nur auf Turnieren der Kategorie `A*` und `A` veranstaltet werden, außer die Bestimmungen der einzelnen Sparte sehen etwas anderes vor. 
+
+---
+Gemini
+---
+
+🏗️ [Lead Architect]
+
+Das ist pures Gold! Dass Sie die Screenshots aus dem alten "SuDo" und Ihre exakten Workflows im Kopf haben, beschleunigt unsere Arbeit enorm. Das ist das perfekte "Querdenken", das wir brauchen.
+Lassen Sie uns Ihre Liste systematisch durchgehen. Ich habe unsere aktuelle Architektur (DomBewerb) parallel offengelegt und abgeglichen.
+
+Das haben Sie exzellent auf den Punkt gebracht:
+
+1. Die Identifikation & Beschreibung
+- `Bewerbsnummer`, `Sparte`, `Kategorie`, `Klasse/Höhe` und `Bezeichnung` haben wir bereits 1:1 in unserem Modell.
+- FEHLT NOCH:
+  - beschreibung (für Zusatztexte wie "Pony Einsteiger Cup OÖ").
+  - aufgabe und aufgabenNummer (extrem wichtig für Dressur und Vielseitigkeit, z.B. "R", "R1").
+  - paraGrade (für Para-Equestrian).
+2. Funktionäre (Richter am Platz)
+Ihre Logik ist perfekt und entspricht exakt unserem Prinzip der "weichen Validierung" (TBA darf überstimmen).
+- FEHLT NOCH: Wir müssen am DomBewerb eine Liste von RichterEinsatz-Objekten anlegen. Ein solcher Einsatz speichert:
+  - funktionaerId (Wer sitzt dort?)
+  - position (Wo sitzt er? z.B. "C", "B", "M" oder "Abreiteplatz").
+  - Die Warn-Logik bei unpassender Qualifikation bauen wir ins Frontend (Wizard) und als Validierungs-Regel ins Backend.
+3. Ort & Zeitplan-Parameter
+Das ist eine beeindruckende Liste an Parametern, die für einen guten Zeitplan nötig sind.
+- FEHLT NOCH: Wir fügen dem DomBewerb folgende Felder hinzu:
+  - austragungsplatzId (Referenz auf die Waldarena).
+  - geplantesDatum (Welcher Turniertag).
+  - beginnZeitTyp (Enum: FIX, ANSCHLIESSEND).
+  - beginnZeit (Uhrzeit, z.B. 08:30).
+  - reitdauerMinuten (Für die Berechnung).
+  - umbauMinuten (Bodenpflege).
+  - besichtigungMinuten (Parcoursbesichtigung).
+  - stechenGeplant (Ja/Nein).
+4. Startgeld / Geldpreis
+- FEHLT NOCH:
+  - startgeldCent (Was kostet das Starten in genau diesem Bewerb?).
+  - geldpreisAusbezahlt (Ja/Nein).
+5. Die Abteilungs-Teilung (Das Herzstück)
+Ihre Anforderung: "auch eine Manuelle Teilung muss machbar sein, so dass ich jedem einzelnen Starter selber eine Abteilungsnummer vergeben kann".
+- FEHLT NOCH: In unserem Enum `AbteilungsTeilungsTypE` (welches bestimmt, wie geteilt wird) fehlt der Wert `MANUELL`. Bisher haben wir nur Automatismen wie `NACH_LIZENZ` oder `NACH_PFERDEALTER`. Die manuelle Teilung ist der wichtigste Fallback für die Meldestelle!
+
+Haben Sie was vergessen? Nein, diese Liste ist absolut umfassend und deckt vom einfachen E-Springen bis zur hochkomplexen getrennt-gerichteten Dressur alles ab.
+Wie geht es weiter?
+
+Da wir jetzt exakt wissen, welche Felder im alten "SuDo" waren und in der Praxis zwingend gebraucht werden, müssen wir unser Domänenmodell DomBewerb (die Bewerbs-Entität im Backend) genau um diese Felder aufbohren.
+
+Soll ich Ihnen direkt den Prompt für den Backend Developer schreiben, damit er diese neuen Felder (aufgabe, richterEinsatz, Zeitplan-Parameter, MANUELL-Teilung) in die Datenbank und den Code einbaut?
+
+---
+Ich
+---
+
+Ich hätte dies gerne visualisiert.
+Damit ich mir unser theoretisches Werk noch einmal ansehen kann.
+Denn ich will die Hierarchie, Haupt-Klassen, Vererbung und so weiter sehen und verstehen.
+
+Dann auch noch hinterfragen, ob es so klever ist, die ganzen Klassen immer mit `DomBewerb` und so weiter zu bezeichnen. Vielleicht wäre es besser, wenn wir diese einfach nur `Bewerb` nennen.
+`DomBewerb` ist hierbei nur als vertreter Beispiel für alle Dom... Klassen Bezeichungen.
+
+Und dann, hätte ich gerne einen genauen Umsetzungsplan.