# VEZA_VERSIONS_ROADMAP.md

> **Système de versionnage Veza — v1.0 de ce document**
>
> Ce fichier est la source de vérité unique pour le déroulé des versions de développement.
> Il est conçu pour être utilisé avec Cursor : donner simplement "implémente la prochaine version"
> suffit pour déclencher une session de travail complète et ciblée.
>
> **Convention** : Chaque version est atomique, testable, et mergeable indépendamment.
> Une version = un incrément de valeur livrable. Pas de version ouverte en parallèle.
>
> **Référence** : Tous les détails techniques et éthiques sont dans les fichiers ORIGIN/.
> Ce fichier orchestre — les ORIGIN spécifient.
>
> **Dernière mise à jour** : 2026-03-04
> **Auteur** : Architecte principal Veza

---

## 📋 ÉTAT GLOBAL

| Phase | Versions | Statut | Objectif |
|-------|----------|--------|----------|
| **P3.5 — Consolidation & Sécurité** | v0.9.1 → v0.9.9 | 🔴 EN COURS | Stabiliser, sécuriser, dettes techniques |
| **P4R — Social & Live** | v0.10.0 → v0.10.9 | ⏳ À VENIR | Chat complet, feed social, livestream |
| **P5R — Analytics & Recherche** | v0.11.0 → v0.11.9 | ⏳ À VENIR | Analytics créateur, recherche éthique |
| **P6R — Premium & Infrastructure** | v0.12.0 → v0.12.9 | ⏳ À VENIR | Plans premium, distribution, perf |
| **v1.0 — Release Stable** | v1.0.0 | ⏳ À VENIR | GO/NO-GO criteria atteints |

---

## 🔴 PHASE P3.5 — CONSOLIDATION & SÉCURITÉ

> Objectif : avant de construire de nouvelles features, rendre le système fiable, sécurisé, et maintenable.
> Aucune feature P4R ne commence avant que P3.5 soit complète.

---

### v0.9.1 — Vulnérabilités Critiques JWT (TASK-SEC-001 + TASK-SEC-002)

**Statut** : ✅ DONE  
**Priorité** : P0 — BLOQUANT  
**Durée estimée** : 2-3 jours  
**Prerequisite** : Aucun  
**Complété le** : 2026-03-05  

**Objectif**  
Corriger les deux vulnérabilités de sécurité critiques identifiées dans l'audit (VEZA-SEC-001 et VEZA-SEC-002). Sans ces correctifs, aucune autre feature ne peut être déployée en production.

**Tâches**

- [x] **TASK-SEC-001** : Migration JWT HS256 → RS256
  - Générer paire de clés RSA 2048-bit (clé privée backend, clé publique publique)
  - Modifier le service JWT pour signer avec RS256
  - Mettre à jour tous les middleware de validation JWT
  - Mettre à jour les variables d'environnement (supprimer `JWT_SECRET`, ajouter `JWT_PRIVATE_KEY_PATH`, `JWT_PUBLIC_KEY_PATH`)
  - Invalider tous les tokens existants (migration token_version)
  - Référence : ORIGIN_SECURITY_FRAMEWORK.md §0 VEZA-SEC-001, ORIGIN_DEPLOYMENT_GUIDE.md §15

- [x] **TASK-SEC-002** : Supprimer les clés privées committées / secrets exposés
  - Audit complet de l'historique git (truffleHog ou équivalent)
  - Rotation immédiate de toutes les clés compromises (Stripe, OAuth, JWT, DB)
  - Mettre en place `.gitignore` complet pour tous les fichiers `.env`
  - Créer `.env.example` documenté avec toutes les variables requises
  - Référence : ORIGIN_SECURITY_FRAMEWORK.md §0 VEZA-SEC-002

**Critères d'acceptation**
- [x] Tous les JWT générés utilisent RS256 (ou HS256 fallback dev) et sont vérifiés avec la clé publique / secret
- [x] Aucun secret hardcodé par défaut (veza-common corrigé, procédure audit docs/SECRETS_AUDIT.md)
- [x] `.env.example` et docs/ENV_VARIABLES.md couvrent les variables requises
- [x] Tests d'authentification passent (unit + handler)
- [ ] Déploiement staging valide avec les nouvelles clés (à valider manuellement)

**Fichiers principaux à modifier**
- `backend/internal/auth/jwt_service.go`
- `backend/internal/middleware/auth_middleware.go`
- `.env.example`
- `backend/configs/`
- `docker-compose.yml` (variables d'env)

---

### v0.9.2 — Sécurité Infrastructure (TASK-SEC-003 à 006)

**Statut** : ✅ DONE  
**Priorité** : P0 — BLOQUANT  
**Durée estimée** : 1-2 jours  
**Prerequisite** : v0.9.1 complète  
**Complété le** : 2026-03-05  

**Objectif**  
Fermer les vecteurs d'attaque infrastructure : endpoint `/metrics` exposé, rate limiting manquant, headers de sécurité absents.

**Tâches**

- [x] **TASK-SEC-003** : Rate limiting global
  - Implémenter rate limiting middleware sur toutes les routes publiques
  - Règles : 100 req/h par IP (non-auth), 1000 req/h (auth)
  - Redis comme backend pour le comptage distribué
  - Référence : ORIGIN_SECURITY_FRAMEWORK.md, ORIGIN_FEATURES_REGISTRY.md F026

- [x] **TASK-SEC-004** : Security headers HTTP
  - `Content-Security-Policy`, `X-Frame-Options`, `X-Content-Type-Options`
  - `Strict-Transport-Security` (HSTS)
  - `Referrer-Policy`
  - Middleware centralisé dans HAProxy ou au niveau Go

- [x] **TASK-SEC-005** : Validation et sanitization des inputs
  - Audit de tous les endpoints existants (pas de SQL injection, XSS)
  - Binding validation exhaustif sur tous les handlers
  - Taille max des payloads (1MB par défaut, 500MB pour upload audio)

- [x] **TASK-SEC-006** : Protection endpoint `/metrics`
  - Route Prometheus `/metrics` accessible seulement depuis réseau interne
  - Authentification bearer token ou IP whitelist
  - Référence : ORIGIN_SECURITY_FRAMEWORK.md §0, ORIGIN_IMPLEMENTATION_TASKS.md TASK-SEC-006

**Critères d'acceptation**
- [x] `curl http://api.veza.app/metrics` depuis internet → 403
- [x] 101ème requête depuis une IP non-auth → 429 Too Many Requests
- [x] Headers de sécurité visibles dans les réponses (vérifiable avec `curl -I`)
- [ ] Tests de pénétration basiques (OWASP Top 10) passent sans résultat critique (à valider manuellement)

---

### v0.9.3 — Toolchain et Environnement (TASK-QA-006 à 010)

**Statut** : ✅ DONE  
**Priorité** : P1  
**Durée estimée** : 1 jour  
**Prerequisite** : v0.9.1 complète  
**Complété le** : 2026-03-05  

**Objectif**  
Standardiser l'environnement de développement pour que tous les développeurs (et Cursor) travaillent dans des conditions identiques et reproductibles.

**Tâches**

- [x] **TASK-QA-006** : Créer `.nvmrc` à la racine du monorepo
  - Version Node.js fixée (LTS actuel)
  - Référence : ORIGIN_QUALITY_METRICS.md §6.4 DT-007

- [x] **TASK-QA-007** : Créer `rust-toolchain.toml` pour le stream server
  - Version Rust stable fixée (existe à la racine)
  - Référence : ORIGIN_QUALITY_METRICS.md §6.4 DT-008

- [x] **TASK-QA-008** : Compléter `Makefile` racine
  - Alias `build` (→ build-all), cible `doctor` vérifiant dépendances
  - Référence : make/build.mk, make/tools.mk

- [x] **TASK-QA-009** : Documenter variables d'environnement + script de validation
  - `docs/ENV_VARIABLES.md` avec description, type, valeur par défaut, exemples
  - `scripts/validate-env.sh` (appelé par `make doctor`)

- [x] **TASK-QA-010** : `docker-compose.dev.yml` fonctionnel
  - Infra : Postgres, Redis, RabbitMQ, ClamAV, MinIO
  - `make dev-full`, `make dev-backend-api`, `make dev-stream-server` utilisent `infra-up-dev`
  - Hot reload pour apps locales (air, cargo-watch)

**Critères d'acceptation**
- [x] `make dev` démarre backend (Docker) + web local
- [x] `make doctor` vérifie dépendances et affiche rapport
- [x] Un développeur peut démarrer l'environnement avec les instructions du README
- [x] README racine à jour avec instructions setup

---

### v0.9.4 — Quality Gates CI/CD (TASK-QA-001 à 005)

**Statut** : ⏳ TODO  
**Priorité** : P1  
**Durée estimée** : 2 jours  
**Prerequisite** : v0.9.3 complète  

**Objectif**  
Mettre en place les quality gates automatisées pour que chaque PR soit validée avant merge. Zéro régression non détectée.

**Tâches**

- [ ] **TASK-QA-001** : Pipeline CI GitHub Actions (ou équivalent)
  - Stage 1 : lint (golangci-lint, ESLint, rustfmt/clippy)
  - Stage 2 : unit tests (Go, Rust, React)
  - Stage 3 : integration tests (avec Postgres + Redis en service)
  - Stage 4 : build (vérification que tout compile)
  - Référence : ORIGIN_QUALITY_METRICS.md §7.1bis

- [ ] **TASK-QA-002** : Coverage gates
  - Go backend : coverage ≥ 60% (objectif 80%)
  - Frontend React : coverage ≥ 50%
  - PR rejetée automatiquement si coverage descend

- [ ] **TASK-QA-003** : Linting strict
  - `.golangci.yml` configuré avec règles pertinentes
  - `.eslintrc` strict pour TypeScript
  - Aucun warning accepté en CI

- [ ] **TASK-QA-004** : Tests d'intégration de santé
  - Test : tous les services démarrent correctement
  - Test : endpoints de health check répondent
  - Test : connexions DB et Redis établies

- [ ] **TASK-QA-005** : Notifications de CI
  - Notification Slack/Discord sur failure
  - Badge CI dans le README

**Critères d'acceptation**
- [ ] Chaque push sur une branche déclenche le pipeline
- [ ] Pipeline complet s'exécute en moins de 10 minutes
- [ ] Une PR avec tests échoués ne peut pas être mergée
- [ ] Coverage visible dans chaque PR

---

### v0.9.5 — Suppression Code Mort (TASK-DEBT-001 à 005)

**Statut** : ⏳ TODO  
**Priorité** : P1  
**Durée estimée** : 1-2 jours  
**Prerequisite** : v0.9.4 complète (les tests protègent contre les régressions)  

**Objectif**  
Supprimer tout le code mort identifié dans l'audit. Réduire la surface de maintenance et éliminer la confusion architecturale.

**Tâches**

- [ ] **TASK-DEBT-001** : Supprimer le répertoire `soundcloud/` (ou équivalent SoundCloud import)
  - Confirmer qu'aucun code en production ne l'importe
  - Supprimer et nettoyer les imports

- [ ] **TASK-DEBT-002** : Supprimer `webrtc.rs` du stream server (si non utilisé)
  - Le stream server Rust ne fait pas de WebRTC (voir ADR-002)
  - Confirmer dans le code, supprimer si orphelin

- [ ] **TASK-DEBT-003** : Supprimer `k8s/chat-server/` (Kubernetes manifests pour le chat Rust obsolète)
  - Le chat server est maintenant en Go (ADR-002)
  - Référence : ORIGIN_IMPLEMENTATION_TASKS_ARCHIVE.md note T0051-T0065

- [ ] **TASK-DEBT-004** : Supprimer ou désactiver tous les endpoints AI/Web3/Gamification
  - Rechercher dans le codebase : routes AI, NFT, XP, leaderboard, gamification
  - Supprimer le code correspondant
  - Référence : ORIGIN_REVISION_SUMMARY.md §1, ORIGIN_FEATURES_REGISTRY.md §29

- [ ] **TASK-DEBT-005** : Nettoyer les dépendances inutilisées
  - `go mod tidy` et vérification des modules Go
  - `npm audit` et suppression des packages inutilisés
  - `cargo update` et nettoyage des crates Rust

**Critères d'acceptation**
- [ ] `grep -r "soundcloud\|nft\|blockchain\|xp_system\|leaderboard" --include="*.go" --include="*.ts" --include="*.rs"` → aucun résultat dans le code actif
- [ ] Taille du bundle frontend réduite (mesurer avant/après)
- [ ] Tous les tests passent après nettoyage

---

### v0.9.6 — Chat Complet : Réactions & Mentions (TASK-CHAT-001 à 003)

**Statut** : ⏳ TODO  
**Priorité** : P1  
**Durée estimée** : 3-4 jours  
**Prerequisite** : v0.9.2 complète  

**Objectif**  
Compléter le module Chat (Go) avec les features manquantes : réactions aux messages, mentions @utilisateur, et search dans l'historique.

**Tâches**

- [ ] **TASK-CHAT-001** : Réactions aux messages (émojis)
  - Backend : endpoint POST/DELETE `/api/v1/chat/messages/{id}/reactions`
  - Table `message_reactions` (message_id, user_id, emoji, created_at)
  - WebSocket : event `message:reaction_added` / `message:reaction_removed`
  - Frontend : picker émoji inline, compteur de réactions
  - Référence : ORIGIN_FEATURES_REGISTRY.md F162

- [ ] **TASK-CHAT-002** : Mentions @utilisateur
  - Backend : parsing des `@username` dans les messages
  - Notification push pour les utilisateurs mentionnés
  - Frontend : autocomplete @username en cours de frappe
  - Référence : ORIGIN_FEATURES_REGISTRY.md F163

- [ ] **TASK-CHAT-003** : Recherche dans l'historique des messages
  - Backend : endpoint GET `/api/v1/chat/rooms/{id}/messages/search?q=...`
  - Elasticsearch ou fulltext PostgreSQL (pg_trgm)
  - Frontend : barre de recherche dans le panel chat
  - Référence : ORIGIN_FEATURES_REGISTRY.md F165

**Critères d'acceptation**
- [ ] Un utilisateur peut réagir à un message avec un émoji, la réaction apparaît en temps réel chez tous les participants
- [ ] `@alice` dans un message déclenche une notification pour alice
- [ ] La recherche retourne des résultats pertinents en moins de 200ms
- [ ] Aucune régression sur les features chat existantes

---

### v0.9.7 — Chat Complet : Fichiers & Threads (TASK-CHAT-004 à 006)

**Statut** : ⏳ TODO  
**Priorité** : P1  
**Durée estimée** : 3-4 jours  
**Prerequisite** : v0.9.6 complète  

**Objectif**  
Compléter le module Chat avec l'envoi de fichiers, les threads (réponse à un message), et la gestion des rooms de groupe.

**Tâches**

- [ ] **TASK-CHAT-004** : Envoi de fichiers dans le chat
  - Backend : endpoint POST `/api/v1/chat/messages/{id}/attachments`
  - Types acceptés : audio (mp3, wav, ogg), image (jpg, png), PDF
  - Upload S3, URL signée temporaire (24h)
  - Taille max : 50MB par fichier
  - Référence : ORIGIN_FEATURES_REGISTRY.md F166

- [ ] **TASK-CHAT-005** : Threads (réponse à un message)
  - Backend : champ `reply_to_message_id` dans la table messages
  - Frontend : UI thread avec message parent visible
  - Référence : ORIGIN_FEATURES_REGISTRY.md F161

- [ ] **TASK-CHAT-006** : Rooms de groupe (invitations, gestion des membres)
  - Backend : endpoints CRUD pour la gestion des membres d'une room
  - Invitations avec lien unique (expire en 7 jours)
  - Rôles dans le groupe : owner, admin, member
  - Référence : ORIGIN_FEATURES_REGISTRY.md F155-F160

**Critères d'acceptation**
- [ ] Partage d'un fichier audio dans le chat → lecture inline possible
- [ ] Thread visible avec message parent
- [ ] Invitation par lien fonctionne (flow complet)
- [ ] Owner peut kick un membre

---

### v0.9.8 — Réduction Dette Technique Backend (TASK-DEBT-006 à 012)

**Statut** : ⏳ TODO  
**Priorité** : P1  
**Durée estimée** : 3-4 jours  
**Prerequisite** : v0.9.4 complète  

**Objectif**  
Corriger les patterns d'erreur identifiés dans l'audit technique (PAT-024 à PAT-028) : propagation de contexte, goroutine leaks, pagination incohérente, error handling non standardisé.

**Tâches**

- [ ] **TASK-DEBT-006** : Standardisation error handling Go
  - Tous les handlers retournent des erreurs au format `{"error": {"code": "...", "message": "...", "context": {...}}}`
  - Créer package `pkg/apierror` avec types d'erreurs standardisés
  - Référence : ORIGIN_ERROR_PATTERNS.md PAT-028, ORIGIN_ERROR_PREVENTION_GUIDE.md §2.6

- [ ] **TASK-DEBT-007** : Context propagation dans tous les services Go
  - Audit : chaque fonction qui fait I/O doit accepter `context.Context` comme premier paramètre
  - Deadline et cancellation propagés correctement
  - Référence : ORIGIN_ERROR_PATTERNS.md PAT-025

- [ ] **TASK-DEBT-008** : Goroutine lifecycle management
  - Audit : chaque goroutine a un mécanisme de terminaison propre
  - `WaitGroup` ou channels de done utilisés correctement
  - Tests de détection de goroutine leaks (goleak)
  - Référence : ORIGIN_ERROR_PATTERNS.md PAT-026

- [ ] **TASK-DEBT-009** : Pagination cohérente sur tous les endpoints de liste
  - Standard : `?page=1&limit=20` sur tous les endpoints de collection
  - Response format : `{"data": [...], "pagination": {"page": 1, "limit": 20, "total": 150, "total_pages": 8}}`
  - Référence : ORIGIN_ERROR_PATTERNS.md PAT-027, ORIGIN_CODE_STANDARDS.md §3.7

- [ ] **TASK-DEBT-010** : JWT mismatch resolution
  - Audit de toutes les validations JWT : uniformiser les claims attendus
  - Référence : ORIGIN_ERROR_PATTERNS.md PAT-024

- [ ] **TASK-DEBT-011** : Logging structuré uniforme
  - Tous les logs au format JSON avec champs : `level`, `time`, `msg`, `request_id`, `user_id` (si applicable)
  - Niveaux : DEBUG (dev uniquement), INFO (prod), WARN, ERROR

- [ ] **TASK-DEBT-012** : Documentation ADR systématique
  - Créer `docs/adr/` avec les ADR existants formalisés (ADR-001 à ADR-012)
  - Référence : ORIGIN_REVISION_SUMMARY.md §3

**Critères d'acceptation**
- [ ] Tous les endpoints de liste ont une pagination cohérente
- [ ] `goleak` ne détecte pas de goroutine leaks dans les tests
- [ ] Toutes les erreurs API suivent le format standardisé
- [ ] Couverture de tests ≥ 70% sur le package `pkg/apierror`

---

### v0.9.9 — Réduction Dette Technique Frontend (TASK-DEBT-013 à 017)

**Statut** : ⏳ TODO  
**Priorité** : P1  
**Durée estimée** : 2-3 jours  
**Prerequisite** : v0.9.4 complète  

**Objectif**  
Nettoyer la dette technique frontend : types TypeScript incomplets, composants non accessibles, bundle non optimisé.

**Tâches**

- [ ] **TASK-DEBT-013** : TypeScript strict mode complet
  - Activer `"strict": true` dans `tsconfig.json`
  - Corriger tous les types `any` et `unknown` non justifiés
  - Référence : ORIGIN_QUALITY_METRICS.md §6.4 DT-013

- [ ] **TASK-DEBT-014** : Accessibilité WCAG AA (audit et corrections)
  - Audit avec axe-core ou Lighthouse
  - ARIA labels sur tous les composants interactifs
  - Keyboard navigation fonctionnelle (Tab, Enter, Escape)
  - Référence : ORIGIN_UI_UX_SYSTEM.md §14, ORIGIN_FEATURE_VALIDATION_STRATEGY.md §7

- [ ] **TASK-DEBT-015** : Optimisation bundle (code splitting)
  - Lazy loading des routes React (React.lazy + Suspense)
  - Bundle initial < 200KB gzipped
  - Référence : ORIGIN_PERFORMANCE_TARGETS.md

- [ ] **TASK-DEBT-016** : Storybook ou équivalent pour les composants UI
  - Documentation des composants du design system SUMI
  - Stories pour les états : default, loading, error, empty
  - Référence : ORIGIN_UI_UX_SYSTEM.md

- [ ] **TASK-DEBT-017** : Tests de régression visuels (optionnel)
  - Playwright ou Chromatic pour screenshots de référence
  - Référence : ORIGIN_TESTING_STRATEGY.md §13

**Critères d'acceptation**
- [ ] `npm run build` sans erreurs TypeScript
- [ ] Score Lighthouse Accessibility ≥ 90
- [ ] Bundle initial < 200KB gzipped (mesuré avec `npx bundlesize`)
- [ ] Navigation clavier complète sur les flows critiques (login, upload, chat)

---

## 🟡 PHASE P4R — SOCIAL & LIVE

> Prerequisite : **Toutes les versions P3.5 (v0.9.x) sont complètes et validées.**
> La phase P4R est déclenche uniquement après GO/NO-GO sur P3.5 (voir critères en fin de document).

---

### v0.10.0 — Feed Social Chronologique (F186-F200)

**Statut** : ⏳ TODO  
**Priorité** : P1  
**Durée estimée** : 4-5 jours  
**Prerequisite** : v0.9.9 complète  

**Objectif**  
Implémenter le système de follow/unfollow et le feed chronologique. Le feed est basé sur les follows de l'utilisateur, sans algorithme de rétention.

**Tâches**

- [ ] Follow / Unfollow un utilisateur (F186)
  - Backend : POST/DELETE `/api/v1/users/{id}/follow`
  - Table `follows` (follower_id, following_id, created_at)
  - Index pour requêtes rapides dans les deux sens
  
- [ ] Compteurs followers/following sur les profils (F187)
  - Dénormalisé dans `users.followers_count` et `users.following_count`
  - Mis à jour via trigger DB ou job asynchrone

- [ ] Feed chronologique des artistes suivis (F210)
  - Backend : GET `/api/v1/feed?cursor=...&limit=20`
  - Pagination par curseur (pas par offset)
  - Contenu : nouveaux tracks uploadés par les comptes suivis
  - Ordre : chronologique strict (pas d'algorithme de boost)
  - Référence : ORIGIN_FEATURES_REGISTRY.md F210, ORIGIN_MASTER_ARCHITECTURE.md §4

- [ ] Suggestions de comptes à suivre (F211)
  - Basé sur : connexions sociales (amis d'amis), genres déclarés, localisation (opt-in)
  - Pas de collaborative filtering ML
  - Référence : ORIGIN_FEATURES_REGISTRY.md §30 (Algorithme de découverte éthique)

- [ ] Notifications de nouveaux followers

**Critères d'acceptation**
- [ ] Follow/unfollow en moins de 100ms
- [ ] Feed se charge en moins de 200ms pour 20 items
- [ ] Feed est strictement chronologique (vérifiable)
- [ ] Pagination par curseur fonctionne correctement (pas de doublons)
- [ ] Aucune donnée de comportement utilisateur utilisée pour le ranking

---

### v0.10.1 — Découverte Éthique : Tags & Genres (F351-F360)

**Statut** : ⏳ TODO  
**Priorité** : P1  
**Durée estimée** : 3-4 jours  
**Prerequisite** : v0.10.0 complète  

**Objectif**  
Implémenter le système de tags déclaratifs et la découverte par genres. C'est le cœur de l'algorithme de découverte éthique.

**Tâches**

- [ ] Système de tags déclaratifs sur les tracks (F351)
  - Tags créés par l'artiste lui-même
  - Validation : max 10 tags par track, longueur max 30 chars
  - Table `track_tags`, table `tags` (avec compteur d'utilisation)

- [ ] Genres musicaux normalisés (F352)
  - Taxonomy fixe (liste fermée, extensible via PR)
  - Multi-genre supporté (max 3 genres par track)

- [ ] Browse par genre / tag (F353)
  - GET `/api/v1/discover/genre/{genre}?sort=recent&cursor=...`
  - GET `/api/v1/discover/tag/{tag}?cursor=...`
  - Tri : chronologique uniquement (pas de popularité)

- [ ] Suivre un genre ou un tag (F354)
  - L'utilisateur peut "suivre" des genres/tags
  - Le feed inclut les nouvelles sorties dans les genres/tags suivis

- [ ] Nouveautés dans les genres suivis (F355)
  - Section dédiée dans le feed : "Nouvelles sorties dans vos genres"
  - Référence : ORIGIN_FEATURES_REGISTRY.md §30

**Critères d'acceptation**
- [ ] Un artiste peut taguer son track avec des tags libres (max 10)
- [ ] Un utilisateur peut suivre le genre "jazz" et voir les nouveautés jazz dans son feed
- [ ] Browse par genre retourne des tracks triées par date (plus récent en premier)
- [ ] Test de biais : les artistes émergents apparaissent autant que les artistes établis dans les résultats de découverte

---

### v0.10.2 — Recherche Fulltext Elasticsearch (F361-F370)

**Statut** : ⏳ TODO  
**Priorité** : P1  
**Durée estimée** : 4-5 jours  
**Prerequisite** : v0.10.1 complète  

**Objectif**  
Implémenter la recherche fulltext avec Elasticsearch. Recherche de tracks, artistes, et playlists par mots-clés.

**Tâches**

- [ ] Index Elasticsearch pour les tracks (F361)
  - Champs indexés : title, artist, tags, genre, description
  - Mapping avec analyzer français/anglais
  - Synchronisation depuis PostgreSQL (via CDC ou job périodique)
  - Référence : ORIGIN_MASTER_ARCHITECTURE.md ADR-012, ORIGIN_TECHNICAL_STACK.md §17

- [ ] Index Elasticsearch pour les utilisateurs (F362)
  - Champs : username, display_name, bio, genres, location

- [ ] Endpoint de recherche unifiée (F363)
  - GET `/api/v1/search?q=...&type=tracks,users,playlists&cursor=...`
  - Résultats groupés par type
  - Highlighting des termes trouvés

- [ ] Recherche phonétique (French + English) (F364)
  - Tolérance aux fautes de frappe
  - Recherche par sonorité (pour les noms d'artistes)

- [ ] Suggestions autocomplete (F365)
  - GET `/api/v1/search/suggest?q=...`
  - Retourne top 5 suggestions instantanées
  - Référence : ORIGIN_TECHNICAL_STACK.md §17

**Critères d'acceptation**
- [ ] Recherche "acid jazz" retourne des tracks taggées avec les deux termes séparément
- [ ] Résultats en moins de 200ms
- [ ] Faute de frappe "jaz" retourne quand même des résultats jazz
- [ ] Pas de résultats basés sur des métriques d'engagement (pas de boost popularity)
- [ ] Test : recherche d'un artiste avec 0 plays retourne les mêmes résultats de pertinence qu'un artiste populaire pour la même requête

---

### v0.10.3 — Commentaires & Interactions Sociales (F201-F215)

**Statut** : ⏳ TODO  
**Priorité** : P2  
**Durée estimée** : 3-4 jours  
**Prerequisite** : v0.10.0 complète  

**Objectif**  
Implémenter les commentaires sur les tracks et les likes, sans métriques de popularité visibles publiquement.

**Tâches**

- [ ] Commentaires sur les tracks (F201)
  - POST `/api/v1/tracks/{id}/comments`
  - Commentaires avec timestamp (position dans la piste)
  - Modération : filtrage par liste de mots-clés (pas de ML)

- [ ] Likes / Unlikes sur les tracks (F202)
  - POST/DELETE `/api/v1/tracks/{id}/like`
  - Compteur visible uniquement par le créateur dans ses analytics (pas publiquement)
  - Référence : ORIGIN_REVISION_SUMMARY.md §2 (anti social validation loop)

- [ ] Reposts (partage d'une track dans son profil) (F203)

- [ ] Notifications pour les interactions (F204)
  - Notification pour le créateur quand quelqu'un commente
  - Pas de notification "votre track a atteint X likes" (anti gamification)

**Critères d'acceptation**
- [ ] Les likes ne sont pas visibles publiquement (confirmé dans le design)
- [ ] Le créateur voit ses stats dans sa section Analytics (privée)
- [ ] Commentaire avec timestamp cliquable pour aller à ce moment dans la track

---

### v0.10.4 — Playlists Collaboratives (F136-F150)

**Statut** : ⏳ TODO  
**Priorité** : P2  
**Durée estimée** : 3-4 jours  
**Prerequisite** : v0.10.0 complète  

**Objectif**  
Améliorer le système de playlists avec les fonctionnalités collaboratives et la curation manuelle.

**Tâches**

- [ ] Playlists collaboratives (plusieurs contributeurs) (F140)
- [ ] Playlists curatoriales éditoriales (rôle admin/modérateur) (F141)
  - Base de la découverte éthique : playlists créées par humains
  - Référence : ORIGIN_FEATURES_REGISTRY.md §30

- [ ] Partage de playlists (lien public, embed) (F143)
- [ ] Import/export de playlists (M3U, JSON) (F145)
- [ ] Playlist "Favoris" automatique par utilisateur (F136)

**Critères d'acceptation**
- [ ] Deux utilisateurs peuvent éditer la même playlist simultanément (sans conflit)
- [ ] Playlist éditoriale visible dans la section Découverte
- [ ] Export M3U fonctionnel

---

### v0.10.5 — Notifications Complètes (F551-F570)

**Statut** : ⏳ TODO  
**Priorité** : P2  
**Durée estimée** : 2-3 jours  
**Prerequisite** : v0.10.3 complète  

**Objectif**  
Implémenter le système de notifications complet, respectueux du temps de l'utilisateur, sans FOMO.

**Tâches**

- [ ] Notifications in-app en temps réel (WebSocket) (F551)
- [ ] Digest hebdomadaire email (opt-in) (F552)
  - Résumé des nouvelles sorties dans les genres suivis
  - Pas de recommandations comportementales
  - Référence : ORIGIN_BUSINESS_LOGIC.md §8.1

- [ ] Préférences de notifications granulaires (F553)
  - Contrôle par type (follow, commentaire, message, etc.)
  - Quiet hours configurables

- [ ] Groupement de notifications (F554)
  - "3 personnes ont commenté votre track" (pas 3 notifications séparées)

- [ ] Centre de notifications (page dédiée) (F555)

**Critères d'acceptation**
- [ ] Aucune notification "vous avez atteint X likes" (anti gamification)
- [ ] Par défaut : notifications push désactivées sauf messages directs et follows
- [ ] L'utilisateur peut désactiver toutes les notifications marketing en un clic

---

### v0.10.6 — Livestreaming Basique (F471-F476)

**Statut** : ⏳ TODO  
**Priorité** : P2  
**Durée estimée** : 5-7 jours  
**Prerequisite** : v0.10.0 complète, stream server Rust fonctionnel  

**Objectif**  
Implémenter le livestreaming audio basique via le stream server Rust (RTMP in, HLS out).

**Tâches**

- [ ] Ingest RTMP depuis OBS/équipement audio (F471)
  - Stream server Rust accepte les connexions RTMP
  - Authentification via stream key unique par créateur

- [ ] Distribution HLS multi-bitrate (F472)
  - Segmentation HLS (segments de 2 secondes)
  - Bitrates : 64kbps, 128kbps, 320kbps
  - Référence : ORIGIN_FEATURES_REGISTRY.md F475

- [ ] Player live dans l'interface web (F473)
  - Latence < 5 secondes
  - Indicateur "LIVE" et nombre d'auditeurs

- [ ] Chat du live (F474)
  - Messages en temps réel pendant le live
  - Modération : rate limiting (1 message/3 secondes)

- [ ] Enregistrement automatique du live (optionnel, F476)
  - Le live peut être sauvegardé comme track après la session

**Critères d'acceptation**
- [ ] Flow complet : créateur lance OBS → stream ingest → auditeur entend en moins de 5 secondes
- [ ] Chat fonctionne pendant le live
- [ ] Pas de crash si 0 auditeurs
- [ ] Arrêt propre du stream (le créateur coupe OBS → le player affiche "Stream terminé")

---

### v0.10.7 — Collaboration Temps Réel (F481-F488)

**Statut** : ⏳ TODO  
**Priorité** : P2  
**Durée estimée** : 5-6 jours  
**Prerequisite** : v0.10.6 complète  

**Objectif**  
Implémenter la collaboration temps réel basique : sessions de co-écoute et partage de projets.

**Tâches**

- [ ] Sessions de co-écoute synchronisée (F481)
  - Plusieurs utilisateurs écoutent la même track en sync
  - Le host contrôle la lecture

- [ ] Partage de projets / stems (F482)
  - Upload de stems séparés (kick, snare, bass, etc.)
  - Autre utilisateur peut télécharger les stems

- [ ] Espace de travail collaboratif partagé (F483)
  - Room collaborative avec chat dédié + partage de fichiers
  - Accès contrôlé (invitation seulement)

**Critères d'acceptation**
- [ ] Co-écoute : synchronisation en moins de 500ms entre participants
- [ ] Partage de stems : tous les formats (wav, aiff, flac) acceptés
- [ ] Room collaborative : max 10 participants simultanés

---

### v0.10.8 — Portabilité des Données (F065, GDPR)

**Statut** : ⏳ TODO  
**Priorité** : P1  
**Durée estimée** : 2-3 jours  
**Prerequisite** : v0.10.0 complète  

**Objectif**  
Implémenter les droits RGPD : export des données, suppression de compte, droit à l'oubli.

**Tâches**

- [ ] Export des données utilisateur (ZIP) (F065)
  - Endpoint POST `/api/v1/users/me/export` → génère un ZIP asynchrone
  - Contenu : profil, tracks, playlists, messages, historique d'écoute
  - Notification email quand le ZIP est prêt (valable 7 jours)
  - Référence : ORIGIN_API_SPECIFICATION.md §7.10, ORIGIN_DATABASE_SCHEMA.md §19

- [ ] Suppression de compte (F065)
  - DELETE `/api/v1/users/me`
  - Soft delete avec période de grâce 30 jours
  - Hard delete après 30 jours (RGPD)
  - Les tracks publiques restent (dissociées du compte) ou sont supprimées selon le choix

- [ ] Droit à l'oubli (anonymisation)
  - Remplacer les données PII par des placeholders
  - Conserver les transactions financières (obligation légale)

**Critères d'acceptation**
- [ ] Export ZIP disponible en moins de 1 heure pour un compte avec 100 tracks
- [ ] Suppression effective en 30 jours (testable avec un compte de test)
- [ ] Conformité RGPD vérifiable : aucune donnée PII ne subsiste après 30 jours

---

## 🟢 PHASE P5R — ANALYTICS & RECHERCHE ÉTHIQUE

> Prerequisite : **Toutes les versions P4R (v0.10.x) sont complètes et validées.**

---

### v0.11.0 — Analytics Créateur (F381-F395)

**Statut** : ⏳ TODO  
**Priorité** : P1  
**Durée estimée** : 4-5 jours  
**Prerequisite** : v0.10.3 complète  

**Objectif**  
Donner aux créateurs des analytics sur leurs tracks, sans exposer ces métriques publiquement. Les données sont au service du créateur, pas de la plateforme.

**Tâches**

- [ ] Dashboard analytics créateur (F381)
  - Nombre de plays, écoutes complètes, durée d'écoute par track
  - Répartition géographique (pays, région — agrégée et anonymisée)
  - Source de découverte (recherche, feed, partage direct, profil)
  - Référence : ORIGIN_REVISION_SUMMARY.md §2 (données agrégées et anonymisées pour le créateur)

- [ ] Evolution temporelle des plays (F382)
  - Graphique par jour/semaine/mois

- [ ] Téléchargements et achats (F383)
  - Historique des ventes, revenus par période
  - Export CSV

- [ ] Analytics d'audience (F384)
  - Profil générique des auditeurs (genre, âge — agrégé, pas individuel)

- [ ] Métriques en temps réel pour les lives (F385)
  - Auditeurs actuels pendant un livestream

**Critères d'acceptation**
- [ ] Aucune donnée individuelle exposée (agrégation minimum 10 utilisateurs)
- [ ] Le créateur peut exporter ses analytics en CSV
- [ ] Les métriques ne sont PAS visibles publiquement sur le profil de l'artiste
- [ ] Score Lighthouse Privacy ≥ 90 sur les pages analytics

---

### v0.11.1 — Analytics Avancés (F396-F410)

**Statut** : ⏳ TODO  
**Priorité** : P2  
**Durée estimée** : 3-4 jours  
**Prerequisite** : v0.11.0 complète  

**Tâches**

- [ ] Heatmap d'écoute (F396)
  - Segments d'une track les plus/moins écoutés (agrégé)
  - Aide le créateur à comprendre où les auditeurs décrochent

- [ ] Comparaison de périodes (F397)
  - "Cette semaine vs semaine dernière"

- [ ] Analytics de la marketplace (F398)
  - Taux de conversion par produit (vues → achats)
  - Revenus cumulés, commissions plateforme

- [ ] Alertes métriques (F399)
  - "Votre track a été jouée 100 fois" → notification opt-in
  - Pas de gamification : juste une information utile

**Critères d'acceptation**
- [ ] Heatmap visible dans le dashboard analytics d'une track
- [ ] Alertes sont opt-in et peuvent être désactivées

---

### v0.11.2 — Modération Avancée (F411-F420)

**Statut** : ⏳ TODO  
**Priorité** : P1  
**Durée estimée** : 3-4 jours  
**Prerequisite** : v0.10.0 complète  

**Objectif**  
Implémenter le système de modération humaine assistée par règles déterministes (pas de ML).

**Tâches**

- [ ] Interface de modération pour les modérateurs (F411)
  - Queue de contenu flaggé
  - Actions : approve, reject, ban temporaire, ban permanent
  - Référence : ORIGIN_BUSINESS_LOGIC.md §4.2

- [ ] Signalement de contenu par les utilisateurs (F412)
  - Bouton "Signaler" sur les tracks, commentaires, profils
  - Categories : spam, contenu offensant, violation de droits, fake

- [ ] Détection déterministe de spam (F413)
  - Règles : titre/description identique (F413a)
  - Règles : liens excessifs (F413b)
  - Règles : patterns de bot (timing, rate) (F413c)
  - Pas d'IA — uniquement des règles explicites
  - Référence : ORIGIN_BUSINESS_LOGIC.md §4.2

- [ ] Audio fingerprinting ACRCloud (F414)
  - Détection de contenu copyrighted
  - Track matchée → flaggée pour review humaine
  - Référence : ORIGIN_FEATURES_REGISTRY.md F465 note

- [ ] Système de strikes (F415)
  - 3 strikes → suspension temporaire
  - Procédure d'appel documentée

**Critères d'acceptation**
- [ ] La décision finale de modération est TOUJOURS humaine (confirmé dans le code)
- [ ] Un modérateur peut traiter une action en moins de 30 secondes
- [ ] Le créateur reçoit une notification avec la raison en cas de rejection

---

### v0.11.3 — Administration Plateforme (F421-F435)

**Statut** : ⏳ TODO  
**Priorité** : P1  
**Durée estimée** : 3-4 jours  
**Prerequisite** : v0.11.2 complète  

**Tâches**

- [ ] Dashboard admin (F421)
  - Métriques plateforme : utilisateurs actifs, tracks uploadées, revenus
  - Alertes système (taux d'erreur, latence, espace disque)

- [ ] Gestion des utilisateurs (F422)
  - Recherche, vue détaillée, édition du rôle, suspension/ban

- [ ] Gestion du contenu (F423)
  - Supprimer/masquer du contenu en violation

- [ ] Gestion des paiements / litiges (F424)
  - Vue des transactions, déclenchement de remboursements

- [ ] Annonces système (F425)
  - Bannière d'information pour tous les utilisateurs

**Critères d'acceptation**
- [ ] Admin peut bannir un utilisateur en moins de 5 clics
- [ ] Dashboard admin accessible uniquement au rôle `admin` (test de sécurité)

---

## 🔵 PHASE P6R — PREMIUM & INFRASTRUCTURE

> Prerequisite : **Toutes les versions P5R (v0.11.x) sont complètes et validées.**
> Pentest externe réalisé avant ce milestone.

---

### v0.12.0 — Marketplace Complète (F226-F265)

**Statut** : ⏳ TODO  
**Priorité** : P1  
**Durée estimée** : 6-8 jours  
**Prerequisite** : v0.11.0 complète  

**Tâches**

- [ ] Création et gestion de produits (F226)
  - Beats, samples, kits, presets, partitions
  - Types de licences : Basic, Standard, Premium, Exclusive
  - Référence : ORIGIN_BUSINESS_LOGIC.md §1.1

- [ ] Checkout complet via Hyperswitch (F251)
  - Stripe et PayPal configurés comme providers
  - Référence : ORIGIN_BUSINESS_LOGIC.md §2.2

- [ ] Téléchargements sécurisés (F252)
  - URL signées S3 (expire en 24h)
  - Limite de téléchargements par licence

- [ ] Système de commissions automatique (F253)
  - Commission déduite à la vente (15% creator, 10% premium)
  - Référence : ORIGIN_BUSINESS_LOGIC.md §2.1

- [ ] Paiements aux créateurs (F254)
  - Payout hebdomadaire automatique si balance ≥ $50
  - Référence : ORIGIN_BUSINESS_LOGIC.md §2.3

- [ ] Codes promo (F255)
  - Création et gestion par les créateurs et les admins

**Critères d'acceptation**
- [ ] Flow complet : achat → téléchargement → paiement créateur (E2E testé)
- [ ] Commission correctement calculée et documentée
- [ ] Remboursement possible sous 14 jours
- [ ] Aucun dark pattern dans le flow d'achat (audit UX)

---

### v0.12.1 — Plans Premium & Abonnements (F001-F030 business)

**Statut** : ⏳ TODO  
**Priorité** : P1  
**Durée estimée** : 4-5 jours  
**Prerequisite** : v0.12.0 complète  

**Tâches**

- [ ] Plans d'abonnement (Free, Creator, Premium) via Hyperswitch
  - Référence : ORIGIN_BUSINESS_LOGIC.md §1.1

- [ ] Gestion des abonnements (upgrade, downgrade, cancel)
- [ ] Factures automatiques (Stripe Invoicing)
- [ ] Essai gratuit 14 jours pour le plan Premium

**Critères d'acceptation**
- [ ] Annulation sans friction (pas de dark patterns)
- [ ] Accès au plan continue jusqu'à la fin de la période payée

---

### v0.12.2 — Distribution vers Plateformes (F501-F510)

**Statut** : ⏳ TODO  
**Priorité** : P2  
**Durée estimée** : 5-6 jours  
**Prerequisite** : v0.12.1 complète (feature Premium)  

**Tâches**

- [ ] Distribution vers Spotify, Apple Music, Deezer (F501)
  - Via partenaire distribution (DistroKid API ou TuneCore)
  - Disponible uniquement pour les plans Creator et Premium

- [ ] Suivi de la distribution (F502)
  - Statut de chaque plateforme (processing, live, rejected)

- [ ] Revenus de streaming externe (F503)
  - Import des royalties depuis les distributeurs

**Critères d'acceptation**
- [ ] Flow de soumission complète en moins de 5 minutes
- [ ] L'artiste est notifié quand sa track est live sur Spotify

---

### v0.12.3 — Formation & Éducation (F276-F305)

**Statut** : ⏳ TODO  
**Priorité** : P3  
**Durée estimée** : 6-8 jours  
**Prerequisite** : v0.12.0 complète  

**Tâches**

- [ ] Upload et vente de cours vidéo (F276)
- [ ] Lecteur vidéo HLS avec transcoding (F290)
- [ ] Système de modules et leçons (F277)
- [ ] Certificats de complétion (F278) — déclaratifs, pas gamifiés
- [ ] Reviews de cours (F279)

**Critères d'acceptation**
- [ ] Cours vidéo en HLS multi-bitrate
- [ ] Acheteur peut accéder aux cours à vie

---

### v0.12.4 — Performance & Scalabilité

**Statut** : ⏳ TODO  
**Priorité** : P1  
**Durée estimée** : 3-4 jours  
**Prerequisite** : v0.12.2 complète  

**Tâches**

- [ ] CDN pour les assets statiques et audio (CloudFront ou Bunny.net)
- [ ] Cache Redis sur les endpoints fréquents (profils, tracks populaires)
- [ ] Optimisation des requêtes PostgreSQL (EXPLAIN ANALYZE sur les slowest queries)
- [ ] Load testing avec k6 (1000 utilisateurs simultanés)
- [ ] Référence : ORIGIN_PERFORMANCE_TARGETS.md §8.4

**Critères d'acceptation**
- [ ] p95 < 100ms sur les endpoints API principaux
- [ ] Démarrage du lecteur audio < 2 secondes
- [ ] 1000 utilisateurs simultanés sans dégradation (k6 test)

---

### v0.12.5 — PWA & Expérience Mobile (F521-F535 revisités)

**Statut** : ⏳ TODO  
**Priorité** : P2  
**Durée estimée** : 4-5 jours  
**Prerequisite** : v0.12.4 complète  

**Objectif**  
Stratégie PWA (Progressive Web App) en remplacement des apps natives Electron (Module 20 révisé).
Référence : ORIGIN_REVISION_SUMMARY.md §6 Incohérence #2

**Tâches**

- [ ] Service Worker pour offline (lecture des tracks téléchargées)
- [ ] Manifest PWA (installable sur mobile)
- [ ] Push notifications web
- [ ] Contrôles media dans la notification bar (Media Session API)
- [ ] Design responsive optimisé mobile (SUMI design system)

**Critères d'acceptation**
- [ ] Score Lighthouse PWA ≥ 90
- [ ] Player audio fonctionne hors ligne pour les tracks téléchargées
- [ ] Installable sur Android et iOS (via "Ajouter à l'écran d'accueil")

---

### v0.12.6 — Pentest & Audit Sécurité Externe

**Statut** : ⏳ TODO  
**Priorité** : P0 (avant v1.0)  
**Durée estimée** : 2-4 semaines (externe)  
**Prerequisite** : v0.12.4 complète  

**Tâches**

- [ ] Sélectionner et mandater un prestataire de pentest
- [ ] Pentest OWASP Top 10 + ASVS Level 2
- [ ] Corriger tous les findings critiques et hauts
- [ ] Référence : ORIGIN_SECURITY_FRAMEWORK.md §12.4, ORIGIN_REVISION_SUMMARY.md §7

**Critères d'acceptation**
- [ ] Rapport de pentest fourni par le prestataire
- [ ] Aucun finding critique ou haut non résolu
- [ ] Rapport de remédiation documenté

---

### v0.12.7 — Internationalisation (i18n)

**Statut** : ⏳ TODO  
**Priorité** : P2  
**Durée estimée** : 3-4 jours  
**Prerequisite** : v0.12.5 complète  

**Tâches**

- [ ] i18n framework (i18next ou FormatJS)
- [ ] Traductions : Français, Anglais, Espagnol (langues initiales)
- [ ] Détection automatique de la langue navigateur
- [ ] Format des dates, nombres, monnaies selon locale

**Critères d'acceptation**
- [ ] Interface 100% traduite en FR/EN/ES
- [ ] Commutation de langue sans rechargement

---

### v0.12.8 — Documentation & API Publique (F586-F600)

**Statut** : ⏳ TODO  
**Priorité** : P2  
**Durée estimée** : 3-4 jours  
**Prerequisite** : v0.12.6 complète  

**Tâches**

- [ ] Documentation API publique (OpenAPI / Swagger UI)
- [ ] Gestion des clés API pour les développeurs tiers
- [ ] Rate limiting spécifique à l'API publique
- [ ] Référence : ORIGIN_FEATURES_REGISTRY.md F586-F600, ORIGIN_API_SPECIFICATION.md

**Critères d'acceptation**
- [ ] Documentation API navigable en ligne
- [ ] Un développeur externe peut s'authentifier et consommer l'API avec sa clé

---

## 🏁 v1.0.0 — RELEASE STABLE

**Statut** : ⏳ TODO  
**Prerequisite** : Toutes les versions P3.5, P4R, P5R, P6R complètes + pentest OK  

### GO/NO-GO Criteria

Toutes les conditions suivantes doivent être remplies avant de taguer v1.0.0 :

**Sécurité**
- [ ] JWT RS256 en production
- [ ] Aucun secret dans le repo git
- [ ] Pentest externe validé (0 finding critique/haut ouvert)
- [ ] RGPD : export et suppression de compte fonctionnels

**Stabilité**
- [ ] Uptime ≥ 99.9% sur les 30 derniers jours (staging ou beta)
- [ ] Taux d'erreur 5xx < 0.1%
- [ ] Aucun incident P0 non résolu

**Performance**
- [ ] p95 API < 100ms
- [ ] Score Lighthouse Performance ≥ 85
- [ ] Score Lighthouse Accessibility ≥ 90
- [ ] Score Lighthouse PWA ≥ 90

**Qualité**
- [ ] Coverage tests ≥ 70% (Go + Rust)
- [ ] 0 linting error
- [ ] CI/CD verte depuis 2 semaines consécutives

**Éthique (obligatoire)**
- [ ] Audit UX anti-dark-patterns validé par un tiers
- [ ] Aucune donnée comportementale n'est revendue ou partagée
- [ ] Algorithm de découverte documenté et auditable
- [ ] Politique de confidentialité à jour et conforme RGPD

**Business**
- [ ] Flux de paiement testé E2E en production (avec de vrais fonds)
- [ ] Flux de payout créateur testé
- [ ] Support accessible (email ou chat)

---

## 📊 TABLEAU DE SUIVI

| Version | Nom | Phase | Statut | Durée est. | Prerequisite |
|---------|-----|-------|--------|------------|--------------|
| v0.9.1 | JWT Migration RS256 | P3.5 | ✅ DONE | 2-3j | — |
| v0.9.2 | Sécurité Infrastructure | P3.5 | ✅ DONE | 1-2j | v0.9.1 |
| v0.9.3 | Toolchain & Environnement | P3.5 | ✅ DONE | 1j | v0.9.1 |
| v0.9.4 | Quality Gates CI/CD | P3.5 | ⏳ TODO | 2j | v0.9.3 |
| v0.9.5 | Suppression Code Mort | P3.5 | ⏳ TODO | 1-2j | v0.9.4 |
| v0.9.6 | Chat : Réactions & Mentions | P3.5 | ⏳ TODO | 3-4j | v0.9.2 |
| v0.9.7 | Chat : Fichiers & Threads | P3.5 | ⏳ TODO | 3-4j | v0.9.6 |
| v0.9.8 | Dette Technique Backend | P3.5 | ⏳ TODO | 3-4j | v0.9.4 |
| v0.9.9 | Dette Technique Frontend | P3.5 | ⏳ TODO | 2-3j | v0.9.4 |
| v0.10.0 | Feed Social Chronologique | P4R | ⏳ TODO | 4-5j | v0.9.9 |
| v0.10.1 | Découverte Tags & Genres | P4R | ⏳ TODO | 3-4j | v0.10.0 |
| v0.10.2 | Recherche Elasticsearch | P4R | ⏳ TODO | 4-5j | v0.10.1 |
| v0.10.3 | Commentaires & Interactions | P4R | ⏳ TODO | 3-4j | v0.10.0 |
| v0.10.4 | Playlists Collaboratives | P4R | ⏳ TODO | 3-4j | v0.10.0 |
| v0.10.5 | Notifications Complètes | P4R | ⏳ TODO | 2-3j | v0.10.3 |
| v0.10.6 | Livestreaming Basique | P4R | ⏳ TODO | 5-7j | v0.10.0 |
| v0.10.7 | Collaboration Temps Réel | P4R | ⏳ TODO | 5-6j | v0.10.6 |
| v0.10.8 | Portabilité Données RGPD | P4R | ⏳ TODO | 2-3j | v0.10.0 |
| v0.11.0 | Analytics Créateur | P5R | ⏳ TODO | 4-5j | v0.10.3 |
| v0.11.1 | Analytics Avancés | P5R | ⏳ TODO | 3-4j | v0.11.0 |
| v0.11.2 | Modération Avancée | P5R | ⏳ TODO | 3-4j | v0.10.0 |
| v0.11.3 | Administration Plateforme | P5R | ⏳ TODO | 3-4j | v0.11.2 |
| v0.12.0 | Marketplace Complète | P6R | ⏳ TODO | 6-8j | v0.11.0 |
| v0.12.1 | Plans Premium & Abonnements | P6R | ⏳ TODO | 4-5j | v0.12.0 |
| v0.12.2 | Distribution Plateformes | P6R | ⏳ TODO | 5-6j | v0.12.1 |
| v0.12.3 | Formation & Éducation | P6R | ⏳ TODO | 6-8j | v0.12.0 |
| v0.12.4 | Performance & Scalabilité | P6R | ⏳ TODO | 3-4j | v0.12.2 |
| v0.12.5 | PWA & Mobile | P6R | ⏳ TODO | 4-5j | v0.12.4 |
| v0.12.6 | Pentest Externe | P6R | ⏳ TODO | 2-4 sem. | v0.12.4 |
| v0.12.7 | Internationalisation | P6R | ⏳ TODO | 3-4j | v0.12.5 |
| v0.12.8 | Documentation & API Publique | P6R | ⏳ TODO | 3-4j | v0.12.6 |
| **v1.0.0** | **Release Stable** | — | ⏳ TODO | — | Tout + pentest |

---

## 📐 INSTRUCTIONS POUR CURSOR

> Quand tu reçois "implémente la prochaine version", exécute les étapes suivantes :

### Étape 1 : Identifier la prochaine version
Chercher dans ce fichier la première version avec **Statut : ⏳ TODO** dans l'ordre du tableau de suivi.

### Étape 2 : Vérifier les prerequisites
Confirmer que toutes les versions listées dans "Prerequisite" ont le statut ✅ DONE.
Si non : signaler le blocage et ne pas continuer.

### Étape 3 : Lire les références ORIGIN
Lire les fichiers ORIGIN mentionnés dans les tâches de la version (dans le dossier ORIGIN/ du repo).
Ces fichiers contiennent les spécifications détaillées, les ADR, et les standards éthiques.

### Étape 4 : Implémenter
Implémenter toutes les tâches de la version, en suivant :
- `ORIGIN/ORIGIN_CODE_STANDARDS.md` pour les conventions
- `ORIGIN/ORIGIN_FEATURE_VALIDATION_STRATEGY.md` pour la checklist de validation
- `ORIGIN/ORIGIN_ERROR_PATTERNS.md` et `ORIGIN_ERROR_PREVENTION_GUIDE.md` pour éviter les patterns problématiques
- `ORIGIN/ORIGIN_UI_UX_SYSTEM.md` §13 anti-patterns et §14 patterns positifs pour le frontend

### Étape 5 : Valider
Pour chaque tâche implémentée :
- Exécuter les tests (`make test`)
- Vérifier les critères d'acceptation listés dans ce fichier
- Vérifier la checklist ORIGIN_FEATURE_VALIDATION_STRATEGY.md

### Étape 6 : Mettre à jour ce fichier
Une fois la version complète et validée :
- Changer le statut de `⏳ TODO` à `✅ DONE`
- Ajouter la date de completion : `**Complété le** : YYYY-MM-DD`
- Mettre à jour le tableau de suivi

### Étape 7 : Créer le tag git
```bash
git tag -a v0.X.Y -m "Version v0.X.Y : [Nom de la version]"
git push origin v0.X.Y
```

---

## 🚫 RÈGLES IMMUABLES POUR CURSOR

1. **Ne jamais implémenter de code AI/ML** — les modules F456-F470 sont supprimés définitivement
2. **Ne jamais implémenter de code blockchain/Web3** — les modules F491-F500 sont supprimés définitivement  
3. **Ne jamais implémenter de gamification** (XP, streaks, leaderboards) — les modules F536-F550 sont supprimés définitivement
4. **Ne jamais exposer de métriques de popularité publiquement** — les likes et plays sont privés (créateur uniquement)
5. **Ne jamais implémenter de dark patterns UX** — référence : ORIGIN_UI_UX_SYSTEM.md §13
6. **Ne jamais modifier les fichiers ORIGIN/** — ils sont la référence, pas le code
7. **Ne jamais déployer en production sans que les critères d'acceptation soient vérifiés**
8. **Si une tâche semble contredire un fichier ORIGIN, la priorité va au fichier ORIGIN** — signaler l'incohérence

---

*Document versionné. Toute modification de ce fichier doit être commitée avec le message : `docs: update VEZA_VERSIONS_ROADMAP [raison]`*

*Référence architecture : ORIGIN/ORIGIN_MASTER_ARCHITECTURE.md*  
*Référence éthique : ORIGIN/ORIGIN_REVISION_SUMMARY.md*  
*Référence sécurité : ORIGIN/ORIGIN_SECURITY_FRAMEWORK.md*