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

7.5 KiB
Raw Blame History

Scope v0.203 — Phase 2 Contenu (finalisation)

Version cible : v0.203 (X=2, Y=3)
Prérequis : v0.202 taguée et mergée dans main
Objectif : Finaliser Phase 2 — Queue collaborative, recherche enrichie, Social Trending
Dernière mise à jour : 20 février 2026
Effort estimé : 3-4 semaines de développement

1. Principe directeur

v0.203 = dernière version Phase 2 (Contenu) avant Phase 3 (Social).

Trois axes principaux :

  1. Queue collaborative (D1) : Partager une queue en session
  2. Recherche enrichie (Lot K) : Phonétique, opérateurs booléens
  3. Social Trending (Lot L) : API /social/trending, brancher l’UI existante

2. Contexte — État post v0.202

2.1 Livré en v0.202

Lot Feature Statut
G Recherche avancée (musical_key, tri pertinence, autocomplete, facettes, historique) ✅
H Analytics créateur (stats, charts, completion rate, export) ✅
F Seller dashboard (GET /sell/stats, liste produits) ✅
C Player (crossfade, gapless, PiP) ✅
D2 Autoplay (GET /tracks/recommendations) ✅

2.2 Fondation existante (à enrichir)

Domaine Existant À ajouter v0.203
Queue Queue sync, PlayerQueue, autoplay D1 : session partagée, routes queue collaborative
Recherche GET /search, /tracks/search, suggestions, filters Phonétique (fuzzy), opérateurs booléens (AND/OR/NOT)
Social Feed, posts, groups, SocialViewTrending (statique) API GET /social/trending basée sur données réelles

3. Features IN SCOPE v0.203

3.1 Lot D1 — Queue collaborative (priorité moyenne)

Objectif : Permettre à plusieurs utilisateurs de partager une queue en session.
Effort : M (4-5 jours)
Référence : Module 4.2, feature 134 (veza_full_features_list)

# Feature Tâche détaillée Backend Frontend Critère de sortie
D1.1 Session queue Créer/joindre une session de queue partagée Modèle queue_session, routes POST/GET/DELETE /queue/session UI création / lien partage Session créée, lien généré
D1.2 Sync temps réel Participants voient la même queue WebSocket ou polling ; extension queue API PlayerQueue affiche queue partagée si session active Ajout/suppression visible par tous
D1.3 Contrôles Qui peut modifier la queue Rôle créateur vs participant (optionnel v1) Bouton « Passer la main » ou permissions Au moins créateur peut modifier

Fichiers clés :

  • Backend : queue_service.go, queue_handler.go, routes_queue.go, modèles queue_session
  • Frontend : PlayerQueue.tsx, useQueueSync.ts, queue API service
  • Chat/WebSocket : réutilisation ou extension pour sync queue (si pertinent)

3.2 Lot K — Recherche enrichie (priorité haute)

Objectif : Améliorer la pertinence et la flexibilité de la recherche.
Effort : M (3-4 jours)
Référence : Module 11, features 361, 363

# Feature Tâche détaillée Backend Frontend Critère de sortie
K1 Recherche phonétique Tolérance aux fautes de frappe, similarité sonore Extension Postgres pg_trgm ou équivalent ; similarity() dans TrackSearchService Aucun (transparent) « synthewave » → résultats « synthwave »
K2 Opérateurs booléens AND, OR, NOT, guillemets pour phrase exacte Parser query dans SearchService / TrackSearchService ; mapping vers tsquery ou ILIKE Option avancée ou syntaxe dans input rock AND jazz → intersection ; "love song" → phrase exacte

Fichiers clés :

  • Backend : track_search_service.go, search_service.go, migrations (pg_trgm si nécessaire)
  • Frontend : SearchPageHeader.tsx, aide contextuelle sur syntaxe booléenne (tooltip)

3.3 Lot L — Social Trending (priorité haute)

Objectif : Remplacer les tags statiques par des données réelles.
Effort : S (2-3 jours)
Référence : Module 6, feature 214 ; SocialViewTrending existant

# Feature Tâche détaillée Backend Frontend Critère de sortie
L1 API Trending Hashtags/posts/tracks tendance Route GET /social/trending ; agrégation posts récents, comptage hashtags Brancher SocialViewTrending sur l’API Données dynamiques affichées
L2 Cache / perf Éviter agrégation à chaque requête Cache Redis 15–60 min ou matview — Latence < 500 ms

Fichiers clés :

  • Backend : social_handler.go ou nouveau trending_handler.go, routes_social.go
  • Frontend : SocialViewTrending.tsx, service socialService.ts ou trendingService.ts

4. Récapitulatif par lot

Lot Nom Priorité Effort Features
D1 Queue collaborative Moyenne M (4-5j) 3
K Recherche enrichie Haute M (3-4j) 2
L Social Trending Haute S (2-3j) 2
TOTAL 9-12j 7

5. Features HORS SCOPE v0.203

Feature Raison Version cible
Collaborative filtering (rec. ML) Nécessite historique riche, complexité v0.301+
Correction orthographique (K3) Dépendance externe, effort v0.301+
Recherches sauvegardées UX secondaire v0.301+
2FA SMS, Passkeys v0.104 dédié v0.104
Go Live vidéo v0.703 v0.703

6. Ordre de livraison recommandé

Semaine Lots Activités
S1 L (Social Trending) L1–L2 : API /social/trending, cache, brancher SocialViewTrending
S2 K (Recherche) K1–K2 : phonétique, booléens
S3 D1 (Queue collaborative) D1.1–D1.3 : session, sync, contrôles
S4 Stabilisation Tests, docs, polish Phase 2

7. Branche et workflow

  • Branche : release/v0.203
  • Format commit : feat(scope): description (ex: feat(search): add boolean operators)
  • Référence scope : SCOPE_CONTROL.md → v0.203
  • PR : gh pr create --base main --head release/v0.203 --title "Release v0.203"

8. Critères de stabilité v0.203

8.1 Build & compilation

  • go build ./... — 0 erreur
  • npm run build — 0 erreur
  • npx tsc --noEmit — 0 erreur

8.2 Tests

  • go test ./... — pas de régression
  • Tests unitaires sur nouveaux services (search, trending, queue session)
  • E2E : recherche booléenne, trending (si applicable)

8.3 Documentation

  • FEATURE_STATUS.md mis à jour
  • CHANGELOG v0.203
  • MSW handlers pour /social/trending, /queue/session (si pertinent)

9. Transition vers Phase 3 (Social)

À l’issue de v0.203 :

  • Phase 2 Contenu est complète (~360 / 600 features)
  • Prochaine version : v0.301 — Phase 3 Social (chat avancé, présence, social complet)
  • Document de scope : V0_301_RELEASE_SCOPE.md (à créer après tag v0.203)

Références