# Design: Reorder-Validierung im PlaylistStore

**Datum:** 2026-03-26
**Scope:** `store.go` (Reorder), `manage/ui.go` (HandleReorderUI), `manage/playlist.go` (HandleReorder)

## Problem

`PlaylistStore.Reorder` akzeptiert beliebige ID-Listen ohne Prüfung:

- Unbekannte oder fremde IDs werden stillschweigend ignoriert (0 Rows affected, kein Fehler)
- Eine Teilliste korrumpiert die Sortierung: nicht geschickte Items behalten ihren alten `order_index`
- Beide Fehlerszenarien sind für den Client unsichtbar — der Response ist trotzdem 204

## Lösung

### 1. Sentinel-Fehler in `store.go`

```go
var ErrReorderMismatch = errors.New("reorder: item list does not match playlist")
```

### 2. Vollständigkeitsprüfung in `Reorder`

Vor den Updates: `COUNT(*)` der Items in der Playlist innerhalb der Transaktion.
Wenn `len(itemIDs) != count` → `ErrReorderMismatch` zurückgeben.

### 3. RowsAffected-Check pro Update

Nach jedem `tx.Exec`: wenn `RowsAffected() != 1` → `ErrReorderMismatch` zurückgeben.
(Fängt fremde IDs, die die `AND playlist_id=`-Bedingung passiert hätten.)

### 4. Handler-Anpassung (400 statt 500)

Beide Handler prüfen `errors.Is(err, store.ErrReorderMismatch)`:
- Match → `http.StatusBadRequest` (400)
- Sonst → `http.StatusInternalServerError` (500)

## Verhalten nach Fix

| Szenario | Vorher | Nachher |
|---|---|---|
| Vollständige, korrekte Liste | 204 ✓ | 204 ✓ |
| Teilliste | 204 (stille Korruption) | 400 → UI reloaded |
| Fremde/unbekannte ID | 204 (still ignoriert) | 400 → UI reloaded |
| DB-Fehler | 500 | 500 |

## Nicht im Scope

- Änderung des Drag&Drop-Frontends (schickt bereits die vollständige Liste)
- Neue Tests (werden im Implementierungsplan ergänzt falls vorhanden)