docs: Konzept fuer Rippy v2 + drei Commander-Entscheide (28.08.2026)

WAS: KONZEPT-V2.md neu — Systemarchitektur, Daten-/Queue-Strategie, die
drei Betriebsmodi, API-/Event-Design, Migrationsplan V2-0 bis V2-7.
KONZEPT.md §10 und ROADMAP.md ziehen nach.

WARUM: Rippy soll drei Betriebsarten bekommen statt einer — Docker,
native Windows-App ohne Docker, Headless-Linux-Dienst; alle mit
demselben Webinterface. Das traegt technisch nur, wenn es EINEN Kern
gibt, dessen Betriebsmodus nur die Auswahl der Treiber hinter vier
Ports ist (Store, Queue, Bus, Drives).

Drei Entscheide des Commanders sind eingearbeitet:

- Reihenfolge: Echtzeit (SSE statt Polling) VOR der Windows-App. Die
  Windows-App braucht SQLite und die lokale Queue ohnehin.
- Disc-Schluessel: automatischer Abruf MIT Rueckfallebene, als Kette in
  drei Stufen (eigener Bestand -> Abruf -> Import von Hand). Das
  verschiebt die Grenze aus KONZEPT.md §10 vom 25.07.2026 bewusst —
  deshalb steht sie dort jetzt ausdruecklich fortgeschrieben statt
  still ersetzt (AGENTS Regel B). Bezugsadresse leer vorbelegt,
  Fehlschlag laut, Bestand wird nie still ueberschrieben.
- Speicherziele: der Host mountet, Rippy prueft und erzeugt die
  kopierbare Zeile. Raeumt die URSACHE der CIFS-Ausfaelle ab (Befund
  26.07.2026: die Verbindung lebt in der Netz-Namespace des
  api-Containers und stirbt mit ihm) statt weiter das Symptom zu
  heilen. SYS_ADMIN, DAC_READ_SEARCH, apparmor:unconfined und die
  Mount-Wache fallen damit weg.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

KONZEPT.md

@@ -220,3 +220,52 @@ Ein modular aufgebautes System, das bei Disc-Einwurf automatisch den Typ erkennt
   Episoden-Zuordnung per Laufzeitabgleich (TMDB) — erfüllt Etappe-12-Ziel
   „Serien-Episoden-Erkennung" in der ersten Ausbaustufe (nur bei
   EINDEUTIGER Zuordnung wird umbenannt).
+- **28.08.2026 — DISC-SCHLÜSSEL: die Grenze vom 25.07. ist verschoben
+  (Commander-Entscheid).** Der Eintrag vom 25.07.2026 oben sagt: *„Rippy
+  liefert und verteilt KEINE Disc-Schlüssel und lädt auch keine herunter."*
+  **Das gilt ab jetzt nicht mehr unverändert.** Auf ausdrückliche Entscheidung
+  des Commanders bekommt Rippy v2 einen automatischen Abruf — mit den
+  bisherigen Wegen als Rückfallebene. Umgesetzt als Kette in DREI Stufen, die
+  der Reihe nach abgearbeitet wird und anhält, sobald eine trägt:
+
+  1. **Eigener Bestand** (Schlüsselspeicher der Installation) — immer zuerst.
+     Gefüllt vom Windows-Knoten, der die Schlüssel über die eigene
+     MakeMKV-Lizenz selbst abruft (unter Linux tut `makemkvcon` das nie,
+     Messung 25.07.2026), und von jedem Import.
+  2. **Automatischer Abruf** von der konfigurierten Quelle — wenn Stufe 1
+     die Disc nicht kennt.
+  3. **Import von Hand** (`_private_data.tar`, `KEYDB.cfg` über das UI) —
+     unverändert aus v1.
+
+  Fünf Regeln gehören zum Entscheid dazu: (a) die Bezugsadresse steht in der
+  KONFIGURATION und ist LEER vorbelegt — ohne Eintrag ist Stufe 2
+  übersprungen; eine vorbelegte Adresse, die irgendwann tot ist, wäre genau
+  die Falle aus `.env.example` („lässt die Konfiguration gesund aussehen und
+  den Bau später scheitern"). (b) Ein funktionierender Bestand wird NIE still
+  überschrieben — neue Datei daneben, prüfen, dann tauschen. (c) Ein
+  Fehlschlag ist LAUT (kein `except: pass`, Meldung im Log und im UI).
+  (d) Das UI zeigt Herkunft und Alter jedes Eintrags. (e) **Rippy bringt
+  selbst nichts mit** — weder Installer noch Docker-Image enthalten Schlüssel
+  oder eine vorbelegte Bezugsadresse; was abgerufen wird, trägt der Betreiber
+  der Installation ein. Ausführlich in `KONZEPT-V2.md` § 7.5 und § 10.
+- **28.08.2026 — SPEICHERZIELE: der Host mountet, Rippy prüft
+  (Commander-Entscheid).** Das Muss-Feature „NFS/Bind-Mount für Medien-Store"
+  (§ 6) bleibt; was wegfällt, ist das Mounten DURCH Rippy. Begründung ist der
+  Befund vom 26.07.2026: Die CIFS-Verbindung lebt in der Netz-Namespace des
+  api-Containers und stirbt mit ihm — dagegen läuft heute eine Mount-Wache.
+  In v2 hängt der Host ein (fstab, `.mount`-Unit oder Compose-Volume-Treiber),
+  und Rippy erzeugt dafür die fertige, kopierbare Zeile. Die Eingabemaske im
+  UI bleibt; der Knopf „Verbinden" wird zu „Zeile kopieren". Die gesamte
+  PRÜF-Logik aus `mounts.py` bleibt erhalten (Erreichbarkeit mit Zeitgrenze
+  im Kindprozess, SMB-Klartextfehler, Pfad-Map-Vorschlag). Folge:
+  `CAP_SYS_ADMIN`, `DAC_READ_SEARCH`, `apparmor:unconfined`,
+  `propagation: rshared` und die Mount-Wache fallen ersatzlos weg.
+- **28.08.2026 — RIPPY v2: drei Betriebsmodi statt eines
+  (Commander-Auftrag).** Die Multi-Container-Architektur aus § 6 bleibt als
+  EINER von drei Modi bestehen. Dazu kommen eine native Windows-Installation
+  ohne Docker und eine Headless-Linux-Anwendung — beide mit demselben
+  Webinterface. Technisch tragen alle drei denselben Kern; ein Modus ist nur
+  die Auswahl der Treiber hinter vier Ports (Store, Queue, Bus, Drives).
+  Damit sind Postgres und Redis für Einzelinstallationen keine Pflicht mehr
+  (SQLite + lokale Queue), bleiben im verteilten Modus aber unverändert.
+  Vollständige Spezifikation: **`KONZEPT-V2.md`**, Etappen in `ROADMAP.md`.

ROADMAP.md

@@ -570,8 +570,105 @@ heruntergerechnet und der Rohschnitt gelöscht worden (`keepOriginal: False`).
 
 ---
 
+## Rippy v2 — Etappen V2-0 bis V2-7 (Plan vom 28.08.2026)
+
+**Vollständige Spezifikation: `KONZEPT-V2.md`.** Hier stehen nur die Etappen
+und ihre Abnahmekriterien.
+
+**Ziel:** drei Betriebsmodi statt eines — Docker (wie heute, aufgeräumt), eine
+native Windows-App ohne Docker, eine Headless-Linux-Anwendung. Alle drei mit
+demselben Webinterface, alle drei aus EINEM Kern.
+
+**Grundregel für den ganzen Weg:** Jede Etappe endet mit grüner Ampel und einem
+lauffähigen System. v1 läuft bis V2-5 produktiv weiter — auf der VM liegen echte
+Medien.
+
+### V2-0: Monorepo — ein Paket statt Zwillingen
+- [ ] `src/rippy/` als gemeinsames Paket anlegen (api UND worker importieren daraus)
+- [ ] Die byte-identischen Zwillinge zusammenführen: `detection.py`,
+      `makemkv_daten.py`, `notify.py` — je zweimal im Repo
+- [ ] Tests wandern mit; `test_zwillinge_sind_byteweise_identisch` wird
+      gegenstandslos und weicht einem Test, der die EINE Quelle prüft
+- [ ] Beide Dockerfiles kopieren `src/rippy`, `PYTHONPATH` gesetzt
+- **Verhalten unverändert.** Kein Funktionsgewinn, reine Struktur.
+- **Fertig, wenn:** Ampel grün, `docker compose up` verhält sich wie vorher,
+      kein Modul mehr doppelt im Repo.
+
+### V2-1: Ports einziehen
+- [ ] `Store`, `Queue`, `Bus`, `Drives` als Python-`Protocol`
+- [ ] v1-Verhalten läuft über die Treiber Postgres / Celery / Redis / Linux
+- [ ] Kein Funktionsgewinn — reine Verdrahtung
+- **Fertig, wenn:** Ampel grün und ein Rip auf der VM durchläuft.
+
+### V2-2: Standalone (SQLite + lokale Queue)
+- [ ] SQLite-Treiber mit WAL, `busy_timeout`, ein Schreiber-Kontext
+- [ ] Alembic statt handgeschriebener `ALTER TABLE … IF NOT EXISTS`
+      (das ist Postgres-only und bricht auf SQLite)
+- [ ] LocalQueue: Auftrags-Tabelle + Lease + Prozesspool, kein Broker
+- [ ] Lease ersetzt `zombies.py` — abgelaufene Lease = Auftrag ist frei
+- [ ] `rippyd --profil standalone`
+- **Fertig, wenn:** ein DVD-Rip komplett ohne Postgres, Redis und Docker läuft.
+
+### V2-3: Echtzeit — Polling raus
+- [ ] Bus-Treiber (asyncio in-process / Redis Pub/Sub)
+- [ ] `GET /api/v2/events` als SSE-Strom, `snapshot` beim Verbinden,
+      lückenlose `seq` für Wiederaufnahme
+- [ ] UI auf einen `useEventStream`-Haken; die neun `setInterval` fliegen raus
+- [ ] `test_grenze_deckt_die_eigene_last_ab` auf die neuen Zahlen ziehen
+- **Fertig, wenn:** Grundlast ≈ 0/min gemessen (heute ≈ 133/min bei einem Tab
+      plus Worker) UND ein Verbindungsabriss keine Liste leert.
+
+### V2-4: Windows nativ
+- [ ] `drives/windows.py` — Win32 statt ioctl (`IOCTL_STORAGE_CHECK_VERIFY2`,
+      `IOCTL_STORAGE_MEDIA_REMOVAL`, `IOCTL_STORAGE_EJECT_MEDIA`,
+      MMC `GET CONFIGURATION` für den Disc-Typ)
+- [ ] Disc-Einwurf per `WM_DEVICECHANGE` statt Polling
+- [ ] Dienst (WinSW) + Tray als GETRENNTE Prozesse; WebView2-Fenster
+- [ ] Nuitka `--standalone` (one-dir, nicht one-file) + Inno Setup
+- [ ] Standby blocken via `SetThreadExecutionState`, ohne `ES_DISPLAY_REQUIRED`
+- **Fertig, wenn:** auf einem frischen Win-11-Rechner gilt: Installer →
+      Disc rein → MKV raus. Und der UHD-Schlüssel kommt automatisch.
+
+### V2-5: Docker neu
+- [ ] EIN Image, drei Profile (`standalone`, `api`, `node`)
+- [ ] GPU-Durchreichung: `/dev/dri` für QSV/VAAPI, `runtime: nvidia` für NVENC
+- [ ] **Host-Mounts statt Container-Mounts** (Entscheid 28.08.2026)
+- [ ] Multi-Arch; ARM64 ist Encode-/API-Knoten (MakeMKV hat kein ARM64-Binary)
+- **Fertig, wenn:** All-in-One und verteilt laufen und `SYS_ADMIN`,
+      `DAC_READ_SEARCH`, `apparmor:unconfined` weg sind.
+
+### V2-6: CLI & Pakete
+- [ ] `rippy status / drives / scan / rip / queue / logs --follow / doctor`
+- [ ] `rippy doctor` = die Prüfphase aus `install.sh` als Befehl (erst alles
+      prüfen, dann berichten, nichts ändern)
+- [ ] systemd-Unit mit `SupplementaryGroups=cdrom` und `DeviceAllow` für
+      block-sr UND char-sg (ohne sg findet MakeMKV kein Laufwerk)
+- [ ] udev-Regel für echte Disc-Ereignisse; ioctl-Poll bleibt Rückfallebene
+- [ ] `.deb` / AppImage
+- **Fertig, wenn:** ein Headless-Server ohne Browser bedienbar ist.
+
+### V2-7: Neue Features
+- [ ] Multi-Drive Parallel-Ripping (Rip parallel, **Schlüssel-Phase
+      serialisiert** — vorher an zwei Laufwerken MESSEN, nicht annehmen)
+- [ ] Zero-Click gegen Interaktiv, je Laufwerk und Disc-Typ
+- [ ] Auto-Presets nach gemessener Hardware (Vorschlag, kein Zwang)
+- [ ] Ton-/Untertitel-Regelwerk (Originalton, Wunschsprachen, erzwungene
+      Untertitel behalten, Kommentarspuren verwerfen, HD-Ton durchreichen)
+- [ ] **Schlüsselkette in drei Stufen** (Entscheid 28.08.2026, `KONZEPT.md` § 10)
+- [ ] Anime über AniList zusätzlich zu Jikan
+- [ ] Medienserver-Refresh als Auftrag MIT Wiederholung (heute still scheiternd)
+- [ ] FFmpeg-Direktpfad für reines Remuxen
+- **Fertig, wenn:** je Feature ein Nachweis vorliegt.
+
+---
+
 ## Ideen-Katalog (Rest) — bewusst offen
 
+> **Stand 28.08.2026:** Punkt 3 (Kodi-Refresh) und Punkt 4 (Windows-Worker als
+> Dienst) sind in den v2-Plan aufgegangen — Punkt 4 ist V2-4, Punkt 3 steckt in
+> V2-7 („Medienserver-Refresh"). Punkt 2 (AI-Box als Transcode-Worker) wird von
+> V2-5 abgedeckt, sobald der Host-Mount-Weg steht.
+
 1. **Design 2.0** — an Gemini übergeben (24.07.2026). Vollständiges
    Briefing: `docs/DESIGN-2.0-BRIEFING.md`. Arbeitsbranch: `design-2.0`
    (deployt bewusst NICHT, nur `main` wird befördert). Kern: 428