Docs: lessons.md — Fix-Diagnose empirisch bestaetigen (Timeout != Account-Haenger)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

tasks/lessons.md

@@ -1,5 +1,25 @@
 # Lessons
 
+## 2026-05-31 — Fix-Diagnose EMPIRISCH bestätigen, bevor man released (Timeout ≠ Account-Hänger)
+
+**Muster:** "acc2/acc3 nie versucht" wurde als "acc1 hängt → Per-Account-Timeout +
+Rotation" diagnostiziert und als v1.7.168 released. Falsch: Mega-Debrid-**Web** ist eine
+180s-Polling-Schleife (`mega-web-fallback.ts`) — acc1 *pollte* legitim, der 60s-Global-
+Timeout (nicht "Hängen") schnitt es ab. Mein 25s-Per-Account-Cap machte es SCHLIMMER
+(endlose 25s-Rotation, Datei nie aufgelöst). Erst der User-Log + Lesen der Provider-
+Impl deckte es auf. Revert v1.7.169.
+
+**Regel:**
+- Ein Timeout bei einem langsam-pollenden Provider ist KEIN Account-Fehler → darf keine
+  Rotation/kein Skippen auslösen. Vor "Account hängt"-Annahmen die Provider-Impl lesen
+  (Polling? internes Ceiling? wie lange dauert ein Erfolg legitim?).
+- Bei zwei gegensätzlichen Diagnosen (hier: Timeout-zu-kurz vs. IP-Block — stand in der
+  EIGENEN Memory!) NICHT die bequeme wählen + releasen. Erst empirisch diskriminieren
+  (Env-Var auf Server, Beobachtung, oder gezielte User-Frage). Ein Symptom, das BEIDE
+  Hypothesen gleich gut erklärt ("Timeout nach Xs"), beweist keine.
+- NICHT lokal "verifizieren" wenn das Problem umgebungsspezifisch ist (geblockte
+  Server-IP) — lokaler Erfolg ist falsch-positiv.
+
 ## 2026-05-30 — Abgestürzten/„aufgehängten" Chat fortsetzen: zuerst reflog lesen
 
 **Muster:** User bat, einen anderen, aufgehängten Chat-Strang „zu Ende zu bringen".