Init

plan.md

@@ -0,0 +1,63 @@
+# 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.