Multi-Hoster-Upload/PROJECT_MEMORY.md

# Projekt-Memory

## Zweck

Multi-Hoster-Upload ist eine Electron-Desktopanwendung für Windows, die große Dateimengen aus einer gemeinsamen Queue gleichzeitig zu Doodstream, VOE, Vidmoly, Byse und Clouddrop hochlädt.

## Aktueller Zustand

- Lokale Entwicklung auf Nutzerwunsch dauerhaft mit automatischem Neustart: `.artifacts/dev-watch.cjs` überwacht Main-/Preload-Dateien, `lib`, `renderer` und den lokalen Bootstrap `.artifacts/menu-test.cjs`. Start über `node .artifacts/dev-watch.cjs`; separater Fenstertitel „Multi-Hoster – Entwicklung (automatischer Neustart)“. Persistentes Testprofil unter `%LOCALAPPDATA%/Multi-Hoster-Upload-Development`, ohne automatische Accountchecks/Ordnerüberwachung/Remote-Steuerung initialisiert. Installierte Anwendung bleibt getrennt. Neustart durch CSS-Dateiänderung anhand gewechselter Electron-PID und erneut sichtbarem Fenster verifiziert. Bei weiteren Code-/UI-Änderungen diesen Watcher verwenden und den Neustart prüfen.
- Online-Backup-Gültigkeitsdauer nach `2.1.49`, noch nicht veröffentlicht: Auswahl und Erstellen-Button verwenden 40 px Höhe und 14 px Schrift; Label und Auswahl sind zur Importzeile ausgerichtet. Footer bricht bei Platzmangel um, auf schmalen Fenstern untereinander. Leere Statuszeile belegt keinen Platz; echte Meldungen bleiben sichtbar. Nativer Select und 14 px Pfeil-Innenabstand bleiben erhalten. Electron-Layoutregression bei 1000, 600 und 360 px; Screenshot der breiten Darstellung visuell geprüft.
- Nach `2.1.49`, noch nicht veröffentlicht: Backup-Untermenü erhält eine durchgängige Hover-Fläche über den sichtbaren Abstand und 250 ms abbrechbare Schließverzögerung. Hover plus Klick bleibt offen, erneutes Betreten startet keine neue Öffnungsanimation; Tastaturfokus hält das Untermenü offen. Pfeil und Pfeiltasten folgen der linken Öffnungsrichtung, Escape schließt nur die aktuelle Untermenüebene. Fremde `animationend`-Ereignisse schließen kein übergeordnetes Panel mehr. Electron-Regression prüft DOM-Treffertests im Abstand, verzögerte Ein-/Austritte, Klick, Fokus und Escape bei 850 und 600 Pixel Fensterbreite. Kein Release beauftragt.
- Release `2.1.49` auf beiden Plattformen veröffentlicht und geprüft: Vidmoly-Sitzungsprüfung, getrennte Upload-Sperrmeldungen, Checkbox-Fokusfix und GB-Dateigrößenlimit. Live-Diagnose am 22.09.2026 bestätigt zuerst gültige Anmeldung mit `UPLOAD_DISABLED` (Upload-Konfiguration HTTP 403), danach erfolgreiche Anmeldung und vollständige Upload-Konfiguration (HTTP 200). Nutzer bestätigt funktionierende Anmeldung und gibt Release frei. Ein tatsächlicher Dateitransfer wurde dadurch nicht nachgewiesen. Ältere Angaben zu unveröffentlichten Änderungen darunter dokumentieren die Vorbereitung; diese Änderungen sind jetzt in `2.1.49` enthalten.
- Vidmoly nach `2.1.48`, noch nicht veröffentlicht: Anmeldung wird über `/api/auth/me` statt anhand der Upload-Konfiguration verifiziert. Öffentliches Website-JavaScript am 22.09.2026 bestätigt unveränderte Upload-Felder sowie `DISK_FULL`, `UPLOAD_IP_BLACKLIST` und `UPLOAD_DISABLED`; diese Antworten werden jetzt getrennt und ohne Antwortdaten angezeigt. Upload übernimmt zusätzlich das aktuelle Webfeld `tos=1`, weiterhin ohne API-Key. HTTP-Fehler, fehlende Benutzer, OTP-Anforderung und ungültige Serveradressen werden geprüft. Die konkrete Serverantwort des gemeldeten Accounts war in den lokalen Logs nicht vorhanden; erfolgreicher Live-Login/Upload ist noch nicht bestätigt.
- Nach `2.1.48` lokal geändert, noch nicht veröffentlicht: Checkboxen in den Hoster-Einstellungen übernehmen beim Mausklick nicht mehr den Fokus-Schatten von Textfeldern. Tastatur-Fokusmarkierung bleibt erhalten; echter isolierter Electron-Test prüft An-/Abhaken, Tabulator, Leertaste und unveränderten Zahlenfeld-Fokus.
- Hoster-Dateigrößenlimit wird direkt in GB eingegeben (`0` unbegrenzt, `1 GB = 1024 MB`). Beide Speicherwege rechnen verlustfrei in das bestehende `maxSizeMb`-Format um; bestehende Einstellungen und Backups bleiben kompatibel. Import-Vorprüfung und Upload-Manager überspringen zu große Dateien pro Hoster, lassen die exakte Grenze und andere Hoster zu. Regressionen prüfen 5 GB, einen Byte darüber sowie Dezimalwerte. Vorab übersprungene Jobs melden korrekt 0 Versuche statt der konfigurierten Höchstzahl.

- IP-Erweiterung am 22.09.2026 nach gesondertem Go aktiviert: Backup-API `2.0.6` produktiv; App `2.1.48` auf beiden Plattformen veröffentlicht. Vorheriger Live-Iststand: Dienst `2.0.5`, 13 Datensätze. Sicherung `/var/backups/mhu-backup-api/20260922-pre-ip.tar.gz` enthält Daten, Konfiguration, öffentlichen Wiederherstellungsschlüssel, Dienstdefinition und bisherigen Dienststand. Archivtest erfolgreich; SHA-256 `7be0a9f4497cae20d89606e4872d41eb555fd66bf4613503e6f84e4aa5300e7f` entspricht der geschützten lokalen Kopie `server-backup-pre-ip-20260922.tar.gz` im Wiederherstellungsordner.
- Staging `staging-ip`: Alle 13 Bestandsdatensätze unverändert lesbar; Erstellen eines Version-4-Testbackups mit Herkunfts-IP, private Wiederherstellung, normaler Import und gezieltes Löschen erfolgreich. Anschließend sämtliche 13 Live-Dateien per SHA-256 mit der getesteten Kopie abgeglichen. Keine Live-Datensätze verändert.
- Lokaler Build `2.1.48`: Installer 98.032.605 Bytes, Portable 97.807.985 Bytes, Produktversion jeweils `2.1.48`. Verpackte Quellmodule und Update-Manifest geprüft; keine Schlüssel oder Nutzerdaten enthalten. Englische/deutsche Release-Texte veröffentlicht. Dienstpfad `/opt/mhu-backup-api/releases/20260922-v2.0.6` aktiviert und Dienst neu gestartet. Live-Smoke bestätigt serverseitige öffentliche Herkunfts-IP, privaten Wiederherstellungsweg und normalen Import. Ausschließlich eigenen Testdatensatz danach gelöscht; alle 13 Bestandsdatensätze per SHA-256 unverändert bestätigt. Kein pauschaler Rollback auf `2.0.5`, sobald neue Version-4-Datensätze vorhanden sind; Daten müssen erhalten bleiben.

- IP-Erweiterung seit `2.1.48` veröffentlicht und aktiviert: Der Dienst speichert die serverseitig ermittelte Herkunfts-IP neuer Sicherungen und gibt sie ausschließlich in der Erstellungsantwort zurück. Client-Schlüsselbund und Oberfläche behalten die IP neben Datum/Uhrzeit; alte Einträge zeigen `IP unbekannt`. Offline-Wiederherstellung unterstützt `--details` für `Datum - Uhrzeit | IP: Adresse | MHU2-…` (Zeitzone Europe/Berlin), ohne Flag weiterhin nur den Schlüssel. Private Schlüssel werden nicht übertragen und vollständige Online-Schlüssel nicht in der Übersicht angezeigt.
- IP-Datensätze verwenden Version 4; neuer Dienst liest weiterhin Versionen 1–3. Ein Rückwechsel auf die alte Serverversion nach ersten Version-4-Datensätzen erfordert einen datenerhaltenden Kompatibilitätsplan. Live-Aktivierung nach Backup, Staging und ausdrücklichem Go erfolgt; keine Migration oder Änderung bestehender Datensätze. Bestehende IPs nicht nachträglich raten.
- Read-only geprüft: Der produktive Proxy für den Backup-Endpunkt überschreibt `X-Forwarded-For` mit der beobachteten Verbindungsadresse; der Dienst vertraut ausschließlich den konfigurierten Loopback-Proxyadressen. Die IP kann die öffentliche Adresse eines VPN/NAT darstellen und ist keine eindeutige Gerätekennung. Sie unterliegt derselben Aufbewahrung wie der Backupdatensatz und wird nicht vom öffentlichen Restore-Endpunkt ausgegeben.

- Version `2.1.47` veröffentlicht: Standardgültigkeit neuer Online-Schlüssel ist `Unbegrenzt`. Bestehende Ablaufdaten bleiben unverändert; Backup-API bleibt `2.0.5`. Release-Commit `afdad99`, annotierter Tag auf beiden Plattformen identisch. 823 Haupttests, 17 Servertests, Lint und Audit erfolgreich. Installer 98.032.502 Bytes, Portable 97.807.793 Bytes. Alle acht veröffentlichten Dateien erneut heruntergeladen und per SHA-512 geprüft. Titel, Sprachen, Assets und Update-Manifeste auf beiden Plattformen verifiziert. Der eingebaute Updater erkennt `2.1.47` ausgehend von `2.1.46`.

- Lokale Erweiterung: Online-Backups erhalten einen RSA-3072/OAEP-SHA256-verschlüsselten Wiederherstellungsumschlag, der an die Datensatzkennung gebunden ist. Der private Wiederherstellungsschlüssel bleibt außerhalb des Servers. Verwaltungswerkzeug: `scripts/backup-recovery.cjs`; Einrichtung und Offline-Wiederherstellung stehen in der README.
- Anwendung `2.1.46` auf GitHub und Forgejo veröffentlicht; Backup-API `2.0.5` nach gesondertem Go produktiv aktiviert. Schlüsselpaar lokal außerhalb des Projekts in einem auf Benutzerkonto und SYSTEM beschränkten Ordner eingerichtet; privater Schlüssel nie auf den Server übertragen. Eine unabhängige Sicherung im Passwortmanager/Offline-Speicher bleibt erforderlich. Der neue Client verweigert neue Exporte ohne verfügbaren öffentlichen Schlüssel. Alte Clients und bisherige Importe bleiben kompatibel.
- Am 22.09.2026: Live-Dienst `2.0.4` aktiv, 12 Datensätze. Sicherung `/var/backups/mhu-backup-api/20260922-pre-recovery.tar.gz` enthält Daten, Konfiguration, Dienstdefinition und bisherigen Programmstand. Gzip-Test erfolgreich; SHA-256 `4adeaae898317b1bbb179df019782065852a84647daa95da2d6147b61fe28838` entspricht der lokalen geschützten Kopie. Staging auf entpackter Kopie: alle 12 bestehenden Datensätze unverändert lesbar; Erstellen, private Wiederherstellung, Import und Löschen eines neuen Testbackups erfolgreich. Keine produktiven Datensätze verändert.
- Release `2.1.46`: Installer 98.032.406 Bytes, Portable 97.807.695 Bytes, beide Produktversion `2.1.46`. Verpackte Wiederherstellungsmodule stimmen mit dem Quellcode überein; keine privaten Schlüssel oder Nutzerdaten enthalten. Installer-SHA-512 und Größe passen zum Update-Manifest. Erneut 822 Haupttests, 17 Servertests und Lint erfolgreich. Beide Releases enthalten vier geprüfte Assets und inhaltlich gleichwertige englische/deutsche Changelogs.
- Aktivierung am 22.09.2026: ausschließlich öffentlichen Schlüssel als `/etc/mhu-backup-recovery-public.pem` installiert, Backup-API `2.0.5` in `/opt/mhu-backup-api/releases/20260922-v2.0.5` bereitgestellt, `RECOVERY_PUBLIC_KEY_FILE` in `/etc/mhu-backup-api.env` ergänzt, `current` umgestellt und Dienst neu gestartet. HTTPS-Smoke bestätigt Schlüsselabfrage, Speicherung, private Wiederherstellung und normalen Import. Ausschließlich den eigenen Testdatensatz anschließend gelöscht. Alle 12 ursprünglichen Datensätze danach mit identischen SHA-256-Prüfsummen bestätigt. Rückfallziel: bisheriger Dienstpfad `20260901T140230Z-v2.0.4` und gesicherte Konfiguration `/var/backups/mhu-backup-api/20260922-pre-recovery.env`.

- Aktive Arbeitslinie: `master` aus `Sucukdeluxe/Multi-Hoster-Upload`.
- Zuletzt veröffentlichter Funktionsstand: Version `2.1.49`, Release-Commit `e9ea91a`, annotierter Tag `1d52286` auf beiden Plattformen identisch.
- Version `2.1.46` ist auf GitHub und Forgejo veröffentlicht. Beide Release-Changelogs benennen die weiterhin fehlgeschlagene DoodStream-Web-Serverermittlung ausdrücklich als bekanntes Problem; ein erfolgreicher Dateiupload wird nicht behauptet.
- Einstiegspunkt des Electron-Hauptprozesses: `main.js`.
- Oberfläche: `renderer/`; gekapselte Fachlogik: `lib/`; Online-Backup-Dienst: `services/backup-api/`.
- Die Abhängigkeiten sind lokal mit Node.js 24 installiert.

## Entscheidungen

- Weiterarbeit erfolgt im aktiven Repository `Multi-Hoster-Upload`, nicht im archivierten `Multi-Hoster-Upload-Private-Archive` und nicht im älteren Tauri-Versuch `Multi-Hoster-Upload-2`.
- Die jüngste Automatik schützt erfolgreiche Uploads mit einem atomar gespeicherten Abschlussnachweis aus vollständigem Pfad, Hoster, Dateigröße und Änderungszeit.
- Schlägt dieser Nachweis fehl, bleibt die Queue erhalten und der Fehler wird als lokale Persistenzstörung behandelt, damit kein stiller Doppel-Upload entsteht.
- DoodStream-OTP-Prüfungen verwenden dieselbe Cookie-Sitzung weiter, fassen identische oder parallele Checks zusammen und fordern einen neuen Code nur nach einer ausdrücklichen Aktion mit mindestens 60 Sekunden Abstand an.
- DoodStream respektiert die ausdrückliche Auswahl `authType=login`: Weblogin und Webupload werden nicht durch einen zusätzlich gespeicherten API-Key übersteuert. API-Accounts und ältere Accounts ohne ausdrückliche Login-Auswahl behalten den API-Weg.
- Sammelchecks melden jedes Account-Ergebnis einzeln an den Renderer, sodass fertige Karten sofort grün, rot oder als OTP-pflichtig erscheinen, während die übrigen Accounts weiter geprüft werden.
- Neue Online-Backups unterstützen `24 Stunden`, `3 Tage`, `7 Tage`, `31 Tage` und `Unbegrenzt` (Standard seit `2.1.47`). Bestehende Schlüssel behalten ihre Laufzeit. Endliche Schlüssel werden lokal aus dem verschlüsselten Schlüsselbund entfernt und serverseitig ab Ablauf nicht mehr wiederhergestellt; der Dienst räumt abgelaufene Datensätze bei Zugriff oder der nächsten Speicherung auf.
- Vorhandene Online-Backups und alte Upload-Payloads ohne Ablaufangabe bleiben zur Abwärtskompatibilität unbegrenzt gültig.
- Backup-Importe wenden Sprache und automatischen Account-Check sofort an. Alle Konfigurationsfelder werden übertragen; Warteschlange, Upload-Wiederherstellungsstatus, letzter Dateiauswahlordner, Automatik-Telemetrie und Pausenzustand bleiben bewusst geräte- beziehungsweise laufzeitgebunden.
- Ein nicht vorhandener Ordnerüberwachungspfad bleibt nach dem Import sichtbar gespeichert, die Überwachung wird aber deaktiviert und der Nutzer erhält eine Warnung. Ein nicht vorhandener Log-Ordner wird ebenfalls gemeldet, ohne den konfigurierten Pfad still zu löschen.
- Upload-Status-Badges und ihre Textlabels sind nicht markierbar; kopierbare Fehlerdetails, Logs und Eingabefelder behalten ihre Textauswahl.
- VOE-Fehler mit der Meldung `Maximum storage space of the account used up.` gelten als temporärer Accountfehler. Die Retry-Schleife bricht auch nach einem bereits erfolgten Account-Wechsel sofort ab und setzt die Fallback-Kette Account für Account fort, bis ein Upload gelingt oder kein weiterer Account verfügbar ist.
- Der DoodStream-Weblogin folgt dem aktuellen Browservertrag über `GET /?op=login_ajax`, behandelt `otp_sent` und `redirect` ausdrücklich und übernimmt `sess_id` auch aus den aktuellen Vue-Daten mit URL-sicheren Sonderzeichen. Die Upload-Server-Ermittlung verwendet `/?op=upload_get_srv` und versteht dessen `server.srv_url`-/`server.disk_id`-Antwort.
- Eine bestätigte DoodStream-Dashboard-Sitzung benötigt beim Account-Check kein Upload-Sessionfeld. Uploads übernehmen unabhängige Kopien der bestätigten Cookie-Sitzung aus dem OTP-Koordinator. Ein fehlender Upload-Server ist vom Login getrennt; bei Web-Accounts findet keine automatische API-Key-Ableitung für Uploads statt.
- Version `2.1.45` ist als GitHub- und Forgejo-Release veröffentlicht; Backup-API `2.0.4` blieb bei dieser reinen Veröffentlichung der Desktopanwendung unverändert aktiv.
- Der eingebaute Updater liest Releases und Binärdateien von Forgejo; GitHub liefert ergänzend die öffentlichen Release Notes. Ein Release ist deshalb erst vollständig, wenn die vier Assets auch im Forgejo-Release vorhanden sind.
- Forgejo bewahrt Leerzeichen in Asset-Namen, GitHub normalisiert sie zu Punkten. Das Forgejo-`latest.yml` und der Release-Plan verwenden Namen wie `Multi-Hoster-Upload Setup 2.1.44.exe`; das GitHub-Manifest muss auf den dort tatsächlich veröffentlichten Punktnamen zeigen.
- `forgejo/master` besitzt eine getrennte ältere Historie. Die aktuelle GitHub-Arbeitslinie wird deshalb zerstörungsfrei unter `forgejo/sync/github-master` gespiegelt.

## Start- und Testbefehle

```powershell
npm ci
npm start
npm run verify
```

Im aktuellen übergeordneten Windows-Pfad enthält der Ordnername ein `&`. Dadurch können von npm erzeugte `.cmd`-Shims zerlegt werden. Die verifizierten direkten Aufrufe sind:

```powershell
node node_modules/eslint/bin/eslint.js .
$testFiles = @((Get-ChildItem tests -Filter '*.test.js').FullName) + (Resolve-Path tests/ui-smoke.js).Path
node --test @testFiles
node --test services/backup-api/test/server.test.mjs
npm audit --omit=dev
```

## Bekannte Probleme

- `npm run verify` bricht in diesem konkreten Arbeitsverzeichnis bereits beim npm-Shim ab, obwohl Linter und Tests bei direktem Aufruf erfolgreich sind.
- Der Forgejo-Standardzweig ist nicht mit dem aktuellen GitHub-`master` verwandt und darf nicht ohne gesonderte Prüfung oder ausdrückliche Freigabe überschrieben werden.
- Der optionale, nur mit `RUN_UI_SMOKE=1` aktivierte Langzeit-UI-Test meldet reproduzierbar 16 bestehende Timing-/Fixture-Abweichungen außerhalb des Accounts-/OTP-Pfads; die reguläre CI aktiviert diesen Test nicht.

## Offene nächste Schritte

- Vidmoly-Livediagnose abgeschlossen: separate lokale Testinstanz mit temporärem Profil und kopierten Vidmoly-Accounts; keine automatischen Accountchecks, Ordnerüberwachung oder Remote-Steuerung. Lokaler Launcher `.artifacts/vidmoly-dev.cjs` erfasst nur HTTP-Status, feste Fehlercodes und Strukturmerkmale in `.artifacts/vidmoly-live-diagnostic.jsonl`; keine Passwörter, OTP-, Cookie- oder Sessionwerte. Erfolgreiche manuelle Anmeldung und Upload-Konfiguration bestätigt; installierte Anwendung nicht automatisch aktualisiert. Dateitransfer bleibt separat zu prüfen.
- DoodStream: Am 12.09.2026 wurde das authentifizierte Dashboard ohne `sess_id` live bestätigt. Der alte Upload-Aufruf lieferte eine andere Seite ohne Upload-Felder. Ein zwischenzeitlich getesteter API-Ausweichweg bestätigte zwar den Account, wurde auf Nutzerwunsch wieder entfernt; dessen Uploadversuch scheiterte serverseitig mit `No servers available for uploads`. Der aktuelle Web-Upload muss noch live auf Serververfügbarkeit und erfolgreichen Dateitransfer geprüft werden. Die lokale Seitendiagnose protokolliert ausschließlich Strukturmerkmale ohne Formularwerte, OTP oder Cookie-Werte.
- Keine offenen Veröffentlichungsschritte für Release `v2.1.49`; ein Server-Rollback muss Version-4-Datensätze erhalten und lesen können. Das oben dokumentierte DoodStream-Uploadproblem bleibt offen. Privaten Wiederherstellungsschlüssel zusätzlich unabhängig vom lokalen PC sichern.
- Bei Bedarf einen Arbeitsweg ohne `&` im absoluten Pfad verwenden oder die npm-Aufrufe weiterhin direkt ausführen.

## Zuletzt verifiziert

- Gültigkeitsdauer-Layout: neue Electron-Regression erfolgreich, Screenshot visuell geprüft, Lint und 18 Servertests erfolgreich. Hauptlauf 838/839 erfolgreich: Menü-Fokustest reagierte einmal zu früh auf asynchronen Fokus. Test wartet jetzt begrenzt auf den tatsächlichen Fokus statt pauschal 240 ms; kompletter Wiederholungslauf der betroffenen Datei 25/25 erfolgreich. Kein Release erstellt.
- Backup-Untermenü nach `2.1.49`: 838 Haupttests, 18 Servertests und Lint erfolgreich. Gezielter Electron-Test nach abschließender Fokuskorrektur erneut erfolgreich; ein Mausklick auf den Trigger hält das Menü beim Verlassen nicht unbeabsichtigt offen. Änderungen noch nicht veröffentlicht.
- Release `2.1.49`: Titel, Tags, englischer GitHub- und deutscher Forgejo-Changelog, jeweils vier Assets und Update-Metadaten geprüft. Alle acht veröffentlichten Dateien erneut heruntergeladen und Größe sowie SHA-512 mit lokalen Dateien verglichen. Echter Updater erkennt `2.1.49` ausgehend von `2.1.48` und akzeptiert englische Hinweise sowie Forgejo-Manifest. Öffentlicher Quellcheck einschließlich Screenshots erfolgreich (164 Dateien). Keine produktive Serveränderung erforderlich.
- Releasevorbereitung `2.1.49`: 837 Haupttests und 18 Backup-API-Tests erfolgreich, Lint erfolgreich, Produktionsaudit ohne Schwachstellen. Installer 98.033.241 Bytes, Portable 97.808.535 Bytes, beide Produktversion `2.1.49`. Gepackte Vidmoly-, Upload-, UI- und Backupmodule entsprechen dem Quellstand; keine Nutzerdaten enthalten. Installer-SHA-512 und Größe stimmen mit dem Update-Manifest überein.
- Vidmoly-Änderung vom 22.09.2026: alle sieben neuen Regressionen und Lint erfolgreich. Hauptlauf: 836 von 837 Tests erfolgreich; bestehender Electron-Checkbox-Fokustest einmal mit Timingfehler, separater Wiederholungslauf der gesamten Datei mit 23 von 23 erfolgreich. Backup-API weiterhin 18 von 18 erfolgreich. Öffentlicher Quellcheck umfasst 164 Dateien. Keine Live-Anmeldung und kein Release durchgeführt.
- Checkbox-/GB-Limit-Änderung nach `2.1.48`: 830 Haupttests und 18 Servertests erfolgreich; Lint ohne Fehler. Echter Electron-Fokustest sowie GB-Speicher-, Import- und Upload-Grenztests erfolgreich. Änderungen noch nicht als Update veröffentlicht.

- Release `2.1.48`: Titel, Sprachen, Veröffentlichung, jeweils vier Assets und Update-Metadaten beider Plattformen verifiziert. Alle acht Assets erneut heruntergeladen und per Größe/SHA-512 mit lokalen Dateien verglichen. Eingebauter Updater mit Version `2.1.47` erkennt `2.1.48`, übernimmt englische Release Notes und akzeptiert das Forgejo-Manifest. Release-Commit `7a49a19`, annotierter Tag `b8df102` auf beiden Remotes identisch. Anleitung auf dem Desktop aktualisiert.

Stand: 22.09.2026 (Produktivaktivierung und Release `2.1.46`; ältere Versionsprüfungen darunter sind historische Nachweise)

- Eingebauter Updater mit isoliertem Testprofil und installierter Version `2.1.45` erkennt `2.1.46`, übernimmt den englischen GitHub-Changelog und akzeptiert das Forgejo-Update-Manifest. Alle acht veröffentlichten Dateien wurden erneut heruntergeladen und anhand Größe und SHA-512 gegen die lokalen Dateien geprüft. Titel, Tag, Sprache, Veröffentlichungsstatus und beide anbieterspezifischen Manifeste stimmen. Vollständiger öffentlicher Quellcheck: 163 erlaubte Dateien, Screenshots gültig. Anleitung auf dem Desktop mit abgeschlossenem Live- und Release-Stand aktualisiert.

- Lint: erfolgreich, 0 Warnungen und 0 Fehler.
- Haupttests: 826 erfolgreich, 0 fehlgeschlagen; Backup-API: 18 erfolgreich; Lint ohne Fehler. Neue IP-Regressionen prüfen IPv4/IPv6, gefälschte Clientangaben, vertrauenswürdige und fremde Proxys, Persistenz im Schlüsselbund, alte Datensatzformate, unbekannte IPs und Offline-Detailausgabe. Öffentliche Quellmanifest-Prüfung umfasst weiterhin 163 Dateien. Die Änderung der Standardgültigkeit ist mit `2.1.47` veröffentlicht; IP-Erweiterung ist mit `2.1.48` veröffentlicht.
- Wiederherstellung lokal Ende-zu-Ende geprüft: öffentliche Schlüsselabfrage, verschlüsselter Serverdatensatz, normaler Import, private Offline-Wiederherstellung und Löschen. Falsche Schlüssel, beschädigte Daten, Kennungstausch, Ablauf, fehlende Serverkonfiguration und Überschreiben bestehender Schlüssel/Ausgabedateien werden geprüft. Anleitung auf dem lokalen Desktop mit eingerichteten Schlüsselpfaden und Sicherungsnachweis aktualisiert.
- Backup-API-Tests: 17 erfolgreich, 0 fehlgeschlagen.
- Der Regressionstest für die VOE-Fallback-Kette bestätigt bei deaktivierter normaler Rotation genau einen Versuch auf jedem vollen Account und anschließend den erfolgreichen Wechsel auf den vierten Account.
- Der öffentliche DoodStream-Webablauf wurde am 12.09.2026 direkt gegen die Startseite und deren aktuelle Browser-Skripte geprüft. Regressionstests bilden den neuen GET-Login, `otp_sent`, `redirect`, Vue-Sessiontokens mit `_`/`-` und die aktuelle `upload_get_srv`-Antwort nach.
- Der lokale Web-Account-Check um 14:35:27 bestätigte das authentifizierte Dashboard ohne Upload-Sessionfeld. Regressionen prüfen zusätzlich explizite Web-Auswahl trotz gespeichertem API-Key, Wiederverwendung der OTP-Sitzung, getrennte Cookie-Kopien für parallele Uploads und Web-Serverausfälle. Der Upload-Aufruf verwendet nachweislich weder API-Ableitung noch einen zweiten Login.
- Das Support-Bundle vom 07.09.2026 bestätigt als Ursache der gemeldeten Datei: Wechsel vom Primäraccount auf `Fallback #1`, dort vier unnötige Versuche, anschließend `skip-account-pause` und Abbruch mit `override-same-as-current` statt Weiterschaltung.
- Der vollständige opt-in UI-Smoke bestätigte zusätzlich, dass Upload-Status-Badges und deren Labels nicht markierbar sind; die 16 bekannten themenfremden Abweichungen blieben unverändert.
- Produktionsabhängigkeiten: `npm audit --omit=dev` meldet 0 Schwachstellen.
- Release `v2.1.45`: Commit `05769cd` und annotierter Tag sind auf beiden Remotes identisch. Die englischen GitHub- und deutschen Forgejo-Changelogs, Titel, Versionsangaben und jeweils vier Assets wurden nach der Veröffentlichung geprüft.
- Der echte Updater mit installierter Version `2.1.44` erkennt `2.1.45` und akzeptiert den englischen GitHub-Changelog sowie das Forgejo-Manifest. Alle acht veröffentlichten Assets wurden heruntergeladen und per Größe sowie SHA-512 gegen die lokalen Dateien geprüft. Beide Manifeste zeigen auf den tatsächlichen Installer-Namen des jeweiligen Anbieters.
- Der Installer `2.1.45` ist 98.031.439 Bytes groß, Portable 97.806.832 Bytes. Datei- und Produktversion stimmen mit `2.1.45` überein; die verpackten Kernmodule stimmen mit dem geprüften Quellcode überein, Nutzereinstellungen sind nicht enthalten. Der vollständige öffentliche Quellcheck einschließlich Screenshots war erfolgreich.
- Release-Commit `e191ea8` und der annotierte Tag `v2.1.44` wurden auf GitHub und Forgejo mit identischen Commit-Hashes verifiziert.
- GitHub- und Forgejo-Release `v2.1.44` enthalten jeweils Installer, Portable-Build, Blockmap und ein zum Anbieter passendes Update-Manifest; GitHub führt den englischen und Forgejo den inhaltlich gleichwertigen deutschen Changelog.
- Der echte Updater mit installierter Version `2.1.43` erkennt Forgejo-Release `v2.1.44`, lädt den englischen GitHub-Changelog und akzeptiert Version, Installername, Größe und SHA-512 des veröffentlichten Manifests.
- Der öffentliche Release-Quellcheck bestätigte 160 erlaubte Dateien, korrekte Versionsmetadaten und gültige Screenshots. Der über den Forgejo-Updatepfad erneut geladene Installer ist 98.029.932 Bytes groß, stimmt mit der Manifest-SHA-512 überein und trägt Datei- sowie Produktversion `2.1.44`.
- Backup-API `2.0.4` läuft produktiv aus `/opt/mhu-backup-api/releases/20260901T140230Z-v2.0.4`; der vorherige Dienststand und alle 10 bestehenden Datensätze wurden davor in `/var/backups/mhu-backup-api/20260901T140230Z-pre-v2.0.4.tar.gz` gesichert und per Gzip-Test sowie SHA-256 geprüft.
- Der produktive HTTPS-Smoke für einen endlichen Testschlüssel bestätigte Erstellen `201`, Wiederherstellen `200`, Löschen `204` und anschließendes Nichtfinden `404`; danach waren weiterhin exakt 10 bestehende Datensätze vorhanden.