diff --git a/ANIMATION_STAND.md b/ANIMATION_STAND.md new file mode 100644 index 0000000..62e2eff --- /dev/null +++ b/ANIMATION_STAND.md @@ -0,0 +1,111 @@ +# 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 ~/mello-dev/worktrees/ `), + 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).