63 lines
5.3 KiB
Markdown
63 lines
5.3 KiB
Markdown
# 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. |