veza/sub_task_agents/FRONTEND_STABLE_TODOLIST_EXHAUSTIVE.md

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 < 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 < 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.