vtuber-awards/docs/dashboard-plan.md

Dashboard & Admin-Panel — Analyse + Plan

Status: Umgesetzt. Dieses Dokument beschreibt die Analyse, die umgesetzte Dashboard-Readiness-Ausrichtung und die noch bewusst zurückgestellte Phase 2. Das Dashboard ist saisonbezogen, bleibt read-only und verlinkt in die Fachseiten.

---

0. Wichtigster Befund vorweg: gespaltene Datenquelle

Das Dashboard mischt zwei verschiedene Saison-Quellen, und das ist die Wurzel der meisten Probleme:

Sektion	Datenquelle	Reagiert auf Jahr-Wechsel im Toolbar?
Metric-Cards (Nominierungen, Stimmen…)	store.admin.metrics → Backend /dashboard → immer IsCurrent-Saison	❌ Nein
Top-Kategorien, Aktivitäten	store.admin (gleiche Quelle)	❌ Nein
Jahreszahlen, Checks, Priority, Toolbar-Stats	store.adminSeasonDetail → ausgewählte Saison	✅ Ja

Wenn der Host im Toolbar das Jahr wechselt, ändern sich die Hälfte der Kacheln nicht. „Stimmen gesamt" (Hero) und „Stimmen gesamt" (Jahreszahlen) können unterschiedliche Werte zeigen. Das muss vereinheitlicht werden, bevor irgendetwas Neues draufkommt.

Umgesetzt: Die ausgewählte Saison (adminSeasonDetail) ist die führende Dashboard-Quelle. /api/admin/dashboard akzeptiert optional seasonId; ohne seasonId bleibt das alte IsCurrent-Verhalten kompatibel.

---

1. Ist-Zustand: bestehende Komponenten

AdminDashboardView.vue — Orchestrator, lädt alles aus useAdminDashboardOverview() und arrangiert 6 Sektionen in Grids. Sauber, dünn, gut.

AdminPageHeader — nur Eyebrow „Dashboard" + Icon. Keine Begrüßung, kein Kontext.

AdminSeasonToolbar — Jahr-Auswahl + Phasen-Pill (nur Text) + 3 Mini-Stats (Kategorien/Kandidaten/Reviews). Zeigt isCurrent als „Öffentlich sichtbar". Es fehlen alle Datumsangaben (Nominierungsstart, Voting-Ende, Show-Termin), obwohl sie in adminSeasonDetail vorliegen.

AdminDashboardHeroSection — „Live-Lage" als generierter Fließband-Satz + Status-Badge

• Metric-Cards mit Quelle: VoteEntries-Tabelle. Die Quell-Labels sind entwicklersprachlich, nicht host-tauglich.

AdminDashboardPrioritySection („Was zuerst?") — 4 Quick-Links (Reviews, Risiko, Kategorien, Kandidaten) mit Permission-Filter. Gut gebaut. Aber statisch: zeigt immer dieselben 4, unabhängig von der Phase.

AdminDashboardChecksSection — 3 Betriebs-Checks (Kategorien ohne Kandidaten, Review-Backlog, Risk Flags) mit Deep-Links und ok/warn/danger. Stärkste Sektion, weil handlungsorientiert.

AdminDashboardYearTotalsSection — 6 reine Zahlen. Überschneidet sich inhaltlich stark mit den Hero-Metric-Cards (Nominierungen, Stimmen, Kategorien, Reviews, Risiko tauchen doppelt auf).

AdminDashboardTopCategoriesSection — Top 5 nach Stimmen mit Balken. Während der Nominierungsphase nutzlos (Stimmen = 0).

AdminDashboardActivitySection — hart auf 3 Audit-Einträge gedeckelt, kein Link zum vollen Audit-Log.

---

2. Personas: was Host vs. Admin wirklich brauchen

Der Host (Jayuhime) denkt in der Timeline der Show, nicht in Tabellen:

• „Wo stehen wir gerade, und wie lange noch?" (Countdown bis Phasen-Ende / Show)
• „Stimmt die gespeicherte Phase mit dem Zeitplan überein?"
• „Ist die öffentliche Seite bereit? Stream-Link gesetzt, keine Wartung an?"
• „Sind wir bereit, Gewinner zu verkünden?"
• „Was zeigt die Community gerade?" (Beteiligung wächst)

Der Admin / das Team denkt operativ:

• „Was liegt in meiner Queue?" (Reviews, Risk, Clips)
• „Wo klemmt es?" (leere Kategorien, Backlog-Verteilung)
• „Wer hat zuletzt was geändert?" (Audit)

Das aktuelle Dashboard bedient fast nur die Admin-Sicht. Die Host-Sicht (Timeline, Bereitschaft, Public-Health) fehlt fast komplett.

---

3. Verbesserungswürdig (bestehende Komponenten)

1. Datenquelle vereinheitlichen (siehe §0) — Metrics/Top-Kategorien/Aktivitäten auf die gewählte Saison umstellen. Empfehlung: gewählte Saison als einzige Quelle.
2. Quell-Labels host-freundlich machen — „Quelle: VoteEntries-Tabelle" → weg damit oder „Aktualisiert aus dem Live-Voting".
3. Redundanz Hero ↔ Jahreszahlen auflösen — eine der beiden Zahlen-Wände streichen; Hero = Live/Aktion, Jahreszahlen = Summen.
4. Top-Kategorien phasenabhängig — in Nominierungsphase „Top nach Nominierungen" statt nach Stimmen zeigen.
5. Priority-Liste phasenabhängig priorisieren — in Show-Vorbereitung „Gewinner setzen" nach oben, in Nominierung „Reviews" nach oben.
6. Aktivitäten — auf 5–6 erhöhen + „Alles ansehen"-Link zum Audit-Log.

---

4. Was fehlt — neue Komponenten (mit Aufbau)

4.1 AdminDashboardTimelineStrip.vue — Phasen-Timeline mit Countdown

• Wofür: Die zentrale Host-Frage „Wo stehen wir, wie lange noch?" auf einen Blick.
• Was es macht: Zeigt die 4 Phasen (Nominierung → Voting → Aufbereitung → Show) als horizontalen Strip mit Datumsspannen; die aktive Phase ist hervorgehoben; ein großer Countdown zeigt „noch X Tage bis Voting-Ende" bzw. „bis zur Show". Warnt sichtbar, wenn die gespeicherte Phase vom Zeitplan abweicht (die Logik existiert bereits in AdminSeasonPhaseSwitcher als autoPhase — wiederverwenden).
• Aufbau: Eigene Computed in useAdminDashboardOverview (timelinePhases, activeCountdown, phaseMismatch) gespeist aus adminSeasonDetail.*StartsAt/*EndsAt/showDate; Datums-/Zustandsmapping aus Common/SeasonMappings.cs (ResolveTimelineState) spiegeln. Reine Props-Komponente, <Card> mit 4 Phasen-Segmenten (analog zu HomeTimelineSection der Landingpage, gleiche Farb-Token). Optional Deep-Link zu /admin/years für Phasenwechsel.

4.2 AdminDashboardReadinessCard.vue — Show-Bereitschaft

• Wofür: „Sind wir bereit, live zu gehen / Gewinner zu verkünden?"
• Was es macht: Checkliste aus votingWorkspace.summary: votedSubcategories / readySubcategories / winnerSetSubcategories vs. totalSubcategories, plus „Show-Datum gesetzt", „Stream-URL gesetzt", „alle Gewinner gesetzt". Ein Fortschrittsring „12 / 14 Unterkategorien gewinnerbereit".
• Aufbau: Computed readinessItems (Label, erfüllt-bool, Deep-Link). Quelle: adminSeasonDetail.votingWorkspace.summary (bereits vorhanden, heute ungenutzt im Dashboard!) + showDate/Stream-Banner-Link. <Card> mit Fortschrittsbalken + Liste mit Häkchen/Warnungen. Nur sichtbar/relevant ab Voting-Phase.

4.3 AdminDashboardPublicHealthCard.vue — Öffentliche Seite

• Wofür: Der Host muss sehen, was die Community sieht.
• Was es macht: Ampel für: Saison öffentlich (isCurrent), Wartungsmodus an/aus, Stream-Link vorhanden, Pflicht-Content (Impressum/Datenschutz) gepflegt. Plus „Landingpage ansehen"-Button.
• Aufbau: Zieht aus adminOptionalFeatureSettings / Operational-Settings (Wartung)
  • adminSiteSettings (Content-Lücken). <Card> mit Status-Zeilen, Deep-Links nach /admin/content und /admin/settings/access. Permission-gated auf content/settings.

4.4 AdminDashboardQueueCard.vue — vereinte Team-Queue

• Wofür: Admins/Reviewer wollen „meine offenen Aufgaben" inkl. Clips, die heute komplett fehlen.
• Was es macht: Zählt Reviews offen, Risk offen, Clips pending in einer Karte mit je Deep-Link und Badge. Ersetzt/erweitert die heutige Priority-Sektion um den Clip-Strang.
• Aufbau: Computed queueItems aus pendingNominations.length, getRiskMetricValue, clipSubmissions.filter(pending); jeweils Permission-gated (Clip nur wenn clipAdminMenuVisible). Listen-<Card> wie AdminDashboardPrioritySection, wiederverwendbares Item-Markup.

4.5 AdminDashboardParticipationTrend.vue (Phase 2) — Beteiligungsverlauf

• Wofür: „Wächst die Beteiligung?" — Motivation/Story für den Host.
• Was es macht: Mini-Sparkline Nominierungen/Stimmen über die letzten Tage.
• Aufbau: Benötigt neues Backend (Zeitreihe, heute liefert /dashboard nur Totals). Daher klar als Phase-2 markieren, nicht im ersten Wurf.

---

5. Was bewusst NICHT ins Dashboard kommt

• Tiefen-Analytics / Kategorie-Health-Matrix → bleibt in /admin/analytics (existiert dort bereits vollständig). Dashboard nur verlinken.
• Voll-Editierbarkeit (Phasen umschalten, Texte ändern, Gewinner setzen) → bleibt in den Fachseiten. Dashboard ist read + deep-link, kein Editor. Ausnahme: höchstens ein „Phase aktivieren"-Shortcut.
• Volles Audit-Log mit Filtern → bleibt in /admin/users-logs. Dashboard zeigt nur die letzten 5 + Link.
• Team-/Rollenverwaltung, Tracking-Rules, DB-Checks → reine Settings, kein Tagesgeschäft.
• Echtzeit-Sparkline im ersten Release (Backend fehlt).

---

6. Empfohlene Ziel-Struktur (Reihenfolge = Sichtbarkeit)

1. PageHeader  +  Begrüßung („Hi Jayuhime") + Datum
2. SeasonToolbar  (+ Datumsspannen ergänzen)
3. TimelineStrip + Countdown            ← NEU, Host-Anker
4. [ Hero/Live-Lage  |  Queue-Card ]    ← Queue NEU (inkl. Clips)
5. ChecksSection  (beibehalten)
6. [ ReadinessCard | PublicHealthCard ] ← beide NEU
7. [ YearTotals (entschlackt) | TopCategories (phasen-aware) ]
8. ActivitySection (5 Einträge + Link)

Reihenfolge der Umsetzung:

1. Datenquelle vereinheitlichen (§0) — Fundament, blockiert alles andere.
2. TimelineStrip + Toolbar-Datumsangaben — größter Host-Mehrwert, Daten schon da.
3. Queue-Card (mit Clips) + Readiness-Card — füllt die echten Lücken, Daten schon da.
4. PublicHealth-Card — kleiner, aber wertvoll.
5. Entschlacken (Redundanz Hero/Jahreszahlen, phasen-aware Top-Kategorien).
6. Phase 2: Beteiligungs-Sparkline (braucht Backend-Zeitreihe).

Umgesetzt: TimelineStrip, Readiness und Queue nutzen bestehende adminSeasonDetail-Daten. Der Dashboard-Endpoint ist zusätzlich saisonfähig, damit Metriken und Top-Kategorien beim Jahrwechsel konsistent bleiben.