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>

features/api/recommendation/historique-reproposition.feature

@@ -0,0 +1,140 @@
+# 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