docs(konzept): Entscheid 8 — der Remote-Worker bleibt bei Docker

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

Damit ist bestaetigt, was in Paragraph 11.1 zuvor nur als Auslegung stand.
Der Remote-Encode-Worker wird WEDER abgeraeumt (er ist Docker, und Docker
bleibt unangetastet — Entscheid 2) NOCH nach v5 uebernommen (v5 ist
Einzelplatz, Entscheid 3 — es gibt dort keinen zweiten Knoten, dem man
etwas schicken koennte).

Dazu die eigentliche Reparatur an diesem Abschnitt: Er war in
Entwickler-Begriffen geschrieben (Modulnamen, PyInstaller, os.name-Zweige)
und deshalb fuer den Adressaten nicht lesbar — zweimal nachgefragt, zweimal
zu Recht. Paragraph 11.1 fuehrt die drei Teile jetzt erst in Klartext ein:

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

Und macht den Unterschied A/C an dem fest, worauf es beim Aufraeumen
ankommt — nicht am Inhalt, sondern am Ort: A sind ganze Ordner, die Docker
nie aufschlaegt (wegwerfen). C sind einzelne Seiten in Ordnern, die Docker
taeglich benutzt (einzeln durchgehen). Erst danach kommt die Tabelle mit
den Dateinamen.

Das ist kein Beiwerk: Genau diese Verwechslung wuerde beim Aufraeumen die
laufende VM treffen. Und manche Windows-Zeile braucht sogar B weiter — etwa
die Regel, dass eine Laufwerkswurzel ihren abschliessenden Trenner behaelt.

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

KONZEPT-WINDOWS.md

@@ -70,9 +70,9 @@ bei einem Container, dem man Windows beibringt.
 
 ## 2. Die Entscheidungen (Commander, 30.08.2026)
 
-Sieben Entscheide, alle am selben Tag. Die ersten vier legen die Architektur
-fest, die letzten drei beantworten die Punkte, die das Konzept offengelassen
-hatte. Sie stehen hier, damit später nachvollziehbar ist, was Entscheidung war
+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
@@ -777,24 +777,71 @@ gemacht wird.
 
 ### 11.1 Der Windows-Anteil in `main` sind DREI Dinge, nicht eins
 
-Das ist die Unterscheidung, an der ein unvorsichtiges Aufräumen scheitern
-würde:
+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** — sie wird durch v5 ersetzt |
-| **B** | **Der Remote-Encode-Worker** — ein Windows-PC als Encoder-Knoten *für die Docker-Installation* (`deploy/worker-windows/`, `/worker-setup/*`, Pfad-Map) | **bleibt** — siehe Kasten |
-| **C** | **Windows-Anpassungen im Docker-Code** — die `os.name == "nt"`-Zweige in `main.py`, `betrieb.py`, `ablauf.py`, `rohdaten.py` und die Fähigkeiten-Auskunft im UI | **einzeln prüfen** — der heikelste Teil |
+| **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** |
 
-> **Warum B bleibt:** Der Remote-Worker ist kein Standalone-Rippy, sondern eine
-> **Funktion der Docker-Installation** — ein zweiter Rechner nimmt der VM das
-> Komprimieren ab. Entscheid 2 sagt, dass die Docker-Version unangetastet
-> bleibt; ihn mit abzuräumen würde der VM eine Fähigkeit nehmen, die heute
-> funktioniert und die niemand gekündigt hat.
+> **Entscheid 8 (30.08.2026) — B bleibt bei Docker und kommt nicht nach v5.**
 >
-> Das ist eine **Auslegung** des Entscheids, keine Anweisung des Commanders.
-> Wenn der Remote-Worker auch weg soll, ist das ein Satz — aber dann bewusst
-> und nicht als Nebenwirkung.
+> 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)
 
@@ -901,8 +948,9 @@ Ergänzungen, die ohne die Kette keinen Sinn hätten.
 ### 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).
-Was daraus an Arbeit folgt, steht in § 11.
+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.
 
 ---