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

• Aktive Arbeitslinie: master aus Sucukdeluxe/Multi-Hoster-Upload.
• Zuletzt veröffentlichter Funktionsstand: Version 2.1.44, Release-Commit e191ea8.
• 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-Accounts mit API-Key werden auch beim Health-Check über die API geprüft und lösen keinen Web-OTP aus.
• 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 (Standard), 31 Tage und Unbegrenzt. 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.
• Version 2.1.44 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

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:

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

• DoodStream: Der echte OTP-Test nach dem ersten Kompatibilitätsfix meldete weiterhin fehlendes sess_id. JSON- und HTTP-Weiterleitungen werden nun vor der Sessionprüfung aufgerufen, einschließlich der dort gesetzten Cookies. 35 gezielte Tests und Lint sind erfolgreich; ein erneuter echter OTP-Login steht aus. Die konkrete Ursache der Nutzersitzung ist noch nicht abschließend bestätigt. Fehlende Sessions liefern HTTP-Status, Gastseiten-/Sessionfeld-Erkennung und Cookie-Anzahl ohne Cookie-Werte oder Zugangsdaten.
• Keine offenen Schritte für Release v2.1.44; Rollback-Ziel ist Anwendungsversion 2.1.43.
• Bei Bedarf einen Arbeitsweg ohne & im absoluten Pfad verwenden oder die npm-Aufrufe weiterhin direkt ausführen.

Zuletzt verifiziert

Stand: 12.09.2026

• Lint: erfolgreich, 0 Warnungen und 0 Fehler.
• Haupttests: 808 erfolgreich, 0 fehlgeschlagen.
• 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.
• 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-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.