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>
178 lines
7.6 KiB
Gherkin
178 lines
7.6 KiB
Gherkin
# language: fr
|
|
Fonctionnalité: Commande "Précédent"
|
|
En tant qu'auditeur
|
|
Je veux que le bouton "Précédent" ait un comportement intelligent
|
|
Afin de rejouer le contenu actuel ou revenir au précédent selon la progression
|
|
|
|
Contexte:
|
|
Étant donné que l'API RoadWave est disponible
|
|
Et qu'un utilisateur est connecté
|
|
|
|
Scénario: Précédent après <10s revient au contenu précédent
|
|
Étant donné que j'ai écouté le contenu "A" pendant 2 minutes
|
|
Et que j'écoute maintenant le contenu "B" depuis 5 secondes
|
|
Quand j'appuie sur "Précédent"
|
|
Alors la lecture revient au contenu "A"
|
|
Et la position de lecture est à 2 minutes (position exacte sauvegardée)
|
|
Et le contenu "B" reste en historique
|
|
|
|
Scénario: Précédent après ≥10s rejoue le contenu actuel
|
|
Étant donné que j'écoute le contenu "C" depuis 15 secondes
|
|
Quand j'appuie sur "Précédent"
|
|
Alors le contenu "C" rejoue depuis le début (position 0:00)
|
|
Et la lecture ne revient pas au contenu précédent
|
|
Et la progress bar revient à 0%
|
|
|
|
Scénario: Précédent exactement à 10s rejoue le contenu actuel
|
|
Étant donné que j'écoute le contenu "D" depuis exactement 10 secondes
|
|
Quand j'appuie sur "Précédent"
|
|
Alors le contenu "D" rejoue depuis le début
|
|
Et la lecture ne revient pas au contenu précédent
|
|
|
|
Scénario: Précédent sur le premier contenu de session
|
|
Étant donné que je viens de démarrer l'application
|
|
Et que j'écoute le contenu "Premier" depuis 3 secondes
|
|
Quand j'appuie sur "Précédent"
|
|
Alors le contenu "Premier" rejoue depuis le début
|
|
Et aucun contenu précédent n'existe
|
|
|
|
Scénario: Historique de navigation limité à 10 contenus
|
|
Étant donné que j'ai écouté 10 contenus [C1, C2, ..., C10]
|
|
Et que l'historique Redis contient 10 entrées
|
|
Quand je passe au contenu C11
|
|
Alors le contenu C1 est supprimé de l'historique (FIFO)
|
|
Et l'historique contient [C2, C3, ..., C10, C11]
|
|
Et la taille reste à 10 contenus maximum
|
|
|
|
Scénario: Position exacte sauvegardée dans l'historique
|
|
Étant donné que j'écoute le contenu "A" (durée 5 minutes)
|
|
Quand j'atteins 2 minutes 30 secondes
|
|
Et que j'appuie sur "Suivant"
|
|
Alors l'historique enregistre:
|
|
| content_id | position_seconds | listened_at |
|
|
| A | 150 | 2026-01-21T10:30:00 |
|
|
Quand je reviens au contenu "A" via "Précédent"
|
|
Alors la lecture reprend exactement à 2 minutes 30 secondes
|
|
|
|
Scénario: Navigation arrière sur plusieurs contenus
|
|
Étant donné que j'ai écouté dans l'ordre: A (2min), B (30s), C (3min)
|
|
Et que j'écoute maintenant D depuis 1 seconde
|
|
Quand j'appuie sur "Précédent" (1ère fois)
|
|
Alors je reviens au contenu C à la position 3 minutes
|
|
Quand j'appuie sur "Précédent" (<10s sur C)
|
|
Alors je reviens au contenu B à la position 30 secondes
|
|
Quand j'appuie sur "Précédent" (<10s sur B)
|
|
Alors je reviens au contenu A à la position 2 minutes
|
|
|
|
Scénario: Précédent après milieu du contenu rejoue depuis début
|
|
Étant donné que j'écoute un contenu de 5 minutes
|
|
Quand j'atteins 2 minutes 30 secondes (milieu)
|
|
Et que j'appuie sur "Précédent"
|
|
Alors le contenu actuel rejoue depuis 0:00
|
|
Et je ne reviens pas au contenu précédent
|
|
|
|
Scénario: Enchaînement Suivant puis Précédent rapide
|
|
Étant donné que j'écoute le contenu "A" depuis 1 minute
|
|
Quand j'appuie sur "Suivant"
|
|
Alors le contenu "B" démarre
|
|
Quand j'appuie immédiatement sur "Précédent" (2s après)
|
|
Alors je reviens au contenu "A" à la position 1 minute
|
|
Et le contenu "B" reste dans l'historique
|
|
|
|
Scénario: Transition fluide avec animation 0.3s
|
|
Étant donné que j'appuie sur "Précédent"
|
|
Quand le changement de contenu se produit
|
|
Alors la transition audio utilise un fade out/in de 0.3 secondes
|
|
Et la progress bar revient avec une animation fluide
|
|
Et l'interface ne montre aucun message de confirmation
|
|
|
|
Scénario: Historique survit au changement de réseau
|
|
Étant donné que j'ai un historique de 5 contenus en cache Redis
|
|
Quand je perds la connexion réseau temporairement
|
|
Et que je reviens en ligne
|
|
Alors l'historique de navigation est toujours disponible
|
|
Et je peux toujours utiliser "Précédent"
|
|
|
|
Scénario: Historique stocké en Redis avec structure complète
|
|
Étant donné que j'ai écouté 3 contenus
|
|
Quand je consulte le cache Redis
|
|
Alors la structure est:
|
|
"""
|
|
user:{user_id}:history = [
|
|
{content_id: "C3", position_seconds: 45, listened_at: "2026-01-21T10:33:00Z"},
|
|
{content_id: "C2", position_seconds: 120, listened_at: "2026-01-21T10:30:00Z"},
|
|
{content_id: "C1", position_seconds: 180, listened_at: "2026-01-21T10:27:00Z"}
|
|
]
|
|
"""
|
|
Et l'ordre est du plus récent au plus ancien
|
|
|
|
Scénario: Précédent sur contenu en cours au début (<10s) du premier
|
|
Étant donné que je démarre une session avec le contenu "Initial"
|
|
Et que j'écoute depuis 3 secondes
|
|
Quand j'appuie sur "Précédent"
|
|
Alors le contenu "Initial" rejoue depuis le début
|
|
Et aucune erreur n'est générée
|
|
Et l'historique reste vide
|
|
|
|
Scénario: Compteur de temps respecte les seuils exacts
|
|
Étant donné que j'écoute un contenu
|
|
Quand le temps écoulé est de 9.9 secondes
|
|
Et que j'appuie sur "Précédent"
|
|
Alors je reviens au contenu précédent
|
|
Quand le temps écoulé est de 10.0 secondes
|
|
Et que j'appuie sur "Précédent"
|
|
Alors le contenu actuel rejoue depuis le début
|
|
|
|
Scénario: Progress bar visuelle reflète le retour exact
|
|
Étant donné que j'ai écouté le contenu "A" jusqu'à 75% (3min45 sur 5min)
|
|
Et que je suis passé au contenu "B"
|
|
Quand je reviens au contenu "A" via "Précédent"
|
|
Alors la progress bar affiche 75%
|
|
Et l'indicateur de temps affiche "3:45 / 5:00"
|
|
Et la lecture reprend exactement à cet endroit
|
|
|
|
Scénario: Métadonnées d'historique incluent timestamp précis
|
|
Étant donné que j'écoute un contenu "X" pendant 45 secondes à 10:30:15
|
|
Quand je passe au contenu suivant
|
|
Alors l'historique enregistre:
|
|
| content_id | position_seconds | listened_at |
|
|
| X | 45 | 2026-01-21T10:30:15Z |
|
|
Et le timestamp précis permet l'analyse d'usage
|
|
|
|
Scénario: Suppression FIFO respecte l'ordre chronologique
|
|
Étant donné un historique de [C1@10:00, C2@10:02, ..., C10@10:20]
|
|
Quand j'ajoute C11 à 10:22
|
|
Alors C1 (le plus ancien) est supprimé
|
|
Et l'historique contient [C2@10:02, ..., C11@10:22]
|
|
Et la taille reste exactement 10 entrées
|
|
|
|
Plan du Scénario: Comportement selon temps écouté
|
|
Étant donné que j'écoute un contenu depuis <temps> secondes
|
|
Quand j'appuie sur "Précédent"
|
|
Alors l'action est <comportement>
|
|
|
|
Exemples:
|
|
| temps | comportement |
|
|
| 1 | revenir au contenu précédent |
|
|
| 5 | revenir au contenu précédent |
|
|
| 9 | revenir au contenu précédent |
|
|
| 10 | rejouer le contenu actuel depuis 0:00 |
|
|
| 11 | rejouer le contenu actuel depuis 0:00 |
|
|
| 30 | rejouer le contenu actuel depuis 0:00 |
|
|
| 180 | rejouer le contenu actuel depuis 0:00 |
|
|
|
|
Plan du Scénario: Positions de reprise exactes
|
|
Étant donné que j'écoute un contenu de 10 minutes
|
|
Quand j'atteins <position> et passe au suivant
|
|
Et que je reviens via "Précédent"
|
|
Alors la lecture reprend exactement à <position>
|
|
|
|
Exemples:
|
|
| position |
|
|
| 0:15 |
|
|
| 1:30 |
|
|
| 3:45 |
|
|
| 5:00 |
|
|
| 7:23 |
|
|
| 9:50 |
|