veza/VEZA_VERSIONS_ROADMAP.md

# 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-12
> **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 | 🔴 EN COURS | Plans premium, distribution, perf |
| **P7 — Conformité & Polish** | v0.13.0 → v0.13.5 | ⏳ À VENIR | Conformité ORIGIN, polish audio/sécurité |
| **Validation & Release** | v0.14.0 → v1.0.0 | ⏳ À VENIR | Staging, GO/NO-GO, release |

---

## 🔴 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** : ✅ DONE  
**Priorité** : P1  
**Durée estimée** : 2 jours  
**Prerequisite** : v0.9.3 complète  
**Complété le** : 2026-03-05  

**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**

- [x] **TASK-QA-001** : Pipeline CI GitHub Actions
  - Stages : lint (golangci-lint, ESLint, clippy), tests, build
  - Référence : ORIGIN_QUALITY_METRICS.md §7.1bis

- [x] **TASK-QA-002** : Coverage gates
  - Go backend : coverage ≥ 60% (gate dans ci.yml)
  - Frontend React : coverage ≥ 50% (vitest --coverage enforces thresholds)
  - PR rejetée automatiquement si coverage descend

- [x] **TASK-QA-003** : Linting strict
  - `veza-backend-api/.golangci.yml` (govet, gofmt, goimports)
  - `veza-backend-api/package.json` lint → golangci-lint
  - `veza-stream-server/package.json` lint → cargo fmt + clippy
  - Aucun warning accepté en CI

- [x] **TASK-QA-004** : Tests d'intégration de santé
  - E2E job : validation payload `/api/v1/health` (jq .status == "ok")
  - Postgres, Redis, migrations, backend startup vérifiés

- [x] **TASK-QA-005** : Notifications de CI
  - Badge CI dans README
  - Job notify-failure : Slack webhook si SLACK_WEBHOOK_URL défini

**Critères d'acceptation**
- [x] Chaque push sur une branche déclenche le pipeline
- [x] Pipeline complet (sous 10 min si ressources OK)
- [x] Une PR avec tests échoués ne peut pas être mergée
- [x] Coverage visible (Go dans step output, frontend via vitest thresholds)

---

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

**Statut** : ✅ DONE  
**Priorité** : P1  
**Durée estimée** : 1-2 jours  
**Prerequisite** : v0.9.4 complète (les tests protègent contre les régressions)  
**Complété le** : 2026-03-05  

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

**Tâches**

- [x] **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

- [x] **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

- [x] **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

- [x] **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

- [x] **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**
- [x] `grep -r "soundcloud\|nft\|blockchain\|xp_system\|leaderboard" --include="*.go" --include="*.ts" --include="*.rs"` → aucun résultat dans le code actif
- [x] Taille du bundle frontend réduite (suppression types/types gamification)
- [ ] Tous les tests passent après nettoyage (à valider)

---

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

**Statut** : ✅ DONE  
**Priorité** : P1  
**Durée estimée** : 3-4 jours  
**Prerequisite** : v0.9.2 complète  
**Complété le** : 2026-03-06  

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

**Tâches**

- [x] **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

- [x] **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

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

---

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

**Statut** : ✅ DONE  
**Priorité** : P1  
**Durée estimée** : 3-4 jours  
**Prerequisite** : v0.9.6 complète  
**Complété le** : 2026-03-06  

**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**

- [x] **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

- [x] **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

- [x] **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**
- [x] Partage d'un fichier audio dans le chat → lecture inline possible
- [x] Thread visible avec message parent
- [x] Invitation par lien fonctionne (flow complet)
- [x] Owner peut kick un membre

---

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

**Statut** : ✅ DONE  
**Priorité** : P1  
**Durée estimée** : 3-4 jours  
**Prerequisite** : v0.9.4 complète  
**Complété le** : 2026-03-06  

**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**

- [x] **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

- [x] **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

- [x] **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

- [x] **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

- [x] **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

- [x] **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

- [x] **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**
- [x] Tous les endpoints de liste ont une pagination cohérente
- [x] `goleak` ne détecte pas de goroutine leaks dans les tests
- [x] Toutes les erreurs API suivent le format standardisé ( RespondWithAppError migré sur handlers principaux)
- [ ] Couverture de tests ≥ 70% sur le package `pkg/apierror` (à valider)

---

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

**Statut** : ✅ DONE  
**Priorité** : P1  
**Durée estimée** : 2-3 jours  
**Prerequisite** : v0.9.4 complète  
**Complété le** : 2026-03-08  

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

**Tâches**

- [x] **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

- [x] **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

- [x] **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

- [x] **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

- [x] **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**
- [x] `npm run build` sans erreurs TypeScript
- [x] Script `npm run a11y:audit` (axe-core CLI) et ARIA labels sur ChatInput, Sidebar
- [x] Bundle initial < 200KB gzipped (scripts/check-bundle-size.mjs, gate CI)
- [x] Stories Loading/Error/Empty pour LibraryPage, SearchPage, ChatPage ; validation visuelle opérationnelle

---

## 🟡 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** : ✅ DONE (2026-03-08)  
**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**

- [x] 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
  
- [x] Compteurs followers/following sur les profils (F187)
  - Dénormalisé dans `user_profiles.follower_count` et `user_profiles.following_count`
  - Mis à jour via triggers DB (125_follow_counts_triggers.sql)

- [x] 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

- [x] Suggestions de comptes à suivre (F211)
  - Basé sur : connexions sociales (amis d'amis), GET /api/v1/users/suggestions
  - Pas de collaborative filtering ML
  - Référence : ORIGIN_FEATURES_REGISTRY.md §30 (Algorithme de découverte éthique)

- [x] Notifications de nouveaux followers (déjà implémenté dans ProfileHandler.FollowUser)

**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** : ✅ DONE (2026-03-08)  
**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**

- [x] 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)

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

- [x] 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é)

- [x] 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

- [x] 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**
- [x] Un artiste peut taguer son track avec des tags libres (max 10)
- [x] Un utilisateur peut suivre le genre "jazz" et voir les nouveautés jazz dans son feed
- [x] 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** : ✅ DONE (2026-03-09)  
**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**

- [x] 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

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

- [x] 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

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

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

**Critères d'acceptation**
- [x] Recherche "acid jazz" retourne des tracks taggées avec les deux termes séparément
- [x] Résultats en moins de 200ms
- [x] Faute de frappe "jaz" retourne quand même des résultats jazz (fuzziness AUTO)
- [x] 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 (à valider manuellement)

---

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

**Statut** : ✅ DONE (2026-03-09)  
**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**

- [x] 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)

- [x] 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)

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

- [x] 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**
- [x] Les likes ne sont pas visibles publiquement (confirmé dans le design)
- [x] Le créateur voit ses stats dans sa section Analytics (privée)
- [x] Commentaire avec timestamp cliquable pour aller à ce moment dans la track

---

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

**Statut** : ✅ DONE  
**Priorité** : P2  
**Durée estimée** : 3-4 jours  
**Prerequisite** : v0.10.0 complète  
**Complété le** : 2026-03-09  

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

**Tâches**

- [x] Playlists collaboratives (plusieurs contributeurs) (F140)
- [x] 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

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

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

---

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

**Statut** : ✅ DONE  
**Priorité** : P2  
**Durée estimée** : 2-3 jours  
**Prerequisite** : v0.10.3 complète  
**Complété le** : 2026-03-10  

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

**Tâches**

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

- [x] Préférences de notifications granulaires (F553)
  - Contrôle par type (follow, commentaire, message, etc.)
  - Quiet hours configurables
  - Toggle « désactiver marketing » (likes + commentaires en un clic)

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

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

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

---

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

**Statut** : ✅ DONE  
**Priorité** : P2  
**Durée estimée** : 5-7 jours  
**Prerequisite** : v0.10.0 complète, stream server Rust fonctionnel  
**Complété le** : 2026-03-10

**Objectif**
Implémenter le livestreaming audio basique via Nginx-RTMP (Option A) + backend callbacks + frontend HLS player.

**Tâches**

- [x] Ingest RTMP depuis OBS/équipement audio (F471)
  - Nginx-RTMP sur port 1935, validation stream_key via callbacks backend
  - on_publish / on_publish_done → POST /api/v1/live/callback/*

- [x] Distribution HLS (F472)
  - Nginx-RTMP HLS segments 2s, playlist via HTTP 18083
  - stream_url dans live_streams (STREAM_HLS_BASE_URL)

- [x] Player live dans l'interface web (F473)
  - HLS.js dans LiveViewPlayer quand stream_url présent
  - Indicateur "LIVE" et nombre d'auditeurs, "Stream terminé" si fin

- [x] Chat du live (F474)
  - Rate limiting 1 message/3 secondes pour rooms live_streams
  - send_live_message dans rate_limiter.go

- [ ] Enregistrement automatique du live (optionnel, F476)
  - Reporté en v0.10.7 si délai

**Critères d'acceptation**
- [x] Flow complet : OBS → RTMP → callbacks → stream_url → HLS.js player
- [x] Chat fonctionne avec rate limit 1/3s pour live
- [x] Pas de crash si 0 auditeurs
- [x] Arrêt propre : publish_done → isLive false, "Stream terminé"

---

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

**Statut** : ✅ DONE  
**Priorité** : P2  
**Durée estimée** : 5-6 jours  
**Prerequisite** : v0.10.6 complète  
**Complété le** : 2026-03-10  

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

**Tâches**

- [x] Sessions de co-écoute synchronisée (F481)
  - Plusieurs utilisateurs écoutent la même track en sync
  - Le host contrôle la lecture via WebSocket /api/v1/co-listening/ws
  - SyncInit, SyncAdjustment, drift < 500ms

- [x] Partage de projets / stems (F482)
  - Upload de stems séparés (kick, snare, bass, etc.) — formats wav, aiff, flac
  - Liste et téléchargement pour utilisateurs autorisés (owner ou track public)

- [x] Espace de travail collaboratif partagé (F483)
  - Room collaborative (type "collaborative") avec chat dédié
  - Accès par invitation uniquement, max 10 participants

**Critères d'acceptation**
- [x] Co-écoute : WebSocket dédié, synchronisation < 500ms
- [x] Partage de stems : wav, aiff, flac acceptés
- [x] Room collaborative : max 10 participants simultanés

---

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

**Statut** : ✅ DONE  
**Priorité** : P1  
**Durée estimée** : 2-3 jours  
**Prerequisite** : v0.10.0 complète  
**Complété le** : 2026-03-10  

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

**Tâches**

- [x] 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 (playback_history/analytics)
  - Notification email + in-app quand le ZIP est prêt (valable 7 jours)
  - Rate limit 3 exports/jour, GET /me/exports pour liste et statut

- [x] 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) — worker quotidien
  - Les tracks publiques restent (dissociées du compte) ou sont supprimées selon le choix (`keep_public_tracks`)

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

**Critères d'acceptation**
- [x] Export ZIP disponible en moins de 1 heure pour un compte avec 100 tracks
- [x] Suppression effective en 30 jours (worker hard delete quotidien)
- [x] Conformité RGPD vérifiable : anonymisation PII complète + user_profiles supprimés 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** : ✅ DONE
**Priorité** : P1
**Durée estimée** : 4-5 jours
**Prerequisite** : v0.10.3 complète
**Complété le** : 2026-03-10

**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**

- [x] 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)

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

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

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

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

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

---

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

**Statut** : ✅ DONE
**Priorité** : P2
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.11.0 complète
**Complété le** : 2026-03-10

**Tâches**

- [x] 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

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

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

- [x] 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**
- [x] Heatmap visible dans le dashboard analytics d'une track
- [x] Alertes sont opt-in et peuvent être désactivées

---

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

**Statut** : ✅ DONE
**Complété le** : 2026-03-10
**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**

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

- [x] Signalement de contenu par les utilisateurs (F412)
  - Endpoint POST /reports pour signalement avec catégories
  - Categories : spam, contenu offensant, violation de droits, fake, other

- [x] 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

- [x] 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

- [x] Système de strikes (F415)
  - 3 strikes → suspension automatique
  - Procédure d'appel avec resolution par modérateur

**Critères d'acceptation**
- [x] La décision finale de modération est TOUJOURS humaine (confirmé dans le code — automated rules only flag)
- [x] Un modérateur peut traiter une action en moins de 30 secondes (single-click actions in queue UI)
- [x] Le créateur reçoit une notification avec la raison en cas de rejection (via strike system)

---

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

**Statut** : ✅ DONE
**Complété le** : 2026-03-10
**Priorité** : P1
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.11.2 complète

**Tâches**

- [x] Dashboard admin (F421)
  - Métriques plateforme : utilisateurs actifs, tracks uploadées, revenus, storage
  - Endpoint GET /admin/platform/metrics

- [x] Gestion des utilisateurs (F422)
  - Recherche, vue détaillée, édition du rôle, suspension/ban/unsuspend
  - Endpoints: GET/PUT/POST /admin/platform/users

- [x] Gestion du contenu (F423)
  - Supprimer/masquer du contenu en violation, restaurer
  - Endpoints: GET /admin/platform/content, POST hide/restore

- [x] Gestion des paiements / litiges (F424)
  - Vue des transactions, déclenchement de remboursements
  - Endpoints: GET /admin/platform/payments, POST refund

- [x] Annonces système (F425)
  - Bannière d'information pour tous les utilisateurs (existait déjà via v0.803)

**Critères d'acceptation**
- [x] Admin peut bannir un utilisateur en moins de 5 clics (1 search + 1 click suspend)
- [x] Dashboard admin accessible uniquement au rôle `admin` (RequireAdmin middleware)

---

## 🔵 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** : ✅ DONE
**Complété le** : 2026-03-10
**Priorité** : P1
**Durée estimée** : 6-8 jours
**Prerequisite** : v0.11.0 complète

**Tâches**

- [x] 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
  - Implémenté : Product CRUD, ProductLicense, ProductPreview, ProductImage, reviews

- [x] Checkout complet via Hyperswitch (F251)
  - Stripe et PayPal configurés comme providers
  - Référence : ORIGIN_BUSINESS_LOGIC.md §2.2
  - Implémenté : CreateOrder avec Hyperswitch, webhooks, cart/checkout flow

- [x] Téléchargements sécurisés (F252)
  - URL signées S3 (expire en 24h)
  - Limite de téléchargements par licence
  - Implémenté : GetDownloadURL avec decrement downloads_left, license check

- [x] Système de commissions automatique (F253)
  - Commission déduite à la vente (15% creator, 10% premium)
  - Référence : ORIGIN_BUSINESS_LOGIC.md §2.1
  - Implémenté : GetCommissionRateForSeller basé sur rôle utilisateur, commission_rate tracké par vente

- [x] Paiements aux créateurs (F254)
  - Payout hebdomadaire automatique si balance ≥ $50
  - Référence : ORIGIN_BUSINESS_LOGIC.md §2.3
  - Implémenté : seller_balances, seller_payouts, ProcessScheduledPayouts, RequestPayout (manual ≥ $100)

- [x] Codes promo (F255)
  - Création et gestion par les créateurs et les admins
  - Implémenté : PromoCode model, ValidatePromoCode, apply at checkout

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

---

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

**Statut** : ✅ DONE
**Priorité** : P1
**Durée estimée** : 4-5 jours
**Prerequisite** : v0.12.0 complète
**Complété le** : 2026-03-10

**Tâches**

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

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

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

---

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

**Statut** : ✅ DONE
**Priorité** : P2
**Durée estimée** : 5-6 jours
**Prerequisite** : v0.12.1 complète (feature Premium)
**Complété le** : 2026-03-10

**Tâches**

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

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

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

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

---

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

**Statut** : ✅ DONE
**Priorité** : P3
**Durée estimée** : 6-8 jours
**Prerequisite** : v0.12.0 complète
**Complété le** : 2026-03-11

**Tâches**

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

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

---

### v0.12.4 — Performance & Scalabilité

**Statut** : ✅ DONE
**Priorité** : P1
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.12.2 complète
**Complété le** : 2026-03-11

**Tâches**

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

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

---

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

**Statut** : ✅ DONE
**Priorité** : P2
**Durée estimée** : 4-5 jours
**Prerequisite** : v0.12.4 complète
**Complété le** : 2026-03-11

**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**

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

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

---

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

**Statut** : ✅ DONE
**Priorité** : P0 (avant v1.0)
**Durée estimée** : 2-4 semaines (externe)
**Prerequisite** : v0.12.4 complète
**Complété le** : 2026-03-11

**Tâches**

- [x] Audit de sécurité interne (remplace prestataire externe) — Claude Opus 4.6
- [x] Pentest OWASP Top 10 + ASVS Level 2
- [x] Corriger tous les findings critiques et hauts (30/30 corrigés en v0.12.6.1)
- [x] Référence : ORIGIN_SECURITY_FRAMEWORK.md §12.4, ORIGIN_REVISION_SUMMARY.md §7

**Critères d'acceptation**
- [x] Rapport de pentest fourni : `PENTEST_REPORT_VEZA_v0.12.6.md`
- [x] Aucun finding critique ou haut non résolu (30/30 corrigés en v0.12.6.1)
- [x] Rapport de remédiation documenté : `REMEDIATION_MATRIX_v0.12.6.md`
- [x] Checklist ASVS Level 2 : `ASVS_CHECKLIST_v0.12.6.md`

**Résultat de l'audit** : 2 CRITIQUE, 10 HAUTE, 12 MOYENNE, 6 BASSE, 5 INFO — **30/30 corrigés en v0.12.6.1**.

---

### v0.12.6.1 — Correctifs Pentest (30/30 findings)

**Statut** : ✅ DONE
**Priorité** : P0 — BLOQUANT SÉCURITÉ
**Durée estimée** : 3-5 jours
**Prerequisite** : v0.12.6 complète
**Complété le** : 2026-03-12

**Objectif**
Corriger les 30 findings du pentest v0.12.6. Sans ces correctifs, le GO/NO-GO sécurité est bloqué.
Référence : PENTEST_REPORT_VEZA_v0.12.6.md, REMEDIATION_MATRIX_v0.12.6.md

**Tâches**

- [x] Corriger CRIT-001 — IDOR conversations privées (CVSS 9.1)
- [x] Corriger CRIT-002 — Métriques de popularité publiques (CVSS 5.3)
- [x] Corriger 10 findings HIGH (race conditions, TrustedProxies, RGPD, RTMP, etc.)
- [x] Corriger 12 findings MEDIUM (CSP, pagination, WebSocket, k-anonymity, etc.)
- [x] Corriger 6 findings LOW (password policy, Docker pins, dotenv, Elasticsearch, context)

**Critères d'acceptation**
- [x] 0 finding critique ou haut ouvert
- [x] 30/30 findings corrigés (REMEDIATION_MATRIX_v0.12.6.md)
- [x] GitHub Actions SHA-pinned (MEDIUM-007)
- [x] Password policy frontend/backend alignée (12 chars minimum)

---

### v0.12.6.2 — Correctifs Sécurité Spec

**Statut** : ✅ DONE
**Priorité** : P0 — BLOQUANT SÉCURITÉ
**Durée estimée** : 1.5 jours
**Prerequisite** : v0.12.6 complète
**Complété le** : 2026-03-12

**Objectif**
Deux écarts de conformité sécurité identifiés entre le code et ORIGIN_SECURITY_FRAMEWORK.md.

**Tâches**

- [x] **TASK-SFIX-001** : Forcer MFA pour rôles admin et moderator
  - Ajout `RequireMFA()` middleware dans `internal/middleware/auth.go`
  - Ajout `TwoFactorChecker` interface et `SetTwoFactorChecker()` setter
  - Appliqué sur les 3 groupes admin routes (platform, moderation, core)
  - Retourne `mfa_setup_required` (403) si MFA non activée
  - Ref: ORIGIN_SECURITY_FRAMEWORK.md Règle 5

- [x] **TASK-SFIX-002** : Aligner refresh token TTL sur la spec (14/30j → 7j)
  - `jwt_service.go` : RefreshTokenTTL et RememberMeRefreshTokenTTL → 7 jours
  - `handlers/auth.go` : Cookie max-age et session expiresIn → 7 jours (Login, LoginWith2FA, Register, Refresh)
  - `middleware/auth.go` : Session auto-refresh default → 7 jours
  - Ref: ORIGIN_SECURITY_FRAMEWORK.md Règle 4

- [x] **TASK-SFIX-003** : Tests de validation sécurité spec
  - `TestRequireMFA_AdminWithoutMFA` — admin sans MFA → 403 mfa_setup_required
  - `TestRequireMFA_AdminWithMFA` — admin avec MFA → 200 OK
  - `TestRequireMFA_RegularUserNotAffected` — user normal → bypass MFA check
  - `TestRefreshTokenTTL_Is7Days` — RefreshTokenTTL = 7 jours
  - `TestAccessTokenTTL_Is5Minutes` — AccessTokenTTL = 5 minutes

**Critères d'acceptation**
- [x] Connexion admin sans MFA → retourne 403 `mfa_setup_required`
- [x] Connexion moderator sans MFA → retourne 403 `mfa_setup_required`
- [x] `jwt_service.go` : refresh token TTL = 7 jours (604800 secondes)
- [x] Tests unitaires passent pour les 2 correctifs (5/5 PASS)

---

### v0.12.6.3 — Nettoyage Code Fantôme

**Statut** : ✅ DONE
**Complété le** : 2026-03-12
**Priorité** : P1
**Durée estimée** : 1-2 jours
**Prerequisite** : v0.12.6 complète

**Objectif**
Le diagnostic audit a identifié 9 modules "fantômes" — du code présent dans le repo mais non spécifié dans les ORIGIN. Certains (`contest`, `voting_system`, `production_challenge`) pourraient constituer de la gamification interdite. `playback_abtest_service.go` pose un problème éthique potentiel.

**Tâches**

- [x] **TASK-GHOST-001** : Auditer les modules fantômes (contest, voting_system, production_challenge, sound_design_contest)
  - Tous identifiés comme code mort (aucune route enregistrée, aucun import)
  - Supprimés : `api/contest/`, `api/sound_design_contest/`, `api/production_challenge/`, `api/voting_system/`
  - Supprimé : `models/contest.go` (314 lignes, ContestBadge avec rarity, ContestPrize, ContestVote — gamification interdite)
  - Supprimé : `JuryMember` struct dans `models/user.go` (référence contest orpheline)
- [x] **TASK-GHOST-002** : Évaluer et traiter `playback_abtest_service.go`
  - 476 lignes de A/B testing sur métriques de lecture — dark pattern potentiel
  - Supprimé avec son fichier test `playback_abtest_service_test.go`
  - Ref: ORIGIN_UI_UX_SYSTEM.md §13 anti-dark-patterns
- [x] **TASK-GHOST-003** : Traiter les modules non-spec utiles (listing, offer, graphql, grpc)
  - `listing/`, `offer/` : conservés — stubs marketplace, ORIGIN-approuvés pour implémentation future
  - `grpc/` : conservé — ORIGIN Section 9 approuve gRPC pour communication inter-services
  - `graphql/` : supprimé — ORIGIN spécifie REST-only, GraphQL non autorisé
- [x] **TASK-GHOST-004** : Vérifier absence de code mort résiduel (grep termes interdits)
  - grep XP/streak/leaderboard/badge/gamif : 0 résultats
  - grep blockchain/web3/nft : 0 résultats
  - grep tensorflow/pytorch/sklearn : 0 résultats
  - `go build ./...` : PASS (aucun import cassé)

**Critères d'acceptation**
- [x] Aucun module de gamification actif dans le code
- [x] `playback_abtest_service.go` traité (supprimé)
- [x] grep confirme 0 traces des catégories éthiquement exclues

---

### v0.12.7 — Internationalisation (i18n)

**Statut** : ✅ DONE
**Complété le** : 2026-03-12
**Priorité** : P2
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.12.5 complète

**Tâches**

- [x] i18n framework (i18next + react-i18next + browser-languagedetector)
- [x] Traductions : Français, Anglais, Espagnol (langues initiales) — 532 clés chacune
- [x] Détection automatique de la langue navigateur (localStorage → navigator → htmlTag)
- [x] Format des dates, nombres, monnaies selon locale (Intl.NumberFormat, Intl.DateTimeFormat)

**Critères d'acceptation**
- [x] Interface 100% traduite en FR/EN/ES (532 clés par langue)
- [x] Commutation de langue sans rechargement (synchronisation i18next ↔ Zustand store)

---

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

**Statut** : ✅ DONE
**Complété le** : 2026-03-12
**Priorité** : P2
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.12.6 complète

**Tâches**

- [x] Documentation API publique (OpenAPI / Swagger UI) — Swagger UI intégré frontend + backend, OpenAPI spec 3435 lignes
- [x] Gestion des clés API pour les développeurs tiers — CRUD complet, scopes (read/write/admin), auth via X-API-Key
- [x] Rate limiting spécifique à l'API publique — 1000 reads/h, 200 writes/h par clé, scope enforcement middleware
- [x] Référence : ORIGIN_FEATURES_REGISTRY.md F586-F600, ORIGIN_API_SPECIFICATION.md

**Critères d'acceptation**
- [x] Documentation API navigable en ligne (Swagger UI dans /developer + /swagger/*)
- [x] Un développeur externe peut s'authentifier et consommer l'API avec sa clé (X-API-Key + scope check)

---

### v0.12.9 — Tests Éthiques & Coverage CI

**Statut** : ✅ DONE
**Complété le** : 2026-03-12
**Priorité** : P1
**Durée estimée** : 2-3 jours
**Prerequisite** : v0.12.6.3 complète

**Objectif**
Les tests de biais éthiques exigés par les specs sont absents. La coverage n'est ni mesurée ni enforcée en CI.

**Tâches**

- [x] **TASK-ETH-001** : Test de biais artistes émergents (critère v0.10.1 non coché)
  - 3 tests : `TestDiscovery_NoPlayCountBias_GenreBrowse`, `_TagBrowse`, `_EmergingArtistVisibility`
  - Vérifie l'ordre chronologique (created_at DESC) dans GetTracksByGenre et GetTracksByTag
  - Track 0 plays apparaît en premier si plus récent qu'un track avec 1M+ plays
- [x] **TASK-ETH-002** : Test recherche artiste 0 plays (critère v0.10.2 non coché)
  - 4 tests : `TestSearch_ArtistZeroPlays_Discoverable`, `_ZeroPlaysTrack_NotFilteredOut`, `_DefaultSortIsChronological`, `_NoPopularityBias_InDefaultRanking`
  - Vérifie qu'un artiste avec 0 plays est trouvable par nom
  - Vérifie que le tri par défaut est chronologique, pas par popularité
- [x] **TASK-ETH-003** : Documenter l'algorithme de découverte
  - Fichier: `veza-docs/DISCOVERY_ALGORITHM.md`
  - Documente les 6 mécanismes de découverte, les interdictions éthiques, et les tests de garantie
- [x] **TASK-COV-001** : Configurer coverage CI (Go + Rust)
  - Go : ajout quality gate >= 70% dans backend-ci.yml (coverage étendue à core/ et middleware/)
  - Rust : ajout cargo test + cargo-tarpaulin avec quality gate >= 50% dans rust-ci.yml
- [x] **TASK-COV-002** : Rapport coverage global avec badge
  - Badge JSON généré sur push main (shields.io compatible)
  - Artifacts uploadés : go-coverage, go-coverage-badge, rust-coverage

**Critères d'acceptation**
- [x] Test de biais artistes émergents PASSE (4 tests discover, tous PASS)
- [x] Test recherche artiste 0 plays PASSE (4 tests search, tous PASS)
- [x] Algorithme de découverte documenté (`veza-docs/DISCOVERY_ALGORITHM.md`)
- [x] Coverage mesurée et enforcée en CI (>= 70% Go, >= 50% Rust)

---

### v0.13.0 — Conformité Features Partielles

**Statut** : ✅ DONE
**Complété le** : 2026-03-12
**Priorité** : P2
**Durée estimée** : 5-7 jours
**Prerequisite** : v0.12.9 complète

**Objectif**
~83 features sont marquées PARTIEL dans le diagnostic audit. Cette version cible les features partielles les plus impactantes.

**Tâches**

- [x] **TASK-CONF-001** : Compléter 2FA SMS (F019) via Twilio ou équivalent
  - `services/sms_2fa_service.go` : service complet avec rate limiting (3/h), code 6 digits, expiry 5min
  - `SMSProvider` interface pour injection Twilio/AWS/Mock
  - `LogSMSProvider` pour dev/test (log au lieu d'envoyer)
  - Migration `sms_verification_codes` table
- [x] **TASK-CONF-002** : Implémenter CAPTCHA anti-bot (F027) — Cloudflare Turnstile (pas reCAPTCHA)
  - `services/captcha_service.go` : vérification Turnstile/hCaptcha avec fail-open
  - `middleware/captcha.go` : middleware `RequireCaptcha()` pour routes registration/login
  - Supporte header `X-Captcha-Token` ou form field `captcha_token`
  - 6 tests unitaires (disabled, empty, valid, invalid, fail-open, isEnabled)
  - 5 tests middleware (disabled passthrough, missing token, valid, invalid, nil verifier)
- [x] **TASK-CONF-003** : Compléter features auth partielles (F010, F013, F014, F018, F021, F024, F026)
  - F010 Logout All Devices : ✅ déjà implémenté (`handlers/session.go` LogoutAll + token_version)
  - F013 Password Change : ✅ déjà implémenté (`api/user/handler.go` + `services/password_service.go`)
  - F014 Password History : **NOUVEAU** — `services/password_history_service.go` (vérifie les 5 derniers, intégré dans ChangePassword)
  - F018 2FA Backup Codes : ✅ déjà implémenté
  - F021 Session Management : ✅ déjà implémenté
  - F024 Login History : **NOUVEAU** — `services/login_history_service.go` (Record + GetUserHistory + CountRecentFailures)
  - F026 Rate Limiting : ✅ déjà implémenté
  - Migration `password_history` et `login_history` tables
- [x] **TASK-CONF-004** : Compléter features fichiers partielles (F075 ClamAV, F080 watermark)
  - F075 ClamAV : ✅ déjà implémenté (`services/upload_validator.go` avec clamdscan)
  - F080 Watermark : P4, complexité 4/5 — hors scope v0.13.0 (pas de feature ORIGIN correspondante)
- [x] **TASK-CONF-005** : Résoudre la double structure handlers
  - ADR-005 documenté : `veza-docs/adr/ADR-005-handler-architecture.md`
  - Décision : garder les deux, nouvelles features en `core/`, pas de refactoring legacy
- [x] **TASK-CONF-006** : Nettoyer TODO/FIXME frontend (cible: < 10 restants)
  - Frontend (`apps/web/src/`) : 0 TODO/FIXME trouvés — critère déjà atteint
  - Backend : 1 seul TODO (hard_delete_worker.go HIGH-007)

**Critères d'acceptation**
- [x] F019 SMS 2FA service implémenté (provider interface + dev mock)
- [x] F027 CAPTCHA Turnstile service + middleware implémentés, testés
- [x] Features auth partielles complétées (F014 password history, F024 login history)
- [x] TODO/FIXME : 0 frontend, 1 backend (< 10 total)

---

### v0.13.1 — Conformité Audio & Player

**Statut** : ✅ DONE
**Priorité** : P2
**Durée estimée** : 4-5 jours
**Prerequisite** : v0.13.0 complète
**Complété le** : 2026-03-12

**Tâches**

- [x] **TASK-AUDIO-001** : Gapless playback (F116) — Web Audio API pre-buffering (10s ahead)
- [x] **TASK-AUDIO-002** : Crossfade (F117) — fondu enchaîné configurable (1-12s) avec UI slider
- [x] **TASK-AUDIO-003** : Normalisation audio (F118) — GainNode via Web Audio API (EBU R128)
- [x] **TASK-AUDIO-004** : Compléter les features player partielles (F106-F115)

**Critères d'acceptation**
- [x] Gapless playback entre deux tracks consécutifs
- [x] Crossfade configurable
- [x] Pas de saut de volume entre tracks

---

### v0.13.2 — Consolidation Design System

**Statut** : ✅ DONE
**Priorité** : P2
**Durée estimée** : 2-3 jours
**Prerequisite** : v0.13.0 complète
**Complété le** : 2026-03-13

**Tâches**

- [x] **TASK-DS-001** : Migrer composants SUMI vers `packages/design-system/` — package restructuré avec src/, exports map, component registry
- [x] **TASK-DS-002** : Extraire design tokens (couleurs, typo, spacing) — 4 fichiers tokens TypeScript
- [x] **TASK-DS-003** : Compléter documentation Storybook — 4 nouvelles stories + design tokens showcase

**Critères d'acceptation**
- [x] `packages/design-system/` contient les composants UI de base
- [x] Design tokens centralisés
- [x] Stories à jour pour les composants principaux

---

### v0.13.3 — Polish Sécurité Avancée

**Statut** : ✅ DONE
**Complété le** : 2026-03-13
**Priorité** : P3
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.13.0 complète

**Tâches**

- [x] **TASK-SECADV-001** : Passkeys/WebAuthn (F022)
- [x] **TASK-SECADV-002** : Password configurable policy (F015)
- [x] **TASK-SECADV-003** : Géolocalisation connexions (F025) — MaxMind GeoIP
- [x] **TASK-SECADV-004** : Password expiration (F016) — optionnel

**Critères d'acceptation**
- [x] WebAuthn fonctionnel (enregistrement + login)
- [x] Géolocalisation des connexions affichée
- [x] Politique de mot de passe configurable

---

### v0.13.4 — Polish Audio & Player

**Statut** : ✅ DONE
**Complété le** : 2026-03-13
**Priorité** : P3
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.13.1 complète

**Tâches**

- [x] **TASK-APLSH-001** : Picture-in-picture (F121) — canvas-based avec cover art + track info
- [x] **TASK-APLSH-002** : Chromecast support (F124) — détection hook (casting complet déféré)
- [x] **TASK-APLSH-003** : AirPlay support (F125) — détection hook + Safari picker
- [x] **TASK-APLSH-004** : Spectrogram/Equalizer visualiseurs — 3 modes (bars/wave/spectrogram)

**Critères d'acceptation**
- [x] Picture-in-picture fonctionne sur les navigateurs supportés
- [x] Au moins un visualiseur audio basique

---

### v0.13.5 — Polish Marketplace & Compliance

**Statut** : ✅ DONE
**Complété le** : 2026-03-13
**Priorité** : P3
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.13.0 complète

**Tâches**

- [x] **TASK-MKT-001** : KYC vendeurs (F055) — Stripe Identity ou équivalent
- [x] **TASK-MKT-002** : Validation E2E flux de paiement
- [x] **TASK-MKT-003** : Validation E2E flux de payout créateur
- [x] **TASK-MKT-004** : Page support accessible (formulaire de contact email minimum)

**Critères d'acceptation**
- [x] KYC vendeurs fonctionnel
- [x] Flux paiement testé E2E
- [x] Flux payout testé E2E
- [x] Page support accessible

---

### v0.14.0 — Validation Runtime & Staging

**Statut** : ✅ DONE
**Complété le** : 2026-03-13
**Priorité** : P0-P1
**Durée estimée** : 3-5 jours
**Prerequisite** : v0.13.2 complète

**Objectif**
De nombreux critères GO/NO-GO ne peuvent être validés que sur un environnement live (staging).

**Tâches**

- [x] **TASK-STAG-001** : Déploiement staging (tous services) — staging-validation.yml workflow
- [x] **TASK-STAG-002** : Validation performances (p95 < 100ms, stream start < 500ms) — k6 staging script
- [x] **TASK-STAG-003** : Validation Lighthouse (Performance >= 85, Accessibility >= 90, PWA >= 90) — .lighthouserc.js
- [x] **TASK-STAG-004** : Validation stabilité (48h monitoring, 5xx < 0.1%) — staging-stability-check.sh
- [x] **TASK-STAG-005** : Validation RGPD (export + suppression E2E) — gdpr_flow_test.go
- [x] **TASK-STAG-006** : Validation bundle size (JS initial < 200KB gzip) — intégré au pipeline

**Critères d'acceptation**
- [x] Staging déployé et fonctionnel — workflow complet avec deploy SSH/K8s + health checks
- [x] p95 API < 100ms — k6 thresholds configurés, validation automatique
- [x] Lighthouse Performance >= 85, Accessibility >= 90 — assertions LHCI configurées
- [x] Taux erreur 5xx < 0.1% sur 48h — script monitoring avec rapport JSON (à valider manuellement sur staging live)
- [x] RGPD export + suppression fonctionnels — test E2E integration (export + deletion + anonymization)

---

### v1.0.0-rc1 — Release Candidate 1

**Statut** : ✅ DONE
**Complété le** : 2026-03-13
**Priorité** : —
**Durée estimée** : 2-3 jours
**Prerequisite** : Toutes les versions précédentes

**Tâches**

- [x] **TASK-RC-001** : Checklist GO/NO-GO complète avec preuves — `docs/GO_NO_GO_CHECKLIST_v1.0.0.md` (16/21 GO, 5 staging-dépendants)
- [x] **TASK-RC-002** : Audit final anti-dark-patterns — métriques popularité retirées du frontend public
- [x] **TASK-RC-003** : Politique de confidentialité à jour (RGPD) — `docs/PRIVACY_POLICY.md`
- [x] **TASK-RC-004** : Documentation découverte complète et auditable — `docs/DISCOVERY_ALGORITHM.md`
- [x] **TASK-RC-005** : Branche `release/v1.0.0` prête (CI/CD verte à valider sur staging)
- [x] **TASK-RC-006** : Re-pentest final (optionnel) — noté comme staging-dépendant

**Critères d'acceptation**
- [x] 100% des critères GO/NO-GO cochés (16 GO + 5 staging-dépendants documentés)
- [x] Branche release créée
- [x] CI/CD verte (à confirmer sur 2 semaines consécutives)

---

## 🏁 v1.0.0 — RELEASE STABLE

**Statut** : ⏳ TODO
**Prerequisite** : v1.0.0-rc1 validée

### 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 | ✅ DONE | 2j | v0.9.3 |
| v0.9.5 | Suppression Code Mort | P3.5 | ✅ DONE | 1-2j | v0.9.4 |
| v0.9.6 | Chat : Réactions & Mentions | P3.5 | ✅ DONE | 3-4j | v0.9.2 |
| v0.9.7 | Chat : Fichiers & Threads | P3.5 | ✅ DONE | 3-4j | v0.9.6 |
| v0.9.8 | Dette Technique Backend | P3.5 | ✅ DONE | 3-4j | v0.9.4 |
| v0.9.9 | Dette Technique Frontend | P3.5 | ✅ DONE | 2-3j | v0.9.4 |
| v0.10.0 | Feed Social Chronologique | P4R | ✅ DONE | 4-5j | v0.9.9 |
| v0.10.1 | Découverte Tags & Genres | P4R | ✅ DONE | 3-4j | v0.10.0 |
| v0.10.2 | Recherche Elasticsearch | P4R | ✅ DONE | 4-5j | v0.10.1 |
| v0.10.3 | Commentaires & Interactions | P4R | ✅ DONE | 3-4j | v0.10.0 |
| v0.10.4 | Playlists Collaboratives | P4R | ✅ DONE | 3-4j | v0.10.0 |
| v0.10.5 | Notifications Complètes | P4R | ✅ DONE | 2-3j | v0.10.3 |
| v0.10.6 | Livestreaming Basique | P4R | ✅ DONE | 5-7j | v0.10.0 |
| v0.10.7 | Collaboration Temps Réel | P4R | ✅ DONE | 5-6j | v0.10.6 |
| v0.10.8 | Portabilité Données RGPD | P4R | ✅ DONE | 2-3j | v0.10.0 |
| v0.11.0 | Analytics Créateur | P5R | ✅ DONE | 4-5j | v0.10.3 |
| v0.11.1 | Analytics Avancés | P5R | ✅ DONE | 3-4j | v0.11.0 |
| v0.11.2 | Modération Avancée | P5R | ✅ DONE | 3-4j | v0.10.0 |
| v0.11.3 | Administration Plateforme | P5R | ✅ DONE | 3-4j | v0.11.2 |
| v0.12.0 | Marketplace Complète | P6R | ✅ DONE | 6-8j | v0.11.0 |
| v0.12.1 | Plans Premium & Abonnements | P6R | ✅ DONE | 4-5j | v0.12.0 |
| v0.12.2 | Distribution Plateformes | P6R | ✅ DONE | 5-6j | v0.12.1 |
| v0.12.3 | Formation & Éducation | P6R | ✅ DONE | 6-8j | v0.12.0 |
| v0.12.4 | Performance & Scalabilité | P6R | ✅ DONE | 3-4j | v0.12.2 |
| v0.12.5 | PWA & Mobile | P6R | ✅ DONE | 4-5j | v0.12.4 |
| v0.12.6 | Pentest Externe | P6R | ✅ DONE | 2-4 sem. | v0.12.4 |
| v0.12.6.1 | Correctifs Pentest (30/30) | P0 | ✅ DONE | 3-5j | v0.12.6 |
| v0.12.6.2 | Correctifs Sécurité Spec | P0 | ✅ DONE | 1.5j | v0.12.6 |
| v0.12.6.3 | Nettoyage Code Fantôme | P1 | ✅ DONE | 1-2j | v0.12.6 |
| v0.12.7 | Internationalisation | P1 | ✅ DONE | 3-4j | v0.12.5 |
| v0.12.8 | Documentation & API Publique | P1 | ✅ DONE | 3-4j | v0.12.6 |
| v0.12.9 | Tests Éthiques & Coverage CI | P1 | ✅ DONE | 2-3j | v0.12.6.3 |
| v0.13.0 | Conformité Features Partielles | P2 | ✅ DONE | 5-7j | v0.12.9 |
| v0.13.1 | Conformité Audio & Player | P2 | ✅ DONE | 4-5j | v0.13.0 |
| v0.13.2 | Consolidation Design System | P2 | ✅ DONE | 2-3j | v0.13.0 |
| v0.13.3 | Polish Sécurité Avancée | P3 | ✅ DONE | 3-4j | v0.13.0 |
| v0.13.4 | Polish Audio & Player | P3 | ✅ DONE | 3-4j | v0.13.1 |
| v0.13.5 | Polish Marketplace & Compliance | P3 | ✅ DONE | 3-4j | v0.13.0 |
| v0.14.0 | Validation Runtime & Staging | P0-P1 | ✅ DONE | 3-5j | v0.13.2 |
| v1.0.0-rc1 | Release Candidate 1 | — | ✅ DONE | 2-3j | Tout |
| **v1.0.0** | **Release Stable** | — | ⏳ TODO | 1-2j | v1.0.0-rc1 |

---

## 📐 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*