# 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.

```powershell
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:

```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 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.