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>
141 lines
6.3 KiB
Gherkin
141 lines
6.3 KiB
Gherkin
# language: fr
|
|
Fonctionnalité: Gestion de l'historique et reproposition
|
|
En tant que système de recommandation
|
|
Je veux gérer l'historique d'écoute intelligemment
|
|
Afin d'éviter les répétitions et offrir une découverte maximale
|
|
|
|
Contexte:
|
|
Étant donné que l'API RoadWave est disponible
|
|
|
|
Scénario: Contenu écouté complètement (>80%) - jamais reproposé
|
|
Étant donné qu'un utilisateur a écouté un contenu à 85%
|
|
Quand l'algorithme génère les recommandations
|
|
Alors ce contenu n'est jamais reproposé
|
|
Et il est marqué comme "écouté" dans l'historique
|
|
|
|
Scénario: Contenu écouté à 80% exactement - jamais reproposé
|
|
Étant donné qu'un utilisateur a écouté un contenu exactement à 80%
|
|
Quand l'algorithme génère les recommandations
|
|
Alors ce contenu n'est pas reproposé (seuil >= 80%)
|
|
|
|
Scénario: Contenu skippé rapidement (<10s) - ne pas reproposer
|
|
Étant donné qu'un utilisateur a skippé un contenu après 8 secondes
|
|
Quand l'algorithme génère les recommandations
|
|
Alors ce contenu n'est pas reproposé (signal négatif fort)
|
|
Et la jauge d'intérêt correspondante est réduite de 0.5%
|
|
|
|
Scénario: Contenu skippé exactement à 10s - ne pas reproposer
|
|
Étant donné qu'un utilisateur a skippé un contenu après exactement 10 secondes
|
|
Quand l'algorithme génère les recommandations
|
|
Alors ce contenu n'est pas reproposé (seuil < 10s strict)
|
|
|
|
Scénario: Contenu partiellement écouté (10-80%) - reproposer avec reprise
|
|
Étant donné qu'un utilisateur a écouté un contenu à 45%
|
|
Et qu'il est arrivé à la position 2:30 (150 secondes)
|
|
Quand l'algorithme propose à nouveau ce contenu
|
|
Alors le contenu peut être reproposé
|
|
Et la position de reprise est 150 secondes
|
|
Et l'utilisateur voit "Reprendre à 2:30"
|
|
|
|
Scénario: Contenu écouté à 11% - reproposition possible
|
|
Étant donné qu'un utilisateur a écouté un contenu à 11%
|
|
Quand l'algorithme génère les recommandations
|
|
Alors ce contenu peut être reproposé (>10%)
|
|
Et la position de reprise est sauvegardée
|
|
|
|
Scénario: Contenu écouté à 79% - reproposition possible
|
|
Étant donné qu'un utilisateur a écouté un contenu à 79%
|
|
Quand l'algorithme génère les recommandations
|
|
Alors ce contenu peut être reproposé (<80%)
|
|
Et l'utilisateur peut terminer l'écoute
|
|
|
|
Scénario: Audio-guide avec flag replayable=true
|
|
Étant donné qu'un audio-guide a le flag "replayable = true"
|
|
Et qu'un utilisateur l'a écouté à 95%
|
|
Quand l'algorithme génère les recommandations
|
|
Alors l'audio-guide peut être reproposé
|
|
Et il est marqué comme "Écouté - Rejouable"
|
|
|
|
Scénario: Podcast standard sans flag replayable
|
|
Étant donné qu'un podcast n'a pas de flag replayable
|
|
Et qu'un utilisateur l'a écouté à 90%
|
|
Quand l'algorithme génère les recommandations
|
|
Alors le podcast n'est jamais reproposé
|
|
|
|
Scénario: Stockage dans user_content_history
|
|
Étant donné qu'un utilisateur écoute un contenu
|
|
Quand l'écoute se termine ou est skippée
|
|
Alors les données suivantes sont enregistrées:
|
|
| champ | exemple |
|
|
| user_id | user-123 |
|
|
| content_id | content-456 |
|
|
| completion_rate | 0.45 (45%) |
|
|
| last_position | 150 (secondes) |
|
|
| listened_at | 2026-01-21 14:30:00 |
|
|
|
|
Scénario: Historique illimité stocké
|
|
Étant donné qu'un utilisateur a écouté 5000 contenus
|
|
Quand il consulte son historique
|
|
Alors tous les 5000 contenus sont disponibles
|
|
Et aucun contenu n'est supprimé automatiquement
|
|
|
|
Scénario: Algorithme considère les 100 derniers pour performance
|
|
Étant donné qu'un utilisateur a écouté 500 contenus
|
|
Quand l'algorithme génère les recommandations
|
|
Alors il vérifie uniquement les 100 derniers contenus pour exclusion
|
|
Et cette limite est une optimisation de requête SQL
|
|
|
|
Scénario: Export historique complet (RGPD)
|
|
Étant donné qu'un utilisateur demande l'export RGPD
|
|
Quand l'export est généré
|
|
Alors l'historique complet est inclus avec:
|
|
| information | inclus |
|
|
| Tous les contenus | ✅ |
|
|
| Dates d'écoute | ✅ |
|
|
| Taux complétion | ✅ |
|
|
| Positions reprise | ✅ |
|
|
|
|
Scénario: Reprise automatique d'un contenu partiellement écouté
|
|
Étant donné que j'ai écouté un podcast à 60% (position 10:00)
|
|
Quand ce podcast est reproposé par l'algorithme
|
|
Et que je lance la lecture
|
|
Alors l'écoute reprend automatiquement à 10:00
|
|
Et je vois une notification "Reprise à 10:00"
|
|
|
|
Scénario: Option "Reprendre du début" pour contenu partiellement écouté
|
|
Étant donné que j'ai écouté un podcast à 60%
|
|
Quand ce podcast est reproposé
|
|
Alors je vois deux options:
|
|
| option | action |
|
|
| Reprendre à 10:00 | Lecture à partir de 10:00 |
|
|
| Depuis le début | Lecture à partir de 0:00 |
|
|
|
|
Scénario: Contenu écouté il y a 6 mois - toujours en historique
|
|
Étant donné qu'un utilisateur a écouté un contenu il y a 6 mois à 90%
|
|
Quand l'algorithme génère les recommandations
|
|
Alors ce contenu n'est toujours pas reproposé
|
|
Et l'historique n'a pas de limite temporelle
|
|
|
|
Scénario: Nouveau contenu du même créateur après écoute complète
|
|
Étant donné qu'un utilisateur a écouté un contenu de "Créateur A" à 90%
|
|
Et que "Créateur A" publie un nouveau contenu
|
|
Quand l'algorithme génère les recommandations
|
|
Alors le nouveau contenu peut être recommandé
|
|
Et seul l'ancien contenu est exclu (pas tout le créateur)
|
|
|
|
Scénario: Statistiques personnelles d'historique
|
|
Étant donné que je consulte mon profil
|
|
Quand j'accède à la section "Historique"
|
|
Alors je vois:
|
|
| métrique | exemple |
|
|
| Nombre total d'écoutes | 1,234 |
|
|
| Heures écoutées | 456h |
|
|
| Taux complétion moyen | 72% |
|
|
| Top 5 catégories | Voyage, Sport |
|
|
|
|
Scénario: Filtrer l'historique par date
|
|
Étant donné que je consulte mon historique
|
|
Quand je filtre par "Dernière semaine"
|
|
Alors seuls les contenus écoutés dans les 7 derniers jours sont affichés
|
|
Et je peux exporter cette sélection
|