b103a09a25
- CI: workflows updates (cd, ci), remove playwright.yml - E2E: global-setup, auth/playlists/profile specs - Remove playwright-report and test-results artifacts from tracking - Backend: auth, handlers, services, workers, migrations - Frontend: components, features, vite config - Add e2e-results.json to gitignore - Docs: REMEDIATION_PROGRESS, audit archive - Rust: chat-server, stream-server updates
137 lines
No EOL
7.2 KiB
Markdown
137 lines
No EOL
7.2 KiB
Markdown
# 🔍 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. |