# ROADMAP — Rippy

> Meilenstein-Plan für den Bau von Rippy. Jede Etappe ist lauffähig für sich.

---

## Etappe 1: Fundament — Container-Infrastruktur + udev-Erkennung

**Ziel:** Das System bootet, erkennt eine eingelegte Disc und erstellt einen Job.

**Was gebaut wird:**
- Docker Compose mit `api`, `worker`, `ui`, `postgres`, `redis`
- Basis-Dockerfiles für jeden Service (Python/FastAPI, Python/Celery, Node/React, PostgreSQL, Redis)
- udev-Regel + separater Daemon (Python), der Disc-Einwurf erkennt und Jobs an den Worker sendet
- Device-Resolver: ermittelt UUID/Serial des Laufwerks, erzeugt Symlink `/dev/disc/<uuid>`
- Job-Erstellung in Celery-Queue mit Disc-Typ und Device-Pfad

**Fertig wenn:**
- ✅ `docker compose up` startet alle 5 Container
- ✅ udev-Regel erkennt Disc-Einwurf
- ✅ udev-Daemon erstellt Celery-Job
- ✅ Celery-Worker nimmt den Job entgegen und gibt "Disc erkannt: DVD, Device: /dev/disc/xxx" aus

**Status:** Abgeschlossen

---

## Etappe 2: Ripping-Pipeline — Verlustfreies Extrahieren

**Ziel:** Disc wird rippt und als rohe Dateien abgelegt.

**Was gebaut wird:**
- CD-Ripping via `abcde` → FLAC, AcoustID-Fingerprinting (chromaprint) + MusicBrainz-Lookup
- DVD/Blu-ray-Ripping via `makejungles` (makeMKV-Äquivalent, OpenSource) → MKV, mit `--all --progress`
- Ripping im Worker-Container, Read-Only Device-Passthrough
- Fortschritts-Reporting über Celery-Signale an SSE-Stream

**Fertig wenn:**
- CD → FLAC-Dateien + MusicBrainz-Metadaten
- DVD → MKV mit allen Titeln
- Blu-ray → MKV mit allen Titeln
- Fortschritt wird in Echtzeit im UI angezeigt

---

## Etappe 3: Metadaten-Lookup + Pre-Scan

**Ziel:** Vor dem Ripping wird die Disc identifiziert und der Commander bestätigt.

**Was gebaut wird:**
- Pre-Scan-Modul: liest TOC (kein Ripping), extrahiert Titel/Laufzeit/Scene-Labels
- TMDB-Integration für Film-/Serien-Matching (Confidence-Score)
- MusicBrainz-Integration für CD-Matching
- TheTVDB-Fallback für Serien
- SQLite-Cache für API-Antworten (LRU, 10k Einträge, TTL)
- Pre-Scan-Latenz: 5–15s, dokumentiert

**Fertig wenn:**
- Nach Disc-Einwurf: Pre-Scan läuft automatisch
- UI zeigt: Titel, Jahr, Cover, Confidence-Score, Trackliste
- Commander kann bestätigen oder manuell korrigieren
- Bestätigte Metadaten werden im Cache persistiert

**Status:** Abgeschlossen

---

## Etappe 4: Jellyfin-Formatierung + NFO-Generierung

**Ziel:** Gerippte Dateien liegen in Jellyfin-konformer Ordnerstruktur mit Metadaten.

**Was gebaut wird:**
- Ordnerstruktur:
  - Filme: `<Filmname> (<Jahr>)/<Filmname>-<title>.mkv`
  - Serien: `<Serienname>/<Staffel N>/<Serienname> - S{N}E{N} - <Episode>.mkv`
  - Musik: `<Künstler>/<Album> (<Jahr>)/<Track-Nr>. <Titel>.flac`
- NFO-Generator im Kodi/NFO-Schema:
  - `movie.nfo`, `series.nfo`, `episode.nfo`, `album.nfo`
  - Alle Metadaten aus Pre-Scan + NFO-Attribution (Source: TMDB)
- Image-Downloader: poster.jpg (500x750), fanart.jpg, backdrop.jpg (1920x1080+) von TMDB
- Jellyfin-kompatible Dateibenennung
- Multi-Disc-Handling: `Disc 1.mkv`, `Disc 2.mkv` etc.

**Fertig wenn:**
- Gerippte Dateien + NFO + Poster in Jellyfin-Ordnerstruktur
- Jellyfin scannt und erkennt alles korrekt
- Multi-Disc-Sets werden als eine Entität angezeigt

**Status:** Abgeschlossen

---

## Etappe 5: API + Auth + WebUI

**Ziel:** Vollständiger Web-Dienst mit Echtzeit-Status und Job-Steuerung.

**Was gebaut wird:**
- FastAPI mit JWT-Auth (Access 15min, Refresh 7 Tage), Rate-Limiting (100/min/API-Key)
- REST-Endpoints: Jobs erstellen/listen/abbrechen, Geräte verwalten, Einstellungen
- SSE-Stream für Echtzeit-Jobstatus
- React-UI (Vite-Build → statisch via Nginx):
  - Dashboard mit Echtzeit-Kacheln (Job-Status, Queue, Disc-Einwurf)
  - Job-Verlauf mit Fortschrittsbalken
  - Metadaten-Preview mit Bestätigungs-Dialog
  - Job-Detail mit Live-Log
  - Ergebnis-View mit Ordnerstruktur-Preview
  - Einstellungen (API-Keys, Transcoding, Backup-Pfade, Jellyfin-Config)
  - Geräte-Verwaltung

**Fertig wenn:**
- Commander kann UI im Browser öffnen und alles bedienen
- Jobs starten, stoppen, Verlauf einsehen
- Echtzeit-Updates via SSE funktionieren
- Alle Einstellungen werden gespeichert

**Status:** Abgeschlossen

---

## Etappe 6: Sicherheit + Compliance + Hardening

**Ziel:** Produktionsreif — sicher, compliant, robust.

**Was gebaut wird:**
- SELinux/AppArmor Profile pro Container
- Read-only Bind-Mounts für System-Bibliotheken
- mTLS zwischen API ↔ Worker
- Netzwerk-Policy: UI→API (HTTPS), API↔Worker (mTLS), Worker↔Internet (nur API)
- PostgreSQL mit verschlüsselten Connections
- Source-Release-Endpoint (GPL-v3-Compliance)
- Lizenz-Dokumentation (MakeMKV, OpenSource-Komponenten)
- Backup-Hooks (PBS-Snapshot-Integration)
- Error-Handling: exponential backoff Retry (max 5), Circuit-Breaker für APIs

**Fertig wenn:**
- Alle Container haben Security-Profile
- Netzwerkverkehr zwischen Containern ist verschlüsselt
- GPL-v3-Compliance-Checkliste abgehakt
- Backup-Hooks funktionieren

**Status:** Abgeschlossen

---

## Etappe 7: API UI Modernisiert

**Ziel:** Modernes React-UI mit Dark Mode Support.

**Was gebaut wird:**
- React UI mit TailwindCSS
- Sidebar Navigation
- Einstellungen mit Tab-Struktur
- Dark Mode mit Theme-Toggle und localStorage persistence
- Status-Badges und StatCards mit Dark Mode Support

**Fertig wenn:**
- UI mit Dark Mode läuft
- Navigation und Einstellungen funktionieren
- Commit `43dfce5` — Dark Mode Implementation

**Status:** Abgeschlossen

---

## Etappe 8: Separation of Concerns (Dark Mode)

**Ziel:** Code-Qualität durch saubere Trennung.

**Was gebaut wird:**
- Theme-Context aus App.tsx auslagern
- Dark Mode Utility für CSS-Klassen
- Theme props in Komponenten verstecken
- Tailwind-Config zentralisieren

**Fertig wenn:**
- Theme-Logik in eigenem Context
- Wiederverwendbare Dark Mode Helper
- Saubere Komponenten-Struktur

**Status:** Abgeschlossen (Teil von Etappe 9)

---

## Etappe 9: SoC Refactoring & Config Validation

**Ziel:** Code-Qualität durch saubere Trennung + Konfigurations-Validierung.

**Was gebaut wird:**
- Theme-Context aus App.tsx in eigenes Context auslagern
- Config Validation mit TMDB-API-Key Pflicht
- Cache Key Centralization (cache/keys.py)
- Worker Refactoring für bessere Trennung
- Docker Compose mit Healthchecks

**Fertig wenn:**
- Theme-Logik in eigenem Context (ThemeContext.tsx)
- Wiederverwendbare Dark Mode Helper (useDarkMode.ts)
- TMDB-API-Key ist Pflicht (Fehler bei Fallback-UI)
- Cache-Keys zentral definiert
- Docker Healthchecks für API

**Status:** In Arbeit

## Etappe 9: Proxmox-Integration

**Ziel:** Ein-Click-Deploy auf Proxmox LXC.

---

## Offene Punkte (aus KONZEPT.md)

| Punkt | Etappe | Behandlung |
|-------|--------|------------|
| TMDB-Matching-Fehler bei Nischentiteln | Etappe 3 | Pre-Scan Confidence-Score + manueller Korrektur-Mechanismus |
| NFO-Format-Abhängigkeit von Jellyfin-Version | Etappe 4 | Kodi/NFO-Schema (stabil, gut dokumentiert) |
| Pre-Scan-Latenz (5–15s) | Etappe 3 | Akzeptabel, Parallelisierung möglich |
| TMDB-Bildrechte | Etappe 4 | Gelöst: TMDB API-ToS erlaubt private Nutzung |
| Hybrid-Discs | Etappe 1 | MVP erkennt nur Standard; als "Kann" notiert |
| Redis Single-Instance | Etappe 1 | MVP reicht; Cluster als "Später" |