chore(main): drop JSON.stringify of files/hosters in start-upload log

At 500+ queued jobs these lines bloated upload-debug.log with
megabyte-sized entries per batch-start and added visible latency to
the IPC handler. Log sizes only.

main.js

@@ -1092,7 +1092,9 @@ ipcMain.handle('start-upload', (_event, payload) => {
   const hosters = payload && Array.isArray(payload.hosters) ? payload.hosters : [];
   const jobs = payload && Array.isArray(payload.jobs) ? payload.jobs : [];
 
-  debugLog(`start-upload: files=${JSON.stringify(files)}, hosters=${JSON.stringify(hosters)}, jobs=${jobs.length}`);
+  // At 500+ jobs JSON.stringify blew up the debug log with MB-sized lines
+  // per start-upload and added noticeable delay — log counts only.
+  debugLog(`start-upload: files=${files.length}, hosters=${hosters.length}, jobs=${jobs.length}`);
 
   const tasks = jobs.length > 0
     ? buildUploadTasksFromJobs(config, jobs)

tasks/todo.md

@@ -1,28 +1,32 @@
-# Account-Rotation: vollständiger Session-Lernprozess
+# Perf/Stabilität Audit (nach 3.1.5)
 
-## Problem
+Ziel: bekannte Schwachstellen aus der Review abarbeiten, jeweils mit eigenem Release.
-1. Byse "disk space full" wurde als file-rejected klassifiziert → keine Rotation. (3.1.4 ✓)
-2. `pre-job-swap` checkte `_failedAccounts` VOR Semaphore-Acquire → alle parallelen Jobs probierten weiter den vollen Account. (3.1.5 ✓)
-3. Wenn beim ersten Fail noch kein Fallback-Account existierte und der User DANACH einen hinzufügt → `_accountOverrides` blieb leer, keine weitere `account-failed`-Emission (nur einmalig pro Account) → System blieb stuck bis zum Neustart. (3.1.5 ✓)
 
-## Fix
+## Schritt 1 — Log-Geschwätz reduzieren (main.js:1066)
-- [x] `lib/upload-manager.js` — Pre-Job-Swap hinter `semaphore.acquire` verschoben, plus zwei public getter: `getFailedAccountKeys()`, `getOverride(hoster)`.
+- [ ] `JSON.stringify(files/hosters)` durch count-only ersetzen
-- [x] `main.js` — `save-config` IPC-Handler ruft nach dem Speichern `getNextFallbackAccount` für alle failed-ohne-Override accounts im aktiven UploadManager. Findet er was, ruft er `switchAccount`. Emittiert `account-switched` an den Renderer.
+- [ ] Bei 500 Jobs spart's MB-große debugLog-Einträge pro start-upload
-- [x] Tests (4 neue):
+- [ ] Release als 3.1.6
-  - pre-job-swap greift für parallele Worker nach Semaphore-Queue.
-  - getFailedAccountKeys + getOverride als public API.
-  - Neustart-Reset: fresh Manager hat keine gelernte failed-Historie.
-  - Late-resolved Override wird von Folgejobs genutzt (mid-batch config add).
-- [x] `npm test` — 80/80 grün.
-- [ ] Release als 3.1.5 (auf User-OK).
 
-## Behavior-Matrix
+## Schritt 2 — persistQueueState-Write vermessen + drosseln
-| Szenario | Verhalten |
+- [ ] Verstehen: wie groß ist das JSON bei 500 Jobs? Wie oft schreibt's während eines Batches?
-|---|---|
+- [ ] Ggf. maximale Write-Größe / Frequenz während Upload erhöhen (derzeit 10s bei uploading, 500ms sonst)
-| acc1 + acc2 gleich aktiv, acc1 wird voll | acc1→acc2 Rotation, alle weiteren Jobs direkt acc2 ✓ |
+- [ ] Ggf. nur bei Status-Änderung, nicht bei Progress-Byte-Change
-| Nur acc1 aktiv, acc2 mid-batch hinzugefügt BEVOR acc1 voll | Erster Fail resolved gegen frische Config, acc2 wird gezogen ✓ |
+- [ ] Release als 3.1.7 (nur wenn echter Bottleneck gefunden)
-| Nur acc1 aktiv, acc1 wird voll, DANACH acc2 hinzugefügt | `save-config` trigert Late-Resolve, `switchAccount(acc2)` wird aufgerufen, Folgejobs swappen pre-job ✓ |
-| App-Neustart | `_failedAccounts` in-memory → fresh, acc1 wird wieder probiert ✓ |
 
-## Review
+## Schritt 3 — Progress-Event-Flood drosseln (app.js:1862-1871)
-Drei Ebenen zusammen (3.1.4 Classifier + 3.1.5 pre-swap-after-queue + 3.1.5 late-resolve) machen das Session-Lernen komplett: disk-space-voll wird erkannt, markiert, alle wartenden Jobs sehen es wenn sie dran sind, und spätere Config-Änderungen werden reaktiv aufgegriffen.
+- [ ] Status-Change-Events rufen sync `updateQueueActionButtons + updateStatusBar + updateStatsPanel`
+- [ ] Bei 50+ parallelen Uploads → 100+ sync Callbacks/Sek
+- [ ] Coalesce via rAF (wie `scheduleQueueRender` für uploading-events)
+- [ ] Tests für den neuen Pfad
+- [ ] Release als 3.1.8
+
+## Schritt 4 — Byse-Poller-Review (lib/hosters.js:440+)
+- [ ] Verstehen warum der Poller existiert (zuverlässigkeitsproblem mit direkter Response?)
+- [ ] Edge-Cases prüfen: was wenn Poll 0 neue Files findet aber Upload durch war?
+- [ ] Dokumentieren was funktioniert und was nicht
+- [ ] Kein Release außer echter Bug gefunden
+
+## Offen nach diesen Schritten
+- Memory-Wachstum bei langen Sessions (bräuchte Instrumentierung)
+- Throughput-Skaling bei 20+ parallelen Uploads (bräuchte Lasttest)
+- Netz-Ausfall-Recovery (bräuchte Netz-Interrupt-Test)