dustin/Melo
1
0
Fork 0
Code Issues Pull Requests 3 Actions Packages Projects Releases Wiki Activity
Files
1734a656a16524282cee1818f7518427a562b183
Melo/docs/reviews/2026-08-27-sync-ausbau/context_brief.md
T
Hermes (Server)andClaude Sonnet 5 852c17cd48 Review-Panel: Sync-Ausbau-Spec (Verdikt 6/10, nachschärfen) 
Adversariales 5-Reviewer-Panel (Opus) mit 2 Debattenrunden,
Vollständigkeits-Audit, konsolidierter Faktenprüfung (~70 Belege,
keine Halluzination) und Richterurteil.

Ergebnis: SPEC NACHSCHÄRFEN DANN FREIGEBEN. Kein P0 im Geltungsbereich.
17 Aktionspunkte, wichtigste: POST /favorites (Voll-Ersatz) streichen
statt Regel, SSE und beidseitigen Playlist-Merge herausnehmen,
irreversiblen Bestands-Löschpfad benennen (Backlog-P0, Rückfrage an
Dustin offen).

Bemerkenswert: Der vom Panel selbst empfohlene Basis-Snapshot wurde
von der Verifikation als gefährlicher entlarvt als das Problem, das
er lösen sollte — abgelehnt.

Reviewer-Rohtexte bleiben lokal (.gitignore), nur Bericht + Urteil
im Repo.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CcDiyJdVRqh1TtJk5JiabX
2026-08-27 01:35:55 +02:00

4.7 KiB
Raw Blame History

Context Brief — Review der Sync-Ausbau-Spec

Review-Gegenstand: /home/dustin/mello-dev/app/docs/superpowers/specs/2026-08-27-sync-ausbau-design.md

Review-Modus: Exhaustive (reines Design-Dokument). ABER: Die Spec macht viele FAKTISCHE Behauptungen über existierenden Code — solche Behauptungen bitte präzise gegen den echten Code prüfen (grep/read, read-only).

Codebase-Zustand: Branch fix/p0-vollwertigkeit in /home/dustin/mello-dev/app (kein Worktree-Sonderfall, Branch aktuell mit origin). Server-Code: /home/dustin/scripts/melo_cloud.py (read-only ansehen erlaubt, NIE ändern).

Projekt

Melo: Flutter-Musik-App (Android), schwarz/rot, 5 Tabs. Backend: Navidrome (Subsonic, read-only) + Melo-Cloud (melo_cloud.py, cloud.baka-net.de, Bearer-JWT via BakaAuth) + yt-Proxy. 602 Tests grün. Nutzer: Dustin (Admin), Baka, Tinker — kleine private Nutzerbasis, ~330 Songs auf dem Server. Projekt-Prinzip „Ponytail“: minimale, robuste Lösungen; YAGNI wird ernst genommen.

Bereits vom Auftraggeber ENTSCHIEDEN (im Brainstorming, mit Begründung)

Reviewer dürfen diese Entscheidungen kritisieren, sollen aber wissen, dass sie bewusst und informiert getroffen wurden:

  1. Cross-Platform (Mac/Win) = eigenes späteres Projekt, NICHT diese Spec.
  2. Upload-UX: Auswahl-Modus-Erweiterung; Auto-Upload bleibt zusätzlich.
  3. Playlist-Konflikte: Union-Merge (kein LWW, kein read-only).
  4. Kein Delta-Protokoll, kein Hintergrund-Sync, kein Chunked-Upload (YAGNI).
  5. Favoriten-Merge-Fix ist gesetzt (Datenverlust-Bug).
  6. Umfang: Einzel-Song-Offline + Playlist-Sync + Notification/Bericht + SSE.

Verifizierte Schlüsselfakten aus der Bestandsaufnahme (2026-08-27)

App-Sync (lib/services/sync_service.dart, melo_cloud_service.dart):

  • Upload existiert: Multipart POST /upload, 50 MB Limit, 120s Timeout; Server-Dedup sha256 + fpcalc-Fingerprint (Jaccard>0.7).
  • planeSync() lädt ALLE Songs ohne cloudId hoch; Tombstones beidseitig; Lösch-Bremse nur für serverLoeschen (>10 && >1/3).
  • _gleicheFavoritenAb() POSTet lokale Favoriten als KOMPLETT-ERSATZ (der Datenverlust-Bug); MeloCloudService.favoriten() (GET) existiert, wird nie aufgerufen.
  • Auto-Sync bei Start/Resume, 15-Min-Drossel (sollAutoSync); Fortschritt als ChangeNotifier-Felder, UI nur in settings_screen.dart.
  • Kein SSE in der App, kein Playlist-Sync in der App.

Server (melo_cloud.py):

  • Endpunkte: list/upload/download/stream(Range)/delete/update/rename/ playlists(CRUD+songs+positions)/favorites(GET/POST/toggle mit set)/ history/sync(since)/subscribe(SSE, Heartbeat 30s).
  • SSE-Events: song_delete, song_update, song_favorite werden emittiert; UPLOAD feuert KEIN Event; playlist_update dokumentiert aber nie emittiert.
  • Playlists/Favoriten: harte DELETEs, KEINE Tombstones.
  • handle_favorites_sync = Full-Replace. handle_list liefert immer ALLES inkl. Grabsteine (kein ETag/Since).
  • Uploads landen in /var/lib/melo-cloud/registry/ und werden AKTIV nach /home/dustin/navidrome/music gehardlinkt + Navidrome-Scan getriggert.
  • Achtung bekanntes Server-Risiko: handle_list selektiert Spalte ist_korrupt, die im CREATE-TABLE-Schema fehlt (nur Live-DB hat sie).
  • Uploads/Downloads liegen serverseitig komplett im RAM.

Offline (download_service.dart u. a.):

  • Alben/Künstler-Download in App-Speicher (Application-Support/ melo_downloads), Drift-Tabelle Downloads (navidromeId), Fortschritt+ Abbrechen; Rückfrage ab 30 Titeln. Abspiel-Cache 2 GB LRU getrennt davon.

Melo v2 (Referenz, /home/dustin/mello-dev/referenz/melo-app-code.md):

  • Hatte: bidirektionalen Favoriten-Merge (Union) + deterministischen set-Push beim Toggle; persistente Sync-Notification (i/n); Sync-Bericht nach >24h; Konflikt-Dialog. Bekannte v2-Lektionen: Sync-Zeitstempel = Snapshot VOR listSongs (Tombstone-Race MED-1); neue Songs sofort MIT cloudId in DB (Doppel-Download MED-2); Dateinamen-Kollisionszähler.

Plattform:

  • flutter_local_notifications ist NICHT in pubspec.yaml (wäre neu).
  • http-Paket vorhanden (client.send für SSE-Streaming möglich).
  • POST_NOTIFICATIONS wird seit kurzem beim App-Start angefragt.
  • Drift-DB mit Migrationen vorhanden (database.dart, schemaVersion).

Regeln für Reviewer

  • READ-ONLY: nichts schreiben außer der eigenen State-Datei, keine git-Operationen, keine Server-Prozesse anfassen, keine .env lesen.
  • Jede Behauptung über existierenden Code mit Datei:Zeile belegen (grep/read). Behauptungen ohne Beleg als [UNVERIFIED] taggen.
  • Findings-Severity: P0 (blockiert die Spec / Datenverlust), P1 (muss vor Implementierung geklärt werden), P2 (sollte), P3 (nice to have).
  • Für jedes P0/P1: falsifizierbaren Check nennen (welcher grep/read würde es widerlegen?), wenn möglich als verification_command (read-only).
Reference in New Issue View Git Blame Copy Permalink