# 🔍 AUDIT COMPLET DU MONOREPO VEZA Tu es un architecte logiciel senior spécialisé en applications web full-stack (Go, React/TypeScript, Rust). Tu dois réaliser un audit exhaustif de ce monorepo et produire un rapport structuré en deux parties. --- ## CONTEXTE Veza est une plateforme audio collaborative pour musiciens indépendants (type SoundCloud/Bandcamp + communauté + marketplace). Le monorepo contient : - **Backend API** : Go - **Frontend** : React / TypeScript - **Services Rust** : Chat temps réel, streaming audio - **Infrastructure** : Docker, éventuellement Nginx/Caddy, base(s) de données L'objectif immédiat est d'atteindre une **version stable v0.101** (proof of concept fonctionnel). L'objectif long terme est la feature list complète de 600 fonctionnalités (document joint). --- ## PARTIE 1 — ÉTAT DE STABILITÉ : QUE MANQUE-T-IL POUR UNE VERSION STABLE ? Analyse chaque couche du projet et produis un diagnostic précis. ### 1.1 Santé du code Pour **chaque service/package** du monorepo : - Le code **compile-t-il sans erreur** ? (Go : `go build ./...`, Rust : `cargo check`, TS : `tsc --noEmit`) - Y a-t-il des **warnings critiques** ignorés ? - Y a-t-il des **imports cassés**, des modules manquants, des dépendances non résolues ? - Les fichiers `.env.example` ou configs nécessaires sont-ils documentés et cohérents ? - Y a-t-il des **TODO/FIXME/HACK** critiques dans le code ? Liste-les tous avec fichier + ligne. ### 1.2 Points bloquants fonctionnels Pour chaque module central, vérifie si le **happy path** fonctionne de bout en bout : - **Auth** : inscription → validation email → login → refresh token → logout. Le flow complet est-il implémenté et fonctionnel ? - **Profils** : création profil → édition → affichage public. Des champs manquants ? Des routes non connectées au frontend ? - **Upload & fichiers** : upload audio → stockage → métadonnées extraites → fichier jouable. La chaîne est-elle complète ? - **Streaming/Lecteur** : play → pause → seek → next → queue. Le lecteur est-il fonctionnel avec de vrais fichiers ? - **Playlists** : CRUD complet → ajout/retrait tracks → réorganisation. Quel est l'état ? - **Chat** : connexion WebSocket → envoi message → réception temps réel → historique. Le service Rust est-il opérationnel ? - **Marketplace** : création produit → affichage catalogue → achat (même simulé). Jusqu'où va l'implémentation ? - **Recherche** : la recherche globale retourne-t-elle des résultats pertinents ? Pour chaque module, classe l'état : ✅ Fonctionnel | ⚠️ Partiel (précise ce qui manque) | ❌ Non implémenté | 🔴 Cassé (précise l'erreur) ### 1.3 Points bloquants techniques - **Base de données** : les migrations sont-elles à jour ? Y a-t-il des incohérences schéma vs code (structs Go, types TS) ? Des migrations en conflit ? - **API** : y a-t-il des endpoints définis côté backend mais non consommés côté frontend (ou vice versa) ? Liste les routes orphelines. - **Sécurité** : les JWT sont-ils correctement validés ? Le CORS est-il configuré ? Y a-t-il des endpoints exposés sans authentification qui ne devraient pas l'être ? Des secrets hardcodés dans le code ? - **Services Rust** : compilent-ils ? Les dépendances Cargo sont-elles résolues ? La communication avec le backend Go (gRPC, HTTP, WebSocket) est-elle fonctionnelle ? - **Docker** : les Dockerfiles buildent-ils ? Le docker-compose lance-t-il tout le stack sans erreur ? Y a-t-il des volumes, networks ou dépendances inter-services mal configurés ? - **Frontend** : y a-t-il des pages/composants avec des erreurs runtime ? Des routes définies mais pointant vers des composants vides ou placeholder ? Des appels API vers des endpoints inexistants ? - **Tests** : quel est l'état des tests existants (unit, integration, E2E Playwright) ? Combien passent, combien échouent ? Y a-t-il des tests critiques manquants ? - **Logs & observabilité** : les erreurs sont-elles loguées de manière exploitable ? Y a-t-il un système de health check ? ### 1.4 Synthèse stabilité Produis une **liste ordonnée par priorité** de tous les points bloquants pour atteindre la stabilité, au format : ``` PRIORITÉ CRITIQUE (bloque le lancement) : 1. [Description] — Fichier(s) concerné(s) — Effort estimé (heures) 2. ... PRIORITÉ HAUTE (dégrade l'expérience) : 1. ... PRIORITÉ MOYENNE (acceptable pour un PoC) : 1. ... ``` --- ## PARTIE 2 — PROGRESSION VERS L'OBJECTIF FINAL (600 FEATURES) En te basant sur le document de features joint (600 fonctionnalités, 21 modules), évalue la couverture actuelle du code. ### 2.1 Matrice de couverture par module Pour **chaque module** (1 à 21), produis : ``` ## Module [N] : [Nom] — [X/Y features] ([Z%]) ### Implémentées (backend + frontend connectés) : - Feature #[N] : [Nom] ✅ ### Partiellement implémentées (backend OU frontend, pas les deux) : - Feature #[N] : [Nom] ⚠️ — Manque : [détail] ### Non implémentées : - Feature #[N] : [Nom] ❌ ### Hors scope v0.101 (TIER 2 / Future) : - Feature #[N] : [Nom] 🔮 ``` ### 2.2 Tableau récapitulatif ``` | Module | Total | ✅ Done | ⚠️ Partiel | ❌ Missing | 🔮 Future | % Done | |-------------------------------|-------|---------|------------|-----------|-----------|--------| | 1. Auth & Sécurité | 30 | ? | ? | ? | ? | ?% | | 2. Profils & Utilisateurs | 35 | ? | ? | ? | ? | ?% | | ... | | | | | | | | TOTAL | 600 | ? | ? | ? | ? | ?% | ``` ### 2.3 Écart par rapport aux tiers de priorité Évalue spécifiquement : - **TIER 0 (V1 Launch — 40 features)** : combien sont faites ? Combien restent ? Quel effort estimé pour finir ? - **TIER 1 (V2-V5 — 150 features)** : combien ont déjà été commencées en avance ? - **TIER 2 (V6-V12 — 410 features)** : y a-t-il du code qui anticipe ces features ? ### 2.4 Recommandations stratégiques Sur la base de ton audit : 1. Quelles sont les **5 actions les plus impactantes** pour avancer vers la stabilité ? 2. Y a-t-il des **choix architecturaux** qui vont poser problème à l'échelle (dette technique structurelle) ? 3. Y a-t-il des **modules surdéveloppés** par rapport à leur priorité (effort mal alloué) ? 4. Y a-t-il des **modules sous-développés** qui sont critiques pour le PoC ? 5. Quelle est ton **estimation réaliste** du temps restant pour atteindre la v0.101 stable ? --- ## FORMAT DE SORTIE - Sois **exhaustif et factuel** : cite les fichiers, les lignes, les erreurs exactes. - Ne suppose rien : si tu ne peux pas vérifier quelque chose, dis-le explicitement. - Utilise les émojis de statut systématiquement : ✅ ⚠️ ❌ 🔴 🔮 - Termine par un **score global de maturité** sur 100 et une phrase de synthèse. - Tous les chemins de fichiers doivent être relatifs à la racine du monorepo. --- ## DOCUMENTS DE RÉFÉRENCE Le document joint "LISTE EXHAUSTIVE DES 600 FONCTIONNALITÉS" contient la feature list complète organisée par modules et tiers de priorité. Utilise-le comme référence absolue pour la Partie 2.