senke/veza
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
veza/VEZA_VERSIONS_ROADMAP.md

67 KiB
Raw Blame History

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

  • 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

  • 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

  • Tous les JWT générés utilisent RS256 (ou HS256 fallback dev) et sont vérifiés avec la clé publique / secret
  • Aucun secret hardcodé par défaut (veza-common corrigé, procédure audit docs/SECRETS_AUDIT.md)
  • .env.example et docs/ENV_VARIABLES.md couvrent les variables requises
  • 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

  • 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

  • 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

  • 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)

  • 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

  • curl http://api.veza.app/metrics depuis internet → 403
  • 101ème requête depuis une IP non-auth → 429 Too Many Requests
  • 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

  • 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

  • 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

  • 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

  • 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)

  • 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

  • make dev démarre backend (Docker) + web local
  • make doctor vérifie dépendances et affiche rapport
  • Un développeur peut démarrer l'environnement avec les instructions du README
  • 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

  • TASK-QA-001 : Pipeline CI GitHub Actions

    • Stages : lint (golangci-lint, ESLint, clippy), tests, build
    • Référence : ORIGIN_QUALITY_METRICS.md §7.1bis

  • 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

  • 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

  • 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

  • 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

  • Chaque push sur une branche déclenche le pipeline
  • Pipeline complet (sous 10 min si ressources OK)
  • Une PR avec tests échoués ne peut pas être mergée
  • 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

  • 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 (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

  • 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 : ✅ 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

  • 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 : ✅ 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

  • 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é ( 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

  • 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
  • Script npm run a11y:audit (axe-core CLI) et ARIA labels sur ChatInput, Sidebar
  • Bundle initial < 200KB gzipped (scripts/check-bundle-size.mjs, gate CI)
  • 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

  • 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 user_profiles.follower_count et user_profiles.following_count
    • Mis à jour via triggers DB (125_follow_counts_triggers.sql)

  • 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), GET /api/v1/users/suggestions
    • Pas de collaborative filtering ML
    • Référence : ORIGIN_FEATURES_REGISTRY.md §30 (Algorithme de découverte éthique)

  • 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

  • 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 : ✅ 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

  • 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/suggestions?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 (fuzziness AUTO)
  • 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

  • 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 : ✅ 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

  • 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 : ✅ 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

  • Notifications in-app en temps réel (WebSocket) (F551)

  • 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

  • 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)

  • 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 : ✅ 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

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

  • Distribution HLS (F472)

    • Nginx-RTMP HLS segments 2s, playlist via HTTP 18083
    • stream_url dans live_streams (STREAM_HLS_BASE_URL)

  • 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

  • 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

  • Flow complet : OBS → RTMP → callbacks → stream_url → HLS.js player
  • Chat fonctionne avec rate limit 1/3s pour live
  • Pas de crash si 0 auditeurs
  • 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

  • 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

  • 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)

  • 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

  • Co-écoute : WebSocket dédié, synchronisation < 500ms
  • Partage de stems : wav, aiff, flac acceptés
  • 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

  • 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

  • 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)

  • 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 (worker hard delete quotidien)
  • 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

  • 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 (à 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

  • 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 : ✅ 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

  • 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

  • Signalement de contenu par les utilisateurs (F412)

    • Endpoint POST /reports pour signalement avec catégories
    • Categories : spam, contenu offensant, violation de droits, fake, other

  • 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 automatique
    • Procédure d'appel avec resolution par modérateur

Critères d'acceptation

  • La décision finale de modération est TOUJOURS humaine (confirmé dans le code — automated rules only flag)
  • Un modérateur peut traiter une action en moins de 30 secondes (single-click actions in queue UI)
  • 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

  • Dashboard admin (F421)

    • Métriques plateforme : utilisateurs actifs, tracks uploadées, revenus, storage
    • Endpoint GET /admin/platform/metrics

  • Gestion des utilisateurs (F422)

    • Recherche, vue détaillée, édition du rôle, suspension/ban/unsuspend
    • Endpoints: GET/PUT/POST /admin/platform/users

  • Gestion du contenu (F423)

    • Supprimer/masquer du contenu en violation, restaurer
    • Endpoints: GET /admin/platform/content, POST hide/restore

  • Gestion des paiements / litiges (F424)

    • Vue des transactions, déclenchement de remboursements
    • Endpoints: GET /admin/platform/payments, POST refund

  • Annonces système (F425)

    • Bannière d'information pour tous les utilisateurs (existait déjà via v0.803)

Critères d'acceptation

  • Admin peut bannir un utilisateur en moins de 5 clics (1 search + 1 click suspend)
  • 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

  • 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

  • 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

  • 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

  • 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

  • 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)

  • 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

  • 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 : ✅ DONE Priorité : P1 Durée estimée : 4-5 jours Prerequisite : v0.12.0 complète Complété le : 2026-03-10

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 : ✅ 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

  • 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 (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

  • 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 : ✅ DONE Priorité : P1 Durée estimée : 3-4 jours Prerequisite : v0.12.2 complète Complété le : 2026-03-11

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 : ✅ 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

  • 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 : ✅ 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

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

Critères d'acceptation

  • Rapport de pentest fourni : PENTEST_REPORT_VEZA_v0.12.6.md
  • Aucun finding critique ou haut non résolu (30/30 corrigés en v0.12.6.1)
  • Rapport de remédiation documenté : REMEDIATION_MATRIX_v0.12.6.md
  • 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

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

Critères d'acceptation

  • 0 finding critique ou haut ouvert
  • 30/30 findings corrigés (REMEDIATION_MATRIX_v0.12.6.md)
  • GitHub Actions SHA-pinned (MEDIUM-007)
  • 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

  • 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

  • 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

  • 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

  • Connexion admin sans MFA → retourne 403 mfa_setup_required
  • Connexion moderator sans MFA → retourne 403 mfa_setup_required
  • jwt_service.go : refresh token TTL = 7 jours (604800 secondes)
  • 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

  • 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)
  • 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
  • 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é
  • 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

  • Aucun module de gamification actif dans le code
  • playback_abtest_service.go traité (supprimé)
  • 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

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

Critères d'acceptation

  • Interface 100% traduite en FR/EN/ES (532 clés par langue)
  • 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

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

Critères d'acceptation

  • Documentation API navigable en ligne (Swagger UI dans /developer + /swagger/*)
  • 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

  • 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
  • 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é
  • 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
  • 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
  • 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

  • Test de biais artistes émergents PASSE (4 tests discover, tous PASS)
  • Test recherche artiste 0 plays PASSE (4 tests search, tous PASS)
  • Algorithme de découverte documenté (veza-docs/DISCOVERY_ALGORITHM.md)
  • 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

  • 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
  • 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)
  • 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
  • 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)
  • 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
  • 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

  • F019 SMS 2FA service implémenté (provider interface + dev mock)
  • F027 CAPTCHA Turnstile service + middleware implémentés, testés
  • Features auth partielles complétées (F014 password history, F024 login history)
  • 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

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

Critères d'acceptation

  • Gapless playback entre deux tracks consécutifs
  • Crossfade configurable
  • 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

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

Critères d'acceptation

  • packages/design-system/ contient les composants UI de base
  • Design tokens centralisés
  • Stories à jour pour les composants principaux

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

Statut : ⏳ TODO Priorité : P3 Durée estimée : 3-4 jours Prerequisite : v0.13.0 complète

Tâches

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

Critères d'acceptation

  • WebAuthn fonctionnel (enregistrement + login)
  • Géolocalisation des connexions affichée
  • Politique de mot de passe configurable

v0.13.4 — Polish Audio & Player

Statut : ⏳ TODO Priorité : P3 Durée estimée : 3-4 jours Prerequisite : v0.13.1 complète

Tâches

  • TASK-APLSH-001 : Picture-in-picture (F121)
  • TASK-APLSH-002 : Chromecast support (F124) — optionnel v1.0
  • TASK-APLSH-003 : AirPlay support (F125) — optionnel v1.0
  • TASK-APLSH-004 : Spectrogram/Equalizer visualiseurs

Critères d'acceptation

  • Picture-in-picture fonctionne sur les navigateurs supportés
  • Au moins un visualiseur audio basique

v0.13.5 — Polish Marketplace & Compliance

Statut : ⏳ TODO Priorité : P3 Durée estimée : 3-4 jours Prerequisite : v0.13.0 complète

Tâches

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

Critères d'acceptation

  • KYC vendeurs fonctionnel
  • Flux paiement testé E2E
  • Flux payout testé E2E
  • Page support accessible

v0.14.0 — Validation Runtime & Staging

Statut : ⏳ TODO 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

  • TASK-STAG-001 : Déploiement staging (tous services)
  • TASK-STAG-002 : Validation performances (p95 < 100ms, stream start < 500ms)
  • TASK-STAG-003 : Validation Lighthouse (Performance >= 85, Accessibility >= 90, PWA >= 90)
  • TASK-STAG-004 : Validation stabilité (48h monitoring, 5xx < 0.1%)
  • TASK-STAG-005 : Validation RGPD (export + suppression E2E)
  • TASK-STAG-006 : Validation bundle size (JS initial < 200KB gzip)

Critères d'acceptation

  • Staging déployé et fonctionnel
  • p95 API < 100ms
  • Lighthouse Performance >= 85, Accessibility >= 90
  • Taux erreur 5xx < 0.1% sur 48h
  • RGPD export + suppression fonctionnels

v1.0.0-rc1 — Release Candidate 1

Statut : ⏳ TODO Priorité : — Durée estimée : 2-3 jours Prerequisite : Toutes les versions précédentes

Tâches

  • TASK-RC-001 : Checklist GO/NO-GO complète avec preuves
  • TASK-RC-002 : Audit final anti-dark-patterns
  • TASK-RC-003 : Politique de confidentialité à jour (RGPD)
  • TASK-RC-004 : Documentation découverte complète et auditable
  • TASK-RC-005 : Branche release/v1.0.0, CI/CD verte 2 semaines
  • TASK-RC-006 : Re-pentest final (optionnel)

Critères d'acceptation

  • 100% des critères GO/NO-GO cochés
  • Branche release créée
  • CI/CD verte

🏁 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 ⏳ TODO 3-4j v0.13.0
v0.13.4 Polish Audio & Player P3 ⏳ TODO 3-4j v0.13.1
v0.13.5 Polish Marketplace & Compliance P3 ⏳ TODO 3-4j v0.13.0
v0.14.0 Validation Runtime & Staging P0-P1 ⏳ TODO 3-5j v0.13.2
v1.0.0-rc1 Release Candidate 1 — ⏳ TODO 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

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