veza/veza_full_feature_list.md

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