Sync-Ausbau abgeschlossen: SYNC_PLAN.md entfernen (kein Dauerdokument)

Alle 13 Tasks + Whole-Branch-Review + zwei Fix-Wellen fertig, PR #5 gegen
fix/p0-vollwertigkeit erstellt. Übergabe-Datei laut eigener Kopfzeile
löschen, sobald die Implementierung fertig ist.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012A2pmbnVNPiHdyf2GW8eLP

SYNC_PLAN.md

@@ -1,100 +0,0 @@
-# Sync-Ausbau — Kontext-Sicherung (2026-08-27)
-
-Diese Datei ist eine Übergabe für eine neue Session. Sie ersetzt nicht die
-Spec/den Plan, sondern sagt: wo stehen wir, was ist als Nächstes dran.
-
-**Wenn diese Datei erledigt ist (Implementierung fertig oder Plan überholt):
-löschen, nicht liegen lassen — sie ist kein Dauerdokument.**
-
-## Die zwei maßgeblichen Dokumente
-
-1. **Spec:** `docs/superpowers/specs/2026-08-27-sync-ausbau-design.md`
-   Status: **Freigegeben, umsetzungsbereit.** Durch ein 5-Reviewer-Panel
-   (agent-review-panel) geprüft, nachgeschärft, gegengelesen.
-2. **Implementierungsplan:** `docs/superpowers/plans/2026-08-27-sync-ausbau.md`
-   13 Tasks nach TDD (echter Code in jedem Schritt, kein Platzhalter),
-   geprüft und korrigiert.
-
-Beide sind committed und gepusht auf Branch `fix/p0-vollwertigkeit`
-(bis Commit `1940e2b7909`).
-
-## Was das Feature ist (kurz)
-
-Sync-Ausbau der Melo-App: Favoriten-Merge-Fix (Datenverlust-Bug),
-gezielter Song-Upload im Auswahl-Modus, Einzel-Song-Offline,
-Playlist-Sicherung (einseitig), „Was ist neu"-Bericht. SSE, persistente
-Notification und beidseitiger Playlist-Merge sind bewusst spätere Stufen,
-nicht Teil dieser Runde.
-
-## Aktueller Stand — was schon passiert ist
-
-1. Bestandsaufnahme (6 parallele Leser über App/Server/Navidrome/Cross-Platform/Melo-v2).
-2. Brainstorming + Spec geschrieben, mit Dustin abgestimmt.
-3. **agent-review-panel** (5 Reviewer, 2 Debattenrunden, Audit, Verifikation,
-   Richterurteil): Score 6/10, Verdikt „nachschärfen dann freigeben". Bericht:
-   `docs/reviews/2026-08-27-sync-ausbau/review_panel_report.md`.
-4. Spec nach den 17 Aktionspunkten des Urteils überarbeitet, gegengelesen,
-   freigegeben.
-5. Implementierungsplan geschrieben, geprüft (fand 3 echte
-   Server-Vertragsfehler in Task 11 — korrigiert), Korrekturrunde committed.
-6. **Der einzige echte Blocker ist behoben:** Ein irreversibler Löschpfad in
-   `melo_cloud.py` (verschwindet eine lokale Datei, wurde sie serverseitig
-   endgültig gelöscht, erneutes Hochladen reparierte es nicht). Hermes hat
-   den Fix eingebaut (Datei-Wiederherstellung im Dedup-Zweig von `upload()`),
-   ich habe ihn end-to-end getestet (eigene Testdatei, Fake-Nutzer, danach
-   restlos aufgeräumt — Registry vor/nach Test bei 325 Titeln): Upload →
-   Löschung (Bug reproduziert, Download 404) → erneuter Upload → **beide
-   Dateien bitgenau wiederhergestellt.** Spec und Plan sind entsprechend
-   aktualisiert (§ERLEDIGT in der Spec, ENTBLOCKT-Marker im Plan).
-
-## Nächster Schritt (Stand 2026-08-27, nach Tasks 1–9)
-
-**Tasks 1–9 sind fertig, reviewed (subagent-driven-development, je ein
-Implementer- + ein Reviewer-Dispatch pro Task, bei Task 7 eine Fix-Runde
-wegen eines CHANGELOG-Vorgriffs) und auf `feature/sync-ausbau` committed**
-(Branch existiert, von `fix/p0-vollwertigkeit` abgezweigt, letzter Commit
-`676f2c5f298`). Ledger mit allen Details:
-`.superpowers/sdd/2026-08-27-sync-ausbau/progress.md`.
-
-Vor Task 10 wurde Dustin gefragt (Plan verlangt hier ausdrücklich eine
-Entscheidung, siehe unten). **Dustins Antwort:** erst eine echte Test-
-Playlist auf dem Server anlegen (über die App, nicht per Skript), dann
-neu entscheiden, ob Feature 2 (Task 10–12) gebaut wird.
-
-**Nächster Schritt für die neue Session:** Bei Dustin nachfragen, ob die
-Test-Playlist inzwischen angelegt/synchronisiert ist. Falls ja: Task 10
-(„Reine Merge-Funktionen (`sync_merge.dart`)" — nein, das ist Task 1, bereits
-fertig; der nächste offene Task ist **Task 10: Drift-Migration
-`Playlists.cloudId`**) im Implementierungsplan starten, mit
-`superpowers:subagent-driven-development` fortsetzen (Workspace/Ledger unter
-`.superpowers/sdd/2026-08-27-sync-ausbau/` existiert schon, Preflight-Scan
-für Tasks 6–13 ist im Ledger dokumentiert). Falls die Playlist noch fehlt:
-weiter warten, nicht eigenmächtig entscheiden.
-
-## Was noch offen ist (kein Blocker, aber zu klären)
-
-- **Tasks 10–12 (Playlist-Sicherung, Feature 2):** bauen oder streichen?
-  Heute 0 Playlisten auf dem Server. Dustin hat entschieden: erst eine
-  Test-Playlist anlegen (läuft), dann neu entscheiden — siehe oben.
-- **Server-Hygiene (an Hermes, eilt nicht):** `_link_user()` im Dedup-Zweig
-  von `upload()` legt einen dritten Hardlink unter `users/<user>/<sid>.mp3`
-  an, den `_entferne_datei_wenn_verwaist()` beim Löschen nicht mit abräumt.
-  Bisher folgenlos, aber seit dem Wiederherstellungs-Fix hinterlässt jeder
-  Dedup-Upload einen verwaisten Hardlink.
-- **App-Seite, bewusst unangetastet:** `markMissing` tombstoned großzügig,
-  die Lösch-Bremse greift erst ab 109 von 325 Titeln. Der Schaden ist jetzt
-  reparabel (siehe oben), also kein Blocker mehr — ob die App trotzdem
-  vorsichtiger werden soll, ist eine eigene, spätere Entscheidung.
-
-## Regeln, die für die neue Session gelten (aus Erfahrung dieser Session)
-
-- Worktree-Lock beachten: `.claude-worktree-lock` im Repo-Root prüfen/setzen/
-  entfernen (siehe `melo-app-workflow`-Skill).
-- `flutter test` im Hintergrund laufen lassen (600+ Tests, mehrere Minuten,
-  kein kurzer Foreground-Timeout).
-- Vor jedem Commit: Qualitäts-Gate (analyze + test) läuft automatisch als
-  Pre-Commit-Hook — das ist schon eingerichtet, nichts zu tun.
-- CHANGELOG.md nach jeder Aufgabe aktualisieren (Projektregel).
-- Bei fertigem Arbeitspaket: melden und stoppen, nicht autonom weitermachen
-  (Dustin startet dann bewusst eine frische Session — siehe
-  Memory `feedback_melden-und-stoppen`).