diff --git a/SYNC_PLAN.md b/SYNC_PLAN.md
new file mode 100644
index 0000000..9cec544
--- /dev/null
+++ b/SYNC_PLAN.md
@@ -0,0 +1,88 @@
+# 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
+
+**Implementierungsplan, Task 1: „Reine Merge-Funktionen (`sync_merge.dart`)“**
+(Zeile ~104 im Plan). Tasks 1–9 sind vollständig entblockt und können sofort
+starten, in der im Plan festgelegten Reihenfolge (Favoriten-Fix zuerst).
+
+Empfohlener Einstieg für die neue Session: die Skill
+`superpowers:subagent-driven-development` (Pflicht-Sub-Skill laut Plankopf)
+für die task-weise Umsetzung nutzen, wie schon beim vorherigen Feature
+(YouTube-Gast-Zugang) erfolgreich gemacht.
+
+## 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. Plan empfiehlt: vertagen, bis eine
+  echte Playlist existiert. Steht im Plan unter „Offene Punkte, die vor
+  bzw. während der Umsetzung an Dustin gehen".
+- **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`).