# Todolist — État stable Veza

**Objectif :** rapprocher l’application d’un état stable, prêt pour la production.  
**Sources :** `FULL_FRONTEND_AUDIT.md`, `FULL_MONOREPO_AUDIT.md` (mise à jour 13/02/2026).

**Légende :**  
- **P0** = bloquant sécurité/stabilité  
- **P1** = important avant prod  
- **P2** = consolidation  
- **P3** = amélioration / long terme  
- **S/M/L/XL** = effort (Small / Medium / Large / XL)

---

## 1. Sécurité (P0)

### Secrets & historique

- [x] **Vérifier l’historique git** pour tout commit de `.env` : `documenté dans docs/SECRETS_VERIFICATION.md`
- [x] Si des secrets ont été committés : aucun secret réel trouvé ; templates supprimés dans ff04c15
- [x] S'assurer que `.env` et `veza-*/\.env` restent bien dans `.gitignore` partout — vérifié

### Auth & contrôle d’accès

- [x] **Chat server — JWT fallback** : supprimer le fallback qui crée un user "user" si l’utilisateur n’existe pas en DB ; rejeter la connexion si user non trouvé (`veza-chat-server`, jwt_manager / auth flow)
- [x] **Rejeter le refresh token** si l’utilisateur n’existe plus en DB (backend Go)
- [x] **Validation des query params (pagination)** : `playlist_handler.go` et `profile_handler.go` (GetTracks, SearchUsers) ont déjà ou ont reçu un bounds checking (page >= 1, limit 1–100). `profile_handler.SearchUsers` corrigé pour retourner 400 au lieu de normaliser.

### Déjà fait (à ne pas refaire)

- ~~SSRF webhook~~ — `IsURLSafe()` dans `webhook_service.go`
- ~~Contrôle d’accès stream~~ — `validate_track_access()` dans `veza-stream-server` (`token_validator.rs`)

---

## 2. Frontend — Urgences (P0 / P1)

### Bugs & comportements critiques

- [x] **Bug 2FA login vs setup** (P0) : flux AuthView corrigé — `AuthViewContent` + `useAuthView` + `LoginForm` : quand login retourne `requires_2fa`, on stocke les credentials et on appelle `completeLogin2FA` (POST /auth/login/2fa) depuis `TwoFactorVerify` onSuccess.
- [x] **Typer `login` / `register`** dans `services/authService.ts` : types explicites `AuthLoginResult` / `AuthRegisterResult` et `Promise<...>`.
- [x] **Cleanup des `setTimeout`** : `ChatInput`, `SocialViewFeedItem`, `PostCard` ont déjà un cleanup dans le `useEffect` (refs + clearTimeout au démontage).

### Logs & hygiène

- [x] **Supprimer les `console.log`** dans GlobalSearchBar : le fichier utilise déjà `logger.debug` / `logger.error` (aucun `console.log` trouvé).

### Accessibilité (WCAG — avant prod)

- [x] **ChatInput** : `aria-label="Type a message"` déjà présent sur l’input — `features/chat/components/ChatInput.tsx`
- [x] **Sidebar mobile** : **focus trap** déjà en place — `FocusTrap` avec `active={sidebarOpen && isMobile}` et `onEscape` dans `components/layout/Sidebar.tsx`
- [ ] (Optionnel P2) MiniPlayer : `aria-live` pour annoncer le changement de piste — `features/player/components/MiniPlayer.tsx`
- [ ] (Optionnel P2) Sidebar ~l.136 : ne pas mettre de texte pertinent dans un élément `aria-hidden`

### Déjà fait

- ~~Skip link~~ — présent dans `App.tsx` (href="#main-content")
- ~~swagger-ui / rollup-plugin-visualizer en prod~~ — en devDependencies

---

## 3. Backend & services Rust (P0 / P1)

### Chat server

- [x] Supprimer le **JWT fallback user** (voir section Sécurité ci-dessus) — déjà conforme.

### Dépendances & cohérence

- [x] **Remplacer `go-clamd`** — déjà fait : `go.mod` utilise `github.com/Lyimmi/go-clamd v1.0.0` (fork maintenu).
- [x] **Redis** : versions déjà alignées — `veza-chat-server` et `veza-stream-server` utilisent tous deux `redis` 0.32.

### Qualité de code / tests

- [ ] Réduire le nombre de tests Rust `#[ignore]` et ajouter des tests unitaires là où c’est critique
- [ ] (P2) Échapper le wildcard LIKE dans `message_repository.rs` ~l.563 si la recherche peut contenir `%`/`_`

---

## 4. Infra, Docker, CI/CD (P1)

### Docker

- [x] **Healthcheck backend** : les deux Dockerfiles (backend) utilisent déjà `http://localhost:8080/api/v1/health`.
- [x] **docker-compose (dev)** : mots de passe via variables (POSTGRES_PASSWORD, RABBITMQ_DEFAULT_PASS) avec défaut devpassword

### CD

- [x] **Activer le pipeline CD** : push configuré (secrets DOCKER_REGISTRY, DOCKER_REGISTRY_USERNAME, DOCKER_REGISTRY_PASSWORD)
- [ ] (P2) Envisager **signature des images Docker** et **SBOM** pour l’intégrité des builds

### Monorepo (P2/P3)

- [ ] (P3) Introduire un orchestrateur (ex. Turborepo) pour builds/tests front + back
- [ ] (P3) Workspace Rust racine (`Cargo.toml` root) pour build/test unifié des services Rust
- [ ] (P3) Workspace Go (`go.work`) si plusieurs modules Go

---

## 5. Frontend — Consolidation (P1 / P2)

### Dette structurante

- [x] **Unifier les composants de loading** : un seul primitif `LoadingSpinner` (`loading-spinner.tsx`) ; `LoadingState` est le wrapper (spinner/inline/skeleton/minimal) qui l’utilise. Aucun composant « Spinner » distinct.
- [x] **Migration Modal → Dialog** : `modal.tsx` supprimé ; `Modal.stories.tsx` et `modal.test.tsx` supprimés ; tests overlay/Escape/close/body scroll ajoutés à `dialog.test.tsx`.
- [x] **Supprimer `(track as any).like_count`** : le type `Track` (player/types) a déjà `like_count?: number` et TrackCard utilise `track.like_count ?? 0`.
- [ ] **Résoudre les ~15 `as unknown as`** dans les services : typer correctement ou utiliser des gardes
- [ ] **Réduire les `console.log`** et autres logs de debug en production (déjà listé GlobalSearchBar ; vérifier le reste)

### Fichiers trop longs

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

### Design system & typo

- [ ] **Unifier la typographie** : soit SUMI uniquement, soit Tailwind uniquement ; documenter le choix (ex. dans DESIGN_TOKENS.md)
- [ ] **Auditer et réduire** les valeurs arbitraires Tailwind en production (script `report-arbitrary-values.mjs`), en priorité hors stories

### Structure du code

- [ ] **Clarifier `components/` vs `features/`** : déplacer les composants feature (admin, social, studio, settings, etc.) vers `features/` ou documenter clairement la règle actuelle
- [ ] **Code mort / studio** : soit exposer une route `/studio` et brancher le backend, soit supprimer ou archiver les ~76 fichiers dans `components/studio/`
- [ ] **Handlers MSW gamification** sans UI : les supprimer ou câbler une UI ; idem pour autres mocks sans backend

### Performance

- [x] **DashboardPage** : `quickActionButtons` est déjà mémoïsé avec `useMemo` ; `QUICK_ACTIONS` et `STATS` sont des constantes module (pas recréées à chaque render).

---

## 6. Tests (P1 / P2)

### Frontend

- [ ] **Corriger les tests en échec** (ordre de grandeur ~42% d’échecs mentionnés) : identifier les tests tracks et autres qui échouent et les stabiliser
- [ ] **Stories** : ajouter les états Loading / Error / Empty aux stories qui en manquent (contrat Storybook)
- [ ] **Réactiver les tests Storybook** dans `vitest.config.ts` (lignes ~49-170 actuellement commentées) après stabilisation
- [ ] **Compléter les mocks MSW** pour les 30+ endpoints backend qui n’ont pas encore de handler (pour dev et Storybook)

### E2E & visuel

- [ ] **E2E Playwright** : ajouter des scénarios pour les parcours critiques (login, library, lecture, playlists, chat)
- [ ] (P2) **CI visuel** : visual regression (Playwright ou outil dédié) pour les écrans clés

### Backend / Rust

- [ ] (P2) Renforcer les tests du chat server et du stream server (réduire `#[ignore]`)

---

## 7. Produit & features (P1 / P2)

### Features fantômes

- [ ] **Décider du sort des 5 routes Coming Soon** (gear, live, education, queue, developer) :  
  - soit les cacher (pas dans la nav) jusqu’à parité backend,  
  - soit les supprimer de la config de routes et de la nav
- [ ] **Marketplace / commerce** : wishlist, panier, paiement — soit implémenter les endpoints backend, soit désactiver/masquer les écrans en prod et gérer proprement l’erreur (pas de crash 404)
- [ ] **Social groups** : `CreateGroupModal` appelle un endpoint inexistant ; soit ajouter l’endpoint, soit désactiver la création de groupes et afficher un message clair
- [ ] **Feature flags** : documenter ou implémenter un mécanisme (env ou backend) pour activer/désactiver les features sans redéploiement

### Cohérence front/back

- [ ] Aligner le **search frontend** avec les endpoints backend : utiliser `/tracks/search`, `/playlists/search`, `/users/search` si c’est le contrat backend, ou documenter l’usage de `/api/v1/search` générique
- [ ] **Tables DB sans code** (contests, contest_*, equipment, hardware_sales) : décider de les migrer/utiliser ou de les retirer du schéma pour éviter la confusion

---

## 8. Base de données & migrations (P2 / P3)

- [ ] **Migration UUID** : `001_migrate_ids_to_uuid_up.sql` ajoute `new_id` mais ne migre pas les PK/FK ; soit compléter la migration, soit documenter l’état et le plan de migration
- [ ] (P3) Nettoyer les **tables fantômes** (contests, equipment, etc.) ou les brancher au code

---

## 9. Frontend — Maturité (P2 / P3)

### TypeScript & qualité

- [ ] (P2) **Activer `noUncheckedIndexedAccess`** dans `tsconfig.app.json` et corriger les ~234 erreurs potentielles
- [ ] **TODO/FIXME** : traiter ou tracker les ~26 TODO/FIXME restants (au moins les critiques)

### Design system & docs

- [ ] (P3) **Extraire le design system SUMI** en package npm séparé (`components/ui/` + tokens `index.css`) si réutilisation multi-projet
- [ ] **Réduire le bruit dans `docs/`** : fusionner les 55+ fichiers d’audit en un CHANGELOG / KNOWN_ISSUES (ou déplacer les audits dans un dossier dédié)
- [ ] (P3) **ADR** (Architecture Decision Records) pour les choix importants (auth, state, design system)

### UX & accessibilité

- [ ] (P2) **aria-live** pour le player et les notifications (contenu dynamique annoncé aux lecteurs d’écran)
- [ ] (P2) **Images** : srcset, WebP/AVIF, lazy loading natif où pertinent
- [ ] (P2) **Code splitting** : séparer gros chunks (framer-motion, axios, DOMPurify) dans `vite.config.ts` si besoin

### Package design-system inutilisé

- [ ] Si `packages/design-system` existe et n’est pas utilisé : le supprimer du workspace ou le brancher pour éviter la duplication avec `src/components/ui/`

---

## 10. Résumé des priorités

| Priorité | Thème | Exemples d’actions |
|----------|--------|---------------------|
| **P0** | Sécurité / auth | Secrets git, JWT fallback chat, 2FA login, pagination bounds |
| **P0/P1** | Frontend critique | 2FA bug, cleanup setTimeout, console.log, aria-label ChatInput, focus trap sidebar |
| **P1** | Stabilité prod | Healthcheck Docker, CD registry, tests en échec, features fantômes |
| **P1** | Dette structurante | Unifier loading, Modal→Dialog, découper interceptors/handlers, Track type |
| **P2** | Consolidation | MSW complets, Storybook tests, E2E, typo unifiée, valeurs arbitraires |
| **P2** | Produit | Gérer Coming Soon, marketplace/wishlist, social groups |
| **P3** | Long terme | Workspace Rust/Go, Turborepo, migration UUID, design system package, ADR, CDN |

---

## 11. Ordre de passage suggéré

1. **Semaine 1–2 (P0)**  
   Secrets, JWT chat, 2FA frontend, pagination, cleanup setTimeout + console.log, aria-label + focus trap sidebar, healthcheck Docker.

2. **Semaine 2–4 (P1)**  
   Tests en échec, migration Modal→Dialog, unifier loading, découpage interceptors/handlers (au moins par fichier), gestion des routes Coming Soon et des features mockées (wishlist/cart/groups), activation CD.

3. **Mois 2 (P2)**  
   Stories Loading/Error/Empty, mocks MSW manquants, E2E parcours critiques, typo unifiée, réduction valeurs arbitraires, optionnel noUncheckedIndexedAccess et aria-live.

4. **Au-delà (P3)**  
   Workspace monorepo, migration UUID, design system package, ADR, CDN, SBOM/signature Docker.

---

*Document généré à partir des audits frontend et monorepo. À mettre à jour au fur et à mesure des réalisations.*