diff --git a/tasks/lessons.md b/tasks/lessons.md
index 2c8397f..54f3bf5 100644
--- a/tasks/lessons.md
+++ b/tasks/lessons.md
@@ -62,3 +62,11 @@
 - file/list → 90.548 Dateien; Uploads landen server-seitig INTERMITTIEREND (viele Burn-Notice-Folgen genau im "Fehler"-Zeitfenster vorhanden). Das leere Formular ist also nicht "immer kaputt", sondern manchmal — der Web-Form-Registrierungs-Callback (fs-public.intconnect.net) timeoutet sporadisch.
 **Konsequenz:** API-Weg (result[0].filecode inline) umgeht den failenden Callback → richtiger Fix. file/list-Recovery ist NICHT tote Last (Dateien erscheinen ja) — aber bei 90k-Accounts MUSS man sort=created&order=desc erzwingen, sonst ist die frische Datei nicht auf Seite 1.
 **Regel:** Bei "geht manchmal/manchmal nicht" + Hoster mit offizieller API: erst per read-only API-Call (account/info, file/list) gegen den ECHTEN Account verifizieren statt am Client weiterzuraten. Das beendet Spekulations-Schleifen.
+
+## 2026-06-17 — Rotation-State pro-Call neu zu bauen = stiller No-Op beim Drip-Feed
+**Symptom:** Account-Rotation (v3.3.74) verteilte korrekt bei einem Drag-Drop-Batch (N Dateien auf einmal), aber bei Folder-Monitor / Einzeldatei-Uploads landete IMMER alles auf Account 1 — die Sekundär-Accounts bekamen nichts.
+**Root cause:** Der Picker wurde INNERHALB jedes `buildUploadTasks`/`buildUploadTasksFromJobs`-Calls frisch erzeugt → `rotIdx` startete jedes Mal bei 0. Der Folder-Monitor speist neue Dateien einzeln via `add-jobs-to-batch` in einen laufenden Batch (und per-Detection-autoStart feuert `start-upload` pro Datei). Jeder dieser Calls baute den Picker neu von Index 0 → `0 % len = 0` = Account 1, immer.
+**Verifiziert:** Unit-Tests gaben falsche Sicherheit — alle 10 nutzten EINEN Picker über N Calls (testet nur Intra-Batch). Der Bug lebte genau im Cross-Call-Verhalten, das kein Test abdeckte.
+**Fix:** Rotation-Cursor lebt AUSSERHALB des Pickers: modul-level `_rotationCursors` in main.js als authoritative Quelle (einmal aus config geseedet), `config.rotationCursors` als Restart-Survival-Backing (das 30-Tage-Quota überlebt App-Neustarts). Picker bekommt `{ indices }`-Seed + exponiert `indices()`/`dirty()`. Persist nur wenn `dirty()`.
+**Regel:** Rotations-/Round-Robin-/Cursor-State, der über mehrere Aufruf-Eintrittspunkte fair verteilen soll, MUSS die Aufrufe überdauern — und wenn das Ziel ein Zeitfenster über Sessions hinweg ist (Quota), auch Restarts. Picker/Iterator pro Call neu instanziieren ist nur korrekt, wenn jeder Call die GESAMTE zu verteilende Menge sieht.
+**Wie anwenden:** Bei jeder "verteile reihum"-Funktion fragen: über wie viele Eintrittspunkte/Calls läuft die zu verteilende Menge real? (Hier: drag-drop=1 Call ABER folder-monitor=1 Call pro Datei.) Tests MÜSSEN den Cross-Call/Drip-Feed-Pfad mit frisch geseedetem State nachstellen, nicht nur einen langlebigen Picker.