OAMC-Auswertung/plan.md

# Plan: OAMC Turnierauswertung — Webanwendung

**Stand:** 2026-09-05 · **Status:** Entwurf, noch nicht freigegeben
**Änderung 05.09.:** Zeitmessung per Lichtschranke aufgenommen (§3.6, §5.4, §6.2, AP 5)

---

## 1. Ausgangslage

### 1.1 Der Verein und die Sportart

Der **OAMC Reinheim e.V. im ADAC** (Odenwälder Automobil- und Motorsportclub) richtet
**ADAC Motorrad-Turniere** aus. Diese laufen nach der **ADAC-Turnierordnung** im Bereich
des **ADAC Hessen-Thüringen (HTH)**.

Motorrad-Turniersport ist kein Rennsport, sondern ein Geschicklichkeitswettbewerb: Die
Fahrer durchfahren einen Parcours mit festen Aufgaben, dabei zählen **Fehlerpunkte** und
**Fahrzeit**.

Aufgaben im Parcours (laut Sportbeschreibung auf oamc.de):

Fahrzeugabnahme · Schätzen (im Stand und in Fahrt) · Slalom · Acht-Figur · Spurgasse ·
Kreisel · Tor · Schrägbrett · Wippe (mit und ohne Spurbrett) · Gummiringe ·
Dose umsetzen · Fahrgasse · Stop Haltelinie · Langsamfahrstrecke

### 1.2 Aktueller Ist-Zustand der Website

Die bestehende Seite **oamc.de** (Zweitdomain: oamc-reinheim.de) ist eine statische
**HTML-4.01-Frameset-Website**:

- Aufbau: `index` → `oben.htm` (Navigation) + `hauptfenster.htm`, jede Rubrik wieder
  ein eigenes Frameset (`m/frame-m.htm` → `m1.htm` Menü + `m2.htm` Inhalt)
- Rubriken: Verein · VÜP ADAC-Platz · Kartgruppe · **Motorradgruppe** · Fahrrad JVS ·
  Anfahrt · Download · Weblinks · Flohmarkt · BikerSafetyDay
- **Alle Ergebnisse liegen ausschließlich als PDF** unter `/datei/` und werden auf
  `d/d-mot-turnier.htm` verlinkt — Tagesergebnisse, Meisterschaftsstände (HTH 2002–2026),
  Bundesturnier-Ergebnisse, Protokolle
- Die Seite **`m/m-fahrer.htm` ist eine „BAUSTELLE"** — es gibt aktuell **keine
  Fahrerdatenbank**. Genau das ist die Lücke, die dieses Projekt schließt.
- `m-ergebnisse.htm` und `m-ausschreibung.htm` verweisen nur auf die PDF-Downloadseite

### 1.3 Wie heute ausgewertet wird

Die Rahmenausschreibung 2026 nennt als Anforderung an den Veranstalter:
> „Auswertungscomputer mit MSOffice (**Excel**) und Drucker sollte zeitgemäß vorhanden sein."

Es existieren Vorlagen als `.xlsx` (z. B. `MT-NENNLISTE-5-2025.xlsx`). Die Auswertung
läuft also heute **in Excel**, das Ergebnis wird als PDF exportiert und manuell auf die
Website gelegt. Meisterschaftsstände werden separat fortgeschrieben.

**Schmerzpunkte:**

| Problem | Auswirkung |
|---|---|
| Ergebnisse nur als PDF | nicht durchsuchbar, nicht verlinkbar, nicht mobil lesbar |
| Meisterschaftsstand manuell | fehleranfällig, spät verfügbar |
| Keine Fahrerhistorie | „Wie oft war X schon dabei?" nicht beantwortbar |
| Fahrerstammdaten pro Turnier neu erfasst | Tippfehler, Dubletten, Namensvarianten |
| Frameset-Website | kein Deep-Link, schlechtes SEO, unbrauchbar auf dem Handy |

---

## 2. Ziel

Eine Webanwendung, die

1. **Turnierergebnisse auswertet** — Fehlerpunkte + Zeit → Platzierung je Wertungsklasse
2. **Alle Daten in einer Datenbank hält** statt in Excel und PDF
3. **Zeiten per API von der Lichtschranken-Zeitmessung entgegennimmt** (zweiter Raspberry
   Pi am Parcours, siehe §3.6), in die Datenbank schreibt und **live anzeigt**
4. **Fahrer samt Stammdaten und Historie** bereitstellt (die heutige „Baustelle")
5. Die **Meisterschafts-/Pokalwertung** automatisch fortschreibt

### Nicht-Ziele (bewusst außerhalb dieses Projekts)

- Ablösung der kompletten oamc.de (Kart, Fahrrad, Flohmarkt, VÜP bleiben, wo sie sind)
- Online-Nennung/Anmeldung durch Teilnehmer → **Phase 2**, siehe §9
- Elektronische Erfassung der **Fehlerpunkte** — die bleiben beim Wertungspersonal im
  Parcours und werden manuell eingegeben (siehe §3.6)
- Zahlungsabwicklung des Nenngelds (10 € je Start, wird vor Ort kassiert)

---

## 3. Fachliche Grundlagen

> ⚠️ Die folgenden Regeln wurden aus der Ergebnisliste
> `2026-05-31-MT-REIN-HAIN.PDF` und der `MT-Rahmenausschreibung-2026.pdf`
> **abgeleitet**. Sie sind **vor der Implementierung gegen die ADAC-Turnierordnung 2026
> (`MT-D2025.pdf`) und mit dem Bereichsleiter zu verifizieren** — siehe §10.

### 3.1 Veranstaltungsstruktur

- Ein Renntag kann ein **Doppelturnier** sein: zwei Turniere zweier Ortsclubs laufen
  parallel auf einem Platz, z. B. „ADAC-Motorrad-Doppelturnier des MSC Hainstadt und
  des OAMC Reinheim".
- **Jeder Fahrer wird in beiden Turnieren getrennt gewertet** — die Ergebnisliste vom
  31.05.2026 enthält für dieselben Fahrer je einen Block „Reinheim" und einen Block
  „Hainstadt" mit **eigenen Zeiten, Fehlern und Platzierungen**.
- ⇒ Datenmodell-Konsequenz: `veranstaltung` (Renntag) : `turnier` (Wertungslauf) = 1:n

### 3.2 Klassen

**Jugendklassen** (Einteilung strikt nach Jahrgang, Ausweispflicht bei der Nennung):

| Klasse | Jahrgang | ~Alter | Fahrzeug |
|---|---|---|---|
| J 1 | 2019 / 2018 / 2017 | 7–9 | Kindermotorrad max. 110 ccm / 5,5 kW |
| J 2 | 2016 / 2015 | 10–11 | Kindermotorrad max. 110 ccm / 5,5 kW |
| J 3 | 2014 / 2013 | 12–13 | Mofa, Motorrad + Roller max. 125 ccm / 11 kW |
| J 4 | 2012 / 2011 | 14–15 | Mofa, Motorrad + Roller max. 125 ccm / 11 kW |
| J 5 | 2010 / 2009 / 2008 (bis 18. Geburtstag) | 16–18 | Mofa, Motorrad + Roller max. 125 ccm / 11 kW |

Für Klasse 1 muss der Teilnehmer **am Veranstaltungstag** bereits 7 Jahre alt sein.
⇒ Die Jahrgangstabelle ist **jahresabhängig** und muss versioniert in der DB liegen,
nicht im Code (`klassen_jahrgang` mit `saison`).

**Erwachsenenklassen:** `S 1`–`S 9` (Stammfahrer) und `A 1`–`A 4` (Anfänger), unterteilt
nach Fahrzeugtyp/Hubraum. Aus der Sportbeschreibung: Mokicks und Roller bis 80 ccm ·
bis 250 ccm · bis 650 ccm · über 650 ccm · Enduro (mehrere Hubraumklassen) ·
Seitenwagen · **Pedelec / E-Bike** · **E-Scooter** (neu).

> ❗ Die genaue Zuordnung `S 1`…`S 9` / `A 1`…`A 4` → Fahrzeugtyp ist aus den
> öffentlichen Seiten **nicht** ersichtlich. Muss erfragt werden (§10).

**Wertungsklasse ≠ Klasse:** In der Ergebnisliste werden Klassen zu Wertungsklassen
zusammengefasst, wenn zu wenige Starter da sind — z. B. eine gemeinsame Wertung
„S 5, S 9, S 3, S 6, S 7" und „A 1, A 4". Das Zusammenlegen ist eine
**Entscheidung pro Turnier** und gehört als Datum in die DB, nicht als Regel in den Code.

### 3.3 Wertungslogik ← Kernstück der Anwendung

Spalten der Ergebnisliste:

`Start-Nr.` · `Voller Name` · `Regionalclub` · `Klasse` · `Geschlecht` · `Kategorie` ·
`Summe Zeit` · `Summe Fehler` · `Gesamt` · `Platzierung`

**Es gibt zwei verschiedene Berechnungen für `Gesamt`:**

**a) Erwachsene (Kategorie S, und A-Fahrer):**
```
Gesamt = Summe Zeit + Summe Fehler
Platzierung = aufsteigend nach Gesamt
```
Belege aus der Liste vom 31.05.2026, Wertungsklasse „S 5, S 9, S 3, S 6, S 7":
| Fahrer | Klasse | Zeit | Fehler | Gesamt | Platz |
|---|---|---|---|---|---|
| Bernius Meik | S 6 | 105,43 | 0 | **105,43** | 1 |
| Schmunk Christian | S 9 | 103,26 | 10 | **113,26** | 2 |
| Krack Robin | S 5 | 130,33 | 0 | **130,33** | 4 |
| Steinbrech Nicolai | S 5 | 65,71 | 1210 | **1275,71** | 11 |

**b) Jugend (Kategorie J):**
```
Gesamt = Summe Fehler          ← die Zeit geht NICHT in die Wertung ein
Platzierung = aufsteigend nach Fehler, bei Gleichstand aufsteigend nach Zeit
```
Das deckt sich mit der Sportbeschreibung:
> „Bei den Turnieren kommt es in der Jugendklasse vorrangig auf die fehlerfreie
> Durchfahrt an, da die Zeit erst bei Punktgleichheit herangezogen wird."

Belege, Wertungsklasse J 3:
| Fahrer | Zeit | Fehler | Gesamt | Platz | Anmerkung |
|---|---|---|---|---|---|
| Freund Philipp | 136,88 | 0 | **0** | 1 | drei Fahrer mit 0 Fehlern … |
| D'Angelo Leandro | 140,40 | 0 | **0** | 2 | … Reihenfolge über die Zeit |
| Heil Luca | 144,46 | 0 | **0** | 3 | |
| Mattes Flynn | 160,05 | 10 | **10** | 4 | |
| Ratter Mitja | 148,42 | 60 | **60** | 7 | Gleichstand 60 Fehler … |
| Kemesies Finlay | 165,39 | 60 | **60** | 8 | … 148,42 < 165,39 |

⇒ Die Wertungsformel ist **pro Kategorie konfigurierbar** zu implementieren, nicht
hart zu verdrahten (`wertungsregel` als Strategie/Enum je Kategorie und Saison).

**Fehlerpunkte** treten in Vielfachen von 10 auf (10/20/30/…/1210). Die Zuordnung
„welcher Fehler an welcher Aufgabe kostet wie viele Punkte" steht in der
ADAC-Turnierordnung und ist zu beschaffen (§10).

**Mehrfachstarts:** Ein Fahrer kann am selben Tag **mehrfach starten** (anderes Fahrzeug,
andere Klasse). Beispiel 31.05.2026: *Schmunk Christian* startet in S 9 **und** S 3,
*Bernius Meik* in S 6 **und** S 7 — jeweils mit eigener Startnummer und eigenem Ergebnis.
⇒ Der Schlüssel eines Ergebnisses ist **nicht** (Turnier, Fahrer), sondern
(Turnier, Start), und Nenngeld fällt „für jeden Start" an.

### 3.4 Meisterschafts-/Pokalwertung (HTH)

- **Erwachsene:** ein Gesamtklassement der A- und S-Fahrer/innen (klassenübergreifend)
- **Jugend:** Pokalwertung **klassenweise** J 1 – J 5

**Streichresultate** — nicht alle Läufe zählen:

| Turniere in der Saison | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 |
|---|---|---|---|---|---|---|---|---|---|
| **davon gewertet** | 8 | 8 | 8 | 7 | 6 | 5 | 4 | 3 | 2 |

Nicht jede Veranstaltung zählt zur Meisterschaft — der Terminkalender markiert Läufe
„mit Meisterschaftswertung" bzw. „o. M. = ohne Meisterschaft".

**Endlaufqualifikation:** die besten **10 Erwachsenen** und **10 Jugendlichen** der
HTH-Meisterschaft (Jugend ohne Trennung Damen/Herren, Verteilung prozentual nach
Teilnehmerzahl der 5 Jugendklassen). **Bei Punktgleichheit zählt die Majorität der
Siege.** Endgültige Festlegung durch den Bereichsleiter ⇒ die Anwendung *schlägt vor*,
sie *entscheidet nicht*.

> ❗ Die **Punktetabelle** (Platz → Meisterschaftspunkte) ist noch nicht bekannt (§10).

### 3.5 Weitere Regeln aus der Rahmenausschreibung 2026

- Nenngeld einheitlich **10 €** je Start (S, A, Jugend, Mofa/Moped, E-Bike, Pedelec, E-Scooter)
- **Nennschluss:** Klasse S + Jugendklassen 14:00 Uhr, A-Klasse + E-Bike/Pedelec/E-Scooter 15:00 Uhr
- Pokalläufe bei Doppelveranstaltungen beginnen generell 09:00 Uhr
- Gültiger Jugendausweis + unterschriebener Haftungsausschluss sind bei der Nennung vorzulegen
- Eine **nummerierte Nennungsliste** ist zu führen, die Reihenfolge nach Möglichkeit einzuhalten
- Für A-Klassen-Fahrer und Gelegenheitsfahrer wird z. B. jede 10. Startnummer freigehalten
- Schlussbericht + Ergebnisliste müssen nach FFM gemeldet werden — **der Veranstalter-Zuschuss
  wird erst überwiesen, wenn beide Dokumente dort sind** ⇒ Export in genau diesen Formaten
  ist kein „nice to have", sondern zahlungsrelevant

### 3.6 Zeitmessung per Lichtschranke *(Vorgabe des Auftraggebers)*

Die API wird von einem **zweiten Raspberry Pi am Parcours** bespielt. Dieser ist an eine
**Lichtschranke** angeschlossen, misst die Fahrzeiten, sendet sie an die Anwendung und
**zeigt die Daten des aktuellen Fahrzeugs/Starters an**.

Damit gibt es **zwei Datenquellen pro Ergebnis**:

| Wert | Quelle | Weg |
|---|---|---|
| `Summe Zeit` | **Lichtschranke** (Messgerät) | automatisch per API |
| `Summe Fehler` | **Wertungspersonal im Parcours** | manuell im internen Frontend |

Ein Ergebnis ist also erst vollständig, wenn **beide** Seiten geliefert haben. Das
Datenmodell muss einen Start mit Zeit, aber ohne Fehlerpunkte (und umgekehrt) sauber
abbilden können — ein „halbes" Ergebnis ist der Normalzustand während der Veranstaltung,
kein Fehler.

#### Konsequenzen für den Entwurf

**a) Rohmessungen statt Summen speichern.**
Die Spalte heißt in der Ergebnisliste `Summe Zeit` — die Zeit ist also vermutlich eine
**Summe mehrerer Messungen** (mehrere Durchgänge oder mehrere gemessene Abschnitte,
z. B. Langsamfahrstrecke und Gesamtdurchfahrt). Die Anwendung speichert deshalb **jede
Einzelmessung** (`zeitmessung`) und bildet die Summe selbst. Rückweg gibt es nicht:
aus einer gespeicherten Summe lassen sich Einzelmessungen nie wieder herstellen, aus
Einzelmessungen die Summe jederzeit. → offene Frage **O-13**

**b) Das Messgerät ist ein eigenständiger API-Client, kein Teil der Anwendung.**
Es bekommt einen **Geräte-Token** (nicht den Auswerter-Login), darf nur Messungen
schreiben und Starter-Daten lesen, und wird in der DB als `geraet` geführt. Ein Gerät
am offenen Platz muss man notfalls einzeln sperren können.

**c) Netzausfall ist der Normalfall, nicht die Ausnahme.**
Am ADAC-Platz kann das Netz wegbrechen. Der Mess-Pi **muss lokal puffern** (SQLite oder
Datei-Queue) und nach Wiederverbindung nachliefern. Deshalb gilt zwingend:
- jede Messung bekommt eine **UUID vom Messgerät** → Server ist idempotent, doppelt
  gesendete Messungen erzeugen keine Dubletten
- die Messung trägt **zwei Zeitstempel**: Wanduhr (`gemessen_am`) und **monotone
  Gerätezeit** (`monotonic_ns`). Die Wanduhr eines Pi ohne Netz und ohne RTC springt
  beim NTP-Sync — die Dauer zwischen zwei Lichtschranken-Ereignissen darf davon nicht
  abhängen. **Der Pi berechnet die Dauer selbst und sendet sie**, der Server rechnet
  keine Differenz aus zwei Wanduhr-Zeitstempeln.
- der Server nimmt Messungen **rückwirkend** an (`gemessen_am` in der Vergangenheit)
  und markiert sie als nachgeliefert

**d) Zuordnung Messung → Starter ist der kritische Punkt.**
Eine Lichtschranke misst eine Zeit, sie weiß nicht, **wer** durchgefahren ist. Die
Zuordnung muss irgendwo herkommen — Eingabe der Startnummer am Mess-Pi, eine
Warteschlange „nächster Starter" aus der Nennliste, oder ein Transponder/RFID.
→ offene Frage **O-14**. Bis zur Klärung wird konservativ geplant:
- der Mess-Pi holt sich per API die **Startreihenfolge** des laufenden Turniers
- er sendet die Messung **mit** der Startnummer, die er gerade anzeigt
- eine Messung **ohne** zuordenbare Startnummer wird nicht verworfen, sondern als
  `zeitmessung` ohne `start_id` gespeichert und im Frontend zur manuellen Zuordnung
  angeboten. Eine gemessene Zeit ist nicht reproduzierbar — sie darf nie verloren gehen,
  nur weil die Zuordnung fehlte.

**e) Fehlmessungen sind Betriebsrealität.**
Zuschauer, Helfer oder ein zurücksetzendes Motorrad lösen die Lichtschranke aus.
Nötig sind: **Entprellung/Mindestabstand** zwischen zwei Triggern auf dem Pi, ein
**Verwerfen-Knopf** in der Erfassung, sowie Plausibilitätsprüfung serverseitig
(eine Fahrzeit von 3 s oder 900 s ist zu markieren, nicht stillschweigend zu übernehmen).
Jede verworfene Messung bleibt mit Grund gespeichert.

**f) Die Anzeige am Parcours ist ein eigener Anwendungsfall.**
Der Mess-Pi zeigt Starter- und Fahrzeugdaten an, zieht sie also **lesend** aus der API.
Das braucht einen schlanken, schnellen Endpunkt und eine Live-Aktualisierung (SSE),
und er muss **auch bei Netzausfall die zuletzt geladene Startliste weiter anzeigen**.

> ❗ Was genau angezeigt werden soll (Startnummer, Name, Klasse, Fahrzeug, laufende Zeit,
> letzte Zeit?) und auf welcher Hardware (HDMI-Monitor, kleines Display, LED-Tafel) ist
> noch offen → **O-15**.

---

## 4. Datenmodell

```
verein ──┐
         ├──< fahrer ──< start >── turnier >── veranstaltung
saison ──┤              │  │          │
         ├──< klasse ───┘  │          └──< wertungsklasse
         │                 ├──< ergebnis        (Zeit + Fehler, berechnet)
         │                 └──< zeitmessung >── geraet   (Lichtschranke)
         └──< meisterschaft ──< meisterschaft_stand
```

### Tabellen

**`verein`** — Regionalclub / Ortsclub
`id` · `name` („OAMC Reinheim", „MSC Schotten", „PMS Kassel", „Hainstadt") ·
`kurzname` · `adac_gau` · `aktiv`

**`fahrer`** — Stammdaten, **einmalig**, nicht pro Turnier
`id` · `nachname` · `vorname` · `geburtsjahr` · `geburtsdatum` (nullable, für J1-Prüfung
„am Veranstaltungstag 7 Jahre") · `geschlecht` (M/W/D) · `verein_id` ·
`adac_mitgliedsnr` (nullable) · `jugendausweis_gueltig_bis` · `aktiv` · `notiz` ·
`erstellt_am` / `geaendert_am`
→ **Dublettenerkennung** beim Import nötig, siehe §6.3

**`saison`** — Jahr, macht Regeln versionierbar
`jahr` (PK) · `turnierordnung_version` · `streichresultate_tabelle` (JSONB) ·
`nenngeld_cent` · `aktiv`

**`klasse`** — Klassendefinition **pro Saison**
`id` · `saison_jahr` · `code` („J 1", „S 6", „A 4") · `kategorie` (J/S/A) ·
`bezeichnung` · `jahrgaenge` (int[], nur Jugend) · `ccm_max` · `kw_max` ·
`fahrzeugtyp` · `sortierung`

**`veranstaltung`** — der Renntag
`id` · `datum` · `titel` · `ort` · `ausrichter_verein_id` · `ist_doppelturnier` ·
`veranstaltungsleiter` · `turnierleiter` · `status` (geplant/laufend/vorlaeufig/final)

**`turnier`** — der einzelne Wertungslauf (bei Doppelturnier zwei pro Veranstaltung)
`id` · `veranstaltung_id` · `name` („Reinheim" / „Hainstadt") · `veranstalter_verein_id` ·
`zaehlt_meisterschaft` (bool) · `status`

**`wertungsklasse`** — pro Turnier zusammengefasste Klassen
`id` · `turnier_id` · `bezeichnung` („S 5, S 9, S 3, S 6, S 7") ·
`klasse_ids` (int[]) · `sortierung`

**`start`** — eine Teilnahme; ein Fahrer kann mehrere pro Turnier haben
`id` · `turnier_id` · `fahrer_id` · `klasse_id` · `wertungsklasse_id` · `startnummer` ·
`fahrzeug` (Text) · `nenngeld_bezahlt` · `status` (genannt/gestartet/DNF/DNS/DSQ)
→ UNIQUE (`turnier_id`, `startnummer`)

**`ergebnis`** — 1:1 zum Start, getrennt für saubere Nachträge/Korrekturen
`start_id` (PK) · `summe_zeit` (numeric(7,2), **aus `zeitmessung` summiert**) ·
`summe_fehler` (int, **manuell erfasst**) · `gesamt` (numeric(9,2), **berechnet**) ·
`platzierung` (int, **berechnet**) · `zeit_vollstaendig` (bool) ·
`fehler_vollstaendig` (bool) · `erfasst_von` · `erfasst_am` · `korrigiert_am` ·
`korrektur_grund`
→ Die beiden `*_vollstaendig`-Flags machen sichtbar, welche der zwei Quellen (§3.6)
  noch fehlt. Gewertet wird erst, wenn beide gesetzt sind.

**`geraet`** — Messgerät / Anzeige am Parcours
`id` · `bezeichnung` („Lichtschranke Ziel", „Anzeige Start") · `typ`
(lichtschranke/anzeige) · `token_hash` · `aktiv` · `letzte_meldung_am` ·
`firmware_version` · `notiz`
→ `letzte_meldung_am` ist der Heartbeat: das Frontend zeigt, ob die Messung noch lebt

**`zeitmessung`** — Einzelmessung, **nicht** die Summe
`id` (UUID, **vom Gerät vergeben** → Idempotenz) · `geraet_id` · `turnier_id` ·
`start_id` (**nullable** — unzugeordnete Messungen gehen nicht verloren) ·
`startnummer_gemeldet` (int, was das Gerät angezeigt hat) · `messpunkt`
(z. B. „Durchgang 1", „Langsamfahrstrecke") · `dauer_sekunden` (numeric(7,2),
**vom Gerät berechnet**) · `gemessen_am` (timestamptz, Wanduhr) · `monotonic_ns` (bigint) ·
`empfangen_am` · `nachgeliefert` (bool) · `status` (gueltig/verworfen/unzugeordnet) ·
`verworfen_grund` · `roh` (JSONB, Rohereignisse der Lichtschranke)
→ UNIQUE (`id`); Index auf (`turnier_id`, `status`), (`start_id`)

**`aufgabe`** / **`ergebnis_aufgabe`** — *optional, Phase 2*: Einzelwertung je Parcours-Aufgabe
(Slalom, Wippe, Kreisel …). Die heutigen PDFs enthalten nur Summen; die Struktur
vorzusehen kostet jetzt nichts und erlaubt später Detailauswertungen. Sobald die
Lichtschranke mehrere Messpunkte bedient, wächst `zeitmessung.messpunkt` natürlich in
diese Struktur hinein.

**`meisterschaft`** — z. B. „HTH Erwachsene 2026", „HTH Jugend J 3 2026"
`id` · `saison_jahr` · `bezeichnung` · `kategorie` · `klasse_id` (nullable) · `regelwerk` (JSONB)

**`meisterschaft_stand`** — materialisiert, nach jedem Turnier neu berechnet
`meisterschaft_id` · `fahrer_id` · `punkte_gesamt` · `punkte_je_lauf` (JSONB) ·
`gestrichene_laeufe` (JSONB) · `anzahl_siege` (Tie-Break!) · `platz` · `berechnet_am`

**`import_job`** — Audit-Trail jedes API-/Datei-Imports
`id` · `quelle` · `dateiname` · `roh_payload` (JSONB) · `status` · `fehler` ·
`angelegt_von` · `angelegt_am`

**`benutzer`** / **`rolle`** — Admin, Auswerter, Lesend

### Kernprinzipien

- `gesamt` und `platzierung` werden **von der Anwendung berechnet**, nicht importiert —
  importierte Werte werden gegen die Berechnung **geprüft** und Abweichungen gemeldet
  (fängt Excel-Fehler in Altdaten und Regelmissverständnisse auf beiden Seiten)
- Alles **saisonversioniert**: Klassen, Jahrgänge, Streichresultate, Punktetabelle.
  Ergebnisse aus 2019 müssen 2030 noch korrekt reproduzierbar sein.
- Ergebnisse sind **append-only mit Korrektur-Historie**, kein stilles UPDATE

---

## 5. Architektur & Technologie

### 5.1 Vorhandene Umgebung (geprüft auf diesem Gerät)

| | |
|---|---|
| Hardware | Raspberry Pi 4 Model B Rev 1.5, 8 GB RAM, 117 GB Speicher (94 GB frei) |
| OS | Debian 13 (trixie), Linux 6.18 aarch64 |
| **PostgreSQL 17.10** | installiert **und aktiv** ✅ |
| **nginx** | installiert **und aktiv** ✅ |
| **Python 3.13.5** + pip 25.1.1 | ✅ |
| Node.js / npm | ❌ nicht installiert |
| Docker | ❌ nicht installiert |
| git | ❌ **nicht installiert** — vor Projektstart nachinstallieren |

### 5.2 Empfohlener Stack

Der Stack folgt dem, was **schon läuft** — auf einem Pi 4 zählt jedes vermiedene
Laufzeit-Ökosystem.

| Schicht | Wahl | Begründung |
|---|---|---|
| Datenbank | **PostgreSQL 17** | läuft bereits; JSONB für Regelwerke, saubere Constraints, echte Transaktionen |
| Backend | **Python 3.13 + FastAPI** | Python ist da; FastAPI liefert die API-Doku (OpenAPI/Swagger) automatisch mit — wichtig, weil Dritte die API bespielen sollen |
| ORM / Migration | **SQLAlchemy 2 + Alembic** | Schemaänderungen über Jahre nachvollziehbar |
| Validierung | **Pydantic v2** | ein Schema für API-Validierung *und* Doku |
| Templates | **Jinja2**, serverseitig gerendert | Ergebnislisten sind Dokumente, keine App. Kein Build-Schritt, kein Node, sofort suchmaschinenlesbar |
| Interaktivität | **HTMX** (~14 kB, per CDN oder lokal) | Filter/Sortierung/Live-Nachladen ohne SPA-Apparat |
| Live-Updates | **SSE** (Server-Sent Events), von FastAPI direkt unterstützt | Anzeige am Parcours und Live-Ergebnisse; einseitiger Datenfluss, kein WebSocket-Zustand nötig, reconnectet von selbst |
| CSS | handgeschrieben oder **Pico.css** | keine Build-Pipeline |
| Excel/CSV-Import | **openpyxl** + `csv` | die Nennlisten sind `.xlsx` |
| PDF-Export | **WeasyPrint** | Schlussbericht + Ergebnisliste müssen nach FFM |
| Server | **uvicorn** hinter dem vorhandenen **nginx** | nginx macht TLS und liefert Statisches |
| Prozess | **systemd-Unit** | kein Docker nötig |
| TLS | **Let's Encrypt / certbot** | |

**Bewusst nicht gewählt:** React/Vue-SPA (Build-Kette auf dem Pi, kein SEO, viel Aufwand
für Tabellenanzeige) · Docker (Overhead ohne Nutzen bei einer App) · SQLite
(Mehrbenutzerbetrieb am Turniertag, Postgres ist schon da)

### 5.3 Betrieb

```
        ╔═══ Am Parcours ═══════════════╗
        ║  Pi #2 „Mess-Pi"              ║
        ║   Lichtschranke → GPIO        ║
        ║   lokale Queue (SQLite)       ║──┐  POST Messungen (idempotent, gepuffert)
        ║   Anzeige Starter/Fahrzeug    ║<─┼─  GET Startliste + SSE Live
        ╚═══════════════════════════════╝  │
                                           │
  Internet / LAN ──> nginx (TLS, statisch) ┘
                       └→ uvicorn/FastAPI (systemd) → PostgreSQL 17 (lokal)
                                                    → /var/oamc/uploads (PDFs, Bilder)
```

- **Backup:** täglicher `pg_dump` + wöchentliche Vollsicherung auf externes Medium.
  Auf einer SD-Karte/SSD im Pi ist das nicht optional.
- **Offline-Fähigkeit am Turniertag** ist durch die Zeitmessung **Pflicht geworden**, nicht
  mehr optional (§3.6c). Zwei Ebenen:
  1. der **Mess-Pi** puffert lokal und liefert nach — deckt kurze Aussetzer ab
  2. bei Veranstaltungen **ohne Internet** muss der Anwendungs-Pi **mit vor Ort** und
     beide Geräte hängen an einem lokalen Netz (Router/Hotspot ohne Uplink). Die
     Synchronisation zum öffentlichen Server erfolgt danach.
  ⇒ Entscheidung dazu offen, siehe **O-7**.
- **Zeitserver:** ohne Internet gibt es kein NTP. Der Anwendungs-Pi sollte im lokalen
  Netz selbst NTP anbieten, damit die Zeitstempel zusammenpassen. Für die *Messung*
  ist das unkritisch (der Mess-Pi rechnet monoton, §3.6c), für die Protokollierung nicht.

### 5.4 Software auf dem Mess-Pi

Bewusst klein und eigenständig — das Gerät muss auch dann sinnvoll weiterlaufen, wenn
der Server nicht erreichbar ist.

| Teil | Wahl |
|---|---|
| GPIO / Lichtschranke | `gpiozero` mit `pigpio`- oder `lgpio`-Backend; Trigger als **Interrupt**, nicht Polling |
| Zeitmessung | `time.monotonic_ns()`, Entprellung/Mindestabstand konfigurierbar |
| Lokale Queue | SQLite, Einträge bleiben bis vom Server quittiert |
| Versand | HTTP + Geräte-Token, Retry mit Backoff, Batch-Nachlieferung |
| Anzeige | Browser im Kiosk-Modus auf die Anzeige-Seite der Anwendung (§7), Daten per SSE, letzte Startliste im `localStorage` als Offline-Rückfall |
| Betrieb | systemd-Unit, `WatchdogSec`, Autostart, read-only Root-FS erwägen (Stromausfall am Platz) |

> Für saubere Zeiten unter Last ist ein Interrupt-basierter Trigger Pflicht. Ob die
> Genauigkeit eines Linux-Userspace-Prozesses reicht, hängt von der geforderten
> Auflösung ab → **O-16**. Die Ergebnislisten führen **1/100 s** (z. B. `159,16`);
> das ist mit `pigpio` gut erreichbar, mit Polling in Python nicht zuverlässig.

---

## 6. API

Zwei Richtungen: **Ingest** (Daten kommen rein) und **Read** (Daten gehen raus).

### 6.1 Ingest — `POST /api/v1/…` (authentifiziert, API-Key)

| Endpunkt | Zweck |
|---|---|
| `POST /api/v1/veranstaltungen` | Renntag anlegen |
| `POST /api/v1/turniere` | Wertungslauf zum Renntag |
| `POST /api/v1/fahrer` · `PUT /api/v1/fahrer/{id}` | Stammdaten |
| `POST /api/v1/turniere/{id}/starts` | Nennliste (Bulk) |
| `POST /api/v1/turniere/{id}/ergebnisse` | **Ergebnis-Bulk-Upload** ← Kernfall |
| `POST /api/v1/import/xlsx` | Excel-Nennliste/Ergebnisliste als Datei |
| `POST /api/v1/turniere/{id}/finalisieren` | Wertung rechnen, Meisterschaft fortschreiben |

Beispiel-Payload Ergebnis-Upload:

```json
{
  "quelle": "excel-auswertung-v3",
  "idempotenz_schluessel": "2026-05-31-reinheim-final",
  "ergebnisse": [
    { "startnummer": 32, "fahrer": { "nachname": "Gál-Szász", "vorname": "Péter",
      "geburtsjahr": 2015, "geschlecht": "M", "verein": "OAMC Reinheim" },
      "klasse": "J 2", "summe_zeit": 159.16, "summe_fehler": 10,
      "gesamt_erwartet": 10, "platzierung_erwartet": 1 }
  ]
}
```

**Regeln für den Ingest:**

- **Idempotent** über `idempotenz_schluessel` — ein doppelt gesendeter Upload legt keine
  Dubletten an. Am Turniertag mit wackligem Netz ist das Pflicht, nicht Komfort.
- **Zweistufig:** `?dry_run=true` liefert eine Validierungsvorschau (welche Fahrer sind
  neu, welche werden gematcht, welche Werte weichen ab) — erst danach wird geschrieben.
- **`gesamt_erwartet` / `platzierung_erwartet`** sind optional; wenn geliefert, rechnet
  der Server nach und meldet Abweichungen als Warnung, statt sie zu übernehmen.
- Jeder Aufruf landet in `import_job` mit Roh-Payload — bei Streit über eine Platzierung
  ist rekonstruierbar, was wann ankam.

### 6.2 Geräte-API — Zeitmessung & Anzeige *(Mess-Pi, Token-Auth)*

Eigener Namensraum mit eigenem Rechteprofil: schreiben **nur** Messungen, lesen **nur**
das, was die Anzeige braucht. Kompromittierung des Geräts am offenen Platz darf keine
Ergebnisse manipulieren können.

| Endpunkt | Zweck |
|---|---|
| `POST /api/v1/geraete/heartbeat` | „ich lebe" + Firmware/Queue-Länge → Statusanzeige im Frontend |
| `GET /api/v1/geraete/konfiguration` | Entprellzeit, Messpunkte, aktives Turnier — zentral gepflegt statt auf dem Pi |
| `GET /api/v1/turniere/aktiv/startliste` | Startreihenfolge für die Anzeige, ETag-fähig, offlinefest zwischenspeicherbar |
| `GET /api/v1/turniere/aktiv/anzeige` (SSE) | Live-Stream: aktueller Starter, letzte Zeit |
| `POST /api/v1/zeitmessungen` | **Messungen (Batch, idempotent)** ← Kernfall |
| `POST /api/v1/zeitmessungen/{id}/verwerfen` | Fehlmessung markieren |

Beispiel-Payload der Zeitmessung — bewusst als **Batch**, weil der Pi nach einem
Netzausfall mehrere Messungen auf einmal nachliefert:

```json
{
  "geraet": "lichtschranke-ziel-01",
  "messungen": [
    {
      "id": "9f2c1e7a-4d38-4b6e-9a11-5c0b2d7e8f30",
      "turnier_id": 42,
      "startnummer_gemeldet": 32,
      "messpunkt": "durchgang-1",
      "dauer_sekunden": 159.16,
      "gemessen_am": "2026-05-31T10:14:02.482+02:00",
      "monotonic_ns": 884213771004,
      "roh": { "trigger_start_ns": 884054611004, "trigger_ziel_ns": 884213771004 }
    }
  ]
}
```

Antwort quittiert **jede Messung einzeln** (`angenommen` / `duplikat` / `unzugeordnet` /
`unplausibel`) — erst eine Quittung löscht den Eintrag aus der lokalen Queue des Pi.

**Festlegungen:**
- Die **`id` vergibt das Gerät** (UUIDv4/v7). Nur so ist Nachliefern nach Timeout ohne
  Dubletten möglich — der Pi weiß nach einem abgebrochenen Request nicht, ob der Server
  ihn verarbeitet hat, und darf ihn deshalb gefahrlos wiederholen.
- Die **Dauer kommt fertig vom Gerät**, der Server rechnet keine Differenz aus Wanduhr-
  Zeitstempeln (Begründung §3.6c).
- `startnummer_gemeldet` ist ein **Hinweis, kein Fremdschlüssel**. Der Server löst sie
  gegen die Startliste auf; scheitert das, wird die Messung als `unzugeordnet`
  gespeichert und im Frontend zur Zuordnung angeboten — **nie verworfen**.
- Plausibilitätsgrenzen (min/max Fahrzeit je Klasse) sind konfigurierbar; Verstöße
  werden **markiert**, nicht abgelehnt.
- Der Geräte-Token ist **nicht** der Auswerter-Login und einzeln sperrbar.

### 6.3 Read — `GET /api/v1/…` (öffentlich, ohne Key)

```
GET /api/v1/veranstaltungen?saison=2026
GET /api/v1/turniere/{id}/ergebnisse?wertungsklasse=J3
GET /api/v1/fahrer?q=bernius&verein=OAMC+Reinheim
GET /api/v1/fahrer/{id}/historie
GET /api/v1/meisterschaften/{id}/stand
GET /api/v1/meisterschaften/{id}/endlauf-qualifikation
```

Zusätzlich **iCal** (`/termine.ics`) für den Terminkalender und **CSV-Export** je Liste.

### 6.4 Fahrer-Matching beim Import

Der heikelste Teil des Imports. Aus den Altdaten sichtbar: Namen mit Sonderzeichen
(*Gál-Szász*), Vereinsangaben mal als „OAMC Reinheim", mal als „Hainstadt" (Ortsname
statt Clubname), Namensgleichheiten in Familien (*Gál-Szász Péter* / *Máté* / *János*;
*Bernius Meik* / *Jörg*; *Krack Robin* / *Luca*; *Tinz Xenia* / *Enrique*).

Vorgehen:
1. Exakter Match auf (Nachname, Vorname, Geburtsjahr) — normalisiert (Unicode NFKD,
   Kleinschreibung, Bindestriche)
2. Unscharfer Match (Levenshtein / `pg_trgm`) → **Vorschlag**, nie automatisch
3. Kein Match → neuer Fahrer wird angelegt, aber im Import-Report als „NEU" markiert
4. **Merge-Funktion** im Admin, um nachträglich erkannte Dubletten zusammenzuführen

---

## 7. Seiten (Frontend)

**Öffentlich:**

| Seite | Inhalt |
|---|---|
| Startseite Motorrad-Turnier | nächster Termin, letzte Ergebnisse, aktueller Meisterschaftsstand |
| **Termine** | Saisonkalender, mit/ohne Meisterschaftswertung, Ausrichter, iCal-Abo |
| **Ergebnisse** | je Veranstaltung → Turnier → Wertungsklasse, sortierbar, mobil lesbar |
| **Live** (Turniertag) | vorläufiger Stand, sobald Zeiten eintreffen — deutlich als *vorläufig* gekennzeichnet, solange Fehlerpunkte fehlen (§3.6) |
| **Fahrer** | durchsuchbare Liste (löst die „BAUSTELLE" ab) |
| **Fahrerprofil** | Stammdaten, alle Starts, Platzierungen, Bestzeiten, Saisonverlauf |
| **Meisterschaft** | HTH-Stand Erwachsene + Jugend J 1–J 5, inkl. Streichresultat-Kennzeichnung |
| **Endlauf-Qualifikation** | aktueller Stand der Top-10-Plätze |
| Sportbeschreibung / Ausschreibung / Downloads | bestehende Inhalte, sauber übernommen |

**Intern (Login):**

| Seite | Inhalt |
|---|---|
| Nennungsannahme | Fahrer suchen/anlegen, Klasse automatisch aus Jahrgang vorschlagen, Startnummer vergeben, Nenngeld quittieren |
| Ergebniserfassung | schnelle Eingabe Zeit/Fehler je Startnummer, tastaturoptimiert |
| Auswertung | Wertungsklassen bilden, rechnen, vorläufig/final setzen |
| Korrekturen | mit Begründung, mit Historie |
| Exporte | Ergebnisliste (PDF, ADAC-Layout), Schlussbericht, Nennliste, CSV |
| **Messungen zuordnen** | unzugeordnete/unplausible Lichtschranken-Messungen einem Start zuweisen oder mit Grund verwerfen |
| **Geräte** | Mess-Pi-Status (Heartbeat, Queue-Länge), Token vergeben/sperren, Entprellzeit und Messpunkte konfigurieren |
| Import-Monitor | Import-Jobs, Warnungen, Fahrer-Dubletten mergen |
| Stammdaten | Saison, Klassen, Vereine, Punktetabelle, Benutzer |

**Anzeige am Parcours** (eigener, minimaler Modus für den Mess-Pi):

| Seite | Inhalt |
|---|---|
| `/anzeige` | aktueller Starter groß (Nr., Name, Klasse, Fahrzeug), laufende/letzte Zeit, nächste Starter; SSE-Update; Kiosk-tauglich; **behält bei Verbindungsverlust die letzte Startliste** und zeigt den Offline-Zustand deutlich an |

**Anforderungen quer:** responsiv (am Platz wird das Handy benutzt) · Deep-Links auf jede
Ergebnisliste · druckbare Ansichten · Aushang-/Beamer-Modus (große Schrift,
Autorefresh) · barrierearm (Kontrast, Tabellen-Semantik)

---

## 8. Arbeitspakete

### AP 0 — Klärung & Setup *(vor allem anderen)*
- Offene Fragen §10 mit dem Verein / Bereichsleiter klären
- **ADAC-Turnierordnung 2026 (`MT-D2025.pdf`) beschaffen und Wertungsregeln verifizieren**
- Punktetabelle Meisterschaft beschaffen
- `git` installieren, Repository anlegen, Python-venv, Projektgerüst
- Zugriff auf die Excel-Vorlagen und ein paar echte Nennlisten

### AP 1 — Datenmodell & Migrationen
- SQLAlchemy-Modelle + Alembic-Initialmigration
- Stammdaten-Seed: Saison 2026, Klassen J 1–J 5, S/A-Klassen, Vereine
- Unit-Tests auf Constraints (Mehrfachstart erlaubt, Startnummer eindeutig je Turnier)

### AP 2 — Wertungs-Engine *(der Kern — zuerst und mit Tests)*
- Regelstrategien je Kategorie (Jugend: Fehler → Zeit; Erwachsene: Zeit + Fehler)
- Platzierung inkl. Gleichstandsauflösung, DNF/DNS/DSQ-Behandlung
- **Regressionstest gegen die reale Ergebnisliste vom 31.05.2026** — alle 13 Wertungs-
  blöcke müssen exakt die publizierten Platzierungen reproduzieren. Das ist der
  Abnahmetest für die Engine.

### AP 3 — Meisterschaftsberechnung
- Punktevergabe, Streichresultate nach Tabelle §3.4
- Tie-Break „Majorität der Siege"
- Endlauf-Qualifikationsvorschlag Top 10 / Top 10 Jugend
- Nachrechnen gegen einen veröffentlichten HTH-Jahresstand als Test

### AP 4 — API
- Read-Endpunkte + OpenAPI-Doku
- Ingest-Endpunkte, Idempotenz, `dry_run`, API-Key-Auth, Rate-Limit
- Import-Job-Protokollierung
- Fahrer-Matching inkl. Merge

### AP 5 — Zeitmessung: Geräte-API & Mess-Pi
- Geräte-Registrierung, Token, Heartbeat, zentrale Konfiguration
- `POST /zeitmessungen` mit Batch, Idempotenz, Einzelquittung, Plausibilitätsprüfung
- Auflösung `startnummer_gemeldet` → Start; unzugeordnete Messungen im Frontend behandeln
- **Client auf dem Mess-Pi:** GPIO-Trigger, Entprellung, monotone Zeitmessung, lokale
  SQLite-Queue, Retry mit Backoff, Kiosk-Anzeige mit Offline-Rückfall
- SSE-Endpunkt und `/anzeige`-Seite
- **Abnahmetest:** Netzstecker während der Messung ziehen — nach Wiederverbindung müssen
  alle Messungen genau einmal in der DB stehen. Ebenso: Batch doppelt senden → keine Dubletten.
- **Kalibrierung:** gemessene Zeiten gegen eine Handstoppung/Referenz vergleichen, bevor
  produktiv damit gewertet wird

### AP 6 — Öffentliches Frontend
- Layout, Navigation, responsive Tabellen
- Termine, Ergebnisse, Fahrerliste, Fahrerprofil, Meisterschaft
- iCal, CSV, Druckansichten

### AP 7 — Internes Frontend
- Login/Rollen, Nennungsannahme, Ergebniserfassung, Auswertung, Korrekturen
- Exporte (PDF-Ergebnisliste im ADAC-Layout, Schlussbericht)

### AP 8 — Datenübernahme Altbestand
- Import der PDF-Ergebnisse ab einem zu definierenden Jahr
  (⚠️ die PDFs nutzen Subset-Fonts mit eigener Kodierung — reine Textextraktion schlägt
  bei den Meisterschafts-PDFs fehl; realistisch ist ein **halbautomatischer** Import mit
  manueller Nacharbeit, ggf. direkt aus den Excel-Originalen statt aus den PDFs)
- Vereinheitlichung Vereinsnamen, Dublettenbereinigung Fahrer

### AP 9 — Deployment & Betrieb
- systemd-Unit, nginx-vHost, TLS
- Backup-Automatik + **getesteter Restore**
- Monitoring, Logrotation
- Einweisung der Auswerter, Kurzanleitung

### AP 10 — Pilotbetrieb
- Eine Veranstaltung **parallel** zu Excel auswerten und Ergebnisse vergleichen
- **Zeitmessung zunächst nur mitlaufen lassen**, nicht werten: Lichtschranken-Zeit gegen
  die manuell gestoppte Zeit stellen. Erst wenn beide über eine ganze Veranstaltung
  übereinstimmen, wird die Messung wertungsrelevant.
- Erst nach fehlerfreiem Parallellauf umstellen

---

## 9. Ausbaustufen nach dem Kern

- **Online-Voranmeldung** — die Rahmenausschreibung wünscht ausdrücklich Voranmeldung
  größerer Teilnehmergruppen und eine Anmeldeliste; das ist die naheliegendste Erweiterung
- **Aufgaben-Einzelwertung** (Tabellen aus §4 bereits vorgesehen) → „woran verliere ich Zeit?"
- Bildarchiv mit Verknüpfung Foto ↔ Fahrer ↔ Veranstaltung
- Automatische Meldung von Schlussbericht/Ergebnisliste an den ADAC
- Mehrmandantenfähigkeit für andere Ortsclubs (MSC Schotten, MSC Hainstadt, PMS Kassel …)
- Übernahme der übrigen oamc.de-Rubriken aus dem Frameset

---

## 10. Offene Fragen

| # | Frage | Warum blockierend |
|---|---|---|
| **O-1** | **Punktetabelle der Meisterschaft** (Platz → Punkte) | AP 3 nicht baubar |
| **O-2** | Zuordnung `S 1`–`S 9` und `A 1`–`A 4` → Fahrzeugtyp/Hubraum/kW | Stammdaten-Seed |
| **O-3** | Zählen **A-Fahrer** zur Meisterschaft? Die Rahmenausschreibung sagt „Gesamtklassement der A- und S-Fahrer/innen", die Spalte `Kategorie` ist bei A-Fahrern in der Ergebnisliste jedoch **leer** (bei S steht „S", bei Jugend „J") | AP 3 |
| **O-4** | Gilt die Jugend-Wertung (nur Fehler) auch beim Bundesendlauf, oder dort Zeit+Fehler? | AP 2 |
| **O-5** | Behandlung von DNF / DNS / Disqualifikation in Tages- und Jahreswertung | AP 2/3 |
| ~~O-6~~ | ~~Wer soll die API bespielen?~~ → **beantwortet:** ein zweiter Raspberry Pi an der Lichtschranke, der Zeiten sendet und Starter-/Fahrzeugdaten anzeigt (§3.6) | erledigt |
| **O-7** | **Ist am ADAC-Platz ein verlässliches Netz?** Wenn nein: muss der Anwendungs-Pi mit vor Ort? WLAN, LTE oder Kabel zwischen Mess-Pi und Server? | **hoch** — bestimmt die gesamte Betriebsarchitektur (§5.3) |
| **O-8** | Ab welchem Jahr sollen Altdaten übernommen werden (PDFs reichen bis 2002 zurück)? | Aufwand AP 8 |
| **O-9** | Wo wird gehostet — dieser Raspberry Pi, ein Server beim Verein, Webhosting? | AP 9, Erreichbarkeit |
| **O-10** | Verhältnis zur bestehenden oamc.de: Unterseite, Subdomain (z. B. `mt.oamc.de`) oder Ablösung? | Navigation, DNS |
| **O-11** | Wer bekommt Schreibrechte, wie viele Auswerter, gemeinsamer Account oder je Person? | AP 7 |
| **O-12** | Liegen die Excel-Originale der Altveranstaltungen noch vor? | macht AP 8 um ein Vielfaches einfacher |

### Neue Fragen zur Zeitmessung

| # | Frage | Warum blockierend |
|---|---|---|
| **O-13** | Was misst die Lichtschranke genau? **Eine** Gesamtdurchfahrt, **mehrere Durchgänge** oder einzelne Abschnitte (Langsamfahrstrecke …)? Woraus setzt sich `Summe Zeit` zusammen? | bestimmt `zeitmessung.messpunkt` und die Summenbildung; AP 5 |
| **O-14** | **Woher weiß der Mess-Pi, wer gerade fährt?** Startnummer manuell eintippen, Warteschlange „nächster Starter" aus der Nennliste, Transponder/RFID? | kritischster Punkt der Zuordnung; AP 5 |
| **O-15** | Was genau soll die **Anzeige** zeigen und auf welcher Hardware (HDMI-Monitor, kleines Display, LED-Tafel)? Für wen — Fahrer, Publikum, Wertungspersonal? | Gestaltung `/anzeige`; AP 5 |
| **O-16** | Geforderte **Messgenauigkeit**? Die Listen führen 1/100 s. Reicht Userspace-GPIO oder braucht es dedizierte Hardware? Ein oder zwei Lichtschranken (Start **und** Ziel)? | Hardware-Auswahl, AP 5 |
| **O-17** | **Wie kommen die Fehlerpunkte in die Anwendung** — Zettel vom Wertungspersonal und zentrale Eingabe, oder Tablets im Parcours? | AP 7; Phase 2 könnte hier ansetzen |
| **O-18** | Löst die Lichtschranke **automatisch** aus (Fahrzeug unterbricht Strahl) oder gibt es zusätzlich einen manuellen Start-/Stopp-Taster als Rückfall? | Ausfallkonzept, AP 5 |
| **O-19** | Wer baut/betreut die **Hardware** (Lichtschranke, Verkabelung, Stromversorgung am Platz)? Existiert sie schon oder wird sie beschafft? | Terminplanung |

---

## 11. Datenschutz

**Das ist hier kein Formalpunkt.** Es werden **Namen, Geburtsjahre, Geschlecht und
Vereinszugehörigkeit von Kindern ab 7 Jahren** verarbeitet und **öffentlich im Internet
angezeigt**. Die heutige Praxis (Namen in öffentlichen PDFs) wird durch eine
durchsuchbare Datenbank mit Personenprofilen **qualitativ verändert** — aus einer
schwer auffindbaren PDF-Liste wird ein über Jahre verknüpftes Profil eines Minderjährigen.
Das ist datenschutzrechtlich eine andere Kategorie und muss vor dem Livegang geklärt sein.

Zu klären und umzusetzen:

- **Rechtsgrundlage** je Verarbeitung; Einwilligung der Erziehungsberechtigten für die
  Veröffentlichung von Jugenddaten (idealerweise in Nennformular/Haftungsausschluss
  aufnehmen — die Formulare werden ohnehin unterschrieben)
- **Datenminimierung öffentlich:** Geburts*jahr* statt Geburtsdatum, kein Wohnort,
  keine Kontaktdaten, keine ADAC-Mitgliedsnummer
- **`robots.txt` / `noindex`** für Fahrerprofile — Ergebnislisten dürfen auffindbar sein,
  Personenprofile von Minderjährigen sollten es nicht sein
- **Opt-out**: Anzeige als „Teilnehmer 12" oder Namenskürzel auf Wunsch
- **Löschkonzept / Aufbewahrungsfristen**, Auskunfts- und Berichtigungsrecht
- **Verzeichnis von Verarbeitungstätigkeiten**, TOMs (Backup-Verschlüsselung, TLS,
  Zugriffsrollen, Protokollierung)
- Ggf. **Auftragsverarbeitung** mit dem Hoster

> Empfehlung: Vor AP 6 (öffentliches Frontend) eine Entscheidung des Vorstands
> herbeiführen, wie Jugenddaten öffentlich dargestellt werden. Die technische Umsetzung
> ist einfach — die Entscheidung ist es nicht, und sie nachträglich zu ändern bedeutet,
> bereits indexierte Seiten wieder einzufangen.

---

## 12. Risiken

| Risiko | Auswirkung | Gegenmaßnahme |
|---|---|---|
| Wertungsregeln in §3.3 sind aus PDFs **abgeleitet**, nicht bestätigt | falsche Platzierungen, Vertrauensverlust | AP 0: Turnierordnung beschaffen; AP 2: Regressionstest gegen echte Listen; AP 10: Parallellauf |
| Ausfall am Turniertag (Pi, Netz, Strom) | Veranstaltung blockiert | Excel-Fallback bereithalten, bis der Parallellauf sauber ist; Export vor Ort möglich halten |
| **Lichtschranke fällt aus oder misst falsch** | Zeiten des laufenden Turniers fehlen — **nicht nachholbar**, die Fahrt ist vorbei | manuelle Zeitnahme als Rückfall **immer** parallel bereithalten; manuelle Nacherfassung im Frontend; Plausibilitätsprüfung serverseitig; AP 10 misst zunächst nur mit |
| **Fehlauslösung** durch Zuschauer/Helfer/rangierendes Motorrad | falsche Zeit im Ergebnis | Entprellung auf dem Pi, Verwerfen-Funktion mit Grund, Plausibilitätsgrenzen, Vier-Augen-Prinzip vor „final" |
| **Messung dem falschen Fahrer zugeordnet** | zwei Ergebnisse gleichzeitig falsch, schwer zu bemerken | Zuordnung (O-14) früh und sauber klären; Anzeige am Parcours macht die Zuordnung für alle sichtbar → Fehler fällt sofort auf |
| Netzausfall zwischen Mess-Pi und Server | Messungen gehen verloren | lokale Queue + Idempotenz (§3.6c); Abnahmetest in AP 5 zieht bewusst den Netzstecker |
| Altdaten-Import aus PDFs scheitert an Font-Kodierung | AP 8 wird teuer | Excel-Originale beschaffen (O-12); Import zeitlich begrenzen; notfalls Start ab 2026 |
| Fahrer-Dubletten durch Namensvarianten | falsche Meisterschaftsstände | Matching + Merge-Werkzeug in AP 4, Import-Report mit „NEU"-Markierung |
| Datenschutzthema Jugenddaten wird spät geklärt | Livegang verzögert oder Rückbau | §11 vor AP 6 entscheiden |
| Projekt hängt an einer Person | keine Wartung | Doku, sauberes Repo, zweite eingewiesene Person |
| Raspberry Pi: SD-Karte/Speicherausfall | Datenverlust | Backup extern + Restore testen, SSD statt SD-Karte erwägen; auf dem Mess-Pi read-only Root-FS erwägen |
| Scope-Ausweitung (Online-Nennung, Bildarchiv …) | Kern wird nie fertig | §9 ist bewusst *nach* dem Kern; AP 10 ist der Zielpunkt |

---

## 13. Nächster Schritt

1. Diesen Plan im Verein durchgehen, insbesondere **§10 (offene Fragen)** und
   **§11 (Datenschutz)**
2. **ADAC-Turnierordnung 2026 und Punktetabelle beschaffen** — ohne die stehen AP 2 und AP 3
3. **Zeitmessung klären: O-13 (was wird gemessen), O-14 (Zuordnung zum Fahrer),
   O-16 (Genauigkeit/Hardware), O-19 (wer baut sie)** — davon hängt AP 5 komplett ab
4. Entscheidung zu **O-7** (Netz am Platz) und **O-9/O-10** (Hosting, Domain)
5. Danach AP 0 → AP 1 → AP 2

> **Reihenfolge-Hinweis:** Die Zeitmessung ist das sichtbarste, aber nicht das erste
> Arbeitspaket. Sie liefert nur die Hälfte eines Ergebnisses (§3.6) und braucht Turnier,
> Startliste und Wertungslogik als Unterbau. AP 1–3 zuerst, dann AP 5 — sonst hat der
> Mess-Pi nichts, wogegen er Startnummern auflösen könnte.

---

### Quellen

- `www.oamc.de` — Startseite, Navigation, Rubrik Motorradgruppe (`m/m1.htm`, `m/m2.htm`,
  `m/m-sportbeschreibung.htm`), Downloadseite `d/d-mot-turnier.htm`
- `www.oamc.de/datei/2026-05-31-MT-REIN-HAIN.PDF` — Tagesergebnis Doppelturnier
  MSC Hainstadt / OAMC Reinheim, 13 Wertungsblöcke; Grundlage für §3.3
- `www.oamc.de/datei/MT-Rahmenausschreibung-2026.pdf` (Stand 1.2.2026) — Nenngeld,
  Nennschluss, Streichresultate, Jugend-Klasseneinteilung, Endlaufqualifikation
- Systemprüfung auf dem Zielgerät (Raspberry Pi 4B) für §5.1