Files

T

Hermes (Server)andClaude Sonnet 5 40171a7c0e Kontext-Sicherung: SYNC_PLAN.md (Übergabe für neue Session)

Stand, nächster Schritt (Implementierungsplan Task 1) und offene
Punkte für den Sync-Ausbau festgehalten, bevor die Session wegen
vollem Kontextfenster endet.

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

2026-08-27 10:34:52 +02:00

4.6 KiB

Raw Blame History

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

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.
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

Bestandsaufnahme (6 parallele Leser über App/Server/Navidrome/Cross-Platform/Melo-v2).
Brainstorming + Spec geschrieben, mit Dustin abgestimmt.
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.
Spec nach den 17 Aktionspunkten des Urteils überarbeitet, gegengelesen, freigegeben.
Implementierungsplan geschrieben, geprüft (fand 3 echte Server-Vertragsfehler in Task 11 — korrigiert), Korrekturrunde committed.
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).

4.6 KiB Raw Blame History Unescape Escape