37c62206ad
Résolution des incohérences #10, #11, et #12 de l'analyse d'architecture. ## Phase 1 : Réorganisation Features BDD (Point #10 - RÉSOLU) - Créer structure features/{api,ui,e2e} - Déplacer 83 features en 3 catégories via git mv (historique préservé) - features/api/ : 53 features (tests API backend) - features/ui/ : 22 features (tests UI mobile) - features/e2e/ : 8 features (tests end-to-end) Domaines déplacés : - API : authentication, recommendation, rgpd-compliance, content-creation, moderation, monetisation, premium, radio-live, publicites - UI : audio-guides, navigation, interest-gauges, mode-offline, partage, profil, recherche - E2E : abonnements, error-handling ## Phase 2 : Mise à jour Documentation ### ADR-007 - Tests BDD - Ajouter section "Convention de Catégorisation des Features" - Documenter règles api/ui/e2e avec exemples concrets - Spécifier step definitions (backend Go, mobile Dart) ### ADR-024 - Stratégie CI/CD Monorepo (NOUVEAU) - Créer ADR dédié pour stratégie CI/CD avec path filters - Architecture workflows séparés (backend.yml, mobile.yml, shared.yml) - Configuration path filters détaillée avec exemples YAML - Matrice de déclenchement et optimisations (~70% gain temps CI) - Plan d'implémentation (~2h, reporté jusqu'au développement) ### ADR-016 - Organisation Monorepo - Simplifier en retirant section CI/CD détaillée - Ajouter référence vers ADR-024 pour stratégie CI/CD ### INCONSISTENCIES-ANALYSIS.md - Point #10 (Tests BDD synchronisés) : ✅ RÉSOLU - Catégorisation features implémentée - ADR-007 mis à jour avec convention complète - Point #11 (70/30 Split paiements) : ✅ ANNULÉ (faux problème) - ADR-009 et Règle 18 parfaitement cohérents - Documentation exhaustive existante (formule, SQL, comparaisons) - Point #12 (Monorepo path filters) : ⏸️ DOCUMENTÉ - Architecture CI/CD complète dans ADR-024 - Implémentation reportée (projet en phase documentation) - Métriques mises à jour : - MODERATE : 6/9 traités (4 résolus + 1 annulé + 1 documenté) - ADR à jour : 100% (19/19 avec ADR-024) ## Phase 3 : Validation - Structure features validée (api/ui/e2e, aucun répertoire restant) - Historique Git préservé (git mv, renommages détectés) - 83 features total (API: 53, UI: 22, E2E: 8) Closes: Point #10 (résolu), Point #11 (annulé), Point #12 (documenté) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
160 lines
7.5 KiB
Gherkin
160 lines
7.5 KiB
Gherkin
# language: fr
|
|
Fonctionnalité: Arrêt du live
|
|
En tant que créateur
|
|
Je veux arrêter ma diffusion en direct de manière contrôlée
|
|
Afin de terminer proprement mon live et générer un replay automatiquement
|
|
|
|
Contexte:
|
|
Étant donné que l'API RoadWave est disponible
|
|
Et que je suis connecté en tant que créateur
|
|
Et que je diffuse actuellement un live
|
|
|
|
Scénario: Arrêt manuel avec compte à rebours 5 secondes
|
|
Quand j'appuie sur le bouton "Arrêter live"
|
|
Alors un compte à rebours de 5 secondes démarre
|
|
Et je vois le message "Ce live se termine dans 5... 4... 3... 2... 1"
|
|
Et un bouton "Annuler" est affiché pendant le décompte
|
|
Et l'audio du compte à rebours est diffusé aux auditeurs
|
|
|
|
Scénario: Annulation du compte à rebours
|
|
Étant donné que j'ai appuyé sur "Arrêter live"
|
|
Et que le compte à rebours affiche "3 secondes"
|
|
Quand j'appuie sur "Annuler"
|
|
Alors le compte à rebours s'arrête
|
|
Et le live continue normalement
|
|
Et aucune notification n'est envoyée aux auditeurs
|
|
|
|
Scénario: Arrêt effectif après compte à rebours
|
|
Étant donné que le compte à rebours est à 0
|
|
Alors le live s'arrête
|
|
Et la diffusion aux auditeurs se termine
|
|
Et le message "Live terminé" s'affiche
|
|
Et le processus de traitement post-live démarre automatiquement
|
|
|
|
Scénario: Déconnexion créateur courte (moins de 60 secondes)
|
|
Étant donné que je diffuse un live
|
|
Quand ma connexion est perdue pendant 30 secondes
|
|
Alors les auditeurs voient le message "Connexion créateur perdue, reconnexion en cours..."
|
|
Et le live continue de bufferer
|
|
Et quand ma connexion revient, le live reprend normalement
|
|
|
|
Scénario: Déconnexion créateur longue (60 secondes ou plus)
|
|
Étant donné que je diffuse un live
|
|
Quand ma connexion est perdue pendant 60 secondes
|
|
Alors le live s'arrête automatiquement
|
|
Et les auditeurs voient le message "Le live est terminé suite à une coupure de connexion"
|
|
Et le processus de traitement post-live démarre
|
|
|
|
Scénario: Enregistrement automatique pendant le live
|
|
Étant donné que je diffuse un live
|
|
Alors mon flux audio est enregistré en continu
|
|
Et le format d'enregistrement est Opus raw
|
|
Et l'enregistrement est stocké temporairement sur le serveur
|
|
|
|
Scénario: Génération automatique du replay après arrêt
|
|
Étant donné que mon live vient de se terminer
|
|
Et que l'option "Publier replay automatiquement" est activée (par défaut)
|
|
Quand le traitement post-live démarre
|
|
Alors un job asynchrone est créé
|
|
Et le job effectue les opérations suivantes:
|
|
| opération | détail |
|
|
| Conversion format | Opus raw → MP3 256 kbps |
|
|
| Génération segments HLS | Segments .ts pour streaming |
|
|
| Normalisation volume | -14 LUFS |
|
|
| Détection silences prolongés | Nettoyage automatique |
|
|
|
|
Scénario: Publication du replay
|
|
Étant donné que le traitement post-live est terminé
|
|
Alors le replay est publié automatiquement sous 5 à 10 minutes
|
|
Et le titre est "[REPLAY] [Titre live original]"
|
|
Et la zone de diffusion est la même que le live
|
|
Et les tags sont identiques au live
|
|
Et la classification d'âge est identique
|
|
Et le type géographique est "Géo-neutre" (contenu pérenne)
|
|
|
|
Scénario: Notification de disponibilité du replay aux auditeurs
|
|
Étant donné que le replay de mon live est publié
|
|
Quand un auditeur qui a écouté le live se reconnecte
|
|
Alors il voit une notification in-app "Le replay de [Titre] est disponible"
|
|
|
|
Scénario: Option désactivation publication automatique replay
|
|
Étant donné que je configure un nouveau live
|
|
Quand je désactive l'option "Publier replay automatiquement"
|
|
Et que je démarre puis arrête le live
|
|
Alors le live est enregistré
|
|
Mais le replay n'est pas publié automatiquement
|
|
Et je peux décider manuellement de le publier plus tard
|
|
|
|
Scénario: Suppression manuelle du replay après publication
|
|
Étant donné que mon live a généré un replay publié
|
|
Quand j'accède à mes contenus
|
|
Alors je vois le replay dans ma liste
|
|
Et je peux le supprimer comme n'importe quel contenu
|
|
Quand je supprime le replay
|
|
Alors le fichier source Opus raw est supprimé immédiatement
|
|
|
|
Scénario: Conservation fichier source Opus raw
|
|
Étant donné que mon live est terminé
|
|
Et que le replay est publié
|
|
Alors le fichier Opus raw est conservé pendant 7 jours
|
|
Et après 7 jours, le fichier raw est supprimé automatiquement
|
|
Et seul le MP3 256 kbps est conservé
|
|
|
|
Scénario: Modification du replay interdite
|
|
Étant donné que mon live a généré un replay publié
|
|
Quand j'essaie de modifier l'audio du replay
|
|
Alors l'action est refusée
|
|
Et je vois le message "Les replays ne peuvent pas être modifiés pour garantir l'intégrité de l'enregistrement"
|
|
Et je peux uniquement modifier les métadonnées (titre, description)
|
|
|
|
Scénario: Statistiques du live disponibles après arrêt
|
|
Étant donné que mon live est terminé
|
|
Quand j'accède aux statistiques
|
|
Alors je vois:
|
|
| métrique | exemple valeur |
|
|
| Durée totale | 1h 23min |
|
|
| Nombre d'auditeurs max | 247 |
|
|
| Nombre d'auditeurs moyen | 183 |
|
|
| Nombre de likes | 89 |
|
|
| Nombre d'abonnements | 12 |
|
|
| Signalements reçus | 0 |
|
|
|
|
Scénario: Live terminé avec signalements en cours
|
|
Étant donné que mon live a reçu 3 signalements pendant la diffusion
|
|
Quand le live se termine
|
|
Alors le replay n'est pas publié automatiquement
|
|
Et le contenu est en attente de modération
|
|
Et je vois le message "Votre replay sera publié après vérification suite aux signalements reçus"
|
|
Et un modérateur doit valider ou refuser le replay sous 24h
|
|
|
|
Scénario: Arrêt forcé par un modérateur
|
|
Étant donné que je diffuse un live
|
|
Et qu'un modérateur détecte du contenu interdit
|
|
Quand le modérateur clique sur "Arrêter le live immédiatement"
|
|
Alors le live s'arrête sans compte à rebours
|
|
Et je vois le message "Votre live a été interrompu par la modération"
|
|
Et je reçois une notification détaillant la raison
|
|
Et le replay n'est pas publié
|
|
Et le fichier source est conservé 30 jours pour appel
|
|
|
|
Scénario: Métriques de bande passante pendant le live
|
|
Étant donné que je diffuse un live
|
|
Et que 100 auditeurs écoutent simultanément
|
|
Alors la bande passante consommée est d'environ 4.8 Mbps via NGINX Cache
|
|
Et le coût estimé infrastructure est d'environ 0.02€ par heure de diffusion
|
|
Et je peux voir ces métriques en temps réel dans l'interface créateur
|
|
|
|
Scénario: Live sans auditeurs pendant 5 minutes
|
|
Étant donné que je diffuse un live
|
|
Et qu'aucun auditeur n'écoute depuis 5 minutes
|
|
Alors je vois un message d'information "Aucun auditeur actuellement connecté"
|
|
Mais le live continue normalement
|
|
Et je peux choisir de continuer ou d'arrêter
|
|
|
|
Scénario: Qualité audio du replay supérieure au live
|
|
Étant donné que mon live était diffusé en Opus 48 kbps
|
|
Quand le replay est généré
|
|
Alors le replay est encodé en MP3 256 kbps
|
|
Et la qualité audio du replay est supérieure au live
|
|
Et la taille du fichier est optimisée pour le stockage long terme
|