Melo/docs/reviews/2026-08-27-sync-ausbau/state/phase_14_judge_ruling.md

Phase 14 — Urteil des Obersten Richters

Gegenstand: docs/superpowers/specs/2026-08-27-sync-ausbau-design.md (Design, noch nicht implementiert). Grundlage: phase_10_11_verification.md, phase_8_audit.md, beide Debatten-Zusammenfassungen, die fünf Phase-7-Schlussurteile, plus eigener Code-Blick (read-only, grep/sed/read auf lib/, test/, /home/dustin/scripts/melo_cloud.py).

Maßstab: Auftraggeber ist ein Hobby-Entwickler, drei Nutzer (Dustin, Baka, Tinker), Projekt-Prinzip „minimale, robuste Lösungen". Keine Enterprise-Sync-Architektur. „Feature streichen oder verschieben" ist eine zulässige und hier mehrfach die richtige Antwort.

---

0. Verifikation zuerst — was die Faktenprüfung entscheidet

Die konsolidierte Verifikation schlägt jede widersprechende Panel-Behauptung. Ich habe stichprobenartig gegengeprüft und keine ihrer Korrekturen widerlegen können. Es gilt daher:

0.1 Kein P0 im Geltungsbereich dieser Spec. [VERIFIZIERT] Das einzige verbliebene Panel-P0 (F1, parseFavoriten + Superset-Invariante) steht auf totem Code: MeloCloudService.favoriten() (lib/services/melo_cloud_service.dart:258-265) hat null Aufrufer in lib/ und test/ — eigener Gegen-Grep bestätigt. Die Live-DB hat 0 Favoriten. Der Befund kann heute nichts verlieren; er wird erst durch die Spec scharf. Nach der Regel des Context Briefs (P0 = Bestandsfehler mit Datenverlust oder durch die Spec neu geschaffener Datenverlust) ist das P1. Die Panel-Aussage „ein P0 hält" ist nicht haltbar.

0.2 Die Lösch-Kette ist Glied für Glied bestätigt. [VERIFIZIERT] markMissing (lib/library/database.dart:237-245) → planeSync serverLoeschen (lib/services/sync_service.dart:68-76) → Lösch-Bremse greift bei 325 Titeln erst ab 109 (:112-113) → _meldeLoeschungen (:210, :239-251) → handle_delete (melo_cloud.py:374-394) → _entferne_datei_wenn_verwaist (:356-372) löscht registry/<sid> und über loese_navidrome (:190-202) navidrome/music/<sid>. Für die Datei existiert kein Grabstein. Der Reparaturweg ist verifiziert kaputt: der überlebende registry.sha256 erzwingt den Dedup-Zweig (:265-267), shutil.move steht nur im Neu-Zweig (:289), os.remove(tmp) verwirft die Bytes (:312), /download antwortet dauerhaft 404 (:1400-1408). Alle drei denkbaren Bruchstellen sind ausgeschlossen (Fremdnutzer-Schutz greift nie — Live-DB Baka|325|0; users/ ist leer; beide Pfade auf /dev/vda3, also echte Hardlinks). Bestandsfehler, nicht von dieser Spec verursacht — Kalibrierung: SUM(deleted) = 0, die Kette wurde noch nie ausgelöst.

0.3 Die Haupt-Empfehlung des Panels schafft selbst einen neuen Löschpfad. [VERIFIZIERT] [PLAN-RISIKO, neu geschaffen] Das ist der wichtigste Einzelbefund dieses Reviews und er richtet sich gegen das Panel, nicht gegen die Spec. Das Panel konvergiert in Runde 2 auf den Basis-Snapshot mit neu = (lokal ∪ server) − (Basis \ lokal) − (Basis \ server). Ich habe nachgerechnet: Liefert GET /favorites fälschlich ∅ — und genau das tut parseFavoriten heute bei jedem {"status":"error"} im 200er-Körper (melo_cloud_service.dart:117-124; sechs Handler desselben Servers antworten so: melo_cloud.py:418, 491, 545, 766, 1021, 1118; der Router verdrahtet für GET /favorites hart 200: :1292-1293) —, dann wird Basis \ server = Basis und die Formel kollabiert zu neu = lokal − Basis: der gesamte bestätigte Bestand wird gelöscht, lokal und über den Delta-Push auch auf dem Server und damit auf allen Geräten. Der Basis-Snapshot ist damit die einzige Maßnahme im gesamten Bericht, die einen neuen Datenverlustpfad einführt. DA und Risk haben das je einmal am Rand notiert; beide Phase-6-Zusammenfassungen führen es nicht als Finding. Es ist tragend für mein Urteil in Abschnitt 1.

0.4 Was die Verifikation dem Panel abspricht. [VERIFIZIERT]

• „Auswahl-Modus in ‚Meine Musik' existiert so nicht" (DA) — widerlegt: my_music_screen.dart:120 → SortableSongList (lib/shared/sortable_song_list.dart:46-54, 194-196) mit vollem Auswahl-Modus. Bleibt ein reines Scoping-Thema (die Aktion erschiene in fünf Ansichten).
• „Pro-Song-Lade-Loop bringt weder Fortschritt noch Doppel-Lauf-Schutz mit" (Feasibility) — widerlegt: DownloadService.lade(List<SubsonicSong>) (lib/services/download_service.dart:72-111) ist öffentlich und bringt Doppel-Lauf-Schutz (:73), Verbindungsprüfung (:77-84) und Fortschritt (:85-104) mit. Die Spec hat hier recht, das Panel nicht.
• Worker-Pool-Erschöpfung (Risk K1) — vom Panel selbst korrekt zurückgezogen (ThreadingMixIn ohne Pool, melo_cloud.py:1449-1453).
• „alle 33 handle_*" (Feasibility) — es sind 32. Ohne Folge.

0.5 Was die Verifikation dem Panel hinzufügt. [VERIFIZIERT] melo_cloud.py:505 löscht user_playlist_songs für jede playlist_id ohne user-Bedingung. Das ist nicht nur ein falsches Erfolgssignal, sondern echte Fremddaten-Löschung. Heute folgenlos (0 Playlisten), aber die Spec befördert genau diesen Endpunkt zum Regelpfad.

0.6 Severity-Dämpfung angewandt. Ein reines [PLAN-RISIKO], das eine sorgfältige Implementierung vermeiden kann, ist höchstens P1. Ein [BESTANDSFEHLER], den diese Spec nicht verursacht, ist Backlog-Punkt, kein Blocker. Nach diesem Maßstab bleibt von der Panel-Liste: 0 × P0, 10 × P1, 8 × P2, 4 × P3. Die Dringlichkeitsrhetorik des Panels ist durch den Live-Stand entkräftet: ein Nutzer mit Songs, 0 gelöschte, 0 Favoriten, 0 Playlisten.

---

1. Entscheidung über die verbliebenen Meinungsverschiedenheiten

1.1 Merge-Mechanismus: Union vs. Basis-Snapshot vs. Drei-Wege-Merge

Beide Lager haben in ihrer Diagnose recht und in ihrer Therapie unrecht. Ich entscheide für eine dritte Option, die keines der beiden vorgeschlagen hat.

Was feststeht:

• Union kann „entfernt" nicht ausdrücken. [VERIFIZIERT] Der Zyklus des Sync-Spezialisten hält, und er ist schärfer als die Spec zugibt: A ent-favorisiert online, Server ∅; B (das seither nicht synchronisiert hat, also praktisch immer) synchronisiert, Union({X}, ∅) = {X}, POSTet {X}; A holt X beim nächsten Lauf zurück. Die Spec-Zusage in Z. 108-112 („Ent-Favorisierungen propagieren über den Sofort-Push (online)") ist damit falsch, nicht nur unvollständig. Sie muss weg.
• Der Basis-Snapshot heilt das, führt aber 0.3 ein. Dazu braucht er kontogebundenen Zustand, der beim Abmelden mitgelöscht werden muss — BakaAuth.abmelden (lib/services/baka_auth.dart:114-120) räumt heute nichts ab, und ein Token-Refresh gibt es auch nicht. Das ist neue Persistenz mit einer neuen Aufräumpflicht für drei Nutzer mit null Favoriten.

Was das Panel übersehen hat (mein eigener Befund, siehe auch Abschnitt 3): Die eigentliche Gefahrenquelle ist gar nicht die Union — es ist der Full-Replace-POST /favorites. Solange die Sync-Phase den kompletten Server-Stand ersetzt, hängt die Datensicherheit an einer Regel (GET-vor-POST), und jede Lücke in dieser Regel (parseFavoriten!) wird sofort zum Datenverlust. Streicht man den Full-Replace, verschwindet die ganze Fehlerklasse strukturell.

URTEIL — additiver Delta-Abgleich, kein Voll-Ersatz, kein Basis-Snapshot:

	schreibt Server	schreibt lokal	neuer Zustand	neuer Löschpfad
heute	POST /favorites (Voll-Ersatz)	—	—	ja, der Bug
Spec (Union + Voll-Ersatz)	POST /favorites	ja	—	ja, sobald GET ∅ täuscht
Panel (Basis-Snapshot)	Delta-Push	ja	Basis je Datentyp, kontogebunden	ja (0.3)
Urteil (additiv)	POST /favorites/toggle set:true, nur für lokal \ server	nur additiv	keiner	keiner

Der Endpunkt existiert und ist deterministisch — eigene Prüfung: melo_cloud.py:1298-1302 (Route, set aus dem JSON-Körper) → handle_favorites_toggle (:644-688), set_state is True/False erzwingt den Zielzustand. Im Client fehlt nur die Methode (kein Treffer für toggle in melo_cloud_service.dart).

Warum das die richtige Antwort für dieses Projekt ist:

1. Ziel 1 wird vollständig erreicht („kein Gerät überschreibt mehr die Server-Favoriten") — und zwar durch Konstruktion statt durch eine Regel. Es gibt danach keinen Codepfad mehr, der den Server-Stand ersetzen kann.
2. Kein neuer Zustand. Kein Basis-Set, keine Aufräumpflicht beim Abmelden, keine Mengenalgebra. Weniger Teile als die Spec heute hat, nicht mehr.
3. Der Fehlerpfad ist selbstheilend. Täuscht der GET eine leere Menge vor, pusht das Gerät seine lokalen Favoriten additiv hoch — harmlos und idempotent. Beim Basis-Snapshot wäre derselbe Fehler eine geräteübergreifende Massenlöschung.
4. Der spätere Ausbau ist nicht verbaut. Wenn sich in der Praxis zeigt, dass Ent-Favorisieren wirklich stört, ist der Basis-Snapshot ein Aufsatz auf denselben Schreibweg (set:false statt set:true) — kein Umbau.
5. Preis, ehrlich benannt: Ent-Favorisieren bleibt geräteübergreifend unzuverlässig. Das ist dieselbe Einschränkung, die die Spec ohnehin schon akzeptiert — nur muss sie richtig beschrieben werden (nicht „offline", sondern „auch online, sobald ein zweites Gerät den alten Stand hält").

Damit ist die Auftraggeber-Entscheidung „Union-Merge" nicht überstimmt, sondern präzisiert: die Vereinigungs-Semantik bleibt genau wie entschieden; nur der Schreibweg wechselt vom Voll-Ersatz auf additive Pushes. Die Panel-Empfehlung Basis-Snapshot wird abgelehnt — mit der Begründung aus 0.3. Sie kommt als benannter Backlog-Punkt ins Dokument, nicht als Bestandteil.

1.2 SSE streichen — ja

Das Panel steht 3:2 für Behalten (mit acht Härtungs-Bausteinen). Ich entscheide gegen die Mehrheit, aber mit einem Argument, das niemand widerlegt hat. Nicht „SSE ist schlecht", sondern: die eigene Vorbedingung von SSE ist in dieser Spec nicht erfüllt.

• Der beworbene Haupt-Nutzen („neuer Song erscheint in Sekunden auf dem anderen Gerät") braucht das song_upload-Event. Das feuert melo_cloud.py nicht (_emit_event nur bei :393 song_delete, :410 song_update, :687 song_favorite — [VERIFIZIERT]), und die Spec lagert es ausdrücklich aus (Z. 211-215, 276-278). Am Auslieferungstag kann SSE genau das nicht, wofür es gebaut wird.
• Die drei vorhandenen Kanäle haben heute keinen Adressaten: Live-DB Baka|325, 0 gelöschte, 0 Favoriten, 0 Playlisten. [VERIFIZIERT]
• Dem stehen acht eigene, je einzeln belegte Fehlerklassen gegenüber (eigener http.Client wegen melo_cloud_service.dart:82-83; Heartbeat-Watchdog gegen den halboffenen Socket nach WLAN↔LTE; 401-Dauerabbruch, weil baka_auth.dart kein Refresh hat; Selbst-Echo-Unterdrückung, weil melo_realtime.py:56-70 an alle Queues des Nutzers ohne Absenderkennung broadcastet; Timer-Abbau bei paused; Debounce; Backoff; Nachhol-Anstoß). Kein anderes Ziel der Spec trägt annähernd so viel Fehleroberfläche.
• Dieselbe Spec lehnt Delta-Protokoll, Hintergrund-Sync und Chunked-Upload mit YAGNI ab. SSE ist die einzige Ausnahme von der eigenen Regel.
• Der ehrliche Preis ist klein und vom Panel selbst festgestellt: Es gibt keinen billigen Poll-Ersatz (automatisch() läuft nur aus initState und resumed, main.dart:175, :203, kein Timer — [VERIFIZIERT]). Der Tausch lautet: Änderungen anderer Geräte erscheinen beim nächsten App-Start oder Zurückkehren — genau wie heute. Für drei private Nutzer ist das der richtige Preis für acht entfallende Fehlerklassen.

URTEIL: SSE (Ziel 6, Feature 6, echtzeit_sync.dart) wird aus dieser Spec herausgenommen und als eigene, spätere Stufe geführt — Vorbedingung: das song_upload-Event steht. Das ist keine Verwerfung, sondern Reihenfolge. Fällt mit weg: der Parameter erzwinge (wäre ohnehin wirkungslos — die Drossel sitzt in automatisch() :166-170, nicht in synchronisiere() :174-180, [VERIFIZIERT]).

1.3 Playlist-Sync drin lassen oder herausschneiden — reduzieren

Risk formuliert es korrekt: entweder vier Semantik-Entscheidungen treffen oder herausschneiden; das Weiterlaufen im jetzigen Zustand nicht. Der Befundstand:

• Namenszuordnung ist keine Funktion (gleichnamige Playlisten per Knopfdruck erzeugbar, playlist_service.dart:75-109).
• Kein Rename-Endpunkt — [VERIFIZIERT], vollständiger Routing-Block melo_cloud.py:1251-1284 gelesen, kein PUT/PATCH auf die Playlist selbst. Die Spec behauptet in Z. 129-130 das Gegenteil.
• POST /playlists nicht idempotent, kein Unique (:488-500).
• handle_playlist_delete löscht user_playlist_songs ohne Owner-Prüfung (:505) — echter Server-Bug.
• „Längerer Stand gewinnt" ist bei Gleichstand undefiniert; updatedAtMs wird app-seitig nur in createPlaylist/deletePlaylist gepflegt.
• N+1-Requests: handle_playlist_list liefert nur song_count.
• Live-Stand: 0 Playlisten auf dem Server.

Das ist kein Nachschärf-Fall, sondern ein Entwurfsfall. Es ist aber auch kein Grund, das Feature ganz zu streichen — der Nutzen (Playlisten überleben ein zurückgesetztes Handy) ist real und billig zu haben, wenn man auf den beidseitigen Merge verzichtet.

URTEIL: Playlist-Sync Stufe 1 = einseitige Sicherung. Die App pusht lokale Playlisten-Änderungen online an den Server und merkt sich die vom Server vergebene cloudId. Kein Rück-Merge. Server-Playlisten werden nur dann lokal angelegt, wenn die lokale Playlisten-Tabelle leer ist (Neuinstallation / Wiederherstellung). Damit entfallen ersatzlos: Namenszuordnung, Reihenfolge-Schiedsrichter, Gleichstands-Regel, Tombstone-Semantik und die Abhängigkeit vom fehlenden Rename-Endpunkt — die Identität stammt immer aus dem eigenen POST /playlists und ist damit per Konstruktion stabil (user_playlists.id ist INTEGER PRIMARY KEY AUTOINCREMENT). Vorbedingung bleibt: melo_cloud.py:505 (Owner-Prüfung) muss serverseitig geflickt sein, bevor die App diesen Endpunkt regelmäßig benutzt. Der beidseitige Playlist-Merge ist eine eigene, spätere Spec. (Wer noch weiter reduzieren will: ganz herausschneiden ist ebenfalls vertretbar und kostet heute nichts.)

---

2. Prüfung der Konsens-Punkte (Konsens kann geschlossen falsch sein)

Konsens-Punkt	Urteil
„Union muss durch einen Basis-Snapshot ersetzt werden" (Runde 2, alle fünf)	FALSCH in der Therapie. Diagnose hält, Empfehlung nicht — siehe 0.3 und 1.1. Der Konsens entstand, weil die Debatte nur zwei Kandidaten kannte (Outbox vs. Basis-Snapshot) und beide in Kombination mit dem Full-Replace-POST dachte.
„DAs Outbox löst nur ein Drittel" (Runde 1, mit Gegenbeispiel akzeptiert)	Zu früh geschlossen. Das Gegenbeispiel lautet wörtlich „Offline-Gerät B resurrects via Union" — es setzt voraus, dass die Union bleibt. Es widerlegt die Outbox nur in dieser Paarung. Für mein Urteil ist das nicht tragend (ich brauche keine Outbox), aber es zeigt den Denkfehler des Konsenses.
„Die GET-vor-POST-Regel ist die beste Stelle der Spec" (Phase 3, alle fünf)	FALSCH und vom Panel selbst korrigiert. Sie ist eine Regel über ein nicht beobachtbares Prädikat. Richtig ist Flutters Umkehrung in Runde 2. Meine Konsequenz geht weiter: eine Regel, deren Verletzung Datenverlust bedeutet, gehört durch eine Konstruktion ersetzt, die den Verlust unmöglich macht (1.1).
„Die Testliste trägt" (7× erwähnt, stets lobend)	FALSCH. Der Auditor hat recht: sie nennt ausschließlich neue Tests. Zwei Bestandstests stehen der Spec aktiv im Weg (melo_cloud_service_test.dart:98-101, sync_service_test.dart:166-202), und der Sofort-Push — der einzige Online-Löschkanal der Spec — hat keinen einzigen Eintrag.
„Der Löschpfad ist Bestand, P1 für die Spec, P0 im Backlog"	RICHTIG. Die einzige Panel-Einstufung, die den Maßstab exakt trifft. Bestätigt.
„Die Architektur wird von keinem Befund angegriffen"	RICHTIG. sync_merge.dart als reine Funktionsdatei ohne I/O ist der richtige Ort — auch für den additiven Abgleich. Der Dateischnitt bleibt (abzüglich echtzeit_sync.dart).
„Die Nicht-Ziele sind diszipliniert und begründet"	RICHTIG — mit einer Ausnahme, die das Panel benannt hat: SSE bricht die eigene YAGNI-Regel. Nach 1.2 ist die Ausnahme beseitigt und der Konsens wird nachträglich vollständig richtig.
„flutter_local_notifications ist der einzige harte Blocker"	RICHTIG, mit Feasibilitys Korrektur: multiDexEnabled ist bei minSdk 24 (FlutterExtension.kt:26) gegenstandslos und fällt aus der Forderung.
„Die Phasenreihenfolge stimmt"	RICHTIG, gegen sync_service.dart:207-215 verifiziert. Aber Z. 225 („Zeitstempel am Ende") widerspricht Z. 250 („Snapshot VOR dem Listen") — beides ist erfüllbar, die Spec sagt es nur nicht.

---

3. Eigener Lücken-Scan — was auch der Auditor nicht gesehen hat

L1 [P1] [EINZELQUELLE: Richter] [PLAN-RISIKO] — Der Full-Replace-POST, nicht die Union, ist die Wurzel. Fünf Reviewer und der Auditor haben zwei Runden über die Mengenformel debattiert und dabei den Schreibweg als gegeben behandelt. Kein Beitrag prüft, was passiert, wenn man POST /favorites einfach nicht mehr benutzt. Ergebnis: Ziel 1 wird dann strukturell erreicht, die Abhängigkeit der Datensicherheit von parseFavoriten entfällt, und es entsteht kein neuer Zustand. Risk hat den Delta-Push als Bestandteil (c) seines Basis-Snapshot-Pakets vorgeschlagen — dass Bestandteil (c) allein genügt, hat niemand geprüft. Ausführlich in 1.1.

L2 [P2] [EINZELQUELLE: Richter] [BESTANDSFEHLER] — Es gibt zwei parallele Favoriten-Systeme in derselben Oberfläche, und die Spec kennt nur eines. lib/shared/server_favorite_button.dart:42 setzt Favoriten über navidrome.setFavorite(navidromeId) — also im Navidrome, nicht in der lokalen Favorites-Tabelle und nicht in der Melo-Cloud. lib/player/now_playing_screen.dart:275-279 zeigt für lokale Songs FavoriteButton (lokal) und für Server-Titel ServerFavoriteButton (Navidrome) — dasselbe Herz-Symbol, zwei getrennte Systeme. Gegenprobe: ServerFavoriteButton / server_favorite_button kommt in keiner der 25 State-Dateien und nicht in der Spec vor (grep -rln → kein Treffer). Der dritte Kanal, PlaylistService.syncFavoritesFromServer() (lib/library/playlist_service.dart:52-71), wurde von Risk (Phase 3, :303-308) und DA (Phase 3, :297-299) als toter Code erkannt (db.songExists(navidromeId) gegen lokale UUIDs) — fiel aber aus allen fünf Schlussurteilen heraus. Folge: Ein Nutzer, der im Now-Playing-Screen ein Herz antippt, kann je nach Titelquelle in zwei völlig verschiedenen Systemen landen; die Spec verspricht Favoriten-Sync, deckt aber nur eines ab. Das ist eine Geltungsbereichs-Frage, die in die Spec gehört, nicht in den Kopf des Umsetzenden.

L3 [P2] [EINZELQUELLE: Richter] [PLAN-RISIKO] — Die Pull-Richtung hat keine Regel für unauflösbare Server-Favoriten. Die Spec sagt „fehlende Favoriten lokal setzen" (Z. 99) und schweigt dazu, was bei einer cloudId passiert, die sich lokal auf keinen Song abbilden lässt (Download fehlgeschlagen, Song noch nicht geladen). Favorites.songId verweist auf Songs.id (database.dart:102-107); ein Favorit ohne Song wäre über watchFavorites() (innerJoin, :371-375) unsichtbar, würde aber über favoriteSongIds() (:534-536) ewig mitgeschleppt und wieder hochgepusht. Nebenbefund am selben Ort: favoriteSongIds() liefert auch Favoriten getombsteter Songs, weil allSongs() (:216) Grabsteine einschließt — ein lokal gelöschter Titel wird also weiter als Favorit gemeldet, während derselbe Lauf ihn am Server löscht. Unter dem additiven Abgleich harmlos, unter jedem Voll-Ersatz nicht.

L4 [P2] [EINZELQUELLE: Richter] — Der additive Delta-Push feuert N SSE-Events. handle_favorites_toggle emittiert bei jedem Aufruf song_favorite (melo_cloud.py:687). Beim ersten Lauf nach der Umstellung sind das so viele Events wie lokale Favoriten. Ohne SSE in der App (Urteil 1.2) folgenlos — aber es gehört als Vorbedingung notiert, falls SSE später kommt: das Selbst-Echo-Fenster muss dann existieren, bevor der Delta-Push zum Regelpfad wird.

L5 [P3] [EINZELQUELLE: Richter] — handle_favorites_get liefert favorited_at, der Client wirft es weg. melo_cloud.py:620 gibt je Favorit favorited_at zurück; parseFavoriten liest nur ['id']. Lokal existiert das Gegenstück als Favorites.createdAtMs (database.dart:103). Kein Handlungsbedarf für diese Spec (ohne Tombstones auf beiden Seiten trägt ein Zeitstempel keine Lösch-Entscheidung), aber es ist die Zutat, die ein späterer echter Merge bräuchte — und sie ist bereits da. Ein Satz im Backlog spart der Zukunft eine Server-Änderung.

---

4. Epistemik- und Typ-Labels (Sammelübersicht)

#	Befund	Epistemik	Typ	Severity
1	parseFavoriten verwandelt Fehlerantworten in []; favoriten() hat null Aufrufer	[VERIFIZIERT]	[PLAN-RISIKO]	P1
2	Union kann „entfernt" nicht ausdrücken; Spec-Zusage Z. 108-112 ist falsch	[VERIFIZIERT]	[PLAN-RISIKO]	P1
3	Basis-Snapshot schafft neuen Löschpfad (Panel-Empfehlung)	[VERIFIZIERT]	[PLAN-RISIKO, neu geschaffen]	P1 — abgelehnt
4	Full-Replace-POST /favorites ist die eigentliche Wurzel	[EINZELQUELLE: Richter]	[PLAN-RISIKO]	P1
5	Irreversibler Löschpfad bis in die Navidrome-Bibliothek	[VERIFIZIERT] [KONSENS]	[BESTANDSFEHLER]	P1 Spec / P0 Backlog
6	Playlist-Identität instabil (4 offene Entscheidungen)	[VERIFIZIERT] [KONSENS]	[PLAN-RISIKO]	P1
7	melo_cloud.py:505 löscht fremde user_playlist_songs ohne Owner-Prüfung	[VERIFIZIERT]	[BESTANDSFEHLER]	P1 Server-Backlog, Vorbedingung
8	Kein Playlist-Rename-Endpunkt (Spec behauptet das Gegenteil)	[VERIFIZIERT]	[PLAN-RISIKO]	P1
9	Fünf „bestehende Schutzmechanismen", die es nicht gibt	[VERIFIZIERT]	[BESTANDSFEHLER] + [PLAN-RISIKO]	P1
10	Gradle-Desugaring für flutter_local_notifications	[VERIFIZIERT] [KONSENS]	[PLAN-RISIKO]	P1 (harter Blocker)
11	SSE-Hauptnutzen hängt am ausgelagerten song_upload-Event	[VERIFIZIERT]	[PLAN-RISIKO]	P1
12	Bestandstest melo_cloud_service_test.dart:98-101 zementiert den Bug	[VERIFIZIERT] (Verifikation)	[BESTANDSFEHLER im Test]	P1
13	Bestandstest sync_service_test.dart:166-202 + Catch-All-Mock :196	[VERIFIZIERT] (Auditor)	[BESTANDSFEHLER im Test]	P1
14	Sofort-Push ohne einen einzigen Testeintrag	[VERIFIZIERT] (Auditor)	[PLAN-RISIKO]	P1
15	Zwei parallele Favoriten-Systeme (ServerFavoriteButton)	[EINZELQUELLE: Richter]	[BESTANDSFEHLER]	P2
16	Pull-Richtung ohne Regel für unauflösbare cloudIds	[EINZELQUELLE: Richter]	[PLAN-RISIKO]	P2
17	Auswahl-Upload nicht abbrechbar	[VERIFIZIERT] (Auditor)	[PLAN-RISIKO]	P2
18	30er-Rückfrage strukturell wirkungslos; kein Platz-Check	[VERIFIZIERT] (Auditor)	[PLAN-RISIKO]	P2
19	Doppelspeicherung Download × Abspiel-Cache	[VERIFIZIERT] (Auditor)	[PLAN-RISIKO]	P2
20	Zeitstempel × Auswahl-Upload × 24-h-Bericht offen	[VERIFIZIERT] (Auditor)	[PLAN-RISIKO]	P2
21	Bericht: letzterLauf == null und „erfolgreich" undefiniert	[VERIFIZIERT] (Auditor)	[PLAN-RISIKO]	P2
22	Offline-Modus von keinem neuen Netz-Verbraucher beachtet	[VERIFIZIERT] (Auditor)	[PLAN-RISIKO]	P2
23	Navidrome-Playlist-Import nicht idempotent („🌐"-Duplikate)	[VERIFIZIERT]	[BESTANDSFEHLER]	P2
24	_LadeKnopf ist privat und in einer anderen Datei	[VERIFIZIERT]	[PLAN-RISIKO]	P2
25	Schema-Divergenz ist_korrupt / uq_user_song	[VERIFIZIERT]	[BESTANDSFEHLER]	P2 Backlog
26	server_titel_screen._geladen-Einmal-Snapshot	[VERIFIZIERT]	[BESTANDSFEHLER]	P2
27	Widerspruch Z. 225 ↔ Z. 250 (Zeitstempel)	[VERIFIZIERT] (Auditor)	[PLAN-RISIKO]	P3
28	„2-GB-Abspiel-Cache" ist ein Standardwert (0–8192 MB)	[VERIFIZIERT] (Auditor)	[PLAN-RISIKO]	P3
29	Kein Migrations-Downgrade-Pfad (Schema 10 → 11)	[VERIFIZIERT] (Auditor)	[PLAN-RISIKO]	P3
30	favorited_at / createdAtMs ungenutzt	[EINZELQUELLE: Richter]	[PLAN-RISIKO]	P3
—	„Auswahl-Modus existiert nicht" (DA)	[BESTRITTEN → widerlegt]	—	entfällt
—	„Pro-Song-Loop ohne Fortschritt/Schutz" (Feasibility)	[BESTRITTEN → widerlegt]	—	entfällt
—	Worker-Pool-Erschöpfung (Risk K1)	[BESTRITTEN → zurückgezogen]	—	entfällt

---

5. Finaler Score und Verdikt

Score: 6 / 10

Über dem Panel-Mittel (5,2), weil die Verifikation zwei tragende Säulen der Panel-Kritik entfernt hat: es gibt kein P0 im Geltungsbereich, und die zentrale Ersatz-Empfehlung des Panels ist selbst gefährlicher als das, was sie ersetzen soll (0.3). Die beiden „ÜBERARBEITEN"-Stimmen begründen sich fast vollständig aus einer Therapie, die ich ablehne.

Nicht höher als 6, weil das Dokument drei belegte Substanzmängel hat: eine falsche Garantie (Z. 108-112 — Ent-Favorisierungen propagieren nicht), fünf zu optimistische Bestandsbehauptungen (Rename-Endpunkt, _LadeKnopf, „verzögert", erzwinge, „vollständig" in Z. 17) und einen Umfang, den es nicht rechtfertigen kann (SSE ohne seine eigene Vorbedingung, Playlist-Sync mit vier offenen Semantik-Entscheidungen, eine Dependency, die den einzigen harten Build-Blocker der ganzen Planung erzwingt).

Verdikt: SPEC NACHSCHÄRFEN DANN FREIGEBEN

Begründung gegen „ÜBERARBEITEN": Jede von mir geforderte Änderung ist entweder (a) die Korrektur eines faktisch falschen Satzes, (b) eine Reduktion des Umfangs — Abschnitte streichen oder verschieben ist keine Neuschrift, oder (c) ein Mechanismus-Tausch, der das Dokument kleiner macht (additiver Delta-Push statt Voll-Ersatz = weniger bewegliche Teile als heute). Rahmen, Zerlegung, Nicht-Ziele, Architektur (sync_merge.dart als reine Funktionsdatei), Phasenreihenfolge und der Testansatz bleiben unangetastet und wurden von keinem Reviewer angegriffen. Es gibt nichts wegzuwerfen.

Begründung gegen „FREIGEBEN": Die falsche Lösch-Garantie und die fünf Bestandsbehauptungen würden den Umsetzenden nachweislich in die Irre führen; zwei grüne Bestandstests stehen der Umsetzung aktiv im Weg; und eine Frage kann kein Reviewer entscheiden (siehe A6).

Bedingung: Die nachgeschärfte Fassung wird einmal kurz gegengelesen, bevor der Implementierungsplan entsteht — die Punkte A1, A5 und A7 ändern, was gebaut wird, nicht nur wie es beschrieben ist.

---

6. AKTIONSLISTE — konkrete Änderungen an der Spec

Priorisiert. Jede Zeile ist so formuliert, dass sie direkt ins Dokument kann.

---

A1 · P1 · [EINZELQUELLE: Richter] [PLAN-RISIKO] · §Feature 1, Punkt „Vereinigung beim Sync" (Z. 95-101) + §Risiken (Z. 252-254)

Full-Replace-POST ersatzlos streichen. Der Abgleich schreibt nur noch additiv.

Die Sync-Phase benutzt nie POST /favorites (Voll-Ersatz). Sie schreibt ausschließlich additiv:

1. GET /favorites → server (Menge von cloudIds).
2. Für jede cloudId in lokal \ server: POST /favorites/toggle mit {"song_id": …, "set": true} (existiert und ist deterministisch: melo_cloud.py:1298-1302 → handle_favorites_toggle:644-688; die Client-Methode ist neu).
3. Für jede cloudId in server \ lokal: lokal Favorit setzen, sofern der Song lokal auflösbar ist.
4. In keiner Richtung wird etwas entfernt.

MeloCloudService.setzeFavoriten (melo_cloud_service.dart:268-280) wird nicht mehr benutzt und entfällt.

Wirkung: Der Datenverlust-Bug aus Ziel 1 ist danach strukturell unmöglich, nicht nur durch eine Regel verhindert — es existiert kein Codepfad mehr, der den Server-Stand ersetzen kann. Deckel: höchstens 200 Pushes je Lauf, der Rest im nächsten Lauf (die Pushes sind idempotent, ein Teilausfall heilt sich beim nächsten Lauf selbst).

Streichen in §Risiken: „POST /favorites bleibt technisch ein Voll-Ersatz — die Sicherheit liegt allein in der GET-vor-POST-Regel." Ersetzen durch: „Die Sicherheit liegt nicht mehr in einer Regel, sondern darin, dass kein Voll-Ersatz-Aufruf mehr existiert."

---

A2 · P1 · [VERIFIZIERT] [PLAN-RISIKO] · §Feature 1 „Sicherheitsregel" (Z. 102-105) + §Tests

parseFavoriten härten — und den grünen Bestandstest mitändern.

Ein GET gilt nur als erfolgreich, wenn HTTP 200 und kein error-Schlüssel und favorites als Liste vorhanden ist. Ein fehlender favorites-Schlüssel ist ein Fehler, keine leere Menge; parseFavoriten wirft dann CloudException, genau wie parseListe (melo_cloud_service.dart:99-100) und parseUpload (:111-112) es bereits tun. Hintergrund: der Router verdrahtet für GET /favorites hart 200 (melo_cloud.py:1292-1293), und sechs Handler desselben Servers geben Fehler im 200er-Körper zurück (:418, 491, 545, 766, 1021, 1118).

Bestandsänderung, Teil des Arbeitspakets: test/services/melo_cloud_service_test.dart:98-101 prüft heute ausdrücklich das Gegenteil (expect(parseFavoriten(jsonEncode({'status':'ok'})), isEmpty)) und wird mit umgeschrieben. Das ist kein Regressionsfehler.

Zwei Pflichttests: „200 mit Fehlerkörper → Phase übersprungen, kein Push" und „200 mit favorites: [] → Phase läuft normal durch" (der zweite verhindert, dass der erste durch ein zu scharfes „wirf bei leer" trivial erfüllt wird).

---

A3 · P1 · [VERIFIZIERT] [PLAN-RISIKO] · §Feature 1, letzter Punkt (Z. 108-112)

Die falsche Lösch-Garantie streichen und durch die richtige Einschränkung ersetzen.

Zu streichen: „Ent-Favorisierungen propagieren über den Sofort-Push (online) … Offline entfernte Herzen kommen beim nächsten Sync zurück". Das ist falsch — es betrifft auch online entfernte Herzen.

Bekannte Einschränkung (bewusst, dokumentiert): Der Abgleich ist rein additiv. Ein Ent-Favorisieren wirkt sofort lokal und — online — auch auf dem Server, ist aber nicht geräteübergreifend garantiert: Hält ein zweites Gerät den Favoriten noch, bringt dessen nächster Sync ihn auf allen Geräten zurück. Das gilt für offline und für online entfernte Herzen. Bewusster Tausch, wie in v2: kein Datenverlust ist wichtiger als verlässliche Lösch-Propagation. Falls das in der Praxis stört: Folgeschritt „Basis-Snapshot" (Backlog). Er lässt sich später ohne Umbau ergänzen, weil der Schreibweg dann schon der Delta-Push ist — aus set:true wird zusätzlich set:false.

---

A4 · P1 · [VERIFIZIERT] [PLAN-RISIKO] · §Risiken, neuer Unterabschnitt „Verworfene Alternativen"

Den Basis-Snapshot ausdrücklich ablehnen und begründen (Gegen-Empfehlung zum Panel).

Verworfen: Drei-Wege-Merge gegen einen persistierten Basis-Snapshot (neu = (lokal ∪ server) − (Basis \ lokal) − (Basis \ server)). Er löst zwar die Lösch-Propagation, führt aber den einzigen neuen Datenverlustpfad der ganzen Planung ein: Liefert GET /favorites fälschlich eine leere Liste, wird Basis \ server = Basis, die Formel kollabiert zu lokal − Basis und löscht den gesamten bestätigten Bestand — lokal und über den Delta-Push auf dem Server und damit auf allen Geräten. Zusätzlich braucht er kontogebundenen Zustand mit Aufräumpflicht beim Abmelden; BakaAuth.abmelden (baka_auth.dart:114-120) räumt heute nichts ab und es gibt kein Token-Refresh. Für drei Nutzer, 0 Favoriten und 0 Playlisten auf dem Server ist der additive Abgleich der bessere Tausch. Der Basis-Snapshot bleibt als Folgeschritt im Backlog.

---

A5 · P1 · [VERIFIZIERT] [KONSENS] [PLAN-RISIKO] · §Ziel 4, §Feature 2 (Z. 114-140), §Nicht-Ziele, §Tests, §Offene Abhängigkeiten

Playlist-Sync auf einseitige Sicherung reduzieren. Der beidseitige Merge wird eigene Spec.

Playlist-Sync Stufe 1 = einseitige Sicherung. Die App meldet lokale Playlisten-Änderungen (anlegen / Song hinzufügen / Song entfernen / Reihenfolge) online fire-and-forget an den Server und persistiert die vom Server vergebene cloudId (Drift-Migration Playlists.cloudId TEXT NULL bleibt). Es findet kein Rück-Merge statt: Server-Playlisten werden nur dann lokal angelegt, wenn die lokale Playlisten-Tabelle leer ist (Neuinstallation / Wiederherstellung).

Damit entfallen ersatzlos: Namenszuordnung, Reihenfolge-Schiedsrichter („längerer Stand gewinnt"), Gleichstands-Regel, Tombstone-Semantik und die Abhängigkeit vom fehlenden Rename-Endpunkt. Die Identität stammt immer aus dem eigenen POST /playlists und ist stabil (user_playlists.id ist INTEGER PRIMARY KEY AUTOINCREMENT).

Nicht abgedeckt (dokumentiert): Umbenennungen propagieren nicht. Playlisten-Änderungen auf einem zweiten Gerät erscheinen auf dem ersten nicht. Der beidseitige Playlist-Merge ist eine eigene, spätere Spec.

Vorbedingung (Server-Auftrag, blockierend): melo_cloud.py:505 löscht user_playlist_songs für jede playlist_id ohne user-Bedingung — echte Fremddaten-Löschung. Muss geflickt sein, bevor die App diesen Endpunkt regelmäßig benutzt.

Ebenfalls vertretbar und heute kostenlos (0 Playlisten auf dem Server): Feature 2 ganz herausschneiden. Entscheidung liegt bei Dustin; das Weiterlaufen im jetzigen Zustand (vier offene Semantik-Entscheidungen) ist es nicht.

---

A6 · P1 für die Spec / P0 im Backlog · [VERIFIZIERT] [KONSENS] [BESTANDSFEHLER] · §Kontext (Z. 15-17) + §Risiken

Den irreversiblen Löschpfad benennen — und die eine Frage stellen, die kein Reviewer entscheiden kann.

§Kontext, Korrektur des Wortes „vollständig":

„… der Weg Handy→Server→Navidrome-Bibliothek existiert also bereits — und er läuft auch rückwärts: verschwindet die lokale Datei, meldet der Sync die Löschung, und der Server entfernt die Audiodatei aus Registry und Navidrome-Bibliothek."

§Risiken, neuer Absatz:

Irreversibler Löschpfad (Bestand, nicht von dieser Spec verursacht — Backlog-P0). markMissing (database.dart:237-245) tombstoned jeden Titel, dessen Datei der Scan nicht findet — auch unbeabsichtigt (SD-Karte nicht eingehängt, Berechtigung entzogen, Dateimanager). planeSync (sync_service.dart:68-76) macht daraus eine Server-Löschung; die Lösch-Bremse (:112-113) greift bei 325 Titeln erst ab 109 — 1 bis 108 Löschungen laufen ungebremst. Der Server löscht registry/<sid> und navidrome/music/<sid> (melo_cloud.py:356-372, :190-202); für die Datei gibt es keinen Grabstein. Erneutes Hochladen repariert es nicht: der überlebende registry.sha256 erzwingt den Dedup-Zweig (:265-267), shutil.move steht nur im Neu-Zweig (:289), os.remove(tmp) verwirft die Bytes (:312), /download antwortet dauerhaft 404 (:1400-1408). Bisher nie ausgelöst (Live-DB: SUM(deleted)=0).

Rückfrage an Dustin — kein Reviewer kann das entscheiden: Ist das gewollt? Bei „ja" ist es eine dokumentierte Eigenschaft. Bei „nein" gehört ein Server-Auftrag (Dedup-Zweig stellt die Datei wieder her, wenn registry_pfad(sid) leer ist) vor Feature 3 — denn Feature 3 gibt mehr Titeln eine cloudId und vergrößert damit die Angriffsfläche.

---

A7 · P1 · [VERIFIZIERT] [PLAN-RISIKO] · §Ziel 6 + §Feature 6 (Z. 193-215) + §Architektur-Tabelle + §Tests + §Offene Abhängigkeiten

SSE aus dieser Spec herausnehmen, als eigene spätere Stufe führen.

Ziel 6 und Feature 6 entfallen; echtzeit_sync.dart fällt aus der Architektur-Tabelle; die SSE-Tests fallen aus der Testliste. Neuer Eintrag unter §Nicht-Ziele:

Kein Echtzeit-Sync (SSE) in dieser Stufe. Der beworbene Haupt-Nutzen („neuer Song erscheint in Sekunden auf dem anderen Gerät") hängt am song_upload-Event, das melo_cloud.py heute nicht feuert (_emit_event nur bei :393, :410, :687) und das diese Spec ausdrücklich auslagert — am Auslieferungstag könnte SSE also genau das nicht, wofür es gebaut wird. Die drei vorhandenen Kanäle (song_delete, song_update, song_favorite) haben heute keinen Adressaten (Live-Stand: ein Nutzer mit Songs, 0 gelöschte, 0 Favoriten, 0 Playlisten). Dem stehen acht eigene Fehlerklassen gegenüber: eigener http.Client (der geteilte aus melo_cloud_service.dart:82-83 würde beim close() laufende Sync-Requests mitreißen), Heartbeat-Watchdog gegen den halboffenen Socket nach WLAN↔LTE, dauerhafter 401-Ausstieg (baka_auth.dart hat kein Refresh), Selbst-Echo-Unterdrückung (melo_realtime.py:56-70 broadcastet an alle Queues des Nutzers ohne Absenderkennung), Timer-Abbau bei paused, Debounce, Backoff, Nachhol-Anstoß. Ehrlicher Preis: Änderungen anderer Geräte erscheinen beim nächsten App-Start oder Zurückkehren — genau wie heute. Es gibt keinen billigeren Poll-Ersatz: automatisch() läuft nur aus initState und resumed (main.dart:175, :203), ein Timer existiert nicht. SSE wird eigene Stufe, sobald das song_upload-Event steht; die acht Bausteine gehören dann in jene Spec, nicht in den Plan.

Ebenfalls streichen: der Parameter erzwinge (Z. 201-202). Er wäre wirkungslos — die 15-Minuten-Drossel sitzt in automatisch() (sync_service.dart:166-170), nicht in synchronisiere() (:174-180).

---

A8 · P1 · [VERIFIZIERT] [KONSENS] [PLAN-RISIKO] · §Ziel 5 + §Feature 5 (Z. 172-191) + §Architektur-Tabelle

Notification halbieren: Bericht sofort, persistente Notification als eigene Stufe mit Beweis-Build.

Stufe A (keine neue Dependency): Sync-Bericht „Was ist neu" als In-App-Dialog. Stufe B (eigenes Arbeitspaket): persistente Fortschritts-Notification. Sie erzwingt flutter_local_notifications und damit isCoreLibraryDesugaringEnabled = true plus coreLibraryDesugaring("com.android.tools:desugar_jdk_libs:2.1.4") in android/app/build.gradle.kts — die Datei hat heute überhaupt keinen dependencies { }-Block, der Gradle-Heap steht auf 2 GB (gradle.properties:1, dokumentierte OOM-Quelle), AGP ist 9.0.1 (settings.gradle.kts:22) und android-37 ist ein Nachbau von 36. Erstes Abnahmekriterium der Stufe B ist ein grüner flutter build apk --target-platform android-arm64 nach dem pub add — vor jeder Zeile Notification-Logik. multiDexEnabled entfällt aus der Forderung: bei minSdkVersion = 24 (FlutterExtension.kt:26) ist es gegenstandslos. Mitzuentscheiden: Channel mit Importance.low, onlyAlertOnce: true, und ein cancel() beim Init gegen die nach App-Kill stehengebliebene Fortschritts-Notification.

---

A9 · P1 · [VERIFIZIERT] [BESTANDSFEHLER] + [PLAN-RISIKO] · §Fehlerfälle (Z. 227-240)

Den Abschnitt von Zusagen auf zu bauende Arbeit umstellen. Fünf „bestehende Schutzmechanismen" gibt es nicht.

Die folgenden Schutzmechanismen existieren nicht und sind Teil dieser Arbeit:

• Phasen-Isolation: synchronisiere() hat heute ein einziges try/catch um alle Phasen (sync_service.dart:188-228). Jede neue Phase bekommt ihr eigenes try/catch mit definiertem Teil-Erfolg.
• „verzögert" gibt es nicht: if (_laeuft) return; (:175) verwirft den Anstoß wortlos. Wer einen Nachlauf will, braucht ein _nachziehen-Flag, das im finally genau einen weiteren Lauf auslöst.
• Der Upload überlebt keinen Timeout: _ladeHoch fängt nur CloudException (:313); der 120-s-Timeout (melo_cloud_service.dart:180) wirft TimeoutException und reißt den ganzen Lauf ab. Timeouts sind wie Einzelfehler zu behandeln.
• Die Drossel sitzt in automatisch() (:166-170), nicht in synchronisiere() (:174-180) — siehe A7, erzwinge entfällt.
• Der Löschweg zum Server wird in den Fehlerfällen nirgends beschrieben — siehe A6.

---

A10 · P1 · [VERIFIZIERT] (Verifikation + Auditor) [BESTANDSFEHLER im Test] · §Tests (Z. 256-272)

Testliste um den Bestand erweitern. Sie nennt heute ausschließlich neue Tests.

Anzupassender Bestand:

• test/services/melo_cloud_service_test.dart:98-101 — zementiert das []-Verhalten, wird mit A2 umgeschrieben.
• test/services/sync_service_test.dart:166-202 („Favoriten werden mit ihren Server-IDs gemeldet") prüft heute genau das Full-Replace-Verhalten, das Ziel 1 beseitigt. Sein MockClient beantwortet jeden Pfad außer /list mit {'status':'ok'} (:196) — unter der neuen Regel liefert GET /favorites dort 200 ohne favorites-Schlüssel und die Phase wird übersprungen. Der Test wird auf den additiven Delta-Push umgeschrieben und bekommt eine explizite /favorites-Antwort. Der Catch-All-Mock darf nicht aufgeweicht werden, um die neue Sicherheitsregel zu umgehen — das ist der schnellste Weg zu Grün und der falsche.
• Dasselbe gilt abgeschwächt für die übrigen sieben Tests derselben Datei.

Neu, heute nicht in der Liste: PlaylistService — der Sofort-Push ist der einzige Online-Kanal der Spec und hat keinen einzigen Testeintrag.

---

A11 · P2 · [VERIFIZIERT] [PLAN-RISIKO] · §Feature 2 (Z. 129-132), §Feature 4 (Z. 159-170)

Drei „existiert bereits"-Behauptungen korrigieren — und zwei ausdrücklich bestätigen.

§Feature 2:

Endpunkte: GET/POST/DELETE /playlists, GET /<id>, POST /<id>/songs, DELETE /<id>/songs/<sid>, PUT /<id>/positions (melo_cloud.py:1251-1284). Einen Rename-Endpunkt gibt es nicht — kein PUT/PATCH auf die Playlist selbst; handle_rename:749 betrifft Songs.

§Feature 4:

ladeEinzelnenTitel(song) ruft den bestehenden öffentlichen DownloadService.lade([song]) (download_service.dart:72-111) auf — der bringt Doppel-Lauf-Schutz (:73), Verbindungsprüfung (:77-84) und Fortschritts-Buchführung (:85-104) mit. Nicht _ladeEinen (:113-139) direkt verdrahten. _LadeKnopf ist eine private Klasse in lib/downloads/downloads_screen.dart:419-429, kein wiederverwendbares Widget — als Muster kopieren oder vorher extrahieren.

Zur Klarstellung im Dokument nicht nötig, aber für den Umsetzenden relevant: Die Spec-Behauptungen „der Pro-Song-Lade-Loop existiert bereits" und „der Auswahl-Modus in ‚Meine Musik' existiert" sind beide richtig — das Panel lag hier falsch (sortable_song_list.dart:46-54, 194-196).

---

A12 · P2 · [EINZELQUELLE: Richter] [BESTANDSFEHLER] · §Feature 1, neuer Satz „Geltungsbereich"

Die beiden parallelen Favoriten-Systeme benennen.

Geltungsbereich: Der Favoriten-Abgleich betrifft ausschließlich die lokale Favorites-Tabelle. Der Stern in der Server-Titel-Ansicht (ServerFavoriteButton, lib/shared/server_favorite_button.dart:42, benutzt in now_playing_screen.dart:279) ist ein anderes System — Navidrome-Starring über navidrome.setFavorite(navidromeId) — und wird von dieser Spec nicht angefasst. Beide erscheinen im Now-Playing-Screen als dasselbe Herz-Symbol; dass sie getrennt bleiben, ist eine Entscheidung, keine Auslassung. PlaylistService.syncFavoritesFromServer() (playlist_service.dart:52-71) ist ein dritter Kanal und heute wirkungslos (db.songExists(navidromeId) gegen lokale UUIDs) — er wird nicht Teil des Abgleichs.

---

A13 · P2 · [EINZELQUELLE: Richter] [PLAN-RISIKO] · §Feature 1, Pull-Richtung

Regel für unauflösbare Server-Favoriten festschreiben.

Server-Favoriten, deren cloudId sich lokal auf keinen Song abbilden lässt (Download fehlgeschlagen, Titel noch nicht geladen), werden übersprungen, nicht gelöscht: Favorites.songId verweist auf Songs.id (database.dart:102-107); ein Favorit ohne Song wäre über watchFavorites() (innerJoin, :371-375) unsichtbar, würde aber über favoriteSongIds() (:534-536) weiter mitgeschleppt und wieder hochgepusht. Der additive Abgleich schreibt sie deshalb weder lokal, noch entfernt er sie serverseitig. Hinweis am selben Ort: favoriteSongIds() liefert auch Favoriten getombsteter Songs (allSongs() schließt Grabsteine ein, :216).

---

A14 · P2 · [VERIFIZIERT] (Auditor) [PLAN-RISIKO] · §Feature 3 (Z. 142-157) + §Feature 4 (Z. 159-170) + §Fehlerfälle

Fünf Entscheidungen treffen, die die Spec heute dem Umsetzenden überlässt.

• Abbrechen: Der Auswahl-Upload bekommt SyncService.abbrechen() nach dem Muster von DownloadService (:46, :66-68, :96) — ein Flag, das die Schleife zwischen zwei Songs prüft. SyncService hat heute keinerlei Abbruchmöglichkeit (0 Treffer für abbrech|cancel in 376 Zeilen); ohne das ist ein versehentlich markierter 60-Titel-Upload nur durch App-Kill zu stoppen — und die Spec bewirbt den Album-Download in Z. 19 ausdrücklich mit „Fortschritt + Abbrechen".
• Zeitstempel: ladeAusgewaehlteHoch schreibt _letzterLauf (:215-217) nicht — es ist kein Sync. Sonst unterdrückt ein manueller Upload 15 Minuten Auto-Sync (sollAutoSync, :120-121) und verschiebt die 24-h-Uhr des Berichts; wer die App täglich zum Hochladen öffnet, sähe den Bericht nie.
• Kein Platz-Check, keine Schwelle beim Einzel-Song-Offline: Die 30er-Rückfrage (download_service.dart:13, :15, :17-21, Aufrufer nur downloads_screen.dart:460 und :496) ist bei einem Einzeltitel per Konstruktion wirkungslos, und einen Check auf freien Speicher gibt es in der ganzen App nicht. Bewusst akzeptiert: der Knopf lädt genau einen Titel.
• Doppelspeicherung: Vor dem Netz-Download prüft ladeEinzelnenTitel, ob die Datei bereits im Abspiel-Cache liegt — sonst entsteht genau die Doppelspeicherung, die audio_handler.dart:326-331 in der Gegenrichtung ausdrücklich verhindert („doppelter Platz und doppeltes Datenvolumen"). Falls zu teuer: als bekannte Einschränkung dokumentieren, nicht schweigen.
• Offline-Modus: Der Schalter (lib/services/offline_mode.dart, settings_screen.dart:218-231) wirkt heute nur auf die Wiedergabe (main.dart:106-110). Entscheidung festhalten: Auswahl-Upload und Einzel-Song-Offline respektieren ihn nicht, weil beides ausdrückliche Nutzeraktionen sind.

---

A15 · P2 · [VERIFIZIERT] (Auditor) [PLAN-RISIKO] · §Feature 5, Sync-Bericht (Z. 187-191)

Erstfall und „erfolgreich" definieren.

letzterLauf == null (Neuinstallation, nach Abmelden, nach App-Daten-Löschen) gilt nicht als fällig — sonst begrüßt der Bericht ein frisch installiertes Gerät mit „Willkommen zurück! 325 neue Songs". Achtung: sollAutoSync (sync_service.dart:120-121) behandelt null genau umgekehrt und ist hier kein Vorbild. „Erfolgreich" heißt: alle Phasen ohne geschluckten Fehler. Dafür führt synchronisiere() ein Flag, das jede Phase bei einem Fehlschlag löscht; der Bericht-Zeitstempel wird nur bei gesetztem Flag geschrieben. Heute schreibt :215-217 denselben Zeitstempel, egal ob Phasen ausgefallen sind (_meldeLoeschungen:243-252 schluckt Fehler).

---

A16 · P3 · [VERIFIZIERT] (Auditor) · Kleinigkeiten, je ein Satz

• §Sync-Phasen Z. 225 ↔ §Risiken Z. 250: „Der Zeitstempel wird vor dem Listen genommen und nach allen Phasen geschrieben." (Heute: _letzterLauf = DateTime.now() in :215, nach allen Phasen.)
• §Kontext Z. 19-20: „automatischer Abspiel-Cache, Standard 2 GB, einstellbar 0–8192 MB" (app_settings.dart:28, :31).
• §Nicht-Ziele: „Ein Rollback auf eine ältere App-Version ist nach der Schema-Migration nicht vorgesehen — database.dart:154-192 kennt nur onCreate und onUpgrade."
• §Offene Abhängigkeiten: Schema-Divergenz ist_korrupt / uq_user_song (nur in der Live-DB, nicht im CREATE TABLE des Skripts) als Backlog-Punkt — trifft nur wiederhergestellte oder Test-Instanzen.
• Backlog-Notiz: handle_favorites_get liefert bereits favorited_at (melo_cloud.py:620), lokal existiert Favorites.createdAtMs — die Zutat für einen späteren echten Merge ist beidseitig vorhanden.

---

A17 · P1 · [KONSENS] · §Neuer Abschnitt „Reihenfolge" (vor §Tests)

Auslieferungsreihenfolge festschreiben — sie fehlt heute ganz.

1. Favoriten-Fix allein (additiver Delta-Push, parseFavoriten, Testanpassung). Wartet auf nichts: kein Server-Auftrag, keine neue Dependency, keine Gradle-Änderung, kein neues UI-Muster. Einzige Stufe mit belegtem Datenverlust-Bezug.
2. Auswahl-Upload + Einzel-Song-Offline (UI, keine neue Dependency).
3. Sync-Bericht (Stufe A, kein Plugin).
4. Playlist-Sicherung Stufe 1 — nach dem Server-Fix melo_cloud.py:505.
5. Notification Stufe B — beginnt mit dem grünen Beweis-Build.
6. SSE — eigene Spec, nach dem song_upload-Event.

---

§Offene Abhängigkeiten — geschlossene Liste (ersetzt Z. 274-281)

#	Auftrag	Art	Blockiert
1	melo_cloud.py:505 — Owner-Prüfung in handle_playlist_delete	Voraussetzung	A5 / Feature 2
2	Datei-Wiederherstellung im Dedup-Zweig von upload()	Voraussetzung, falls Antwort auf A6 „nein"	Feature 3
3	song_upload-SSE-Event	Voraussetzung für die spätere SSE-Stufe	nichts in dieser Spec
4	Playlist-Rename-Endpunkt (PUT/PATCH)	optional	nichts (A5 braucht ihn nicht mehr)
5	Playlist-Tombstones serverseitig	optional / Backlog	nichts

---

7. Meta-Beobachtung

Zur Spec-Qualität. Das Dokument ist auffallend ehrlich in seinen Nicht-Zielen und faktisch überwiegend korrekt — rund zwanzig Bestandsbehauptungen haben fünf unabhängigen Prüfungen standgehalten, und zwei angebliche Fehler des Panels waren in Wahrheit Fehler des Panels. Seine zwei echten Schwächen sind typisch für Specs, die von jemandem geschrieben werden, der den Code gut kennt: Es verwechselt „ich weiß, wie das geht" mit „das ist schon da" (fünf zu optimistische Bestandssätze), und es formuliert Sicherheit als Regel statt als Konstruktion („nie ohne erfolgreiches GET POSTen") — Regeln haben Lücken, Konstruktionen nicht. Der größte Einzelmangel ist aber der Umfang: sechs Ziele, von denen genau eines auf nichts wartet und einen belegten Bug behebt, während die anderen fünf zusammen vier Server-Aufträge, eine Build-Umbauaktion und acht Fehlerklassen mitbringen. Das ist kein Denkfehler, das ist fehlende Reihenfolge — und sie ist mit einem Abschnitt behoben.

Zum Panel-Prozess. Der Prozess war stark, wo er üblicherweise schwach ist, und schwach an einer Stelle, die der Prozess nicht vorsieht. Stark: Die Beleglage ist außergewöhnlich — ~70 geprüfte Datei:Zeile-Belege, keine einzige Halluzination, keine Fehlzuordnung. Mehrere Reviewer haben eigene P0 aktiv falsifiziert (DA hat seine eigene Rettungshypothese widerlegt, Risk hat sein eigenes P0 konzediert, Feasibility hat drei eigene Befunde fallen lassen). Das ist das Gegenteil von Konsens-Drift. Schwach: Der Prozess prüft die Spec adversarial, aber die eigene Empfehlung nur konsensual. Sobald Runde 2 auf den Basis-Snapshot konvergiert war, hat niemand ihn mehr mit derselben Härte angegriffen wie zuvor die Union — obwohl DA und Risk den entscheidenden Einwand (0.3) je einmal notiert hatten. Beide Phase-6-Zusammenfassungen führen ihn nicht als Finding. Ein Panel, das eine Therapie empfiehlt, braucht eine Runde, in der die Therapie der Review-Gegenstand ist. Erst die separate Verifikation hat das aufgedeckt — sie ist der wertvollste Bestandteil dieses Verfahrens gewesen. Zweiter blinder Fleck: Der Suchraum war zu klein. Zwei Runden über „Outbox oder Basis-Snapshot" haben den Schreibweg (POST /favorites als Voll-Ersatz) als gegeben behandelt. Die billigste Lösung lag außerhalb der Debattenachse — sie bestand darin, einen Aufruf zu streichen, nicht einen Mechanismus zu bauen. Das ist die wiederkehrende Blindstelle von Review-Panels: Sie sind darauf trainiert, Lücken zu finden, und finden deshalb Dinge, die man hinzufügen muss. Dritter Punkt: Die Testschuld wurde erst vom Vollständigkeits-Auditor entdeckt. Fünf Reviewer haben sync_service.dart zeilengenau seziert und test/ nur einmal betreten. Für ein Projekt mit TDD-Pflichtworkflow ist das die bemerkenswerteste Lücke des ganzen Durchlaufs — und die mit den unmittelbarsten Folgen, weil der schnellste Weg zu Grün darin bestünde, die neue Sicherheitsregel im Mock wieder aufzuweichen.

---

Alle eigenen Prüfungen read-only (grep/sed/read auf lib/, test/, android/, melo_cloud.py). Keine git-Operationen, keine .env, keine Server-Prozesse. Geschrieben wurde ausschließlich diese Datei.