3977184fd4
- Pro Mega-Debrid-Account UND Debrid-Link-Key im Bearbeiten-Dialog: Badge mit Login-Gueltigkeit + Premium-Restlaufzeit (connectUser vip_end / account/infos premiumLeft) - "Alle pruefen"-Button oben rechts; prueft alle Accounts (Concurrency-Cap 4), Ergebnis persistiert (debridAccountStatuses), ueberlebt Neustart - Rotations-Verlauf-Panel: zeigt live welcher Account/Key versucht wurde + warum gewechselt (Ring-Buffer -> Snapshot -> UI), statt nur "Link-Umwandlung erneut" - Bug A: Mega-Debrid Per-Account-Verbrauch wurde nie erfasst (Heute/Insgesamt immer 0) - Bug B: isProviderConfigured erkannte reine megaCredentials-Multi-Config nicht - Neu: account-check.ts (standalone), CHECK_DEBRID_ACCOUNTS IPC, 13 Tests Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
52 lines
2.9 KiB
Markdown
52 lines
2.9 KiB
Markdown
# Lessons
|
||
|
||
## 2026-05-30 — Nicht in chaotische Parallel-Tool-Batches verfallen (User-Korrektur: "bist du in nem endless loop")
|
||
|
||
**Muster:** Bei einem großen Multi-File-Edit habe ich Dutzende Tool-Calls (Bash-Probes,
|
||
Reads, Edits, Python-Inline-Skripte, mehrfache tsc-Läufe) in EINEN Message-Block gepackt.
|
||
Resultat: Ein einzelner Fehler/Cancel hat die ganze parallele Kette abgebrochen, Edits
|
||
landeten halb, ich verlor den Überblick welche Änderung wirklich auf Disk war, und es
|
||
wirkte wie eine Endlosschleife. Dazu: wegwerf-`scripts/_*.py`/`_*.txt` als Workaround
|
||
gegen Output-Encoding statt der dedizierten Tools.
|
||
|
||
**Regel:**
|
||
- Edits über mehrere Dateien **sequenziell, einer nach dem anderen**, mit kurzer
|
||
Verifikation dazwischen — nicht 20 spekulative Calls auf einmal.
|
||
- Nach jedem Edit, der fehlschlagen kann (Anchor evtl. nicht eindeutig), das Ergebnis
|
||
lesen, bevor der nächste folgt. Edit/Write erroren laut — darauf vertrauen.
|
||
- KEINE Wegwerf-Python-Skripte ins Repo schreiben, um Shell-Output zu parsen. `Grep`/
|
||
`Read`/`Edit` nutzen. Wenn doch ein Temp nötig ist: nach `os.tmpdir()`, nie nach
|
||
`scripts/`, und sofort wieder löschen.
|
||
- Verifikation gebündelt am ENDE (1× tsc, 1× build, 1× vitest), nicht 10× zwischendrin.
|
||
|
||
|
||
## 2026-05-28 — Analyse-Befund gegen beobachtete Realität gaten (Advisor-Korrektur)
|
||
|
||
**Muster:** Meine Analyse sagte einen *häufigen* Bug voraus (jede letzte Datei im
|
||
Standard-Modus + jede Nested-Datei landet unbenannt), während der User nur "1-2 pro
|
||
Staffel" meldete. Ich habe die Diskrepanz bemerkt ("zu schwer um unbemerkt zu bleiben")
|
||
und sie mit weiterem Timing-Argument wegrationalisiert.
|
||
|
||
**Regel:** Wenn die eigene Analyse etwas vorhersagt, das der beobachteten Realität
|
||
widerspricht, NICHT die bequeme Lesart wählen — **mit einem Reproduktions-Test gaten**,
|
||
bevor man fixt. Failing Test gegen den Ist-Stand zuerst (TDD/systematic-debugging Phase 4):
|
||
- reproduziert → Bug bestätigt, mit Sicherheit fixen.
|
||
- reproduziert nicht → Analyse hat eine Mitigation übersehen, kein Fix für Nicht-Bug.
|
||
|
||
## 2026-05-28 — Crash-Debris im Working Tree: stashen, nicht verwerfen
|
||
|
||
**Muster:** Eine abgestürzte Session (API 400) hinterließ ein uncommittetes Working Tree,
|
||
das drei releaste Commits revertierte. Verlockung: `git checkout`/discard, um clean HEAD
|
||
zu bekommen.
|
||
|
||
**Regel:** Fremde/unverstandene uncommittete Änderungen **`git stash`** (non-destruktiv,
|
||
recoverable), nie blind verwerfen. Gibt clean HEAD, nichts geht verloren, kein Stall auf
|
||
User-Rückfrage. Danach dem User sagen WAS gestasht wurde und WARUM.
|
||
|
||
## Wiring-Lock vs. Mechanism-Test
|
||
|
||
Ein Test, der eine Hilfsfunktion mit dem richtigen Flag direkt aufruft, beweist nur, dass
|
||
das Flag funktioniert — NICHT, dass der Produktionspfad das Flag setzt. Für echte
|
||
Absicherung einen End-to-End-Test durch den realen Einstiegspunkt fahren und per
|
||
Negativ-Gate (Flag temporär entfernen → Test muss fallen) verifizieren.
|