WAS:
- pipeline.starten fängt jede Ausnahme und meldet sie als Fehler des
Laufwerks; vor dem Start eine Schreibprobe am Zielordner mit Klartext
(„nicht erreichbar … NAS verbunden?"). Vorher warf mkdirSync bei toter
Ablage aus starten() heraus, der Aufrufer schluckte es: kein Fehler im
Fenster, keine Protokollzeile, der Dialog ging zu (Sonde 10).
- kern/index.ts: unbehandelte Promise-Ablehnungen landen im Protokoll und
im Fenster (gemessen: ein Electron-utilityProcess stirbt daran nicht,
er schweigt); echte Ausnahmen werden protokolliert, der Kern endet
kontrolliert, der Haupt startet ihn neu. Die Einlege-Kette hat ein
Fangnetz.
- kernstart.ts spannt nach einem Kern-Neustart den Fenster-Port neu auf;
das Fenster schließt den toten Port und meldet den Neustart als Zeile.
Vorher blieb es taub, bis Rippy komplett neu gestartet wurde.
- wache.runde() löscht den geplanten Timer, bevor es einen neuen setzt —
jeder Auswurf legte sonst eine weitere 3-s-Kette an (Sonde 3).
- beenden() räumt den leeren Roh-Ordner, verschont aber rettung.iso und
den Bericht (RETTUNG_DATEIEN).
- Typ „unbekannt" heißt nur ohne Titel-Auftrag ISO; mit Auftrag rippt
makemkvcon, der Typ folgt der Größe (Blu-ray/DVD) für Preset und Ordner.
WARUM: Durchsicht 12.09.2026, Funde F2, F4, F6, F8, F10 — jeder mit Test.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
kern/laufwerk in drei Schichten: codes.ts (Steuercodes HERGELEITET wie
win_ioctl.py, gegen die Doku-Zahlen getestet), win32.ts (der einzige
koffi-Ort im Kern, Muster aus beweise/laufwerk.js), disc.ts (Logik gegen
die LaufwerkApi-Schnittstelle — classify mit den cdrom.py-Schwellen,
Geraete-Info mit ready/empty/unknown + Klartext-Grund, Auswurf als
entriegeln→auswerfen→NACHSEHEN mit injizierbarem Warten). Dazu wache.ts
im 3-Sekunden-Takt (§ 5 Plan A): Uebergangslogik pur, gescheiterte Runde
behaelt den Stand (R2) und meldet laut (R4).
Fenster zeigt Laufwerke live (Modell, Typ, Groesse, Grund) mit
Auswerfen-Knopf; Ereigniszeilen fuer Disc rein/raus und Fehler.
Bündel-Falle gefunden und behoben: Ein woertliches require überlebt
Rollup nicht — win32 wird per dynamischem import() als eigener Chunk
gebaut; der Fehler war dank R4 im Fenster sichtbar statt still.
Gemessen am echten BU40N (30.08.2026, RIPPY_MESSUNG=1):
Laufwerk G: status=ready typ=bluray groesse=33759690752
modell=HL-DT-ST BD-RE BU40N 1.03 serial=0025114C0149
Der Auswurf-Beweis (messung.auswurf) folgt am Ende der Sitzung — der
BU40N kann die Schublade nicht selbst einziehen.
52 Tests gruen (Steuercodes, classify, Auswurf-Ablauf, Geraete-Info,
Wache, Smoke weiterhin gruen mit Laufwerks-Kachel im Bild).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
