rippy/KONZEPT-WINDOWS.md

KONZEPT — Rippy für Windows

Rippy v5. Ein eigenständiges Windows-Programm, gebaut mit Electron und TypeScript. Grüne Wiese: kein Docker-Code, kein Python, keine Container-Reste.

Stand: 30.08.2026 · Branch worktree-windows-electron

---

0. Leseanleitung

§	Frage
1	Warum wird neu gebaut statt repariert?
2	Was hat der Commander entschieden?
3	Was wurde gemessen, bevor entschieden wurde?
4–5	Wie ist das Programm aufgebaut, und was passiert, wenn eine Disc reingeht?
6–9	Features, Oberfläche, Setup, Werkzeuge
10	Was kommt aus dem alten Rippy mit?
11	Was aus main entfernt wird
12–14	Etappen, Risiken, was NICHT gebaut wird

Was dieses Dokument NICHT tut: Es erfindet keine Messungen. Alles, was hier als Zahl oder Verhalten steht, ist entweder in § 3 an dieser Maschine gemessen, im alten Rippy belegt (SAVEPOINT.md, AGENTS.md) oder ausdrücklich als Annahme markiert. Die Trennung ist wichtig, weil dieses Projekt schon mehrfach teuer dafür bezahlt hat, dass jemand eine plausible Erklärung für eine gemessene gehalten hat.

---

1. Warum neu gebaut wird

Die heutige Windows-Fassung ist kein Windows-Programm. Sie ist der Docker-Code in einer EXE:

RippySetup.exe  (PyInstaller)
  ├─ docker/api/      →  FastAPI, uvicorn auf 127.0.0.1:7788
  ├─ docker/worker/   →  der Celery-Worker, nur ohne Celery
  ├─ docker/ui/dist/  →  dieselbe React-Oberfläche wie im Browser
  └─ pywebview        →  ein Fenster davor

Das Ergebnis steht im SAVEPOINT.md: elf Release-Kandidaten in drei Tagen. Und die Funde sind fast alle vom selben Typ — Linux-Annahmen, die unter Windows etwas anderes bedeuten:

Fund	Was passierte
timeout 4 ls -d <pfad> als Verzeichnisprüfung	Unter Windows gibt es timeout.exe, aber sie kennt weder ls noch -d. Antwort war „weg" für jedes Verzeichnis — Rohdaten waren grundsätzlich unsichtbar. Dazu blitzten Konsolenfenster auf.
shutil.which("makemkvcon")	Findet unter Windows nie etwas — Programme liegen in Program Files, nicht im PATH. Die 4K-Schlüssel-Automatik lief deshalb nie an.
os.path.isdir("/app")	Rippy hielt sich für einen fremden Docker-Worker. Zweimal gefunden, an zwei Stellen.
Routen /dev/{name}	Das UI ruft mit G auf, gebaut war /dev/G. Auswerfen und Disc-Scan antworteten immer mit 404.
F:\ wurde zu F:	Unter Windows ist F: ohne Trenner der aktuelle Ordner auf F, nicht dessen Wurzel. 16,5 GB Rohschnitt unsichtbar; der Dialog bot nur „Neu rippen" an.
makemkvcon überlebte den Elternprozess	Windows räumt Kindprozesse nicht auf. Zwei Waisen hielten das Laufwerk fest.
Zwei Speicher für dieselben Ordner	Die Oberfläche schrieb outputDir in die Datenbank, der Betrieb las storage.medien aus einer Konfigurationsdatei, die niemand schrieb. Eingestellt E:\Rippy, angezeigt C:\Users\...\Videos\Rippy.

Diese Liste ist nicht das Problem — sie ist das Symptom. Jeder einzelne Fund war eine Stelle, an der Code, der für einen Linux-Container geschrieben wurde, unter Windows etwas anderes bedeutet. Solange die Grundlage ein umgebogener Container ist, ist der nächste Fund dieser Sorte nur eine Frage der Zeit.

Die Entscheidung ist deshalb nicht „das ist schlecht gebaut", sondern: das ist am falschen Ort gebaut. Ein Windows-Programm fängt bei Windows an, nicht bei einem Container, dem man Windows beibringt.

---

2. Die Entscheidungen (Commander, 30.08.2026)

Acht Entscheide, alle am selben Tag. Die ersten vier legen die Architektur fest, die naechsten drei beantworten die Punkte, die das Konzept offengelassen hatte, und der achte steht bei der Sache, zu der er gehoert (Paragraph 11.1). Sie stehen hier, damit später nachvollziehbar ist, was Entscheidung war und was Vorschlag.

Entscheid 1 — Alles TypeScript/Node

Es gibt keinen Python-Anteil in Rippy für Windows. Kein Sidecar, keine mitgelieferte Laufzeit, keine IPC-Brücke zwischen zwei Sprachen. Eine Sprache, eine Werkzeugkette, ein Setup.

Was das kostet: Die rund 18.000 Zeilen Python werden nicht übernommen. Was übernommen wird, ist ihr Wissen — die Parser-Regeln, die gemessenen Fallen, die Kommandozeilen (§ 10). Das ist der teure Teil an ihnen, und der wandert vollständig mit.

Was das bringt: Der ganze Fehlertyp aus § 1 kann nicht mehr entstehen. Es gibt keinen Container-Pfad, den jemand vergessen könnte, weil es nie einen gab.

Entscheid 2 — Die Docker-Version bleibt unangetastet

Rippy auf der VM läuft weiter wie heute. Es wird nicht angefasst, nicht migriert, nicht mitgepflegt. Zwei getrennte Produkte, keine geteilten Module.

Begründung: Geteilte Module zwischen zwei Betriebssystemen sind genau die Konstruktion, an der v1 gelitten hat — drei Dateien lagen byte-identisch doppelt im Repo, und db.py schrieb es sogar in den Kopfkommentar: „Wer die Struktur ändert, ändert BEIDE Dateien."

Entscheid 3 — Reiner Einzelplatz

Ein Rechner macht alles: erkennen, rippen, komprimieren, ablegen. Kein Server, keine Netz-Queue, keine Worker-Verwaltung, keine Pfad-Übersetzung zwischen Maschinen.

Was damit ersatzlos wegfällt: Celery, Redis, Postgres, die Worker-Tabelle, worker_direct, die Lease-Mechanik über Netz, RIPPY_PATH_MAP, die Zombie-Erkennung, die Mount-Wache, das Rate-Limit (es gibt keinen fremden Client mehr), /worker-setup/*, die Encoder-Auswahl je Knoten.

Grob geschätzt sind das 40 % der heutigen Komplexität — und zwar der Teil, der die meisten Fehlerbilder erzeugt hat.

Was bleibt: Die Ablage darf trotzdem auf dem NAS liegen. Ein UNC-Pfad (\\nas\medien) oder ein verbundenes Netzlaufwerk ist für Rippy nur ein Pfad. Windows mountet, Rippy prüft — dieselbe Trennung wie in Entscheid 3 des v2-Konzepts, nur ohne Container drumherum.

Entscheid 4 — Eigener Branch im selben Gitea-Repo

Ein Git-Worktree unter .claude/worktrees/windows-electron auf dem Branch worktree-windows-electron. main bleibt unberührt und jederzeit deploybar.

Entscheid 5 — Kein Code-Signing-Zertifikat

„ist egal, brauchen wir nich"

Die EXE bleibt unsigniert. Folge: Beim ersten Start eines Downloads zeigt Windows den SmartScreen-Hinweis („Der Computer wurde geschützt"); über Weitere Informationen → Trotzdem ausführen geht es weiter. Das gehört in die Anleitung, nicht unter den Teppich.

Eine Folge, die dazugehört und in § 6.8 steht: Ohne Signatur kann electron-updater ein heruntergeladenes Update nicht auf Echtheit prüfen. Die Absicherung liegt damit vollständig beim Transportweg — Updates werden nur über HTTPS geladen, nie über einfaches HTTP.

Entscheid 6 — Updates aus Gitea, auch für Fremde erreichbar

„Gerne das Gitea Release, mit Möglichkeit dass auch EXTERNE diese Updates fahren können"

Zwei Teile, und der zweite hat eine Bedingung, die Rippy nicht selbst lösen kann:

1. Rippys Seite — die Update-Adresse steht in der Konfiguration, vorbelegt mit dem Gitea des Commanders. electron-updater braucht dafür nur einen statischen HTTPS-Ort mit zwei Dateien (latest.yml und das Setup). Damit ist Rippy von der Frage unabhängig, wo dieser Ort liegt.

2. Die Netz-Seite — ⚠️ Gitea läuft auf 192.168.178.153 im Heimnetz. Von außen ist das nicht erreichbar. „Externe können Updates fahren" verlangt also einen von drei Wegen, und die Wahl gehört dem Commander:

   Weg	Was zu tun ist	Bewertung
   Gitea veröffentlichen	Reverse-Proxy + DynDNS + TLS-Zertifikat	Ein Dienst im Heimnetz wird öffentlich — die Angriffsfläche wächst. Nur mit Bedacht
   Öffentlicher Spiegel	Der Bau schiebt das Release zusätzlich zu einem öffentlichen Ort (GitHub-Release, Objektspeicher, gemieteter Webspace)	Empfehlung. Gitea bleibt privat, nur die fertigen Dateien liegen draußen
   Jeder trägt seine eigene Quelle ein	Nichts — die Konfiguration kann es schon	Für einzelne Nutzer mit eigenem Server. Skaliert nicht

   Rippy wird für alle drei gebaut: eine Adresse in der Konfiguration, sonst nichts. Die Entscheidung kann später fallen, ohne das Programm anzufassen.

Entscheid 7 — Der alte Windows-Weg wird entfernt, auch aus main

„Nein — direkt weg, auch aus dem Original Repo. Das neue Standalone Windows Rippy wird ein komplett neues Produkt und kein Aufbau auf die Docker-Architektur."

Die PyInstaller-Fassung bleibt nicht parallel installierbar, und ihr Code verlässt das Repo. Das ist die schärfere Fassung von Entscheid 2: Nicht nur werden die beiden Produkte nicht verwandt sein — der Zwitter dazwischen wird abgeräumt.

Das ist kein Widerspruch zu Entscheid 2. „Docker bleibt unangetastet" meint die Docker-Funktion; der Windows-Standalone-Zweig ist gerade nicht Docker, sondern der Fremdkörper darin. Was genau entfernt wird, steht in § 11 — mit einer Unterscheidung, die beim Aufräumen entscheidend ist.

---

3. Was gemessen wurde, bevor entschieden wurde

Electron bedeutet: Die Arbeit macht Node, nicht Python. Damit hängt das ganze Konzept an einer Frage, die vorher niemand geprüft hat:

Kann Node überhaupt alles, was Rippy am Laufwerk braucht?

Wäre die Antwort nein, wäre das Konzept wertlos. Also gemessen — am 30.08.2026, auf diesem Rechner, am echten Laufwerk.

3.1 Die Werkzeuglage

Node          v24.19.0
npm           11.17.0
Electron      44.0.0   (Chromium 152.0.7977.54 · Node 24.18.1)
WebView2      151.0.4129.107
Laufwerk      G:  HL-DT-ST BD-RE BU40N USB Device   (Medium eingelegt)

3.2 Win32 aus Node — die Laufwerks-Steuerung

koffi 3.1.6 installiert, dieselben Steuercodes wie in src/rippy/drives/win_ioctl.py (die dort aus dem CTL_CODE-Makro hergeleitet sind, nicht abgeschrieben). Nur lesende Aufrufe, nichts ausgeworfen:

1. GetLogicalDrives + GetDriveTypeW  ->  optische Laufwerke: [ 'G' ]
2. CreateFileW \\.\G: (Zugriff 0)     ->  offen
   CreateFileW \\.\G: (GENERIC_READ)  ->  offen
3. IOCTL_STORAGE_QUERY_PROPERTY  ->  Hersteller: HL-DT-ST | Modell: BD-RE BU40N
                                     | Rev: 1.03 | Serial: 0025114C0149
4. IOCTL_STORAGE_CHECK_VERIFY2   ->  Medium eingelegt
5. IOCTL_CDROM_DISK_TYPE         ->  Win32-Fehler 50
6. IOCTL_DISK_GET_LENGTH_INFO    ->  33.759.690.752 Bytes (33,76 GB)  =>  Blu-ray

Punkt 5 ist kein Fehlschlag, sondern eine Bestätigung. Fehler 50 ist ERROR_NOT_SUPPORTED — genau das, was auch der Python-Treiber an diesem Laufwerk sieht (SAVEPOINT.md, rc11). Node verhält sich identisch. Und die Lehre daraus steht schon im alten Code: Die Disc-Einordnung darf sich nicht auf IOCTL_CDROM_DISK_TYPE verlassen — die Größe ist der verlässliche Weg.

3.3 Die Prozess-Leine — überlebt makemkvcon einen Absturz?

Der Befund aus rc10: Windows räumt Kindprozesse nicht auf. Ein hart beendeter Rippy hinterlässt ein makemkvcon, das das Laufwerk festhält. Die Lösung dort war eine Windows-Arbeitsgruppe (Job Object) mit JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE.

In Node nachgestellt — Job Object gesetzt, Kind gestartet, Eltern mit taskkill /F ohne /T abgeschossen (genau das, was bei einem Absturz und beim Drüber-Installieren passiert):

1. CreateJobObjectW           ->  Arbeitsgruppe angelegt
2. SetInformationJobObject    ->  KILL_ON_JOB_CLOSE gesetzt
3. AssignProcessToJobObject   ->  dieser Prozess hängt in der Gruppe
4. Kindprozess gestartet, PID 16040

vor dem Abschuss:   Eltern lebt: True    Kind lebt: True
taskkill /F /PID 29488  ->  ERFOLGREICH
danach:             Eltern lebt: False   Kind lebt: False

3.4 Datenbank ohne native Abhängigkeit

node:sqlite eingebaut  ->  geht

Node 24 bringt SQLite mit (node:sqlite, DatabaseSync). Keine better-sqlite3-Kompilierung, kein node-gyp, kein Visual-Studio-Build in der Bau-Kette.

⚠️ Ungeprüft: Electron kompiliert sein Node mit eigenen Flags. Ob node:sqlite in Electron 44 vorhanden ist, ist an dieser Stelle nicht gemessen — nur in Node 24.19.0 selbst. Das ist der erste Handgriff in Etappe W-0. Rückfallebene: better-sqlite3 (bewährt, aber nativ und damit eine Kompilierung in der Bau-Kette).

3.5 Ein Nebenbefund für die Bau-Kette

npm 11 blockiert Install-Skripte fremder Pakete standardmäßig:

npm warn allow-scripts  koffi@3.1.6 (install: node ./cnoke.cjs -P . --prebuild --release)

koffi lädt trotzdem — es bringt vorgebaute Binärdateien mit. Aber die Warnung gehört in die Bau-Anleitung, sonst sucht jemand eines Tages an der falschen Stelle.

---

4. Aufbau

4.1 Drei Teile, drei Prozesse

┌──────────────────────────────────────────────────────────────┐
│  Rippy.exe  —  Electron Main-Prozess                         │
│  ├─ Tray-Symbol, Fensterverwaltung, Autostart, Selbst-Update │
│  └─ hält die Prozess-Leine (§ 3.3) — ALLES stirbt mit ihm    │
└───────────┬─────────────────────────────┬────────────────────┘
            │ IPC                         │ MessagePort
┌───────────▼──────────────┐   ┌──────────▼───────────────────────┐
│  Fenster (Renderer)      │   │  Kern (utilityProcess)           │
│  React + Tailwind        │◄──┤  die GANZE Arbeit                │
│  zeigt an, sonst nichts  │   │  ├─ Laufwerkswache (koffi/Win32) │
│                          │   │  ├─ Ablauf-Steuerung             │
│  kein Node-Zugriff       │   │  ├─ Auftragstabelle (SQLite)     │
│  (contextIsolation)      │   │  └─ Werkzeuge als Kindprozesse:  │
│                          │   │     makemkvcon · HandBrakeCLI    │
└──────────────────────────┘   └──────────────────────────────────┘

Warum drei und nicht einer:

1. Ein Rip dauert 30–90 Minuten. Läuft er im Main-Prozess, friert die Oberfläche ein — Electrons eigene Dokumentation sagt das ausdrücklich.
2. Der Kern darf abstürzen, ohne das Fenster mitzureißen. Dann steht dort „Der Kern ist abgestürzt, ich starte ihn neu" statt eines toten Fensters.
3. Das Fenster darf zugehen, ohne den Rip zu beenden. Rippy lebt dann im Tray weiter — genau wie heute, nur ohne den Umweg über einen HTTP-Server.

Warum utilityProcess und nicht child_process.fork: Electrons eigene Empfehlung. utilityProcess kann einen MessagePort direkt zum Renderer aufbauen — der Fortschritt eines Rips geht damit ohne Umweg über den Main-Prozess ins Fenster.

Was es NICHT gibt: keinen HTTP-Server, keinen Port, kein localhost:7788, keine REST-API, kein SSE. Fenster und Kern reden über Electrons IPC. Ein lokaler Webserver in einer Einzelplatz-Anwendung ist eine offene Tür ohne Gegenwert — und er war der Grund für das Rate-Limit, den Proxy-Kummer und die Polling-Last im alten Rippy.

4.2 Ordner

rippy-windows/
├── package.json
├── electron.vite.config.ts
├── src/
│   ├── haupt/              Electron Main
│   │   ├── index.ts        Start, Einzelinstanz-Sperre, Leine setzen
│   │   ├── fenster.ts      Fenster anlegen, Zustand merken
│   │   ├── tray.ts         Symbol + Kontextmenü
│   │   ├── autostart.ts    HKCU\...\Run
│   │   └── update.ts       electron-updater
│   │
│   ├── kern/               utilityProcess — die Arbeit
│   │   ├── laufwerk/
│   │   │   ├── win32.ts        DER EINZIGE ORT MIT koffi
│   │   │   ├── wache.ts        Einwurf/Auswurf erkennen
│   │   │   └── disc.ts         Typ, Label, Größe, TOC
│   │   ├── metadaten/
│   │   │   ├── tmdb.ts  tvdb.ts  omdb.ts  musicbrainz.ts
│   │   │   ├── discmerkmale.ts  Label + Laufzeiten + BDMV-Titel
│   │   │   └── zuordnung.ts     Treffer + Sicherheitsgrad
│   │   ├── rip/
│   │   │   ├── makemkv.ts      Kommandobau + Aufruf
│   │   │   ├── parser.ts       TINFO/SINFO/PRGV/MSG  (rein, testbar)
│   │   │   ├── audiocd.ts      Roh-Sektoren + FLAC
│   │   │   └── iso.ts          Datendiscs 1:1 sichern
│   │   ├── komprimieren/
│   │   │   ├── handbrake.ts    Kommandobau + Aufruf + Fortschritt
│   │   │   ├── encoder.ts      GEMESSEN, nicht behauptet
│   │   │   └── presets.ts
│   │   ├── ablage/
│   │   │   ├── struktur.ts     Jellyfin/Emby/Kodi/Plex
│   │   │   ├── nfo.ts  poster.ts  medienserver.ts
│   │   ├── ablauf/
│   │   │   ├── pipeline.ts     die Verkettung — NUR HIER
│   │   │   ├── zustand.ts      Zustandsmaschine
│   │   │   └── auftraege.ts    Warteschlange, Slots
│   │   ├── werkzeuge/
│   │   │   ├── katalog.ts      wo liegt makemkvcon/HandBrakeCLI/flac
│   │   │   ├── beschaffen.ts   holen, prüfen, einrichten
│   │   │   └── leine.ts        Job Object (§ 3.3)
│   │   └── speicher/
│   │       ├── db.ts           SQLite
│   │       ├── einstellungen.ts  EINE Quelle (§ 6.7)
│   │       └── bibliothek.ts
│   │
│   ├── gemeinsam/          Typen + Ereignis-Schema — Fenster UND Kern
│   └── fenster/            React
│
├── bau/                    electron-builder, NSIS-Skript, Icon
└── test/                   Vitest

4.3 Sechs Regeln, die den Aufbau tragen

Jede ist aus einem bezahlten Fehler abgeleitet. Sie sind mechanisch prüfbar und bekommen je einen Wächter-Test.

R1 — Win32 lebt nur in laufwerk/win32.ts. Kein koffi-Import irgendwo sonst. Ein Wächter-Test greift bei jedem anderen Fundort. (Grund: In v1 rief main.py eject() direkt auf — deshalb brauchte der API-Container Geräte-Zugriff und SYS_ADMIN.)

R2 — Ein Fehlschlag löscht nie einen Zustand. Kein catch { return [] }. Wer nichts Neues weiß, behält, was er wusste. (Grund: Fünfmal catch(() => []) im alten UI — jeder verpasste Abruf hieß „es gibt keine Jobs", die Liste leerte sich im Sekundentakt. Der Commander meldete es als „wird oft neu geladen".)

R3 — Auswerfen heißt: entriegeln, auswerfen, nachsehen. In dieser Reihenfolge. Kein Rückgabewert gilt als Beweis. (Grund: CDROMEJECT quittiert auf einem verriegelten Laufwerk Erfolg und tut nichts. MakeMKV verriegelt die Tür während des Rips.)

R4 — Jede Hintergrundschleife meldet ihren Fehler. Kein stilles catch {}. (Grund: Ein except Exception: pass in einer Vorrats-Schleife hat einmal eine Stunde gekostet.)

R5 — Externe Schnittstellen werden gemessen, nicht erinnert. Jeder Kommandozeilen-Schalter, jeder IOCTL-Code trägt im Kommentar, wo er herkommt. (Grund: --audio-codec gibt es bei HandBrakeCLI nicht — es heißt -E/--aencoder. Ein unbekannter Schalter ist für HandBrake kein Fehler: Rückgabewert 0. Das kostete einen fertigen 16,5-GB-Rip, und ein Test hatte den Fehler festgeschrieben statt ihn zu finden.)

R6 — Alles läuft an der Leine. Jeder Werkzeugaufruf hängt in der Arbeitsgruppe aus § 3.3. Ausgenommen ist nur das Aufräum-Skript der Deinstallation — es muss Rippy überleben.

---

5. Der Ablauf — was passiert, wenn eine Disc reingeht

Der rote Faden des Commanders: so viel Arbeit abnehmen wie möglich.

 1. Disc rein
      │  WM_DEVICECHANGE / DBT_DEVICEARRIVAL  (Ereignis, kein Poll)
      │  Rückfallebene: 3-Sekunden-Takt, falls die Nachricht ausbleibt
      ▼
 2. Was ist das?
      │  Größe (33,76 GB → Blu-ray)  ·  Audio-TOC?  ·  Dateisystem lesbar?
      │  → Film / Serie / Musik / Daten
      ▼
 3. Was ist da drauf?     ← DER SCHRITT, DER HEUTE ZU DÜNN IST
      │  Disc-Label · Titel-Laufzeiten · BDMV-Titel · DVD-IFO · CD-DiscID
      │  → TMDb / TVDb / OMDb / MusicBrainz
      │  → Treffer mit SICHERHEITSGRAD
      ▼
 4. Sicher genug?
      │  ja   → sofort losrippen, nur Bescheid sagen        (Zero-Click)
      │  nein → fragen: Fenster hoch, Vorschläge zur Wahl
      ▼
 5. Rippen        makemkvcon, verlustfrei, Fortschritt aus PRGV
      ▼
 6. Komprimieren  HandBrakeCLI, Encoder GEMESSEN, Preset je Disc-Typ
      ▼
 7. Ablegen       Zielstruktur · NFO · Poster/Fanart
      ▼
 8. Melden        Medienserver anstoßen · Benachrichtigung · Auswerfen
      ▼
 9. Merken        Bibliothek fortschreiben — beim nächsten Mal erkannt

Was an Schritt 3 neu ist. Heute nimmt Rippy im Wesentlichen das Disc-Label und die längste Laufzeit. Das reicht bei „PIRATES_OF_THE_CARIBBEAN", aber nicht bei „LOGICAL_VOLUME_ID" — und dann fragt Rippy, obwohl die Antwort auf der Disc steht. Vier Quellen kommen dazu:

Quelle	Wo	Was sie liefert
BDMV-Metadaten	BDMV/META/DL/bdmt_*.xml auf der Blu-ray	Der vom Studio hinterlegte Disc-Titel, oft mit Sprachvarianten. Deutlich besser als das Volume-Label.
Titel-Struktur	makemkvcon info	Die Anzahl und Länge der Titel ist ein Fingerabdruck: 1 langer + viele kurze = Film; 6–13 gleich lange = Serienstaffel.
DVD-Struktur	VIDEO_TS, IFO-Dateien	Kapitelzahl und Titelsatz-Aufbau
CD-DiscID	Audio-TOC	Bereits gebaut und bewiesen (rc8): Spurlage → MusicBrainz → Album, Interpret, Jahr, jeder Titel.

Dazu ein Sicherheitsgrad, der ehrlich ist. Rippy sagt nicht „das ist Akira", sondern „das ist sehr wahrscheinlich Akira (1988)" — und fragt nur, wenn es das nicht sagen kann. Die Schwelle ist einstellbar; wer will, lässt Rippy immer fragen, und wer will, lässt es immer durchlaufen.

Und wenn Rippy sich irrt: Der Titel lässt sich nachträglich ändern, und die Ablage wandert mit. Das ist der Unterschied zwischen „falsch geraten" und „falsch abgelegt".

---

6. Die Features

6.1 Automatische Erkennung (§ 5, Schritt 2–4)

Siehe oben. Kernsatz: Rippy fragt nur, wenn es wirklich nicht weiß.

6.2 Rippen

makemkvcon im Robot-Modus (--robot --messages=-stdout --progress=-same), verlustfrei. Der Parser (TINFO/SINFO/PRGV/MSG) wandert aus dem Python-Code nach TypeScript — er ist reine Textverarbeitung und damit vollständig testbar, ohne Laufwerk.

Was aus dem alten Rippy zwingend mitkommt:

• Lesefehler heißen Lesefehler. MakeMKV kann 1 von 2 Titeln sichern und sich trotzdem mit 0 beenden. Rippy warnt nach dem Rip — auch und gerade dann, wenn er als Erfolg endete — und nennt die MSG-Nummer: MakeMKVs Texte sind übersetzt, die Nummern nicht.
• Erst nachsehen, dann rippen. Liegt keine Disc drin, sagt Rippy das in einem Satz, statt zwei Minuten in makemkvcon zu laufen und mit Code 11 zu enden. Aber: Wenn das Nachsehen selbst scheitert, wird trotzdem gerippt — „ich weiß es nicht" darf nie zu „es geht nicht" werden.
• Die Ausgabe binär lesen. makemkvcon mischt Kodierungen; ein ü im Pfad hat die Kompression einmal getötet (UnicodeDecodeError auf Byte 0x81).

6.3 Audio-CDs

Der Weg aus rc8, bewiesen: Roh-Sektoren über Win32 lesen (eine Audio-CD hat kein Dateisystem — die Track01.cda sind 44-Byte-Platzhalter), dann durch flac.exe. Dazu MusicBrainz über die DiscID.

Zwei Fallen, beide gemessen und beide dokumentiert: Die DiscID rechnet mit den 150 Frames Vorlauf, das Lesen ohne. Und die Leseadresse zählt in 2048er-Einheiten, obwohl ein Audio-Sektor 2352 Bytes hat.

6.4 ISO-Backup für Datendiscs (neu)

Die einzige echte Lücke gegenüber ARM. Wird eine Disc weder als Film noch als Musik erkannt, wird sie 1:1 gesichert statt abgelehnt: sequenziell aus \\.\G: lesen, Länge aus IOCTL_DISK_GET_LENGTH_INFO (in § 3.2 gemessen: liefert exakte Bytes). Kein Fremdwerkzeug nötig.

6.5 Mehrere Laufwerke gleichzeitig (neu)

Laufwerke sind eigenständige Objekte mit stabiler Kennung (Seriennummer, nicht Buchstabe — 0025114C0149 in § 3.2 gemessen). Ein Rip-Auftrag belegt genau ein Laufwerk; die Zahl gleichzeitiger Rips und Kompressionen ist einstellbar.

⚠️ Annahme, zu messen bevor sie festgeschrieben wird: Mehrere makemkvcon-Prozesse teilen sich ein Datenverzeichnis (_private_data.tar, settings.conf). Der Entwurf sieht deshalb vor: Rip-Phase parallel, Schlüssel-Phase serialisiert. Das ist aus der Aktenlage abgeleitet, nicht gemessen — und gehört an zwei Laufwerken geprüft, bevor die Grenze im Code steht.

6.6 Bibliothek (neu)

Eine Ansicht über alles Gerippte: Cover, Größe, Datum, Ablageort, Dauer des Vorgangs. Und der praktische Teil: Rippy erkennt beim Einlegen, wenn eine Disc schon einmal durchgelaufen ist (über die Disc-Merkmale aus § 5) und fragt nach, statt stumm zu doppeln.

6.7 Arbeitsverzeichnis und Ablage — eine Quelle

Der Fund aus rc11: Die Oberfläche schrieb in die Datenbank, der Betrieb las aus einer Konfigurationsdatei, die niemand schrieb. Eingestellt E:\Rippy, angezeigt C:\Users\...\Videos\Rippy.

In v5 gibt es genau einen Speicher für Einstellungen (speicher/einstellungen.ts, SQLite). Ein Wächter-Test prüft mechanisch, dass kein zweiter Ort entsteht.

Dazu die Pfad-Regeln aus rc11, als reine Funktionen mit Tests:

• Eine Laufwerkswurzel behält ihren Trenner (F:\, nicht F:)
• UNC-Wurzeln bleiben absolut
• Verzeichnisprüfungen sind windows-nativ — kein timeout ls -d
• Pro Rip darf ein anderes Arbeitsverzeichnis gewählt werden, und gesucht wird später unter der Wahl des Jobs, nicht unter der heutigen Einstellung

6.8 Selbst-Update (neu)

electron-updater gegen die Releases im Gitea (Entscheid 6). Rippy prüft beim Start und danach täglich, lädt im Hintergrund und installiert beim nächsten Start — nie mitten in einem Rip.

Die Quelle steht in der Konfiguration und ist vorbelegt. Ein nicht erreichbarer Update-Server ist kein Fehler, sondern eine Zeile im Protokoll.

Vier Regeln, die zum Entscheid gehören:

1. Nur HTTPS. Ohne Code-Signing (Entscheid 5) kann electron-updater ein heruntergeladenes Update nicht auf Echtheit prüfen — die Absicherung liegt damit ganz beim Transportweg. Eine http://-Update-Adresse wird abgelehnt, nicht stillschweigend akzeptiert.
2. Nie während eines Rips. Weder herunterladen noch installieren. Ein Neustart mitten in einem 90-Minuten-Rip wäre der teuerste Fehler, den ein Update-Mechanismus machen kann.
3. Ein Fehlschlag ist sichtbar, aber nicht laut. Die Prüfung darf still scheitern (WLAN weg, Server aus) — aber der Zeitpunkt der letzten erfolgreichen Prüfung steht im Über-Dialog. Wer nie prüft, weiß sonst nicht, dass er nie prüft.
4. Die Version, die läuft, ist ablesbar. Im Fenster und im Protokollkopf. Eine Fehlermeldung ohne Versionsnummer ist bei einem sich selbst aktualisierenden Programm die halbe Miete verloren.

6.9 Erst-Einrichtung (neu gedacht)

Der Befund des Commanders zur heutigen Fassung: „Dann hätte ich beim Setup auch erwartet, dass ein echtes Setup passiert — wo will ich das hinspeichern, ein Pre-Requirement-Check usw. Da kommt gar nichts, Rippy geht einfach auf."

Der Assistent läuft nach der Installation, im Programm selbst, in fünf Schritten:

Schritt	Was passiert
1 Willkommen	Was Rippy tut, in vier Sätzen
2 Prüfung	Laufwerke · Werkzeuge · Plattenplatz · Internet · WebView2 — jeder Befund sagt, was zu tun ist
3 Werkzeuge	Was fehlt, wird geholt (§ 9) — mit Fortschritt, nicht mit einem eingefrorenen Fenster
4 Ordner	Ablage und Arbeitsverzeichnis, mit echten Windows-Ordnerdialogen und Platzanzeige
5 Automatik	Wie viel soll Rippy allein entscheiden? Je Disc-Typ einstellbar.

Zwei Regeln, die aus dem alten Setup übernommen werden:

• Nur ein Fehler blockiert. Eine Warnung, die den Knopf sperrt, ist Bevormundung; ein Fehler, der nur warnt, ist eine Falle. Kein optisches Laufwerk ist eine Warnung — eine reine Komprimier-Maschine ist ein vorgesehener Betriebsfall.
• Ein Setup meldet nie Erfolg, während ein Pflichtwerkzeug fehlt. Der Bestand wird VOR und NACH dem Versuch gelesen; berichtet wird, was danach wirklich da ist.

6.10 Was unverändert erhalten bleibt

Alles, was der Commander heute benutzt:

Kompression je Disc-Typ abwählbar (4K verlustfrei durchreichen) · Preset-Wahl je Typ · Sprachwahl für Ton und Untertitel vor dem Rip · Original behalten · Vollautomatik · Nur-Hauptfeature · automatischer Auswurf · Medienserver-Refresh (Jellyfin/Emby/Plex/Kodi) · NFO + Poster + Fanart · Serien-Staffelablage mit Episoden-Zuordnung per Laufzeitabgleich (nur bei eindeutiger Zuordnung wird umbenannt) · Webhook-Benachrichtigungen (Discord/Slack/ntfy/generisch) · Live-Log · Job-Detailansicht · Wiederholen ab Rip oder ab Kompression · 4K-Schlüsselkette in drei Stufen · Restzeit-Schätzung.

---

7. Die Oberfläche

Entscheid: Neu bauen, Look behalten.

Wiedererkennbar bleibt die Design-Sprache — dunkel/hell, die Kachel-Anordnung, das Kino-Banner, die Farbwelt. Neu ist, dass die Oberfläche eine Einzelplatz-Anwendung bedient statt eines Docker-Clusters.

Was verschwindet: Worker-Verwaltung · Container-Platte · „Prüfen: docker compose ps" · Speicherziele-Einhängen · Pfad-Map · Worker-Setup-Paket · Encoder-Auswahl je Knoten · alles, was einen zweiten Rechner voraussetzt.

Was dazukommt:

• Echte Windows-Ordnerdialoge statt eines nachgebauten Dateibrowsers im Web. Das ist ein spürbarer Unterschied im Alltag: Der Nutzer sieht seine Netzlaufwerke, seine Schnellzugriffe, seine gewohnte Oberfläche.
• Tray-Symbol mit Zustand — auf einen Blick: läuft ein Rip, wie weit, wie lange noch. Rechtsklick: Öffnen, Pause, Beenden.
• Windows-Benachrichtigungen (echte Toasts, nicht Browser-Popups), mit Klick direkt in den Job.
• Fortschritt in der Taskleiste — Windows kann einen Fortschrittsbalken über dem Symbol zeigen. Bei einem 90-Minuten-Rip ist das genau die Information, die man will, ohne das Fenster zu öffnen.
• Die Bibliothek als eigene Ansicht (§ 6.6).

Was die Oberfläche NIE tut: Eine Liste auf leer setzen, weil eine Nachricht ausblieb (R2). Bei einem Aussetzer bleibt der letzte Stand stehen, und ein Banner sagt, dass gerade nichts Neues kommt.

---

8. Setup, Autostart, Deinstallation

Entscheid: pro Benutzer, ohne Administratorrechte, Windows 10 (ab 1809) und 11, x64.

Installer	electron-builder → NSIS, ein RippySetup.exe
Ziel	%LOCALAPPDATA%\Programs\Rippy — kein UAC-Dialog
Autostart	HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Update	electron-updater, NSIS-Ziel (§ 6.8)
Deinstallation	Über die Windows-Programmliste, räumt wirklich auf

Warum kein Windows-Dienst: Ein Dienst startet vor der Anmeldung — klingt besser, kostet aber bei jeder Installation und jedem Update eine Administrator-Abfrage, und er kann kein Tray-Symbol zeigen (keine Benutzersitzung). Für einen Rechner, an dem jemand sitzt und Discs einlegt, ist der Autostart-Eintrag der richtige Weg.

Drei Dinge, die aus den alten Fehlern übernommen werden:

1. Drüber-Installieren funktioniert. Rippy läuft fast immer (Autostart) — der Installer beendet die laufende Fassung, bevor er kopiert. Sonst landet die neue Version als Rippy.exe.neu daneben. (Genau das ist passiert.)
2. Die Deinstallation räumt die WebView-Reste weg. Beim letzten Mal blieben 148 Dateien liegen, weil die Renderer-Hilfsprozesse den Zwischenspeicher offen hielten — und der Deinstallierer meldete trotzdem „Rippy wurde entfernt."
3. Das Aufräum-Skript darf keine Laufwerkswurzel löschen. Wenn der Installationsort aus der Registry eine Wurzel wäre, löschte die Deinstallation das Laufwerk. Nicht beobachtet — aber nicht wiedergutzumachen.

SmartScreen — entschieden (Entscheid 5): kein Zertifikat. Die unsignierte EXE bekommt beim ersten Start eine Warnung („Der Computer wurde geschützt"); über Weitere Informationen → Trotzdem ausführen geht es weiter. Das gehört in die Anleitung, nicht unter den Teppich — und die Anleitung sagt auch, woran man erkennt, dass die Datei aus der richtigen Quelle stammt (Größe und Prüfsumme stehen beim Release).

Die Folge für den Update-Weg steht in § 6.8: Ohne Signatur ist der Transportweg die einzige Absicherung, also nur HTTPS.

---

9. Die Werkzeuge

Der Entscheid vom 28.08.2026 gilt unverändert: „handbrake und makemkv MÜSSEN mitgeliefert werden oder während des Setups separat installiert werden." Die Wege unterscheiden sich, und der Grund ist die Lizenz, nicht die Bequemlichkeit.

	Weg	Warum
HandBrakeCLI	mitgeliefert (~35 MB)	GPL-2 erlaubt die Weitergabe, solange Lizenztext und Quellverweis dabei sind. Damit komprimiert Rippy auch ohne Internet.
FLAC	mitgeliefert (~2 MB)	Xiph-Lizenz (BSD-artig), Weitergabe erlaubt. ⚠️ flac.exe braucht libFLAC.dll daneben — mit nur der EXE endet jeder Aufruf ohne eine Zeile Ausgabe.
MakeMKV	beim Einrichten geholt	Proprietär — die Lizenz erlaubt Dritten keine Weitergabe. Rippy lädt die offizielle Datei vom Hersteller und startet dessen Installer.

Die Bezugskette für MakeMKV (aus dem 28.08.-Entscheid, unverändert): eigene Quelle → Hersteller-Seite → Hersteller-Forum → Internet Archive. Mit zwei Feinheiten, beide gemessen: Die höchste Versionsnummer gewinnt, nicht die erste (das Archiv meldet sonst 1.18.2 statt 1.18.4), und jeder Versuch bekommt eine knappe Zeitgrenze (8 s), weil das Forum in zwei von drei Abrufen ausfiel.

MakeMKV signiert seinen Installer nicht (NotSigned, an der echten Datei gemessen) — geprüft wird deshalb die Versions-Ressource (CompanyName: GuinpinSoft inc). Das ersetzt keine Signatur, fängt aber ab, was hier wirklich droht: eine Fehlerseite mit .exe-Namen, ein abgebrochener Download, eine falsche Fassung.

9.1 Der Beta-Key — ein Termin, kein Detail

MakeMKVs freier Beta-Key ist bis Ende September 2026 gültig. Die Kaufseite für die Dauerlizenz ist seit Mai 2026 defekt.

Das trifft Rippy in etwa vier Wochen, und ohne gültigen Key geht keine Blu-ray und keine 4K-Disc mehr auf (DVDs laufen weiter).

Rippy v5 geht damit so um:

1. Der Key wird automatisch geholt (wie heute) — aus dem Forum-Thread, in dem der Hersteller ihn veröffentlicht.
2. Rippy zeigt das Ablaufdatum im Dashboard und warnt sieben Tage vorher — statt dass ein Rip mitten in der Nacht scheitert und niemand weiß, warum.
3. Ein abgelaufener Key ist eine klare Meldung, kein rätselhafter MakeMKV-Fehlercode.
4. Ein eingetragener Dauerlizenz-Schlüssel schlägt alles. Wer eine Lizenz hat, trägt sie ein und ist raus aus dem Thema.

---

10. Was aus dem alten Rippy mitkommt

Kein Code. Aber jede teuer bezahlte Erkenntnis.

Das ist der Kern des Grüne-Wiese-Ansatzes: Der Python-Code wird nicht portiert, aber er ist die beste verfügbare Dokumentation darüber, wie sich MakeMKV, HandBrake und Windows-Laufwerke wirklich verhalten. Diese Tabelle ist die Arbeitsliste für den Neubau.

Herkunft	Was übernommen wird	Wohin
ripping.py	TINFO/SINFO/PRGV/MSG-Parser, Kommandobau, laengster_titel, episoden_titel, Sprach-Zusammenfassung	rip/parser.ts, rip/makemkv.ts
win_ioctl.py	Die hergeleiteten Steuercodes samt Herleitung — in § 3.2 aus Node bestätigt	laufwerk/win32.ts
windows.py, winlauf.py	Zugriffsgründe je Fehlernummer, CREATE_NO_WINDOW, Standby verhindern, die Prozess-Leine	laufwerk/, werkzeuge/leine.ts
caps.py	Encoder messen statt behaupten (HandBrakeCLI --help auswerten)	komprimieren/encoder.ts
handbrake_aufruf.py	--aencoder (nicht --audio-codec), Container aus dem Preset erzwingen, letzte 12 Zeilen puffern, unknown option-Erkennung	komprimieren/handbrake.ts
medien.py	Zielstruktur, NFO-Schema, Episoden-Zuordnung per Laufzeit, Medienserver-Refresh	ablage/
prescan.py, clients/*	TMDb/TVDb/OMDb/MusicBrainz/Jikan-Abfragen, Zwischenspeicher, Confidence	metadaten/
pfade.py	Laufwerkswurzeln, UNC, naechster_vorhandener ohne Endlosschleife	speicher/pfade.ts
musicbrainz_cd.py, audio_cd.py	DiscID-Rechnung (mit/ohne 150 Frames), 2048-vs-2352-Falle	rip/audiocd.ts
presets.py, eta.py, phasen.py	Preset-Zuordnung je Disc-Typ, Restzeit, Phasenmodell	komprimieren/, ablauf/
beschaffen.py, katalog.py	Suchreihenfolge für Werkzeuge, Registry-Auswertung, Ausweichquellen	werkzeuge/
AGENTS.md	Die sechs Regeln aus § 4.3	Wächter-Tests

Die Tests wandern sinngemäß mit. Von den 977 heutigen Tests ist der größte Teil reine Textverarbeitung (Parser, Pfade, Kommandobau) — die Testfälle gelten unverändert, nur die Sprache wechselt. Das ist kein Nebeneffekt, sondern die Absicherung: Ein neu geschriebener Parser, der dieselben Testfälle besteht wie der alte, hat dieselben Fallen abgedeckt.

---

11. Was aus main entfernt wird

Entscheid 7. Die Arbeit gehört in den main-Branch, nicht hierher — dieser Abschnitt ist die Arbeitsliste dafür, damit sie nicht aus dem Gedächtnis gemacht wird.

11.1 Der Windows-Anteil in main sind DREI Dinge, nicht eins

Diese Unterscheidung ist der ganze Abschnitt. Wer sie überspringt, löscht entweder zu wenig oder reißt die Docker-Version mit.

Zuerst in Klartext, ohne Dateinamen:

A ist Rippy. B ist ein Handlanger für die VM. C sind Notizzettel, die wegen A eingeklebt wurden.

A — „Rippy" auf einem Windows-PC. Das Programm, das man heute kennt: RippySetup.exe, Doppelklick, Symbol in der Taskleiste, ein Fenster geht auf. Disc rein, Rippy erkennt sie, rippt, komprimiert, legt ab. Ein vollständiges Rippy, das alles allein macht. Genau das wird durch v5 ersetzt.

B — „Rippy Worker" auf einem Hilfsrechner. Ein anderes Programm, RippyWorkerSetup.exe. Es rippt nichts und hat keine Bedienoberfläche. Beim Installieren fragt es drei Dinge: IP der Rippy-VM? Name dieses Helfers? Wie viele Kerne? Danach wartet es. Will die Docker-Rippy auf der VM einen Film komprimieren und ist selbst zu langsam, schickt sie die Arbeit dorthin.

   VM (Docker-Rippy)                    Ein Windows-PC
   ├─ Disc einlesen
   ├─ rippen
   └─ komprimieren? zu langsam  ──────►  B: „Rippy Worker"
                                           komprimiert und
      Ergebnis  ◄─────────────────────     schickt zurück

B läuft nur zufällig auf Windows — es gehört zur Docker-Welt.

C — Notizzettel im Docker-Code. Keine eigenen Dateien, sondern verstreute Stellen mitten in Dateien, die Docker jeden Tag benutzt, wo jemand schrieb: „falls wir gerade auf Windows laufen, mach es anders". Eingebaut wurden sie, damit A funktioniert.

Der Unterschied zwischen A und C ist nicht der Inhalt, sondern der Ort:

	Bild	Aufräumen heißt
A	Ganze Ordner, auf denen „Windows" steht. Docker schlägt sie nie auf.	Ordner wegwerfen. Ganze Dateien löschen, fertig.
C	Einzelne Seiten mit Windows-Notizen, die in Ordnern liegen, die Docker täglich benutzt.	Seiten einzeln durchgehen. Die Datei bleibt, ein paar Zeilen gehen — und bei jeder Zeile ist zu prüfen, ob wirklich nur A sie brauchte.

Deshalb ist C der heikle Teil: Erwischt man eine Zeile, die Docker doch braucht, geht auf der VM etwas kaputt. Und manche Windows-Zeile braucht sogar B weiter — etwa die Regel, dass eine Laufwerkswurzel F:\ mit Trenner geschrieben werden muss (§ 1). Der Handlanger läuft ja auf Windows.

In Dateien ausgedrückt:

	Was es ist	Schicksal
A	Die Standalone-App — PyInstaller-Setup, Tray, WebView2-Fenster, Einrichtungs-Assistent, lokale Queue, Werkzeug-Beschaffung, Win32-Treiber	weg — v5 ersetzt sie
B	Der Remote-Encode-Worker — deploy/worker-windows/, /worker-setup/*, Pfad-Map	bleibt
C	Windows-Zweige im Docker-Code — die os.name == "nt"-Stellen in main.py, betrieb.py, ablauf.py, rohdaten.py, dazu die Fähigkeiten-Auskunft im UI	einzeln prüfen

Entscheid 8 (30.08.2026) — B bleibt bei Docker und kommt nicht nach v5.

Commander: „Das soll NICHT Teil des neuen Standalone-Produktes sein, da dieser NUR für die Docker-Variante verwendet wird."

Damit ist bestätigt, was zuvor nur Auslegung war: Der Remote-Worker ist kein Standalone-Rippy, sondern eine Funktion der Docker-Installation. Er wird weder abgeräumt (er ist Docker, und Docker bleibt unangetastet) noch nach v5 übernommen (v5 ist Einzelplatz, Entscheid 3 — es gibt dort keinen zweiten Knoten, dem man etwas schicken könnte).

11.2 Teil A — die Standalone-App (weg)

src/rippy/windows_app.py          Installer, Dienst, Deinstallation
src/rippy/fenster.py              WebView2-Fenster
src/rippy/setup_fenster.py        Einrichtungs-Assistent
src/rippy/einrichtung.py          Voraussetzungs-Prüfungen
src/rippy/standalone.py           lokale Zustellung statt Celery
src/rippy/drives/windows.py       Win32-Laufwerkstreiber
src/rippy/drives/win_ioctl.py     die Steuercodes
src/rippy/platform/winlauf.py     CREATE_NO_WINDOW, Waisen, Job Object
src/rippy/platform/win_registry.py
src/rippy/platform/verknuepfungen.py
src/rippy/platform/dateiangaben.py
src/rippy/tools/                  Werkzeug-Katalog + Beschaffung (Windows-only)
src/rippy/rip/audio_cd.py         Audio-CD über Win32
src/rippy/rip/musicbrainz_cd.py   DiscID-Rechnung
packaging/windows/                der PyInstaller-Bau
dist/windows/                     die gebaute EXE + vendor/
  + die zugehörigen test_*.py

Dazu: src/rippy/queue/lokal.py und queue/laeufer.py (die lokale Queue hat außerhalb der Standalone-App keinen Aufrufer) und bus/waechter.py, soweit er nur die Windows-Disc-Wache bedient.

Die Steuercodes und Parser sterben nicht — sie sind bereits nach v5 übernommen (§ 3.2 hat sie aus Node bestätigt, § 10 listet den Rest). Was gelöscht wird, ist die Python-Fassung, nicht das Wissen.

11.3 Teil C — die verstreuten Zweige (einzeln prüfen)

Hier ist blindes Löschen gefährlich, weil manches auch ohne die Standalone-App gebraucht wird — vom Remote-Worker (Teil B) oder von der Pfad-Behandlung allgemein.

Fundort	Prüfen
docker/api/main.py — betrieb.windows_laufwerke(), die Browse-Sonderfälle, /betrieb-Fähigkeiten	Die Fähigkeiten-Auskunft bleibt sinnvoll (Docker-AiO vs. verteilt), nur die Windows-Werte fallen weg
src/rippy/betrieb.py	Ganz raus oder auf Docker-Fälle eindampfen
docker/worker/ablauf.py, rohdaten.py	Die Windows-Pfadzweige raus — aber nativ_nachsehen() prüfen: gilt es auch für den Remote-Worker?
docker/api/rohdaten.py, mounts.py	dito
src/rippy/pfade.py	Bleibt. Laufwerkswurzeln und UNC braucht auch der Remote-Worker
UI: useBetrieb, WorkerVerwaltung, Anleitung, Settings	Nur die Standalone-Texte raus; die Worker-Verwaltung bedient Teil B
src/rippy/test_keine_container_reste.py	Der Wächter-Test wird gegenstandslos — mit weg

11.4 Wie das gemacht wird

1. Ein eigener Branch, nicht direkt auf main. Der Umfang ist zu groß für einen Freihand-Commit.
2. In der Reihenfolge A → C → (B bleibt). Erst die eindeutigen Dateien, dann die verstreuten Zweige — sonst sucht man Aufrufer, die es noch gibt.
3. Die Ampel nach jedem Schritt. AGENTS.md Regel A gilt unverändert; ein Aufräumen, das die Tests rot macht, ist nicht fertig, sondern angefangen.
4. Erst wenn v5 die Etappe W-6 erreicht hat. Solange v5 nicht installierbar ist, ist die alte Fassung das einzige Windows-Rippy, das es gibt. Sie zu löschen, bevor der Ersatz steht, wäre eine Lücke ohne Gegenwert — der Entscheid nennt kein Datum, nur die Richtung.
5. Ein SAVEPOINT-Eintrag dazu, mit der Zahl der entfernten Zeilen und dem Hinweis, wo das Wissen jetzt liegt.

---

12. Etappen

Grundregel: Jede Etappe endet mit grüner Ampel und einem Programm, das man starten kann. Kein großer Umbau, nach dem monatelang nichts geht.

#	Titel	Inhalt	Fertig, wenn
W-0	Gerüst	Electron 44 + TypeScript + Vite + Vitest, drei Prozesse, IPC, node:sqlite in Electron prüfen (§ 3.4), Prozess-Leine, CI-Ampel	Ein Fenster geht auf, der Kern läuft, ein Testlauf ist grün
W-1	Laufwerk	laufwerk/win32.ts aus dem § 3.2-Beweis, Wache über WM_DEVICECHANGE, Disc-Typ, Verriegeln, Auswerfen mit Nachsehen	Disc rein → Rippy sagt korrekt, was es ist. Auswerfen wirkt (nachgemessen, nicht geglaubt)
W-2	Rippen	makemkvcon-Aufruf, Parser, Fortschritt, Abbruch, Lesefehler-Warnung, Werkzeug-Beschaffung	Eine DVD und eine Blu-ray laufen durch, verlustfrei
W-3	Komprimieren + Ablegen	HandBrake, Encoder gemessen, Presets, Zielstruktur, NFO, Poster, Medienserver	Ein Film liegt fertig in Jellyfin und ist dort sichtbar
W-4	Metadaten-Automatik	Die vier Quellen aus § 5, Sicherheitsgrad, Nachkorrektur	Fünf verschiedene Discs richtig erkannt, ohne Nachfrage
W-5	Oberfläche	Dashboard, Einstellungen, Logs, Bibliothek, Tray, Windows-Toasts, Taskleisten-Fortschritt	Der Commander bedient Rippy einen Abend lang ohne Rückfrage
W-6	Setup + Update	NSIS, Autostart, Erst-Einrichtung, Selbst-Update, Deinstallation	Frischer Rechner: Setup → Disc rein → MKV raus. Und: drüber-installieren geht
W-7	Der Rest	Audio-CD, ISO-Backup, mehrere Laufwerke, 4K-Schlüsselkette	Je Feature ein Nachweis

Reihenfolge-Begründung: W-1 bis W-3 sind die Kette, ohne die Rippy nichts tut. W-4 und W-5 machen sie bequem. W-6 macht sie weitergebbar. W-7 sind die Ergänzungen, die ohne die Kette keinen Sinn hätten.

---

13. Risiken und offene Punkte

Risiko	Bewertung	Behandlung
MakeMKV-Beta-Key läuft Ende September 2026 ab	hoch × sicher	§ 9.1 — Ablaufdatum sichtbar, Warnung 7 Tage vorher, klare Meldung, Dauerlizenz eintragbar. Das ist der akuteste Punkt im ganzen Dokument.
node:sqlite in Electron ungeprüft	mittel × unbekannt	Erster Handgriff in W-0. Rückfallebene better-sqlite3
Neubau dauert länger als eine Reparatur	sicher	Deshalb Entscheid 2: Die Docker-Version läuft weiter. Es entsteht keine Lücke
Electron-Paket ~150–200 MB	sicher, gering	Ein einmaliger Download. Der Gegenwert ist eine Werkzeugkette statt zweier
SmartScreen bei unsignierter EXE	mittel	Entscheid 5: kein Zertifikat. Anleitung + Prüfsumme beim Release
Update ohne Signaturprüfung	mittel × Folge von Entscheid 5	§ 6.8 — nur HTTPS, http:// wird abgelehnt. Der Transportweg ist die einzige Absicherung, deshalb darf er nicht optional sein
Öffentliche Update-Quelle für Externe	offen × Netz-Frage	Entscheid 6 — Gitea liegt im LAN. Rippy ist für alle drei Wege gebaut (Adresse in der Konfiguration); die Wahl ist eine Infrastruktur-Entscheidung, keine Programmänderung
Aufräumen von main reißt Docker mit	mittel × vermeidbar	§ 11 — drei Teile sauber getrennt, Remote-Worker bleibt, Ampel nach jedem Schritt, und erst nach v5 W-6
koffi + Electron + npm-Install-Sperre	niedrig	§ 3.5 gemessen: koffi lädt mit vorgebauten Binärdateien. In W-0 im Electron-Kontext gegenprüfen
Parallel-Rip vs. MakeMKV-Datenverzeichnis	mittel	§ 6.5 — messen, bevor die Grenze festgeschrieben wird
Ein neu geschriebener Parser bringt neue Fehler	mittel	Die alten Testfälle wandern mit (§ 10). Ein Parser, der sie besteht, kennt dieselben Fallen
4K-UHD-Schlüssel	gelöst	Unter Windows holt makemkvcon sie selbst — der strukturelle Vorteil dieser Plattform, gemessen 25.07.2026

Alle drei offenen Punkte sind entschieden (30.08.2026)

Code-Signing: nein (Entscheid 5) · Update-Quelle: Gitea, auch für Externe (Entscheid 6) · alter Windows-Weg: wird entfernt (Entscheid 7) · der Remote-Worker bleibt bei Docker (Entscheid 8, § 11.1). Was daraus an Arbeit folgt, steht in § 11.

---

14. Was NICHT gebaut wird

• Kein Python. Auch nicht „nur für den einen Parser".
• Kein HTTP-Server, kein Port, kein localhost. Fenster und Kern reden über IPC.
• Keine Docker-Kompatibilität. Kein geteiltes Modul, kein gemeinsames Schema, keine Container-Pfade.
• Kein Linux, kein macOS. „100 % für Windows gebaut" heißt: Wo eine Windows-Lösung besser ist als eine portable, gewinnt die Windows-Lösung.
• Kein ARM-Fork. Rippy bleibt ein Eigenbau.
• Keine Auth. Einzelplatz, kein Netzdienst — es gibt nichts zu schützen.

---

Anhang — Verhältnis zu den bestehenden Konzepten

KONZEPT.md (v1) und KONZEPT-V2.md (v2) bleiben gültig für die Docker-Version. Dieses Dokument ersetzt sie nicht, es steht daneben.

Drei Punkte aus v2 werden für Windows bewusst anders entschieden — jeweils mit Begründung:

v2 sagt	v5 macht	Warum
Entscheid 4: kein Electron, pywebview + WebView2 (8 MB statt 150 MB)	Electron	Die Rechnung war richtig und die Schlussfolgerung trotzdem falsch: Sie hat nur die Fenster-Frage betrachtet. Der Preis für pywebview war nicht 0 MB, sondern eine zweite Werkzeugkette — PyInstaller, hidden imports, pythonnet, und ein Kern, der aus Container-Code bestand. Electron kostet 150 MB und schenkt uns eine Sprache von der Oberfläche bis zum Laufwerk.
Eine Anwendung, drei Verdrahtungen (Ports/Treiber)	Ein Windows-Programm	Die Ports-Architektur ist richtig für ein Produkt, das drei Betriebsarten tragen muss. Bei Entscheid 2 (Docker bleibt getrennt) trägt sie nichts mehr — sie wäre Abstraktion auf Vorrat.
REST + SSE als Schnittstelle	IPC	Ein lokaler Webserver in einer Einzelplatz-Anwendung ist eine offene Tür ohne Gegenwert.

---

Rippy v5 · Konzept · 30.08.2026 · Branch worktree-windows-electron