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.