feat(bdd): réorganiser features en catégories api/ui/e2e et créer ADR-024
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>
This commit is contained in:
142
features/ui/interest-gauges/degradation-temporelle.feature
Normal file
142
features/ui/interest-gauges/degradation-temporelle.feature
Normal file
@@ -0,0 +1,142 @@
|
||||
# language: fr
|
||||
Fonctionnalité: Pas de dégradation temporelle des jauges
|
||||
En tant que système de recommandation
|
||||
Je veux que les jauges n'évoluent que par les actions utilisateur
|
||||
Afin d'avoir un comportement prévisible et fiable
|
||||
|
||||
Contexte:
|
||||
Étant donné que l'API RoadWave est disponible
|
||||
Et qu'un utilisateur est connecté
|
||||
|
||||
Scénario: Aucune dégradation automatique avec le temps
|
||||
Étant donné que ma jauge "Économie" est à 80%
|
||||
Et que je n'écoute aucun contenu pendant 30 jours
|
||||
Quand je me reconnecte après 30 jours
|
||||
Alors ma jauge "Économie" est toujours à 80%
|
||||
Et aucune dégradation temporelle n'a été appliquée
|
||||
|
||||
Scénario: Jauges conservées après 6 mois d'inactivité
|
||||
Étant donné que mes jauges sont:
|
||||
| catégorie | niveau |
|
||||
| Automobile | 75% |
|
||||
| Voyage | 60% |
|
||||
| Musique | 45% |
|
||||
Et que je pars en vacances pendant 6 mois sans utiliser l'app
|
||||
Quand je me reconnecte après 6 mois
|
||||
Alors mes jauges sont exactement les mêmes:
|
||||
| catégorie | niveau |
|
||||
| Automobile | 75% |
|
||||
| Voyage | 60% |
|
||||
| Musique | 45% |
|
||||
|
||||
Scénario: Évolution naturelle par les actions
|
||||
Étant donné que j'aimais "Économie" il y a 1 an (jauge 80%)
|
||||
Et que depuis, je skip tous les contenus "Économie"
|
||||
Et que j'ai skippé 50 contenus "Économie" en 1 an
|
||||
Alors ma jauge "Économie" descend naturellement via les skips
|
||||
Et atteint environ 55% (80% - 50 × 0.5% = 55%)
|
||||
Et la dégradation vient des actions, pas du temps
|
||||
|
||||
Scénario: Pas de cron job de dégradation
|
||||
Étant donné que le système vérifie les jauges quotidiennement
|
||||
Quand un utilisateur n'a pas d'activité depuis 90 jours
|
||||
Alors aucun job de dégradation n'est exécuté
|
||||
Et les jauges restent inchangées
|
||||
Et aucune ressource CPU n'est consommée pour la dégradation
|
||||
|
||||
Scénario: Comportement prévisible après absence
|
||||
Étant donné que ma jauge "Sport" était à 70%
|
||||
Et que je n'utilise pas l'app pendant 1 an
|
||||
Quand je reviens et demande des recommandations
|
||||
Alors mes recommandations reflètent toujours mes goûts d'avant
|
||||
Et je reçois du contenu "Sport" prioritaire
|
||||
Et le comportement est cohérent et prévisible
|
||||
|
||||
Scénario: Réinitialiser manuellement mes centres d'intérêt
|
||||
Étant donné que je veux repartir de zéro
|
||||
Quand je vais dans les paramètres
|
||||
Et que je clique sur "Réinitialiser mes centres d'intérêt"
|
||||
Et que je confirme l'action
|
||||
Alors toutes mes jauges reviennent à 50%
|
||||
Et je vois le message "Vos centres d'intérêt ont été réinitialisés"
|
||||
|
||||
Scénario: Confirmation avant réinitialisation
|
||||
Étant donné que je suis dans les paramètres
|
||||
Quand je clique sur "Réinitialiser mes centres d'intérêt"
|
||||
Alors je vois un message de confirmation:
|
||||
| titre | Êtes-vous sûr ? |
|
||||
| message | Cette action remettra toutes vos jauges à 50% |
|
||||
| actions | Confirmer / Annuler |
|
||||
|
||||
Scénario: Annuler la réinitialisation
|
||||
Étant donné que j'ai cliqué sur "Réinitialiser mes centres d'intérêt"
|
||||
Et que la confirmation est affichée
|
||||
Quand je clique sur "Annuler"
|
||||
Alors mes jauges ne sont pas modifiées
|
||||
Et je reviens aux paramètres
|
||||
|
||||
Scénario: Raison de réinitialisation - changement de vie
|
||||
Étant donné que j'utilisais RoadWave pour mes trajets professionnels
|
||||
Et que mes jauges reflétaient "Économie" (85%) et "Technologie" (75%)
|
||||
Et que je change de vie et deviens musicien
|
||||
Quand je réinitialise mes centres d'intérêt
|
||||
Alors je peux repartir avec toutes les jauges à 50%
|
||||
Et découvrir du contenu "Musique" et "Culture" sans biais
|
||||
|
||||
Scénario: Pas de suggestion automatique de réinitialisation
|
||||
Étant donné que je n'ai pas utilisé l'app depuis 1 an
|
||||
Quand je me reconnecte
|
||||
Alors aucune suggestion de réinitialisation n'est affichée
|
||||
Et mes jauges sont conservées telles quelles
|
||||
Et je garde le contrôle total
|
||||
|
||||
Scénario: Historique conservé après réinitialisation
|
||||
Étant donné que j'ai écouté 500 contenus
|
||||
Quand je réinitialise mes centres d'intérêt
|
||||
Alors mes jauges reviennent à 50%
|
||||
Mais mon historique d'écoute est conservé
|
||||
Et je peux toujours consulter mes anciens contenus écoutés
|
||||
|
||||
Scénario: Évolution future basée sur nouvelles actions
|
||||
Étant donné que j'ai réinitialisé mes jauges à 50%
|
||||
Quand j'écoute 5 contenus "Voyage" à >80%
|
||||
Alors ma jauge "Voyage" monte à 60% (50% + 5 × 2%)
|
||||
Et l'algorithme recommence à apprendre mes nouvelles préférences
|
||||
|
||||
Scénario: Respect de l'historique utilisateur
|
||||
Étant donné qu'un utilisateur aime "Cryptomonnaie" depuis 2 ans
|
||||
Et que sa jauge est à 90%
|
||||
Quand 2 ans s'écoulent sans dégradation temporelle
|
||||
Alors sa jauge reste à 90%
|
||||
Car l'historique de ses goûts est respecté
|
||||
Et le système ne fait pas d'"oubli" artificiel
|
||||
|
||||
Scénario: Coût infrastructure zéro
|
||||
Étant donné qu'aucune dégradation temporelle n'existe
|
||||
Quand le système calcule les jauges
|
||||
Alors aucun calcul de date n'est nécessaire
|
||||
Et aucun batch nocturne ne tourne
|
||||
Et aucun bug de fuseau horaire ne peut survenir
|
||||
Et le coût CPU est minimal
|
||||
|
||||
Scénario: UX prévisible - jauge = actions
|
||||
Étant donné qu'un utilisateur consulte sa jauge "Sport" à 65%
|
||||
Quand il se demande pourquoi elle est à 65%
|
||||
Alors il peut retracer ses actions:
|
||||
| action | impact |
|
||||
| 10 likes automatiques | +10% |
|
||||
| 3 abonnements Sport | +15% |
|
||||
| 5 skips de contenu non-Sport| 0% |
|
||||
Et il comprend que c'est le reflet exact de ses actions
|
||||
Et il n'y a pas de mystère ou automatisme caché
|
||||
|
||||
Scénario: Statistiques affichées sans date
|
||||
Étant donné que je consulte mes centres d'intérêt
|
||||
Quand je vois mes jauges
|
||||
Alors je vois:
|
||||
| information | affiché |
|
||||
| Niveau actuel | ✅ 75% |
|
||||
| Évolution depuis début | ✅ +25% |
|
||||
| Dernière mise à jour | ❌ |
|
||||
Et aucune date n'est affichée car non pertinente
|
||||
Et seules les actions comptent
|
||||
Reference in New Issue
Block a user