veza/sub_task_agents/STABLE_STATE_TODOLIST.md

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

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

Auth & contrôle d’accès

• 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)
• Rejeter le refresh token si l’utilisateur n’existe plus en DB (backend Go)
• 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

• 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.
• Typer login / register dans services/authService.ts : types explicites AuthLoginResult / AuthRegisterResult et Promise<...>.
• Cleanup des setTimeout : ChatInput, SocialViewFeedItem, PostCard ont déjà un cleanup dans le useEffect (refs + clearTimeout au démontage).

Logs & hygiène

• Supprimer les console.log dans GlobalSearchBar : le fichier utilise déjà logger.debug / logger.error (aucun console.log trouvé).

Accessibilité (WCAG — avant prod)

• ChatInput : aria-label="Type a message" déjà présent sur l’input — features/chat/components/ChatInput.tsx
• 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

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

Dépendances & cohérence

• Remplacer go-clamd — déjà fait : go.mod utilise github.com/Lyimmi/go-clamd v1.0.0 (fork maintenu).
• 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

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

CD

• 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

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

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