Moped-Tracking/plan.md

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.