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-09 Auteur : Architecte principal Veza

---

📋 ÉTAT GLOBAL

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

---

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

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

---

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

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

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

Tâches

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

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

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

Tâches

• Sessions de co-écoute synchronisée (F481)

  • Plusieurs utilisateurs écoutent la même track en sync
  • Le host contrôle la lecture

• Partage de projets / stems (F482)

  • Upload de stems séparés (kick, snare, bass, etc.)
  • Autre utilisateur peut télécharger les stems

• Espace de travail collaboratif partagé (F483)

  • Room collaborative avec chat dédié + partage de fichiers
  • Accès contrôlé (invitation seulement)

Critères d'acceptation

• Co-écoute : synchronisation en moins de 500ms entre participants
• Partage de stems : tous les formats (wav, aiff, flac) acceptés
• Room collaborative : max 10 participants simultanés

---

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

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

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

Tâches

• Export des données utilisateur (ZIP) (F065)

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

• Suppression de compte (F065)

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

• Droit à l'oubli (anonymisation)

  • Remplacer les données PII par des placeholders
  • Conserver les transactions financières (obligation légale)

Critères d'acceptation

• Export ZIP disponible en moins de 1 heure pour un compte avec 100 tracks
• Suppression effective en 30 jours (testable avec un compte de test)
• Conformité RGPD vérifiable : aucune donnée PII ne subsiste après 30 jours

---

🟢 PHASE P5R — ANALYTICS & RECHERCHE ÉTHIQUE

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

---

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

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

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

Tâches

• Dashboard analytics créateur (F381)

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

• Evolution temporelle des plays (F382)

  • Graphique par jour/semaine/mois

• Téléchargements et achats (F383)

  • Historique des ventes, revenus par période
  • Export CSV

• Analytics d'audience (F384)

  • Profil générique des auditeurs (genre, âge — agrégé, pas individuel)

• Métriques en temps réel pour les lives (F385)

  • Auditeurs actuels pendant un livestream

Critères d'acceptation

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

---

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

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

Tâches

• Heatmap d'écoute (F396)

  • Segments d'une track les plus/moins écoutés (agrégé)
  • Aide le créateur à comprendre où les auditeurs décrochent

• Comparaison de périodes (F397)

  • "Cette semaine vs semaine dernière"

• Analytics de la marketplace (F398)

  • Taux de conversion par produit (vues → achats)
  • Revenus cumulés, commissions plateforme

• Alertes métriques (F399)

  • "Votre track a été jouée 100 fois" → notification opt-in
  • Pas de gamification : juste une information utile

Critères d'acceptation

• Heatmap visible dans le dashboard analytics d'une track
• Alertes sont opt-in et peuvent être désactivées

---

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

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

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

Tâches

• Interface de modération pour les modérateurs (F411)

  • Queue de contenu flaggé
  • Actions : approve, reject, ban temporaire, ban permanent
  • Référence : ORIGIN_BUSINESS_LOGIC.md §4.2

• Signalement de contenu par les utilisateurs (F412)

  • Bouton "Signaler" sur les tracks, commentaires, profils
  • Categories : spam, contenu offensant, violation de droits, fake

• Détection déterministe de spam (F413)

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

• Audio fingerprinting ACRCloud (F414)

  • Détection de contenu copyrighted
  • Track matchée → flaggée pour review humaine
  • Référence : ORIGIN_FEATURES_REGISTRY.md F465 note

• Système de strikes (F415)

  • 3 strikes → suspension temporaire
  • Procédure d'appel documentée

Critères d'acceptation

• La décision finale de modération est TOUJOURS humaine (confirmé dans le code)
• Un modérateur peut traiter une action en moins de 30 secondes
• Le créateur reçoit une notification avec la raison en cas de rejection

---

v0.11.3 — Administration Plateforme (F421-F435)

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

Tâches

• Dashboard admin (F421)

  • Métriques plateforme : utilisateurs actifs, tracks uploadées, revenus
  • Alertes système (taux d'erreur, latence, espace disque)

• Gestion des utilisateurs (F422)

  • Recherche, vue détaillée, édition du rôle, suspension/ban

• Gestion du contenu (F423)

  • Supprimer/masquer du contenu en violation

• Gestion des paiements / litiges (F424)

  • Vue des transactions, déclenchement de remboursements

• Annonces système (F425)

  • Bannière d'information pour tous les utilisateurs

Critères d'acceptation

• Admin peut bannir un utilisateur en moins de 5 clics
• Dashboard admin accessible uniquement au rôle admin (test de sécurité)

---

🔵 PHASE P6R — PREMIUM & INFRASTRUCTURE

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

---

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

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

Tâches

• Création et gestion de produits (F226)

  • Beats, samples, kits, presets, partitions
  • Types de licences : Basic, Standard, Premium, Exclusive
  • Référence : ORIGIN_BUSINESS_LOGIC.md §1.1

• Checkout complet via Hyperswitch (F251)

  • Stripe et PayPal configurés comme providers
  • Référence : ORIGIN_BUSINESS_LOGIC.md §2.2

• Téléchargements sécurisés (F252)

  • URL signées S3 (expire en 24h)
  • Limite de téléchargements par licence

• Système de commissions automatique (F253)

  • Commission déduite à la vente (15% creator, 10% premium)
  • Référence : ORIGIN_BUSINESS_LOGIC.md §2.1

• Paiements aux créateurs (F254)

  • Payout hebdomadaire automatique si balance ≥ $50
  • Référence : ORIGIN_BUSINESS_LOGIC.md §2.3

• Codes promo (F255)

  • Création et gestion par les créateurs et les admins

Critères d'acceptation

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

---

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

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

Tâches

• Plans d'abonnement (Free, Creator, Premium) via Hyperswitch

  • Référence : ORIGIN_BUSINESS_LOGIC.md §1.1

• Gestion des abonnements (upgrade, downgrade, cancel)

• Factures automatiques (Stripe Invoicing)

• Essai gratuit 14 jours pour le plan Premium

Critères d'acceptation

• Annulation sans friction (pas de dark patterns)
• Accès au plan continue jusqu'à la fin de la période payée

---

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

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

Tâches

• Distribution vers Spotify, Apple Music, Deezer (F501)

  • Via partenaire distribution (DistroKid API ou TuneCore)
  • Disponible uniquement pour les plans Creator et Premium

• Suivi de la distribution (F502)

  • Statut de chaque plateforme (processing, live, rejected)

• Revenus de streaming externe (F503)

  • Import des royalties depuis les distributeurs

Critères d'acceptation

• Flow de soumission complète en moins de 5 minutes
• L'artiste est notifié quand sa track est live sur Spotify

---

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

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

Tâches

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

Critères d'acceptation

• Cours vidéo en HLS multi-bitrate
• Acheteur peut accéder aux cours à vie

---

v0.12.4 — Performance & Scalabilité

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

Tâches

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

Critères d'acceptation

• p95 < 100ms sur les endpoints API principaux
• Démarrage du lecteur audio < 2 secondes
• 1000 utilisateurs simultanés sans dégradation (k6 test)

---

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

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

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

Tâches

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

Critères d'acceptation

• Score Lighthouse PWA ≥ 90
• Player audio fonctionne hors ligne pour les tracks téléchargées
• Installable sur Android et iOS (via "Ajouter à l'écran d'accueil")

---

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

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

Tâches

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

Critères d'acceptation

• Rapport de pentest fourni par le prestataire
• Aucun finding critique ou haut non résolu
• Rapport de remédiation documenté

---

v0.12.7 — Internationalisation (i18n)

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

Tâches

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

Critères d'acceptation

• Interface 100% traduite en FR/EN/ES
• Commutation de langue sans rechargement

---

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

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

Tâches

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

Critères d'acceptation

• Documentation API navigable en ligne
• Un développeur externe peut s'authentifier et consommer l'API avec sa clé

---

🏁 v1.0.0 — RELEASE STABLE

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

GO/NO-GO Criteria

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

Sécurité

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

Stabilité

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

Performance

• p95 API < 100ms
• Score Lighthouse Performance ≥ 85
• Score Lighthouse Accessibility ≥ 90
• Score Lighthouse PWA ≥ 90

Qualité

• Coverage tests ≥ 70% (Go + Rust)
• 0 linting error
• CI/CD verte depuis 2 semaines consécutives

Éthique (obligatoire)

• Audit UX anti-dark-patterns validé par un tiers
• Aucune donnée comportementale n'est revendue ou partagée
• Algorithm de découverte documenté et auditable
• Politique de confidentialité à jour et conforme RGPD

Business

• Flux de paiement testé E2E en production (avec de vrais fonds)
• Flux de payout créateur testé
• Support accessible (email ou chat)

---

📊 TABLEAU DE SUIVI

Version	Nom	Phase	Statut	Durée est.	Prerequisite
v0.9.1	JWT Migration RS256	P3.5	✅ DONE	2-3j	—
v0.9.2	Sécurité Infrastructure	P3.5	✅ DONE	1-2j	v0.9.1
v0.9.3	Toolchain & Environnement	P3.5	✅ DONE	1j	v0.9.1
v0.9.4	Quality Gates CI/CD	P3.5	✅ 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	⏳ TODO	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	⏳ TODO	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	⏳ TODO	5-6j	v0.10.6
v0.10.8	Portabilité Données RGPD	P4R	⏳ TODO	2-3j	v0.10.0
v0.11.0	Analytics Créateur	P5R	⏳ TODO	4-5j	v0.10.3
v0.11.1	Analytics Avancés	P5R	⏳ TODO	3-4j	v0.11.0
v0.11.2	Modération Avancée	P5R	⏳ TODO	3-4j	v0.10.0
v0.11.3	Administration Plateforme	P5R	⏳ TODO	3-4j	v0.11.2
v0.12.0	Marketplace Complète	P6R	⏳ TODO	6-8j	v0.11.0
v0.12.1	Plans Premium & Abonnements	P6R	⏳ TODO	4-5j	v0.12.0
v0.12.2	Distribution Plateformes	P6R	⏳ TODO	5-6j	v0.12.1
v0.12.3	Formation & Éducation	P6R	⏳ TODO	6-8j	v0.12.0
v0.12.4	Performance & Scalabilité	P6R	⏳ TODO	3-4j	v0.12.2
v0.12.5	PWA & Mobile	P6R	⏳ TODO	4-5j	v0.12.4
v0.12.6	Pentest Externe	P6R	⏳ TODO	2-4 sem.	v0.12.4
v0.12.7	Internationalisation	P6R	⏳ TODO	3-4j	v0.12.5
v0.12.8	Documentation & API Publique	P6R	⏳ TODO	3-4j	v0.12.6
v1.0.0	Release Stable	—	⏳ TODO	—	Tout + pentest

---

📐 INSTRUCTIONS POUR CURSOR

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

Étape 1 : Identifier la prochaine version

Chercher dans ce fichier la première version avec Statut : ⏳ TODO dans l'ordre du tableau de suivi.

Étape 2 : Vérifier les prerequisites

Confirmer que toutes les versions listées dans "Prerequisite" ont le statut ✅ DONE. Si non : signaler le blocage et ne pas continuer.

Étape 3 : Lire les références ORIGIN

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

Étape 4 : Implémenter

Implémenter toutes les tâches de la version, en suivant :

• ORIGIN/ORIGIN_CODE_STANDARDS.md pour les conventions
• ORIGIN/ORIGIN_FEATURE_VALIDATION_STRATEGY.md pour la checklist de validation
• ORIGIN/ORIGIN_ERROR_PATTERNS.md et ORIGIN_ERROR_PREVENTION_GUIDE.md pour éviter les patterns problématiques
• ORIGIN/ORIGIN_UI_UX_SYSTEM.md §13 anti-patterns et §14 patterns positifs pour le frontend

Étape 5 : Valider

Pour chaque tâche implémentée :

• Exécuter les tests (make test)
• Vérifier les critères d'acceptation listés dans ce fichier
• Vérifier la checklist ORIGIN_FEATURE_VALIDATION_STRATEGY.md

Étape 6 : Mettre à jour ce fichier

Une fois la version complète et validée :

• Changer le statut de ⏳ TODO à ✅ DONE
• Ajouter la date de completion : **Complété le** : YYYY-MM-DD
• Mettre à jour le tableau de suivi

Étape 7 : Créer le tag git

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