eb2862092d
- Backend: callbacks on_publish/on_publish_done, UpdateStreamURL, GetByStreamKey - Nginx-RTMP: config infra, docker-compose service (profil live) - Frontend: stream_url dans LiveStream, HLS.js dans LiveViewPlayer, état Stream terminé - Chat: rate limit send_live_message 1 msg/3s pour rooms live_streams - Env: RTMP_CALLBACK_SECRET, STREAM_HLS_BASE_URL, NGINX_RTMP_HOST - Roadmap v0.10.6 marquée DONE
1293 lines
48 KiB
Markdown
1293 lines
48 KiB
Markdown
# 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**
|
|
|
|
- [x] **TASK-SEC-001** : Migration JWT HS256 → RS256
|
|
- Générer paire de clés RSA 2048-bit (clé privée backend, clé publique publique)
|
|
- Modifier le service JWT pour signer avec RS256
|
|
- Mettre à jour tous les middleware de validation JWT
|
|
- Mettre à jour les variables d'environnement (supprimer `JWT_SECRET`, ajouter `JWT_PRIVATE_KEY_PATH`, `JWT_PUBLIC_KEY_PATH`)
|
|
- Invalider tous les tokens existants (migration token_version)
|
|
- Référence : ORIGIN_SECURITY_FRAMEWORK.md §0 VEZA-SEC-001, ORIGIN_DEPLOYMENT_GUIDE.md §15
|
|
|
|
- [x] **TASK-SEC-002** : Supprimer les clés privées committées / secrets exposés
|
|
- Audit complet de l'historique git (truffleHog ou équivalent)
|
|
- Rotation immédiate de toutes les clés compromises (Stripe, OAuth, JWT, DB)
|
|
- Mettre en place `.gitignore` complet pour tous les fichiers `.env`
|
|
- Créer `.env.example` documenté avec toutes les variables requises
|
|
- Référence : ORIGIN_SECURITY_FRAMEWORK.md §0 VEZA-SEC-002
|
|
|
|
**Critères d'acceptation**
|
|
- [x] Tous les JWT générés utilisent RS256 (ou HS256 fallback dev) et sont vérifiés avec la clé publique / secret
|
|
- [x] Aucun secret hardcodé par défaut (veza-common corrigé, procédure audit docs/SECRETS_AUDIT.md)
|
|
- [x] `.env.example` et docs/ENV_VARIABLES.md couvrent les variables requises
|
|
- [x] Tests d'authentification passent (unit + handler)
|
|
- [ ] Déploiement staging valide avec les nouvelles clés (à valider manuellement)
|
|
|
|
**Fichiers principaux à modifier**
|
|
- `backend/internal/auth/jwt_service.go`
|
|
- `backend/internal/middleware/auth_middleware.go`
|
|
- `.env.example`
|
|
- `backend/configs/`
|
|
- `docker-compose.yml` (variables d'env)
|
|
|
|
---
|
|
|
|
### v0.9.2 — Sécurité Infrastructure (TASK-SEC-003 à 006)
|
|
|
|
**Statut** : ✅ DONE
|
|
**Priorité** : P0 — BLOQUANT
|
|
**Durée estimée** : 1-2 jours
|
|
**Prerequisite** : v0.9.1 complète
|
|
**Complété le** : 2026-03-05
|
|
|
|
**Objectif**
|
|
Fermer les vecteurs d'attaque infrastructure : endpoint `/metrics` exposé, rate limiting manquant, headers de sécurité absents.
|
|
|
|
**Tâches**
|
|
|
|
- [x] **TASK-SEC-003** : Rate limiting global
|
|
- Implémenter rate limiting middleware sur toutes les routes publiques
|
|
- Règles : 100 req/h par IP (non-auth), 1000 req/h (auth)
|
|
- Redis comme backend pour le comptage distribué
|
|
- Référence : ORIGIN_SECURITY_FRAMEWORK.md, ORIGIN_FEATURES_REGISTRY.md F026
|
|
|
|
- [x] **TASK-SEC-004** : Security headers HTTP
|
|
- `Content-Security-Policy`, `X-Frame-Options`, `X-Content-Type-Options`
|
|
- `Strict-Transport-Security` (HSTS)
|
|
- `Referrer-Policy`
|
|
- Middleware centralisé dans HAProxy ou au niveau Go
|
|
|
|
- [x] **TASK-SEC-005** : Validation et sanitization des inputs
|
|
- Audit de tous les endpoints existants (pas de SQL injection, XSS)
|
|
- Binding validation exhaustif sur tous les handlers
|
|
- Taille max des payloads (1MB par défaut, 500MB pour upload audio)
|
|
|
|
- [x] **TASK-SEC-006** : Protection endpoint `/metrics`
|
|
- Route Prometheus `/metrics` accessible seulement depuis réseau interne
|
|
- Authentification bearer token ou IP whitelist
|
|
- Référence : ORIGIN_SECURITY_FRAMEWORK.md §0, ORIGIN_IMPLEMENTATION_TASKS.md TASK-SEC-006
|
|
|
|
**Critères d'acceptation**
|
|
- [x] `curl http://api.veza.app/metrics` depuis internet → 403
|
|
- [x] 101ème requête depuis une IP non-auth → 429 Too Many Requests
|
|
- [x] Headers de sécurité visibles dans les réponses (vérifiable avec `curl -I`)
|
|
- [ ] Tests de pénétration basiques (OWASP Top 10) passent sans résultat critique (à valider manuellement)
|
|
|
|
---
|
|
|
|
### v0.9.3 — Toolchain et Environnement (TASK-QA-006 à 010)
|
|
|
|
**Statut** : ✅ DONE
|
|
**Priorité** : P1
|
|
**Durée estimée** : 1 jour
|
|
**Prerequisite** : v0.9.1 complète
|
|
**Complété le** : 2026-03-05
|
|
|
|
**Objectif**
|
|
Standardiser l'environnement de développement pour que tous les développeurs (et Cursor) travaillent dans des conditions identiques et reproductibles.
|
|
|
|
**Tâches**
|
|
|
|
- [x] **TASK-QA-006** : Créer `.nvmrc` à la racine du monorepo
|
|
- Version Node.js fixée (LTS actuel)
|
|
- Référence : ORIGIN_QUALITY_METRICS.md §6.4 DT-007
|
|
|
|
- [x] **TASK-QA-007** : Créer `rust-toolchain.toml` pour le stream server
|
|
- Version Rust stable fixée (existe à la racine)
|
|
- Référence : ORIGIN_QUALITY_METRICS.md §6.4 DT-008
|
|
|
|
- [x] **TASK-QA-008** : Compléter `Makefile` racine
|
|
- Alias `build` (→ build-all), cible `doctor` vérifiant dépendances
|
|
- Référence : make/build.mk, make/tools.mk
|
|
|
|
- [x] **TASK-QA-009** : Documenter variables d'environnement + script de validation
|
|
- `docs/ENV_VARIABLES.md` avec description, type, valeur par défaut, exemples
|
|
- `scripts/validate-env.sh` (appelé par `make doctor`)
|
|
|
|
- [x] **TASK-QA-010** : `docker-compose.dev.yml` fonctionnel
|
|
- Infra : Postgres, Redis, RabbitMQ, ClamAV, MinIO
|
|
- `make dev-full`, `make dev-backend-api`, `make dev-stream-server` utilisent `infra-up-dev`
|
|
- Hot reload pour apps locales (air, cargo-watch)
|
|
|
|
**Critères d'acceptation**
|
|
- [x] `make dev` démarre backend (Docker) + web local
|
|
- [x] `make doctor` vérifie dépendances et affiche rapport
|
|
- [x] Un développeur peut démarrer l'environnement avec les instructions du README
|
|
- [x] README racine à jour avec instructions setup
|
|
|
|
---
|
|
|
|
### v0.9.4 — Quality Gates CI/CD (TASK-QA-001 à 005)
|
|
|
|
**Statut** : ✅ DONE
|
|
**Priorité** : P1
|
|
**Durée estimée** : 2 jours
|
|
**Prerequisite** : v0.9.3 complète
|
|
**Complété le** : 2026-03-05
|
|
|
|
**Objectif**
|
|
Mettre en place les quality gates automatisées pour que chaque PR soit validée avant merge. Zéro régression non détectée.
|
|
|
|
**Tâches**
|
|
|
|
- [x] **TASK-QA-001** : Pipeline CI GitHub Actions
|
|
- Stages : lint (golangci-lint, ESLint, clippy), tests, build
|
|
- Référence : ORIGIN_QUALITY_METRICS.md §7.1bis
|
|
|
|
- [x] **TASK-QA-002** : Coverage gates
|
|
- Go backend : coverage ≥ 60% (gate dans ci.yml)
|
|
- Frontend React : coverage ≥ 50% (vitest --coverage enforces thresholds)
|
|
- PR rejetée automatiquement si coverage descend
|
|
|
|
- [x] **TASK-QA-003** : Linting strict
|
|
- `veza-backend-api/.golangci.yml` (govet, gofmt, goimports)
|
|
- `veza-backend-api/package.json` lint → golangci-lint
|
|
- `veza-stream-server/package.json` lint → cargo fmt + clippy
|
|
- Aucun warning accepté en CI
|
|
|
|
- [x] **TASK-QA-004** : Tests d'intégration de santé
|
|
- E2E job : validation payload `/api/v1/health` (jq .status == "ok")
|
|
- Postgres, Redis, migrations, backend startup vérifiés
|
|
|
|
- [x] **TASK-QA-005** : Notifications de CI
|
|
- Badge CI dans README
|
|
- Job notify-failure : Slack webhook si SLACK_WEBHOOK_URL défini
|
|
|
|
**Critères d'acceptation**
|
|
- [x] Chaque push sur une branche déclenche le pipeline
|
|
- [x] Pipeline complet (sous 10 min si ressources OK)
|
|
- [x] Une PR avec tests échoués ne peut pas être mergée
|
|
- [x] Coverage visible (Go dans step output, frontend via vitest thresholds)
|
|
|
|
---
|
|
|
|
### v0.9.5 — Suppression Code Mort (TASK-DEBT-001 à 005)
|
|
|
|
**Statut** : ✅ DONE
|
|
**Priorité** : P1
|
|
**Durée estimée** : 1-2 jours
|
|
**Prerequisite** : v0.9.4 complète (les tests protègent contre les régressions)
|
|
**Complété le** : 2026-03-05
|
|
|
|
**Objectif**
|
|
Supprimer tout le code mort identifié dans l'audit. Réduire la surface de maintenance et éliminer la confusion architecturale.
|
|
|
|
**Tâches**
|
|
|
|
- [x] **TASK-DEBT-001** : Supprimer le répertoire `soundcloud/` (ou équivalent SoundCloud import)
|
|
- Confirmer qu'aucun code en production ne l'importe
|
|
- Supprimer et nettoyer les imports
|
|
|
|
- [x] **TASK-DEBT-002** : Supprimer `webrtc.rs` du stream server (si non utilisé)
|
|
- Le stream server Rust ne fait pas de WebRTC (voir ADR-002)
|
|
- Confirmer dans le code, supprimer si orphelin
|
|
|
|
- [x] **TASK-DEBT-003** : Supprimer `k8s/chat-server/` (Kubernetes manifests pour le chat Rust obsolète)
|
|
- Le chat server est maintenant en Go (ADR-002)
|
|
- Référence : ORIGIN_IMPLEMENTATION_TASKS_ARCHIVE.md note T0051-T0065
|
|
|
|
- [x] **TASK-DEBT-004** : Supprimer ou désactiver tous les endpoints AI/Web3/Gamification
|
|
- Rechercher dans le codebase : routes AI, NFT, XP, leaderboard, gamification
|
|
- Supprimer le code correspondant
|
|
- Référence : ORIGIN_REVISION_SUMMARY.md §1, ORIGIN_FEATURES_REGISTRY.md §29
|
|
|
|
- [x] **TASK-DEBT-005** : Nettoyer les dépendances inutilisées
|
|
- `go mod tidy` et vérification des modules Go
|
|
- `npm audit` et suppression des packages inutilisés
|
|
- `cargo update` et nettoyage des crates Rust
|
|
|
|
**Critères d'acceptation**
|
|
- [x] `grep -r "soundcloud\|nft\|blockchain\|xp_system\|leaderboard" --include="*.go" --include="*.ts" --include="*.rs"` → aucun résultat dans le code actif
|
|
- [x] Taille du bundle frontend réduite (suppression types/types gamification)
|
|
- [ ] Tous les tests passent après nettoyage (à valider)
|
|
|
|
---
|
|
|
|
### v0.9.6 — Chat Complet : Réactions & Mentions (TASK-CHAT-001 à 003)
|
|
|
|
**Statut** : ✅ DONE
|
|
**Priorité** : P1
|
|
**Durée estimée** : 3-4 jours
|
|
**Prerequisite** : v0.9.2 complète
|
|
**Complété le** : 2026-03-06
|
|
|
|
**Objectif**
|
|
Compléter le module Chat (Go) avec les features manquantes : réactions aux messages, mentions @utilisateur, et search dans l'historique.
|
|
|
|
**Tâches**
|
|
|
|
- [x] **TASK-CHAT-001** : Réactions aux messages (émojis)
|
|
- Backend : endpoint POST/DELETE `/api/v1/chat/messages/{id}/reactions`
|
|
- Table `message_reactions` (message_id, user_id, emoji, created_at)
|
|
- WebSocket : event `message:reaction_added` / `message:reaction_removed`
|
|
- Frontend : picker émoji inline, compteur de réactions
|
|
- Référence : ORIGIN_FEATURES_REGISTRY.md F162
|
|
|
|
- [x] **TASK-CHAT-002** : Mentions @utilisateur
|
|
- Backend : parsing des `@username` dans les messages
|
|
- Notification push pour les utilisateurs mentionnés
|
|
- Frontend : autocomplete @username en cours de frappe
|
|
- Référence : ORIGIN_FEATURES_REGISTRY.md F163
|
|
|
|
- [x] **TASK-CHAT-003** : Recherche dans l'historique des messages
|
|
- Backend : endpoint GET `/api/v1/chat/rooms/{id}/messages/search?q=...`
|
|
- Elasticsearch ou fulltext PostgreSQL (pg_trgm)
|
|
- Frontend : barre de recherche dans le panel chat
|
|
- Référence : ORIGIN_FEATURES_REGISTRY.md F165
|
|
|
|
**Critères d'acceptation**
|
|
- [x] Un utilisateur peut réagir à un message avec un émoji, la réaction apparaît en temps réel chez tous les participants
|
|
- [x] `@alice` dans un message déclenche une notification pour alice
|
|
- [x] La recherche retourne des résultats pertinents en moins de 200ms
|
|
- [x] Aucune régression sur les features chat existantes
|
|
|
|
---
|
|
|
|
### v0.9.7 — Chat Complet : Fichiers & Threads (TASK-CHAT-004 à 006)
|
|
|
|
**Statut** : ✅ DONE
|
|
**Priorité** : P1
|
|
**Durée estimée** : 3-4 jours
|
|
**Prerequisite** : v0.9.6 complète
|
|
**Complété le** : 2026-03-06
|
|
|
|
**Objectif**
|
|
Compléter le module Chat avec l'envoi de fichiers, les threads (réponse à un message), et la gestion des rooms de groupe.
|
|
|
|
**Tâches**
|
|
|
|
- [x] **TASK-CHAT-004** : Envoi de fichiers dans le chat
|
|
- Backend : endpoint POST `/api/v1/chat/messages/{id}/attachments`
|
|
- Types acceptés : audio (mp3, wav, ogg), image (jpg, png), PDF
|
|
- Upload S3, URL signée temporaire (24h)
|
|
- Taille max : 50MB par fichier
|
|
- Référence : ORIGIN_FEATURES_REGISTRY.md F166
|
|
|
|
- [x] **TASK-CHAT-005** : Threads (réponse à un message)
|
|
- Backend : champ `reply_to_message_id` dans la table messages
|
|
- Frontend : UI thread avec message parent visible
|
|
- Référence : ORIGIN_FEATURES_REGISTRY.md F161
|
|
|
|
- [x] **TASK-CHAT-006** : Rooms de groupe (invitations, gestion des membres)
|
|
- Backend : endpoints CRUD pour la gestion des membres d'une room
|
|
- Invitations avec lien unique (expire en 7 jours)
|
|
- Rôles dans le groupe : owner, admin, member
|
|
- Référence : ORIGIN_FEATURES_REGISTRY.md F155-F160
|
|
|
|
**Critères d'acceptation**
|
|
- [x] Partage d'un fichier audio dans le chat → lecture inline possible
|
|
- [x] Thread visible avec message parent
|
|
- [x] Invitation par lien fonctionne (flow complet)
|
|
- [x] Owner peut kick un membre
|
|
|
|
---
|
|
|
|
### v0.9.8 — Réduction Dette Technique Backend (TASK-DEBT-006 à 012)
|
|
|
|
**Statut** : ✅ DONE
|
|
**Priorité** : P1
|
|
**Durée estimée** : 3-4 jours
|
|
**Prerequisite** : v0.9.4 complète
|
|
**Complété le** : 2026-03-06
|
|
|
|
**Objectif**
|
|
Corriger les patterns d'erreur identifiés dans l'audit technique (PAT-024 à PAT-028) : propagation de contexte, goroutine leaks, pagination incohérente, error handling non standardisé.
|
|
|
|
**Tâches**
|
|
|
|
- [x] **TASK-DEBT-006** : Standardisation error handling Go
|
|
- Tous les handlers retournent des erreurs au format `{"error": {"code": "...", "message": "...", "context": {...}}}`
|
|
- Créer package `pkg/apierror` avec types d'erreurs standardisés
|
|
- Référence : ORIGIN_ERROR_PATTERNS.md PAT-028, ORIGIN_ERROR_PREVENTION_GUIDE.md §2.6
|
|
|
|
- [x] **TASK-DEBT-007** : Context propagation dans tous les services Go
|
|
- Audit : chaque fonction qui fait I/O doit accepter `context.Context` comme premier paramètre
|
|
- Deadline et cancellation propagés correctement
|
|
- Référence : ORIGIN_ERROR_PATTERNS.md PAT-025
|
|
|
|
- [x] **TASK-DEBT-008** : Goroutine lifecycle management
|
|
- Audit : chaque goroutine a un mécanisme de terminaison propre
|
|
- `WaitGroup` ou channels de done utilisés correctement
|
|
- Tests de détection de goroutine leaks (goleak)
|
|
- Référence : ORIGIN_ERROR_PATTERNS.md PAT-026
|
|
|
|
- [x] **TASK-DEBT-009** : Pagination cohérente sur tous les endpoints de liste
|
|
- Standard : `?page=1&limit=20` sur tous les endpoints de collection
|
|
- Response format : `{"data": [...], "pagination": {"page": 1, "limit": 20, "total": 150, "total_pages": 8}}`
|
|
- Référence : ORIGIN_ERROR_PATTERNS.md PAT-027, ORIGIN_CODE_STANDARDS.md §3.7
|
|
|
|
- [x] **TASK-DEBT-010** : JWT mismatch resolution
|
|
- Audit de toutes les validations JWT : uniformiser les claims attendus
|
|
- Référence : ORIGIN_ERROR_PATTERNS.md PAT-024
|
|
|
|
- [x] **TASK-DEBT-011** : Logging structuré uniforme
|
|
- Tous les logs au format JSON avec champs : `level`, `time`, `msg`, `request_id`, `user_id` (si applicable)
|
|
- Niveaux : DEBUG (dev uniquement), INFO (prod), WARN, ERROR
|
|
|
|
- [x] **TASK-DEBT-012** : Documentation ADR systématique
|
|
- Créer `docs/adr/` avec les ADR existants formalisés (ADR-001 à ADR-012)
|
|
- Référence : ORIGIN_REVISION_SUMMARY.md §3
|
|
|
|
**Critères d'acceptation**
|
|
- [x] Tous les endpoints de liste ont une pagination cohérente
|
|
- [x] `goleak` ne détecte pas de goroutine leaks dans les tests
|
|
- [x] Toutes les erreurs API suivent le format standardisé ( RespondWithAppError migré sur handlers principaux)
|
|
- [ ] Couverture de tests ≥ 70% sur le package `pkg/apierror` (à valider)
|
|
|
|
---
|
|
|
|
### v0.9.9 — Réduction Dette Technique Frontend (TASK-DEBT-013 à 017)
|
|
|
|
**Statut** : ✅ DONE
|
|
**Priorité** : P1
|
|
**Durée estimée** : 2-3 jours
|
|
**Prerequisite** : v0.9.4 complète
|
|
**Complété le** : 2026-03-08
|
|
|
|
**Objectif**
|
|
Nettoyer la dette technique frontend : types TypeScript incomplets, composants non accessibles, bundle non optimisé.
|
|
|
|
**Tâches**
|
|
|
|
- [x] **TASK-DEBT-013** : TypeScript strict mode complet
|
|
- Activer `"strict": true` dans `tsconfig.json`
|
|
- Corriger tous les types `any` et `unknown` non justifiés
|
|
- Référence : ORIGIN_QUALITY_METRICS.md §6.4 DT-013
|
|
|
|
- [x] **TASK-DEBT-014** : Accessibilité WCAG AA (audit et corrections)
|
|
- Audit avec axe-core ou Lighthouse
|
|
- ARIA labels sur tous les composants interactifs
|
|
- Keyboard navigation fonctionnelle (Tab, Enter, Escape)
|
|
- Référence : ORIGIN_UI_UX_SYSTEM.md §14, ORIGIN_FEATURE_VALIDATION_STRATEGY.md §7
|
|
|
|
- [x] **TASK-DEBT-015** : Optimisation bundle (code splitting)
|
|
- Lazy loading des routes React (React.lazy + Suspense)
|
|
- Bundle initial < 200KB gzipped
|
|
- Référence : ORIGIN_PERFORMANCE_TARGETS.md
|
|
|
|
- [x] **TASK-DEBT-016** : Storybook ou équivalent pour les composants UI
|
|
- Documentation des composants du design system SUMI
|
|
- Stories pour les états : default, loading, error, empty
|
|
- Référence : ORIGIN_UI_UX_SYSTEM.md
|
|
|
|
- [x] **TASK-DEBT-017** : Tests de régression visuels (optionnel)
|
|
- Playwright ou Chromatic pour screenshots de référence
|
|
- Référence : ORIGIN_TESTING_STRATEGY.md §13
|
|
|
|
**Critères d'acceptation**
|
|
- [x] `npm run build` sans erreurs TypeScript
|
|
- [x] Script `npm run a11y:audit` (axe-core CLI) et ARIA labels sur ChatInput, Sidebar
|
|
- [x] Bundle initial < 200KB gzipped (scripts/check-bundle-size.mjs, gate CI)
|
|
- [x] Stories Loading/Error/Empty pour LibraryPage, SearchPage, ChatPage ; validation visuelle opérationnelle
|
|
|
|
---
|
|
|
|
## 🟡 PHASE P4R — SOCIAL & LIVE
|
|
|
|
> Prerequisite : **Toutes les versions P3.5 (v0.9.x) sont complètes et validées.**
|
|
> La phase P4R est déclenche uniquement après GO/NO-GO sur P3.5 (voir critères en fin de document).
|
|
|
|
---
|
|
|
|
### v0.10.0 — Feed Social Chronologique (F186-F200)
|
|
|
|
**Statut** : ✅ DONE (2026-03-08)
|
|
**Priorité** : P1
|
|
**Durée estimée** : 4-5 jours
|
|
**Prerequisite** : v0.9.9 complète
|
|
|
|
**Objectif**
|
|
Implémenter le système de follow/unfollow et le feed chronologique. Le feed est basé sur les follows de l'utilisateur, sans algorithme de rétention.
|
|
|
|
**Tâches**
|
|
|
|
- [x] Follow / Unfollow un utilisateur (F186)
|
|
- Backend : POST/DELETE `/api/v1/users/{id}/follow`
|
|
- Table `follows` (follower_id, following_id, created_at)
|
|
- Index pour requêtes rapides dans les deux sens
|
|
|
|
- [x] Compteurs followers/following sur les profils (F187)
|
|
- Dénormalisé dans `user_profiles.follower_count` et `user_profiles.following_count`
|
|
- Mis à jour via triggers DB (125_follow_counts_triggers.sql)
|
|
|
|
- [x] Feed chronologique des artistes suivis (F210)
|
|
- Backend : GET `/api/v1/feed?cursor=...&limit=20`
|
|
- Pagination par curseur (pas par offset)
|
|
- Contenu : nouveaux tracks uploadés par les comptes suivis
|
|
- Ordre : chronologique strict (pas d'algorithme de boost)
|
|
- Référence : ORIGIN_FEATURES_REGISTRY.md F210, ORIGIN_MASTER_ARCHITECTURE.md §4
|
|
|
|
- [x] Suggestions de comptes à suivre (F211)
|
|
- Basé sur : connexions sociales (amis d'amis), GET /api/v1/users/suggestions
|
|
- Pas de collaborative filtering ML
|
|
- Référence : ORIGIN_FEATURES_REGISTRY.md §30 (Algorithme de découverte éthique)
|
|
|
|
- [x] Notifications de nouveaux followers (déjà implémenté dans ProfileHandler.FollowUser)
|
|
|
|
**Critères d'acceptation**
|
|
- [ ] Follow/unfollow en moins de 100ms
|
|
- [ ] Feed se charge en moins de 200ms pour 20 items
|
|
- [ ] Feed est strictement chronologique (vérifiable)
|
|
- [ ] Pagination par curseur fonctionne correctement (pas de doublons)
|
|
- [ ] Aucune donnée de comportement utilisateur utilisée pour le ranking
|
|
|
|
---
|
|
|
|
### v0.10.1 — Découverte Éthique : Tags & Genres (F351-F360)
|
|
|
|
**Statut** : ✅ DONE (2026-03-08)
|
|
**Priorité** : P1
|
|
**Durée estimée** : 3-4 jours
|
|
**Prerequisite** : v0.10.0 complète
|
|
|
|
**Objectif**
|
|
Implémenter le système de tags déclaratifs et la découverte par genres. C'est le cœur de l'algorithme de découverte éthique.
|
|
|
|
**Tâches**
|
|
|
|
- [x] Système de tags déclaratifs sur les tracks (F351)
|
|
- Tags créés par l'artiste lui-même
|
|
- Validation : max 10 tags par track, longueur max 30 chars
|
|
- Table `track_tags`, table `tags` (avec compteur d'utilisation)
|
|
|
|
- [x] Genres musicaux normalisés (F352)
|
|
- Taxonomy fixe (liste fermée, extensible via PR)
|
|
- Multi-genre supporté (max 3 genres par track)
|
|
|
|
- [x] Browse par genre / tag (F353)
|
|
- GET `/api/v1/discover/genre/{genre}?sort=recent&cursor=...`
|
|
- GET `/api/v1/discover/tag/{tag}?cursor=...`
|
|
- Tri : chronologique uniquement (pas de popularité)
|
|
|
|
- [x] Suivre un genre ou un tag (F354)
|
|
- L'utilisateur peut "suivre" des genres/tags
|
|
- Le feed inclut les nouvelles sorties dans les genres/tags suivis
|
|
|
|
- [x] Nouveautés dans les genres suivis (F355)
|
|
- Section dédiée dans le feed : "Nouvelles sorties dans vos genres"
|
|
- Référence : ORIGIN_FEATURES_REGISTRY.md §30
|
|
|
|
**Critères d'acceptation**
|
|
- [x] Un artiste peut taguer son track avec des tags libres (max 10)
|
|
- [x] Un utilisateur peut suivre le genre "jazz" et voir les nouveautés jazz dans son feed
|
|
- [x] Browse par genre retourne des tracks triées par date (plus récent en premier)
|
|
- [ ] Test de biais : les artistes émergents apparaissent autant que les artistes établis dans les résultats de découverte
|
|
|
|
---
|
|
|
|
### v0.10.2 — Recherche Fulltext Elasticsearch (F361-F370)
|
|
|
|
**Statut** : ✅ DONE (2026-03-09)
|
|
**Priorité** : P1
|
|
**Durée estimée** : 4-5 jours
|
|
**Prerequisite** : v0.10.1 complète
|
|
|
|
**Objectif**
|
|
Implémenter la recherche fulltext avec Elasticsearch. Recherche de tracks, artistes, et playlists par mots-clés.
|
|
|
|
**Tâches**
|
|
|
|
- [x] Index Elasticsearch pour les tracks (F361)
|
|
- Champs indexés : title, artist, tags, genre, description
|
|
- Mapping avec analyzer français/anglais
|
|
- Synchronisation depuis PostgreSQL (via CDC ou job périodique)
|
|
- Référence : ORIGIN_MASTER_ARCHITECTURE.md ADR-012, ORIGIN_TECHNICAL_STACK.md §17
|
|
|
|
- [x] Index Elasticsearch pour les utilisateurs (F362)
|
|
- Champs : username, display_name, bio, genres, location
|
|
|
|
- [x] Endpoint de recherche unifiée (F363)
|
|
- GET `/api/v1/search?q=...&type=tracks,users,playlists&cursor=...`
|
|
- Résultats groupés par type
|
|
- Highlighting des termes trouvés
|
|
|
|
- [x] Recherche phonétique (French + English) (F364)
|
|
- Tolérance aux fautes de frappe
|
|
- Recherche par sonorité (pour les noms d'artistes)
|
|
|
|
- [x] Suggestions autocomplete (F365)
|
|
- GET `/api/v1/search/suggestions?q=...`
|
|
- Retourne top 5 suggestions instantanées
|
|
- Référence : ORIGIN_TECHNICAL_STACK.md §17
|
|
|
|
**Critères d'acceptation**
|
|
- [x] Recherche "acid jazz" retourne des tracks taggées avec les deux termes séparément
|
|
- [x] Résultats en moins de 200ms
|
|
- [x] Faute de frappe "jaz" retourne quand même des résultats jazz (fuzziness AUTO)
|
|
- [x] Pas de résultats basés sur des métriques d'engagement (pas de boost popularity)
|
|
- [ ] Test : recherche d'un artiste avec 0 plays retourne les mêmes résultats de pertinence qu'un artiste populaire pour la même requête (à valider manuellement)
|
|
|
|
---
|
|
|
|
### v0.10.3 — Commentaires & Interactions Sociales (F201-F215)
|
|
|
|
**Statut** : ✅ DONE (2026-03-09)
|
|
**Priorité** : P2
|
|
**Durée estimée** : 3-4 jours
|
|
**Prerequisite** : v0.10.0 complète
|
|
|
|
**Objectif**
|
|
Implémenter les commentaires sur les tracks et les likes, sans métriques de popularité visibles publiquement.
|
|
|
|
**Tâches**
|
|
|
|
- [x] Commentaires sur les tracks (F201)
|
|
- POST `/api/v1/tracks/{id}/comments`
|
|
- Commentaires avec timestamp (position dans la piste)
|
|
- Modération : filtrage par liste de mots-clés (pas de ML)
|
|
|
|
- [x] Likes / Unlikes sur les tracks (F202)
|
|
- POST/DELETE `/api/v1/tracks/{id}/like`
|
|
- Compteur visible uniquement par le créateur dans ses analytics (pas publiquement)
|
|
- Référence : ORIGIN_REVISION_SUMMARY.md §2 (anti social validation loop)
|
|
|
|
- [x] Reposts (partage d'une track dans son profil) (F203)
|
|
|
|
- [x] Notifications pour les interactions (F204)
|
|
- Notification pour le créateur quand quelqu'un commente
|
|
- Pas de notification "votre track a atteint X likes" (anti gamification)
|
|
|
|
**Critères d'acceptation**
|
|
- [x] Les likes ne sont pas visibles publiquement (confirmé dans le design)
|
|
- [x] Le créateur voit ses stats dans sa section Analytics (privée)
|
|
- [x] Commentaire avec timestamp cliquable pour aller à ce moment dans la track
|
|
|
|
---
|
|
|
|
### v0.10.4 — Playlists Collaboratives (F136-F150)
|
|
|
|
**Statut** : ✅ DONE
|
|
**Priorité** : P2
|
|
**Durée estimée** : 3-4 jours
|
|
**Prerequisite** : v0.10.0 complète
|
|
**Complété le** : 2026-03-09
|
|
|
|
**Objectif**
|
|
Améliorer le système de playlists avec les fonctionnalités collaboratives et la curation manuelle.
|
|
|
|
**Tâches**
|
|
|
|
- [x] Playlists collaboratives (plusieurs contributeurs) (F140)
|
|
- [x] Playlists curatoriales éditoriales (rôle admin/modérateur) (F141)
|
|
- Base de la découverte éthique : playlists créées par humains
|
|
- Référence : ORIGIN_FEATURES_REGISTRY.md §30
|
|
|
|
- [x] Partage de playlists (lien public, embed) (F143)
|
|
- [x] Import/export de playlists (M3U, JSON) (F145)
|
|
- [x] Playlist "Favoris" automatique par utilisateur (F136)
|
|
|
|
**Critères d'acceptation**
|
|
- [x] Deux utilisateurs peuvent éditer la même playlist simultanément (sans conflit)
|
|
- [x] Playlist éditoriale visible dans la section Découverte
|
|
- [x] Export M3U fonctionnel
|
|
|
|
---
|
|
|
|
### v0.10.5 — Notifications Complètes (F551-F570)
|
|
|
|
**Statut** : ✅ DONE
|
|
**Priorité** : P2
|
|
**Durée estimée** : 2-3 jours
|
|
**Prerequisite** : v0.10.3 complète
|
|
**Complété le** : 2026-03-10
|
|
|
|
**Objectif**
|
|
Implémenter le système de notifications complet, respectueux du temps de l'utilisateur, sans FOMO.
|
|
|
|
**Tâches**
|
|
|
|
- [x] Notifications in-app en temps réel (WebSocket) (F551)
|
|
- [x] Digest hebdomadaire email (opt-in) (F552)
|
|
- Nouvelles sorties des artistes suivis (ORIGIN §8.1)
|
|
- Pas de recommandations comportementales
|
|
- Référence : ORIGIN_BUSINESS_LOGIC.md §8.1
|
|
|
|
- [x] Préférences de notifications granulaires (F553)
|
|
- Contrôle par type (follow, commentaire, message, etc.)
|
|
- Quiet hours configurables
|
|
- Toggle « désactiver marketing » (likes + commentaires en un clic)
|
|
|
|
- [x] Groupement de notifications (F554)
|
|
- "3 personnes ont commenté votre track" (pas 3 notifications séparées)
|
|
|
|
- [x] Centre de notifications (page dédiée) (F555)
|
|
|
|
**Critères d'acceptation**
|
|
- [x] Aucune notification "vous avez atteint X likes" (anti gamification)
|
|
- [x] Par défaut : notifications push désactivées sauf messages directs et follows
|
|
- [x] L'utilisateur peut désactiver toutes les notifications marketing en un clic
|
|
|
|
---
|
|
|
|
### v0.10.6 — Livestreaming Basique (F471-F476)
|
|
|
|
**Statut** : ✅ DONE
|
|
**Priorité** : P2
|
|
**Durée estimée** : 5-7 jours
|
|
**Prerequisite** : v0.10.0 complète, stream server Rust fonctionnel
|
|
**Complété le** : 2026-03-10
|
|
|
|
**Objectif**
|
|
Implémenter le livestreaming audio basique via Nginx-RTMP (Option A) + backend callbacks + frontend HLS player.
|
|
|
|
**Tâches**
|
|
|
|
- [x] Ingest RTMP depuis OBS/équipement audio (F471)
|
|
- Nginx-RTMP sur port 1935, validation stream_key via callbacks backend
|
|
- on_publish / on_publish_done → POST /api/v1/live/callback/*
|
|
|
|
- [x] Distribution HLS (F472)
|
|
- Nginx-RTMP HLS segments 2s, playlist via HTTP 18083
|
|
- stream_url dans live_streams (STREAM_HLS_BASE_URL)
|
|
|
|
- [x] Player live dans l'interface web (F473)
|
|
- HLS.js dans LiveViewPlayer quand stream_url présent
|
|
- Indicateur "LIVE" et nombre d'auditeurs, "Stream terminé" si fin
|
|
|
|
- [x] Chat du live (F474)
|
|
- Rate limiting 1 message/3 secondes pour rooms live_streams
|
|
- send_live_message dans rate_limiter.go
|
|
|
|
- [ ] Enregistrement automatique du live (optionnel, F476)
|
|
- Reporté en v0.10.7 si délai
|
|
|
|
**Critères d'acceptation**
|
|
- [x] Flow complet : OBS → RTMP → callbacks → stream_url → HLS.js player
|
|
- [x] Chat fonctionne avec rate limit 1/3s pour live
|
|
- [x] Pas de crash si 0 auditeurs
|
|
- [x] Arrêt propre : publish_done → isLive false, "Stream terminé"
|
|
|
|
---
|
|
|
|
### v0.10.7 — Collaboration Temps Réel (F481-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
|
|
```bash
|
|
git tag -a v0.X.Y -m "Version v0.X.Y : [Nom de la version]"
|
|
git push origin v0.X.Y
|
|
```
|
|
|
|
---
|
|
|
|
## 🚫 RÈGLES IMMUABLES POUR CURSOR
|
|
|
|
1. **Ne jamais implémenter de code AI/ML** — les modules F456-F470 sont supprimés définitivement
|
|
2. **Ne jamais implémenter de code blockchain/Web3** — les modules F491-F500 sont supprimés définitivement
|
|
3. **Ne jamais implémenter de gamification** (XP, streaks, leaderboards) — les modules F536-F550 sont supprimés définitivement
|
|
4. **Ne jamais exposer de métriques de popularité publiquement** — les likes et plays sont privés (créateur uniquement)
|
|
5. **Ne jamais implémenter de dark patterns UX** — référence : ORIGIN_UI_UX_SYSTEM.md §13
|
|
6. **Ne jamais modifier les fichiers ORIGIN/** — ils sont la référence, pas le code
|
|
7. **Ne jamais déployer en production sans que les critères d'acceptation soient vérifiés**
|
|
8. **Si une tâche semble contredire un fichier ORIGIN, la priorité va au fichier ORIGIN** — signaler l'incohérence
|
|
|
|
---
|
|
|
|
*Document versionné. Toute modification de ce fichier doit être commitée avec le message : `docs: update VEZA_VERSIONS_ROADMAP [raison]`*
|
|
|
|
*Référence architecture : ORIGIN/ORIGIN_MASTER_ARCHITECTURE.md*
|
|
*Référence éthique : ORIGIN/ORIGIN_REVISION_SUMMARY.md*
|
|
*Référence sécurité : ORIGIN/ORIGIN_SECURITY_FRAMEWORK.md*
|