Multi-Hoster-Upload/PROJECT_MEMORY.md

Projekt-Memory

Zweck

Multi-Hoster-Upload ist eine Electron-Desktopanwendung für Windows zum Hochladen von Dateien an mehrere Hoster. Diese Datei enthält ausschließlich öffentlich geeignete Projektinformationen. Zugangsdaten, persönliche Arbeitsumgebungen, konkrete Serverpfade, Sicherungsnachweise und Betriebsprotokolle gehören nicht in das Repository.

Aktueller Zustand

• Veröffentlicht: Version 2.1.50.
• Einstiegspunkt: main.js; Oberfläche: renderer/; Fachlogik: lib/; optionaler Sicherungsdienst: services/backup-api/.
• Version 2.1.50 enthält verbesserte Sicherungsmenüs, getrennte Online-Backup-Bereiche, einheitliche Automatik- und Log-Einstellungen sowie korrigierte Such- und Update-Anzeigen.
• Ordnerüberwachung lässt sich unabhängig von ihrem Aktivierungszustand mit gespeicherten Regeln schreibgeschützt testen. Testscans starten keine Uploads und verändern keine laufende Überwachung.
• Nach dem Release wurden ausschließlich Wartebedingungen zweier Electron-Tests korrigiert. Die Anwendungsversion bleibt unverändert.

Entscheidungen

• DoodStream-Webaccounts verwenden ausdrücklich die Web-Sitzung; ein gespeicherter API-Key darf diese Auswahl nicht übersteuern. Parallele Accountchecks teilen ihre OTP-Anforderung.
• Accountchecks melden einzelne Ergebnisse sofort an die Oberfläche.
• Accountbezogene Speicherfehler führen zum nächsten verfügbaren Fallback-Account; vorübergehende Netzwerkfehler bleiben davon getrennt.
• Hoster-Dateigrößenlimits werden in GB eingegeben und kompatibel im bestehenden MB-Format gespeichert. Zu große Dateien werden für den jeweiligen Hoster übersprungen.
• Online-Backups sind clientseitig verschlüsselt. Neue Schlüssel sind standardmäßig unbegrenzt gültig; bestehende Ablaufdaten bleiben erhalten.
• Wiederherstellungsschlüssel bleiben außerhalb des Repositorys und des Sicherungsdienstes. Datensatzformatänderungen benötigen einen datenerhaltenden Kompatibilitätsplan.
• Backup-Importe übertragen Einstellungen; Warteschlange, Verlauf und laufzeitgebundene Zustände bleiben davon getrennt.
• Nicht vorhandene Überwachungspfade bleiben gespeichert; die Überwachung wird bis zur Korrektur deaktiviert.
• Erfolgreiche Uploads erhalten einen persistenten Abschlussnachweis. Bei einem Speicherfehler bleibt die Warteschlange erhalten, um unbeabsichtigte Wiederholungen zu vermeiden.
• Dropdowns benötigen ausreichenden Pfeilabstand und müssen auch in schmalen Fenstern bedienbar bleiben. Kopierbare Inhalte und Eingabefelder behalten ihre Textauswahl.
• Update-Metadaten müssen zu den tatsächlich veröffentlichten Dateinamen, Größen und Prüfsummen passen. Versionsmeldungen zeigen gültige Veröffentlichungszeitpunkte in lokaler Gerätezeit.
• Release-Changelogs sind auf GitHub englisch und auf Forgejo deutsch, bei inhaltlich gleichem Umfang.
• Die aktive Arbeitslinie ist master; der zweite Remote verwendet sync/github-master. Eine getrennte ältere Historie darf nicht überschrieben werden.

Start- und Testbefehle

Node.js 24 und die im Lockfile festgelegten Abhängigkeiten verwenden.

npm ci
npm start
npm run dev
npm run verify

Bei Problemen mit Shell-Sonderzeichen im Projektpfad können die Prüfungen direkt ausgeführt werden:

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 und nächste Schritte

• Die DoodStream-Web-Upload-Serverermittlung ist weiterhin gesondert zu prüfen. Ein erfolgreicher Accountcheck bestätigt keinen erfolgreichen Dateitransfer.
• Der optionale Langzeit-UI-Smoke hat bekannte Timing-/Fixture-Abweichungen außerhalb der regulären CI. Diese getrennt untersuchen; reguläre Regressionen nicht überspringen.
• Die CI meldet eine Laufzeit-Abkündigung für die verwendeten Checkout-/Node-Setup-Actions. Ein Versionswechsel ist separat zu prüfen.
• Öffentliche Dokumentation auf Architektur, Verhalten und reproduzierbare Entwicklung beschränken. Keine betrieblichen Einzelfalldaten ergänzen.

Zuletzt verifiziert

• Stand: 22.09.2026.
• Release 2.1.50: 845 Haupttests und 18 Servertests erfolgreich; Lint und Abhängigkeitsprüfung erfolgreich. Installer, portable Anwendung und Update-Metadaten beider Plattformen einschließlich Download-Prüfsummen geprüft.
• CI-Timingkorrektur: beide betroffenen Tests zehnmal hintereinander erfolgreich. Gesamte lokale Suite und GitHub-CI einschließlich Windows-Build erfolgreich. Tests warten mit Zeitlimit auf verarbeitete Eingaben beziehungsweise den angekommenen Dateikandidaten, ohne Zustandsprüfungen abzuschwächen.
• Öffentliche Dokumentation von konkreten Betriebs-, Sicherungs- und Diagnosedetails bereinigt. Keine Anwendungscodeänderung und keine Umschreibung der Git-Historie; ältere Dokumentfassungen bleiben historisch erreichbar.