# Prompt: Familien-Motorrad-Tracker (Web-App)

Baue eine vollständige, produktionsreife Web-App, mit der eine Familie gemeinsam mehrere Motorräder verwaltet: Reparaturen, TÜV/HU-Termine, Inspektionen, Reifen-/Ölwechsel und ein Fahrtenbuch. Die App läuft als Docker-Projekt auf einem eigenen Server hinter einer Domain.

## 1. Nutzung & Rollen

- Mehrere Benutzer (Familie) teilen sich **einen gemeinsamen Datenbestand** (kein getrenntes Multi-Tenant-System) – jeder sieht alle Motorräder.
- Zwei Rollen:
    - **Admin**: kann Benutzer anlegen/löschen/Rolle ändern, Motorräder löschen, alles was Mitglieder auch können.
    - **Mitglied**: kann Motorräder anlegen/bearbeiten, Wartungseinträge und Fahrten erfassen, aber keine Benutzerverwaltung und kein Löschen von Motorrädern.
- Login per E-Mail + Passwort (kein öffentliches Self-Signup — Benutzer werden ausschließlich vom Admin angelegt).
- Beim allerersten Start der App wird automatisch ein erster Admin-Account aus Umgebungsvariablen erzeugt (`ADMIN_EMAIL`, `ADMIN_PASSWORD`, `ADMIN_NAME`), falls noch keine Benutzer existieren.
- Es muss immer mindestens ein Admin-Account bestehen bleiben (Löschen/Degradieren des letzten Admins verhindern).

## 2. Datenmodell

**Motorrad**
- Name/Spitzname, Marke, Modell, Baujahr, Fahrgestellnummer (VIN), Kennzeichen, aktueller Kilometerstand, Notizen.

**Wartungs-Ereignis** (pro Motorrad, mehrere Einträge über die Zeit)
- Typ: Reparatur, TÜV/HU, Inspektion, Reifenwechsel, Ölwechsel, Sonstiges
- Titel, Beschreibung, Datum, Kilometerstand, Kosten (€)
- Optional: nächster Fälligkeitstermin (Datum) UND/ODER nächste Fälligkeit (km-Stand) — daraus werden Erinnerungen/Status abgeleitet
- Ersteller (welcher Benutzer hat den Eintrag angelegt)
- Optional ein angehängtes Dokument/Foto (z. B. Rechnung, Foto vom Mängelbericht)

**Fahrtenbuch-Eintrag** (pro Motorrad)
- Datum, Fahrer (Benutzer), Start-km, End-km (Distanz wird daraus berechnet), Zweck, Notizen

**Benutzer**
- Name, E-Mail, Passwort (gehasht), Rolle (Admin/Mitglied)

Der aktuelle Kilometerstand eines Motorrads soll sich automatisch aktualisieren, wenn ein neuer Wartungseintrag oder eine Fahrt mit einem höheren km-Stand erfasst wird.

## 3. Kernfunktionen

- **Dashboard/Übersicht**: alle Motorräder auf einen Blick, mit visuellem Status für TÜV und Inspektion (grün = ok, gelb = bald fällig, rot = überfällig). Liste der nächsten anstehenden Termine über alle Motorräder hinweg.
- **Motorrad-Detailseite**: Stammdaten, komplette Wartungshistorie (neueste zuerst), Formular zum Hinzufügen neuer Einträge inkl. Datei-Upload, Fahrtenbuch-Tabelle mit Formular zum Erfassen neuer Fahrten.
- **Admin-Bereich**: Benutzerliste, neuen Benutzer anlegen, Rolle ändern, Benutzer löschen.
- Responsive, auch gut auf dem Handy in der Werkstatt/unterwegs bedienbar.

## 4. Design-Richtung

- Werkstatt-/Technik-Ästhetik, keine generische SaaS-Optik. Kein cremefarbenes Standard-Design mit Terracotta-Akzent, kein reines Schwarz mit Neon-Akzent.
- Farbpalette: dunkles warmes Anthrazit/Ink als Basis, warmes Papier-Weiß als Hintergrund für Inhalte, Stahlgrau für sekundäre Elemente, Signalgelb (Werkstatt/Warnband) als Hauptakzent, Rostrot für "überfällig", gedämpftes Grün für "ok".
- Typografie: eine kondensierte, kräftige Headline-Schrift (z. B. Oswald) für Überschriften, eine gut lesbare Grotesk für Fließtext, eine Monospace-Schrift für Kilometerstände/Zahlen (Tacho-Optik).
- **Signature-Element**: TÜV-Plakette als visuelles Element für Fälligkeiten — eine runde "Prüfplakette" mit Monat/Jahr, deren Farbe den Status zeigt (grün/gelb/rot). Wird im Dashboard und auf der Motorrad-Karte verwendet.

## 5. Technischer Rahmen

- **Frontend + Backend**: Next.js (App Router, TypeScript), Server Actions/Route Handlers statt separatem REST-Backend.
- **Datenbank**: SQLite, idealerweise über Node's eingebautes `node:sqlite` oder eine reine JS-Lösung — **keine Abhängigkeit, die native Kompilierung oder externe Binär-Downloads beim Build braucht** (das erschwert Docker-Builds unnötig). Datenbankdatei liegt in einem gemounteten Volume.
- **Auth**: Sitzungsbasiert (z. B. NextAuth mit Credentials-Provider + JWT-Session), Middleware schützt alle Seiten außer Login.
- **Datei-Uploads**: Anhänge (Belege/Fotos) werden im Dateisystem in einem gemounteten Volume gespeichert, nicht in der Datenbank; Auslieferung über eine geschützte Route.
- **Styling**: Tailwind CSS.
- **Deployment**: fertiges Docker-Projekt mit `Dockerfile` (Multi-Stage-Build) und `docker-compose.yml`. Volumes für Datenbank und Uploads, damit Daten Container-Neustarts überleben. `.env.example` mit allen nötigen Variablen (Admin-Zugang, Auth-Secret, Port). Soll problemlos hinter einem Reverse Proxy (z. B. nginx/Traefik) mit eigener Domain laufen.
- Nach dem Bauen: `npm run build` muss fehlerfrei durchlaufen; Code muss TypeScript-sauber und ohne Lint-Fehler sein.

## 6. Liefergegenstand

- Vollständiger, lauffähiger Quellcode als Projektstruktur.
- `README.md` mit: lokaler Entwicklung, Docker-Build & -Start, Standard-Admin-Zugang, Hinweis zum Passwortwechsel nach erstem Login, Hinweis zu Backups (welche Pfade/Volumes gesichert werden müssen).
- Kurzer Hinweis auf sinnvolle nächste Ausbaustufen (z. B. E-Mail-Erinnerungen vor Fälligkeit, Mehrsprachigkeit, PDF-Export der Wartungshistorie) — aber nicht implementieren, nur erwähnen.