Update release notes and deploy workspace
This commit is contained in:
@@ -13,6 +13,7 @@ For workflow details, see [workflow.md](workflow.md). For code standards, see
|
||||
- [ ] Relevant docs and existing implementation were read.
|
||||
- [ ] Frontend/backend contract and source of truth are identified.
|
||||
- [ ] Permission, workflow, empty, loading, error, and disabled states are handled.
|
||||
- [ ] Large touched files were checked against [maintainability-backlog.md](maintainability-backlog.md).
|
||||
- [ ] Docs are updated when behavior, setup, or architecture changed.
|
||||
- [ ] Frontend build, backend build, and targeted manual checks are run.
|
||||
|
||||
|
||||
@@ -136,6 +136,8 @@ settings, deployment, and responsive UI changes.
|
||||
| [workflow.md](workflow.md) | Day-to-day delivery flow. |
|
||||
| [branching.md](branching.md) | Branch and commit policy. |
|
||||
| [release-process.md](release-process.md) | Release, deploy, smoke test, and rollback expectations. |
|
||||
| [end-to-end-smoke.md](end-to-end-smoke.md) | Repeatable local/browser smoke path for nomination, voting, winners, and permissions. |
|
||||
| [maintainability-backlog.md](maintainability-backlog.md) | Large-file and boundary risks to reduce in focused refactor passes. |
|
||||
| [../DESIGN.md](../DESIGN.md) | Product visual language and UI implementation guidance. |
|
||||
| [workflow-feedback-plan.md](workflow-feedback-plan.md) | Product feedback implementation plan for awards workflow improvements. |
|
||||
|
||||
|
||||
@@ -0,0 +1,191 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,136 @@
|
||||
# End-To-End Smoke Standard
|
||||
|
||||
This checklist defines the repeatable smoke path for the core awards workflow.
|
||||
It complements the build checks in `docs/workflow.md` and should be used after
|
||||
changes to nominations, categories, candidates, voting, winners, permissions,
|
||||
or public landing-page workflow.
|
||||
|
||||
## Scope
|
||||
|
||||
Core workflow:
|
||||
|
||||
```text
|
||||
Nomination -> Admin preparation -> Candidate -> Voting -> Winner preparation -> Winner/archive
|
||||
```
|
||||
|
||||
Public nomination is grouped by main category (`Category.GroupName`). Voting and
|
||||
winners stay on concrete subcategory `Category` rows.
|
||||
|
||||
## Automated Local Smoke
|
||||
|
||||
Run this against a local backend. If an admin session token is available, the
|
||||
script also checks admin endpoints.
|
||||
|
||||
```bash
|
||||
scripts/smoke-local.sh
|
||||
ADMIN_SESSION_TOKEN=<token> scripts/smoke-local.sh
|
||||
```
|
||||
|
||||
Expected local defaults:
|
||||
|
||||
- Backend: `http://127.0.0.1:5084`
|
||||
- Frontend: `http://127.0.0.1:5173`
|
||||
- Database: PostgreSQL on `localhost:5433`
|
||||
|
||||
The script checks:
|
||||
|
||||
- `/api/health`
|
||||
- `/api/health/database`
|
||||
- `/api/public/overview`
|
||||
- current-season category structure
|
||||
- legacy parent labels are not exposed by the public category endpoint
|
||||
- optional admin season/team endpoints when `ADMIN_SESSION_TOKEN` is set
|
||||
|
||||
## Manual Browser Smoke
|
||||
|
||||
Use the local frontend with backend running as a pair.
|
||||
|
||||
### Public Nomination
|
||||
|
||||
- Open the public landing page.
|
||||
- Start nomination.
|
||||
- Confirm only main categories are selectable.
|
||||
- Submit 1, 2, and 3 links in one main category.
|
||||
- Confirm duplicate links in the same main category are blocked.
|
||||
- Confirm empty categories can be skipped.
|
||||
- Confirm Twitch links get tracker status when possible.
|
||||
- Confirm non-Twitch links are accepted and need manual tier choice.
|
||||
|
||||
### Admin Review And Candidate Preparation
|
||||
|
||||
- Open `/admin/nominations`.
|
||||
- Confirm nominations are grouped by main category and streamer identity.
|
||||
- Confirm the tracker tier suggestion is visible when available.
|
||||
- Promote a Twitch nomination using the suggested tier.
|
||||
- Promote a non-Twitch nomination with manual tier override.
|
||||
- Confirm candidate `NominationTally` reflects grouped nominations.
|
||||
- Confirm candidate clip metadata requires a link when winner clip is mandatory.
|
||||
|
||||
### Voting
|
||||
|
||||
- Open the public voting modal.
|
||||
- Confirm categories show as main category with subcategories.
|
||||
- Switch category and subcategory without the modal jumping or resizing.
|
||||
- Vote in at least one subcategory.
|
||||
- Save vote again and confirm this is treated as vote editing.
|
||||
- Confirm missing-vote warning appears before completion when applicable.
|
||||
|
||||
### Admin Voting Workspace
|
||||
|
||||
- Open `/admin/voting`.
|
||||
- Confirm the page appears only for roles with `voting`, `analytics`, or
|
||||
`winners` effective access.
|
||||
- Confirm the tree groups by main category, with subcategories as children.
|
||||
- Confirm leaderboard order defaults to most votes first.
|
||||
- Confirm vote count, candidate count, open reviews, clip status, readiness,
|
||||
ties or close races, and soft "few nominators" warnings are visible.
|
||||
- Use quick links to candidates, nominations/review, and winners.
|
||||
|
||||
### Winners And Archive
|
||||
|
||||
- Open `/admin/winners`.
|
||||
- Confirm it focuses on final winner assignment and landing-page release readiness.
|
||||
- Set or clear a winner in a subcategory.
|
||||
- Confirm `max. 1x winner` identity guard is visible/enforced.
|
||||
- Confirm missing winner clip blocks or warns according to workflow settings.
|
||||
- Confirm publishing is blocked while winners, reviews, or blocking workflow
|
||||
rules are incomplete.
|
||||
- Publish the year and confirm current winners appear on the landing page while
|
||||
the previous landing-page winner year moves into the archive list.
|
||||
- Confirm current landing-page winners are not listed as an archive year at the
|
||||
same time.
|
||||
- Open the public archive modal and confirm winner clip/video embeds render.
|
||||
|
||||
### Permissions
|
||||
|
||||
- Open `/admin/team`.
|
||||
- Confirm permission catalog includes current admin pages:
|
||||
Dashboard, Jahre, Nominierungen, Kategorien, Kandidaten, Clips, Landingpage,
|
||||
Risiko, Audit-Log, Analytics, Voting, Gewinner, Einstellungen, Team.
|
||||
- Confirm roles with `analytics` or `winners` still get effective `voting`
|
||||
access for navigation and route guards.
|
||||
- Confirm write actions still fail for read-only organization-team access.
|
||||
|
||||
### Responsive Checks
|
||||
|
||||
Check public voting, admin voting, admin winners, and admin categories at:
|
||||
|
||||
- `360px`
|
||||
- `390px`
|
||||
- `768px`
|
||||
- desktop
|
||||
|
||||
In the browser console:
|
||||
|
||||
```js
|
||||
document.documentElement.scrollWidth <= window.innerWidth
|
||||
```
|
||||
|
||||
The expression must be `true` unless a deliberate horizontal data table is in a
|
||||
contained scroll area.
|
||||
|
||||
## Cleanup
|
||||
|
||||
Temporary local nominations, candidates, votes, clips, and winners may be
|
||||
created for smoke validation. Remove test artifacts before finishing if they
|
||||
would pollute future manual checks.
|
||||
@@ -0,0 +1,59 @@
|
||||
# Maintainability Backlog
|
||||
|
||||
This backlog tracks large-file and boundary risks that should be reduced in
|
||||
small, focused follow-up changes. It is intentionally separate from feature
|
||||
plans so stabilization work does not become a hidden refactor.
|
||||
|
||||
## Current Priority
|
||||
|
||||
1. `Backend/Endpoints/AdminSiteSettingsEndpoints.cs`
|
||||
- Risk: settings, content, operational toggles, OAuth/demo handling, and
|
||||
mapping live in one endpoint file.
|
||||
- Next split: move mapping/snapshot/change-detection helpers into a focused
|
||||
support file or service.
|
||||
|
||||
2. `frontend/src/components/admin/useAdminSeasonManager.ts`
|
||||
- Risk: season forms, phase gateways, readiness facts, dashboard links, and
|
||||
navigation helpers are coupled in one composable.
|
||||
- Next split: extract phase-gateway/readiness builders into a pure
|
||||
TypeScript helper with unit-test-friendly functions.
|
||||
|
||||
3. `frontend/src/components/home/HomeExtrasSection.vue`
|
||||
- Risk: public extras, showact/sponsor presentation, and responsive layout
|
||||
are harder to reason about in one component.
|
||||
- Next split: separate showact, sponsor, and footer/content blocks into
|
||||
focused presentational components.
|
||||
|
||||
4. `Backend/Endpoints/AdminSeasonDetailEndpoints.cs`
|
||||
- Risk: one endpoint assembles categories, nominations, voting workspace,
|
||||
winners, clips, rules, and mappings.
|
||||
- Next split: move voting-workspace assembly into an admin voting service
|
||||
and keep the endpoint as orchestration.
|
||||
|
||||
5. `frontend/src/views/admin/AdminTeamView.vue`
|
||||
- Risk: member table, role matrix, modals, permission explanations, and
|
||||
actions share one route-level view.
|
||||
- Next split: extract the permission matrix and member editor into separate
|
||||
components.
|
||||
|
||||
## Audit Command
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
scripts/file-size-audit.sh
|
||||
```
|
||||
|
||||
Default warning threshold is 500 lines. Override with:
|
||||
|
||||
```bash
|
||||
MAX_LINES=650 scripts/file-size-audit.sh
|
||||
```
|
||||
|
||||
## Refactor Rules
|
||||
|
||||
- Do not combine these refactors with unrelated feature work.
|
||||
- Prefer pure helper extraction before behavior changes.
|
||||
- Keep route-level Vue views thin.
|
||||
- Keep backend endpoint files focused on HTTP shape and orchestration.
|
||||
- Re-run frontend/backend builds after any extraction.
|
||||
@@ -73,7 +73,8 @@ Minimum automated smoke signals:
|
||||
|
||||
Add manual smoke checks for the changed workflow, especially for admin,
|
||||
auth/permissions, voting, nomination, clip review, showact, sponsor, or content
|
||||
management changes.
|
||||
management changes. Use [end-to-end-smoke.md](end-to-end-smoke.md) as the
|
||||
standard core-workflow smoke checklist.
|
||||
|
||||
## Rollback And Recovery
|
||||
|
||||
|
||||
@@ -154,6 +154,7 @@ Ziel: Auswertung und Gewinnerdarstellung folgen den internen Regeln.
|
||||
Umsetzung:
|
||||
|
||||
- Gewinner pro Unterkategorie verwalten.
|
||||
- Gewinner-Speichern bleibt intern; ein separater jahresweiter Freigabe-Button veroeffentlicht Gewinner auf der Landingpage und schiebt den bisherigen Landingpage-Jahrgang ins Archiv.
|
||||
- Guard fuer "eine Person gewinnt maximal ein Mal" einplanen.
|
||||
- Konfigurierbare Regel "Gewinner braucht Clip-Link" einplanen; Standard blockiert Gewinner ohne gepflegte YouTube-/Twitch-Compilation.
|
||||
- Guard oder Warnung fuer "eine Person maximal zwei Mal nominiert" einplanen.
|
||||
@@ -164,6 +165,7 @@ Umsetzung:
|
||||
Akzeptanz:
|
||||
|
||||
- Admins koennen Gewinner nicht versehentlich doppelt vergeben, ohne Warnung oder bewusste Bestaetigung.
|
||||
- Admins koennen ein vollstaendiges Award-Jahr bewusst veroeffentlichen; erst danach ersetzt es den vorherigen Landingpage-Gewinnerjahrgang.
|
||||
- Admins koennen steuern, ob Gewinner ohne Clip-Link blockiert oder nur gewarnt werden.
|
||||
- Archiv zeigt vorhandene Gewinner-Clips eingebettet an und bleibt bei fehlenden Clips stabil.
|
||||
- Countdown ist auf Desktop und Mobile gut lesbar.
|
||||
|
||||
@@ -87,6 +87,10 @@ dotnet build Backend/Backend.csproj --configuration Release
|
||||
git diff --check
|
||||
```
|
||||
|
||||
For core nomination, category, voting, winner, permission, or archive changes,
|
||||
also run the repeatable smoke path in
|
||||
[end-to-end-smoke.md](end-to-end-smoke.md).
|
||||
|
||||
Add targeted validation by risk:
|
||||
|
||||
- API checks for backend behavior;
|
||||
|
||||
Reference in New Issue
Block a user