# Todolist exhaustive — Frontend stable sans régressions

**Objectif :** Atteindre un frontend stable, sans régressions, avec une base backend solide.  
**Stratégie :** Backend d’abord (API stable, auth, validation), puis frontend (tests, UX, dette).

**Légende :** P0 = bloquant | P1 = important avant prod | P2 = consolidation | P3 = long terme  
**Effort :** S < 1h | M 1–4h | L 4h–1j | XL > 1j

---

## Partie A — Backend d’abord (base solide pour le frontend)

### A1. Sécurité backend (P0) — à faire avant de stabiliser le front

- [ ] **A1.1** Vérifier l’historique git pour secrets : `git log -p -- .env veza-backend-api/.env veza-stream-server/.env apps/web/.env*` (S)
- [ ] **A1.2** Si secrets committés : rotation JWT_SECRET, DB_PASSWORD, RABBITMQ_URL, REDIS_URL ; invalider tokens/sessions (M)
- [ ] **A1.3** Confirmer que `.env`, `veza-*/.env`, `apps/web/.env.local` sont dans `.gitignore` (S)
- [ ] **A1.4** Chat server — supprimer le JWT fallback qui crée un user "user" si absent en DB ; rejeter la connexion (fichier : `veza-chat-server`, flow JWT/auth) (M)
- [ ] **A1.5** Backend Go — rejeter le refresh token si l’utilisateur n’existe plus en DB (handler refresh token) (S)
- [ ] **A1.6** Pagination — bounds checking : `page >= 1`, `limit` entre 1 et 100 (ou max défini) dans :
  - [ ] `veza-backend-api` : `playlist_handler.go` (~l.145)
  - [ ] `veza-backend-api` : `profile_handler.go` (~l.205)
  - [ ] `veza-backend-api` : `track/handler.go` (~l.814)
  - Interdire `page < 1`, `limit > 100` et retourner 400 avec message clair (M)

### A2. API & contrats backend (P1) — pour éviter 404 / incohérences front

- [ ] **A2.1** Documenter ou implémenter les endpoints manquants pour :
  - [ ] Wishlist / panier (marketplace) : soit implémenter, soit retourner 501 + message (L)
  - [ ] Social groups : endpoint création de groupe (ou désactiver côté front) (M)
- [ ] **A2.2** Aligner search : décider du contrat (ex. `/api/v1/search` vs `/tracks/search`, `/playlists/search`, `/users/search`) et documenter dans un fichier API.md (M)
- [ ] **A2.3** Healthcheck : dans `Dockerfile.production` (backend), utiliser le path réel `/api/v1/health` (ou celui exposé par l’API) au lieu de `/health` (S)
- [ ] **A2.4** Remplacer ou désactiver `go-clamd` (abandonné) dans `upload_validator.go` ; si désactivé, documenter et gérer proprement l’absence de scan (M)

### A3. Services Rust (P1)

- [ ] **A3.1** Redis : aligner versions entre `veza-chat-server` (0.32) et `veza-stream-server` (0.27) dans les `Cargo.toml` (S)
- [ ] **A3.2** Réduire les tests Rust `#[ignore]` et ajouter tests unitaires sur les chemins critiques (auth, messages) (L)
- [ ] **A3.3** (P2) Échapper le wildcard LIKE dans `message_repository.rs` ~l.563 si la recherche peut contenir `%`/`_` (S)

### A4. Infra & déploiement (P1)

- [ ] **A4.1** Docker-compose dev : supprimer mots de passe en dur ; utiliser variables d’env ou `.env` non committé (S)
- [ ] **A4.2** CD : décommenter et configurer tag / push registry dans `.github/workflows/cd.yml` (M)

---

## Partie B — Frontend : bugs et comportements critiques (P0/P1)

### B1. Auth & 2FA (P0)

- [ ] **B1.1** Corriger le bug 2FA login vs setup dans `TwoFactorVerify.tsx` ~l.47 : appeler le service de **vérification login** 2FA, pas celui du setup (M)
- [ ] **B1.2** Typer strictement `login` / `register` dans `services/authService.ts` (l.35, 54) : remplacer les `any` par types dédiés (S)
- [ ] **B1.3** Vérifier que le flux “redirect si déjà authentifié” (LoginPage, RegisterPage) utilise bien `authStore` / `useUser` et ne provoque pas de boucles (S)

### B2. Memory leaks & hygiène (P0/P1)

- [ ] **B2.1** `ChatInput.tsx` ~l.106 : cleanup des `setTimeout` (annuler dans un cleanup useEffect ou utiliser une ref pour éviter updates après unmount) (S)
- [ ] **B2.2** `SocialViewFeedItem.tsx` ~l.25, 31 : idem cleanup `setTimeout` (S)
- [ ] **B2.3** `PostCard.tsx` ~l.94, 101 : idem cleanup `setTimeout` (S)
- [ ] **B2.4** Supprimer les 16 `console.log` dans `components/search/GlobalSearchBar.tsx` (S)
- [ ] **B2.5** Audit global : `rg "console\.(log|debug|info)" apps/web/src --glob "!*.test.*"` et réduire les logs de debug en prod (M)

### B3. Accessibilité (P1 — avant prod)

- [ ] **B3.1** `ChatInput.tsx` : ajouter `aria-label` sur le champ principal (et `aria-describedby` pour les erreurs si possible) (S)
- [ ] **B3.2** `Sidebar.tsx` : ajouter un **focus trap** quand la sidebar est ouverte (mobile) (M)
- [ ] **B3.3** (P2) `MiniPlayer.tsx` : `aria-live` pour annoncer le changement de piste (S)
- [ ] **B3.4** (P2) Sidebar ~l.136 : ne pas mettre de texte pertinent dans un élément `aria-hidden` (S)

---

## Partie C — Frontend : tests et non-régression (P1)

### C1. Tests unitaires / intégration

- [ ] **C1.1** Lister tous les tests en échec : `cd apps/web && npx vitest run 2>&1 | tee vitest_run.txt` puis parser les FAIL (S)
- [ ] **C1.2** Corriger les tests qui échouent par “provider manquant” (QueryClient, Router, Auth) : wrappers communs dans un `test-utils.tsx` (M)
- [ ] **C1.3** Corriger les tests qui échouent par “mock manquant” (MSW, vi.mock) : aligner les mocks sur les vrais contrats API (L)
- [ ] **C1.4** Corriger les tests qui échouent par “texte / i18n” : aligner les assertions sur les chaînes actuelles (EN/FR) ou utiliser des data-testid (M)
- [ ] **C1.5** S’assurer que `waitFor` / `findBy*` sont importés de `@testing-library/react` partout où utilisés (déjà corrigé usePreload, usePlaybackRealtime ; vérifier le reste) (S)
- [ ] **C1.6** Objectif : `npx vitest run` avec **0 échec** (ou &lt; 5% échecs documentés et skippés avec ticket) (L)
- [ ] **C1.7** Supprimer ou implémenter les tests actuellement en `describe.skip` / `it.skip` (voir `vitest.config.ts` exclude list) (M)

### C2. MSW & contrats API

- [ ] **C2.1** Comparer `apps/web/src/mocks/handlers.ts` avec les routes réelles du backend ; lister les 30+ endpoints sans handler (S)
- [ ] **C2.2** Ajouter des handlers MSW pour au moins : auth (login, register, refresh, me), tracks (list, get, search), playlists (list, get, create), user (settings, profile) (L)
- [ ] **C2.3** Aligner le format des réponses MSW avec le wrapper réel (ex. `{ success, data }` ou `data` seul) utilisé par les interceptors (M)
- [ ] **C2.4** (P2) Handlers “gamification” et autres mocks sans backend : soit les câbler à une UI, soit les supprimer pour éviter la confusion (M)

### C3. Storybook & contrat

- [ ] **C3.1** Pour chaque story de composant “feature”, ajouter les états **Loading** (Skeleton), **Error**, **Empty** (voir `STORYBOOK_CONTRACT.md`) (L)
- [ ] **C3.2** Lancer `npm run test:storybook` (build + serve 6007) et corriger les erreurs réseau / console (M)
- [ ] **C3.3** (P2) Réactiver les tests Storybook dans `vitest.config.ts` (lignes ~49–170 commentées) après stabilisation (M)

### C4. E2E & visuel (P2)

- [ ] **C4.1** Scénarios Playwright pour : login, library, lecture d’un track, création playlist, envoi message chat (L)
- [ ] **C4.2** (P2) Visual regression (Playwright ou outil dédié) sur écrans clés (dashboard, player, chat) (M)

---

## Partie D — Frontend : dette structurante (P1/P2)

### D1. Composants & design system

- [ ] **D1.1** Unifier les 3 composants de loading (Spinner, LoadingSpinner, LoadingState) → un seul dans `components/ui/` (M)
- [ ] **D1.2** Migrer les ~6 derniers importeurs de `Modal` vers `Dialog`, puis déprécier/supprimer `modal.tsx` (M)
- [ ] **D1.3** `TrackCard.tsx` ~l.43 : étendre le type `Track` (ex. `like_count?: number`) et supprimer `(track as any).like_count` (S)
- [ ] **D1.4** Réduire les `as unknown as` dans les services : typer correctement ou utiliser des gardes de type (L)
- [ ] **D1.5** Unifier la typographie (SUMI vs Tailwind) et documenter dans `DESIGN_TOKENS.md` (M)
- [ ] **D1.6** Lancer `node scripts/report-arbitrary-values.mjs` et réduire les valeurs arbitraires Tailwind en priorité hors stories (M)

### D2. Fichiers trop longs

- [ ] **D2.1** Découper `interceptors.ts` (~1203 lignes) en modules : CSRF, retry, validation, cache (L)
- [ ] **D2.2** Découper `handlers.ts` MSW (~1606 lignes) par domaine : auth, tracks, playlists, users, etc. (L)

### D3. Structure & code mort

- [ ] **D3.1** Clarifier la règle `components/` vs `features/` : documenter dans un CONTRIBUTING ou déplacer les composants feature (admin, social, studio, settings) vers `features/` (M)
- [ ] **D3.2** Studio : soit exposer une route `/studio` et brancher le backend, soit archiver/supprimer les ~76 fichiers dans `components/studio/` (L)
- [ ] **D3.3** (P2) Si `packages/design-system` existe et n’est pas utilisé : le supprimer du workspace ou le brancher (S)

### D4. Performance

- [ ] **D4.1** `DashboardPage` : mémoïser les tableaux et callbacks (l.66–71, 131–164, 300–304) avec `useMemo` / `useCallback` (S)

---

## Partie E — Features fantômes & cohérence produit (P1/P2)

### E1. Routes & features

- [ ] **E1.1** Décider du sort des 5 routes “Coming Soon” (gear, live, education, queue, developer) : les cacher de la nav jusqu’à parité backend, ou les retirer de la config de routes (M)
- [ ] **E1.2** Marketplace (wishlist, panier, paiement) : soit implémenter les endpoints, soit masquer les écrans en prod et gérer l’erreur (message clair, pas de crash 404) (M)
- [ ] **E1.3** Social groups : `CreateGroupModal` appelle un endpoint inexistant ; soit ajouter l’endpoint, soit désactiver la création et afficher un message (M)
- [ ] **E1.4** Documenter ou implémenter un mécanisme de feature flags (env ou backend) (M)

### E2. Cohérence front/back

- [ ] **E2.1** Aligner le search frontend avec les endpoints backend (voir A2.2) (M)
- [ ] **E2.2** (P2/P3) Tables DB sans code (contests, contest_*, equipment, hardware_sales) : décider migration/usage ou retrait du schéma (L)

---

## Partie F — Qualité & maturité (P2/P3)

### F1. TypeScript & hygiène

- [ ] **F1.1** (P2) Activer `noUncheckedIndexedAccess` dans `tsconfig` et corriger les erreurs (ou traiter par sous-ensemble de fichiers) (L)
- [ ] **F1.2** Traiter ou tracker les TODO/FIXME critiques restants (au moins ceux liés sécurité/auth) (M)

### F2. Docs & ADR

- [ ] **F2.1** Réduire le bruit dans `docs/` : fusionner les 55+ fichiers d’audit en CHANGELOG / KNOWN_ISSUES ou déplacer dans `docs/archive/` (M)
- [ ] **F2.2** (P3) ADR pour auth, state (Zustand + React Query), design system (SUMI/Tailwind) (M)

### F3. UX & perf (P2)

- [ ] **F3.1** aria-live pour le player et les notifications (contenu dynamique pour lecteurs d’écran) (S)
- [ ] **F3.2** Images : srcset, WebP/AVIF, lazy loading où pertinent (M)
- [ ] **F3.3** Code splitting : séparer gros chunks (framer-motion, axios, DOMPurify) dans `vite.config.ts` si nécessaire (M)

---

## Partie G — Base de données & migrations (P2/P3)

- [ ] **G1** Migration UUID : `001_migrate_ids_to_uuid_up.sql` — soit compléter la migration PK/FK, soit documenter l’état et le plan (L)
- [ ] **G2** (P3) Nettoyer les tables fantômes (contests, equipment, etc.) ou les brancher (M)

---

## Partie H — Ordre d’exécution recommandé

### Phase 1 — Backend solide (avant de tout stabiliser le front)

1. A1.1 → A1.3 (secrets & gitignore)  
2. A1.4 → A1.6 (auth chat, refresh, pagination)  
3. A2.1 → A2.4 (API, healthcheck, go-clamd)  
4. A3.1 (Redis aligné)  
5. A4.1 → A4.2 (Docker, CD)

### Phase 2 — Frontend critique (P0/P1)

6. B1.1 → B1.3 (2FA, typage auth)  
7. B2.1 → B2.5 (setTimeout, console.log)  
8. B3.1 → B3.2 (aria-label ChatInput, focus trap Sidebar)

### Phase 3 — Tests et non-régression

9. C1.1 → C1.7 (corriger tous les tests en échec)  
10. C2.1 → C2.3 (MSW handlers et format)  
11. C3.1 → C3.2 (Storybook Loading/Error/Empty, test:storybook)  
12. C4.1 (E2E parcours critiques)

### Phase 4 — Dette et structure

13. D1.1 → D1.4 (loading, Modal→Dialog, Track type, as unknown)  
14. D2.1 → D2.2 (découper interceptors, handlers)  
15. D3.1 → D3.2 (components vs features, studio)  
16. D4.1 (Dashboard mémo)

### Phase 5 — Produit et cohérence

17. E1.1 → E1.4 (routes Coming Soon, marketplace, groups, feature flags)  
18. E2.1 (search aligné)

### Phase 6 — Maturité (P2/P3)

19. F1.2, F2.1 (TODO/FIXME, docs)  
20. F3.1 (aria-live)  
21. G1 (migration UUID doc ou complétion)

---

## Checklist “Frontend stable sans régression” (validation finale)

- [ ] `npx vitest run` : 0 échec (ou &lt; 5% skippés avec ticket)  
- [ ] `npm run build` : succès sans warning bloquant  
- [ ] `npx tsc --noEmit` : 0 erreur  
- [ ] `npm run test:storybook` : 0 erreur après build + serve 6007  
- [ ] Aucun `console.log` / debug en prod (build sans stub)  
- [ ] Skip link + aria-label ChatInput + focus trap Sidebar en place  
- [ ] 2FA login corrigé ; pagination backend bornée  
- [ ] Routes “Coming Soon” soit cachées soit retirées ; pas de crash 404 sur marketplace/groups  
- [ ] MSW handlers couvrant au moins auth, tracks, playlists, user settings pour dev/Storybook  

---

*Document dérivé de `STABLE_STATE_TODOLIST.md` et des audits frontend/monorepo. À mettre à jour au fur et à mesure.*