# Animations-Serie (HyperOS-inspiriert) — Stand bei Pause

Projekt pausiert am 2026-08-31. Dieses Dokument fasst zusammen, wo die
Animations-Serie steht, damit eine neue Session nahtlos weitermachen kann.

## Herkunft

Ausgangspunkt: Analyse-Auftrag zur Xiaomi-Musik-App/HyperOS-Design-Sprache,
daraus ein Bericht mit 5 Animations-Empfehlungen für Mello, priorisiert nach
Aufwand/Wirkung. Punkte 1+2 sind umgesetzt, Punkt 3 ist im Design fertig
abgestimmt, aber **noch nicht implementiert**. Punkte 4+5 sind offen.

## Status je Punkt

### ✅ Punkt 1 — Staggered List-Enter-Animation (fertig, gemerged-bereit)
`EinblendItem`-Widget (`lib/shared/einblend_item.dart`), eingebunden in
`song_list.dart`/`artist_list.dart`. Fertig, getestet, committet+gepusht auf
Branch `fix/tinker-feedback` (im Worktree `~/mello-dev/app`). Noch nicht in
`main` gemerged.

### ✅ Punkt 2 — Vollbild-Player als Live-Blur-Overlay (fertig, gepusht)
NowPlayingScreen von Navigator-Route zu persistentem Overlay in HomeShell
umgebaut (`PlayerExpansionController`, Live-Blur/Cover-Interpolation während
der Wischgeste). Vollständig umgesetzt (10-Task-Plan + 3 Bugfixes aus dem
finalen Review), 626 Tests grün, `flutter analyze` sauber.

- **Branch:** `feature/blur-oeffnen-transition` (Basis: `fix/tinker-feedback`)
- **Worktree:** `~/mello-dev/worktrees/blur-transition` (dieser hier)
- **Gepusht**, PR noch nicht erstellt/gemerged:
  https://git.baka-net.de/dustin/Melo/pulls/new/feature/blur-oeffnen-transition
- **Spec:** `docs/superpowers/specs/2026-08-29-blur-oeffnen-transition-design.md`
- **Plan:** `docs/superpowers/plans/2026-08-29-blur-oeffnen-transition.md`
- Durchlief ein Adversarial-Review-Panel (Budget-Mode, 3 Reviewer) vor der
  Umsetzung — fand einen echten P0 (falsches `AnimatedBuilder.child`-Muster).
  Ein zweites Review NACH der Umsetzung, vor dem Push, fand nochmal 3 echte
  Bugs (Provider-Scope-Crash bei per `Navigator.push` geöffneten Screens,
  RenderFlex-Overflow während der Öffnen-Geste, asymmetrischer
  `dragEnd`-Bug) — alle behoben, siehe Commit-History auf dem Branch.
- **Wichtige Lektion für künftige Overlay-artige Provider:** Ein
  `ChangeNotifierProvider`, der nur innerhalb eines Screens (nicht oberhalb
  des Navigators) bereitgestellt wird, ist für per `Navigator.push` geöffnete
  Screens unsichtbar (die sind Geschwister im selben Navigator/Overlay,
  keine Nachfahren). `PlayerExpansionController` sitzt deshalb jetzt in
  `MeloApp`s `MultiProvider` (`lib/main.dart`), nicht in `HomeShell`.

### 🔜 Punkt 3 — Karaoke-Glow in der Songtext-Ansicht (Design fertig, NICHT umgesetzt)
**Nächster Schritt beim Wiederaufnehmen.** Brainstorming abgeschlossen,
Design mit Dustin abgestimmt und freigegeben — direkt umsetzbar ohne erneute
Rückfrage:

- **Datei:** `lib/player/now_playing_screen.dart`, Klasse `_Mitlaufend`
  (aktuell Zeile ~759-810 auf diesem Branch), nur der `AnimatedDefaultTextStyle`
  darin (~Zeile 793-800).
- **Änderung:**
  - `style:` bekommt zusätzlich `shadows:`, animiert über den bestehenden
    `AnimatedDefaultTextStyle`-Mechanismus (kein neuer Controller nötig,
    `TextStyle.lerp` interpoliert `shadows` automatisch):
    - Inaktive Zeile: `shadows: const []`
    - Aktive Zeile: `shadows: [Shadow(color: MeloTheme.red.withValues(alpha: 0.55), blurRadius: 10)]`
  - Textfarbe bleibt wie bisher (`Colors.white`/`MeloTheme.text3`) — bewusst
    **kein** rot eingefärbter Text (Kontrast/Lesbarkeit auf dunklem Grund),
    stattdessen weißer Text mit rotem Glow dahinter ("Spotlight"-Effekt).
    Diese Frage wurde Dustin explizit gestellt, Antwort: Glow statt
    Rot-Einfärbung.
  - `duration:` von `MeloMotion.fast` (120ms) auf `MeloMotion.normal` (220ms)
    korrigiert — laut `theme.dart`s eigener Doku ist `fast` für
    Touch-Feedback gedacht, ein Zeilenwechsel ist aber ein Inhalts-Wechsel
    (`normal`). Passt auch besser zum "fließenden" Karaoke-Gefühl.
- **Testing:** bestehenden Widget-Test für `_Mitlaufend`/`_LyricsSheet`
  (falls vorhanden) auf den neuen `shadows`-Wert prüfen; neuer Test bestätigt
  aktive Zeile hat `MeloTheme.red`-farbenen Schatten, inaktive `shadows: []`.
- **Workflow ab hier:** TDD-Umsetzung (bounded, kein Plan-Dokument nötig) →
  `@code-reviewer`-Skill (`/code-review`) vor dem Commit → committen+pushen
  auf `feature/blur-oeffnen-transition` (baut direkt auf Punkt 2 auf, gleiche
  Datei).

### ⬜ Punkt 4 — Advanced-Blur-Kopplung am Farbverlauf-Hintergrund (offen)
Aus dem ursprünglichen Bericht: `_CoverGrund`s Farbverlauf-Hintergrund
zusätzlich leicht auf Wisch-Distanz reagieren lassen (Blur-Radius steigt
beim Öffnen/Schließen). Noch nicht brainstormed/geplant. Mittlerer Aufwand,
baut auf Punkt 2s `progress`-Wert auf (`PlayerExpansionController`).

### ⬜ Punkt 5 — Equalizer-Visualizer (offen, niedrige Priorität)
Spektrum-Visualizer in `equalizer_screen.dart`, analog zu Xiaomis
Musik-App. Braucht Audio-Frequenzanalyse (aktuell nicht vorhanden) —
deutlich höherer Aufwand, im ursprünglichen Bericht selbst als
"nice-to-have, niedrige Priorität" eingestuft. Noch nicht brainstormed.

## Wichtige Rahmenbedingungen fürs Wiederaufnehmen

- **Worktree-Disziplin:** `~/mello-dev/app` ist ein GETEILTER Worktree
  (andere Session, aktuell "Hermes"/`mello-dev-80`, arbeitet dort an
  YouTube-Gast-Zugang o.ä.) — vor jedem `git`-Befehl dort `git status`
  prüfen, nicht blind committen. Für neue, eigenständige Punkte (4/5) einen
  eigenen Worktree anlegen (`git worktree add -b <branch> ~/mello-dev/worktrees/<name> <basis>`),
  wie bei Punkt 2 geschehen.
- **Flutter-Binary:** IMMER `/home/dustin/development/flutter/bin/flutter`
  verwenden, NICHT das über PATH auffindbare Snap-`flutter` — letzteres
  wirft "Invalid kernel binary format version" (Toolchain-Mismatch mit den
  gecachten Native-Hooks).
- **Pläne/fertige Designs gehen an Hermes** (Peer-Session `mello-dev-80`),
  nicht direkt an Dustin im Chat — Hermes bespricht mit Dustin und gibt dann
  die Freigabe zurück. Ausnahme: reine Werkzeug-/Ziel-Klärungen.
- **Skill-Workflow laut Projekt-CLAUDE.md:** brainstorming → planning (nur
  bei Architectural-Einstufung) → agent-review-panel → TDD → Debugging.
  Für Punkt 2 wurde ein Budget-Mode-Adversarial-Panel genutzt (3 Reviewer:
  Code-Quality-Auditor, Feasibility-Analyst, Devil's Advocate + Synthese
  ohne separaten Richter-Agent, da die Befunde stark konvergent/eindeutig
  waren) — hat sich gelohnt, fand echte Bugs vor UND nach der Umsetzung.
- **Subagent-Profile aktiv nutzen:** `@melo-specialist` für alle
  App-Änderungen (nicht general-purpose).