# language: fr
Fonctionnalité: Gestion des contenus supprimés pendant offline
  En tant qu'utilisateur offline
  Je veux être informé des contenus supprimés à la reconnexion
  Afin de comprendre pourquoi certains contenus ont disparu

  Contexte:
    Étant donné qu'un utilisateur a téléchargé 50 contenus offline
    Et que l'utilisateur part offline pendant 7 jours

  # Processus de synchronisation

  Scénario: Reconnexion WiFi - Validation des contenus locaux
    Étant donné que l'utilisateur se reconnecte au WiFi
    Quand l'application détecte la connexion internet
    Alors une requête API est envoyée: GET /offline/validate
    Et l'API retourne:
      """json
      {
        "valid_ids": [1, 2, 3, 5, 7, 8, ...],
        "deleted_ids": [4, 6, 10],
        "metadata_updates": [
          {"id": 9, "new_title": "Nouveau titre", "creator": "CreateurA"}
        ]
      }
      """

  Scénario: Traitement réponse validation - Suppression fichiers locaux
    Étant donné que l'API retourne deleted_ids = [4, 6, 10]
    Quand l'application traite la réponse
    Alors les fichiers locaux des contenus 4, 6, 10 sont supprimés immédiatement
    Et les métadonnées locales SQLite sont mises à jour
    Et un compteur de suppressions est incrémenté

  Scénario: Renouvellement validité contenus valides
    Étant donné que l'API retourne valid_ids = [1, 2, 3, 5, 7, 8, ...]
    Quand l'application traite la réponse
    Alors la validité de ces contenus est renouvelée pour 30 jours
    Et la date d'expiration est mise à jour: today + 30 jours

  Scénario: Mise à jour métadonnées modifiées
    Étant donné que l'API retourne metadata_updates avec un nouveau titre
    Quand l'application traite la réponse
    Alors la base SQLite locale est mise à jour:
      | content_id | nouveau_titre    | nouveau_creator |
      | 9          | Nouveau titre    | CreateurA       |
    Et les fichiers audio restent inchangés

  # Gestion contenu en cours d'écoute

  Scénario: Contenu supprimé en cours de lecture - Arrêt immédiat
    Étant donné que l'utilisateur écoute le contenu 4 (à 1:30 sur 3:00)
    Et que l'API retourne deleted_ids = [4]
    Quand la synchronisation détecte que contenu 4 est supprimé
    Alors la lecture s'arrête immédiatement
    Et une modal s'affiche:
      """
      Contenu supprimé

      Ce contenu n'est plus disponible
      et a été retiré par le créateur.

      Passage au contenu suivant...

      [OK]
      """
    Et le fichier audio est supprimé localement
    Et après 2 secondes, le contenu suivant démarre

  Scénario: Contenu supprimé PAS en cours - Suppression silencieuse
    Étant donné que l'utilisateur écoute le contenu 1
    Et que l'API retourne deleted_ids = [4, 6, 10]
    Quand la synchronisation traite les suppressions
    Alors les fichiers 4, 6, 10 sont supprimés silencieusement
    Et aucune interruption de lecture ne se produit
    Et un toast récapitulatif est affiché à la fin de la lecture actuelle

  # Message récapitulatif

  Scénario: Plusieurs contenus supprimés - Popup récapitulative
    Étant donné que 3 contenus ont été supprimés (4, 6, 10)
    Quand la synchronisation est terminée
    Alors une popup s'affiche:
      """
      Contenus supprimés

      3 contenus téléchargés ne sont plus
      disponibles et ont été retirés.

      Les créateurs peuvent supprimer ou
      modifier leurs contenus à tout moment.

      [Voir la liste] [OK]
      """

  Scénario: Bouton "Voir la liste" - Affichage détails
    Étant donné que la popup récapitulative est affichée
    Quand l'utilisateur clique sur [Voir la liste]
    Alors une nouvelle vue s'affiche avec:
      | Contenu               | Créateur    | Raison           |
      | Podcast Auto Episode 4| CreateurA   | Retiré créateur  |
      | Musique Classique     | CreateurB   | Modération       |
      | Audio-guide Paris     | CreateurC   | Retiré créateur  |
    Et l'historique est conservé 7 jours puis purgé

  Scénario: Bouton "OK" - Fermeture popup
    Étant donné que la popup récapitulative est affichée
    Quand l'utilisateur clique sur [OK]
    Alors la popup se ferme
    Et l'utilisateur continue normalement
    Et l'historique des suppressions reste accessible pendant 7 jours

  # Toast notification

  Scénario: Toast simple si 1 seul contenu supprimé
    Étant donné qu'un seul contenu a été supprimé (4)
    Quand la synchronisation est terminée
    Alors un toast s'affiche pendant 5 secondes:
      """
      1 contenu supprimé a été retiré
      """
    Et aucune popup n'est affichée (toast suffit)

  Scénario: Popup si 2+ contenus supprimés
    Étant donné que 2 ou plus contenus ont été supprimés
    Quand la synchronisation est terminée
    Alors une popup complète est affichée (pas juste un toast)
    Car l'utilisateur doit être informé clairement

  # Motifs de suppression

  Scénario: Contenu supprimé par créateur volontairement
    Étant donné que le créateur a supprimé le contenu 4 volontairement
    Quand l'API retourne deleted_ids = [4] avec motif "creator_deleted"
    Alors le contenu est retiré immédiatement (pas de grace period MVP)
    Et la raison affichée est: "Retiré par le créateur"

  Scénario: Contenu supprimé par modération (violation CGU)
    Étant donné que le contenu 6 a été modéré pour violation CGU
    Quand l'API retourne deleted_ids = [6] avec motif "moderation"
    Alors le contenu est retiré immédiatement
    Et la raison affichée est: "Retiré pour modération"

  Scénario: Contenu passé en Premium (créateur change statut)
    Étant donné que le contenu 10 est passé en "Premium exclusif"
    Et que l'utilisateur est gratuit
    Quand l'API retourne deleted_ids = [10] avec motif "premium_only"
    Alors le contenu est retiré immédiatement
    Et la raison affichée est: "Réservé aux abonnés Premium"

  # Justification KISS

  Scénario: Comparaison avec grace period - Simplicité MVP
    Étant donné qu'on compare la suppression immédiate vs grace period
    Quand on évalue les avantages KISS
    Alors les avantages suppression immédiate sont:
      | avantage                     | description                                        |
      | Simplicité technique         | Pas de gestion états intermédiaires complexes      |
      | Respect créateur             | Volonté immédiate respectée                        |
      | Conformité légale            | Contenu illégal retiré immédiatement               |
      | Cas rare                     | Peu de créateurs suppriment contenus après publi   |

  # Post-MVP : Grace period (si feedback négatifs)

  Scénario: Post-MVP - Grace period 7 jours pour suppression créateur volontaire
    Étant donné qu'on implémente la grace period post-MVP
    Et que le contenu 4 est supprimé volontairement par le créateur
    Quand l'API retourne deleted_ids = [4] avec motif "creator_deleted"
    Alors le contenu est marqué "Bientôt retiré" avec badge
    Et l'utilisateur peut encore l'écouter pendant 7 jours
    Et après 7 jours, le contenu est supprimé

  Scénario: Post-MVP - Pas de grace period pour modération
    Étant donné qu'on implémente la grace period post-MVP
    Et que le contenu 6 est modéré (illégal, violation CGU)
    Quand l'API retourne deleted_ids = [6] avec motif "moderation"
    Alors le contenu est supprimé immédiatement (pas de grace period)
    Car sécurité/légalité prime

  Scénario: Post-MVP - Grace period si user Premium et contenu devient Premium
    Étant donné qu'on implémente la grace period post-MVP
    Et que le contenu 10 passe en "Premium exclusif"
    Et que l'utilisateur a un abonnement Premium
    Quand l'API retourne deleted_ids = [10] avec motif "premium_only"
    Alors l'utilisateur Premium conserve l'accès (pas supprimé)
    Mais l'utilisateur gratuit perd l'accès après 7 jours

  # Cas limites

  Scénario: Tous les contenus offline supprimés - Message spécifique
    Étant donné que l'utilisateur avait 5 contenus offline
    Et que les 5 contenus ont été supprimés pendant offline
    Quand la synchronisation retourne deleted_ids = [1, 2, 3, 4, 5]
    Alors une popup spécifique s'affiche:
      """
      Tous vos contenus offline ont été supprimés

      Les 5 contenus téléchargés ne sont plus disponibles.

      Téléchargez de nouveaux contenus pour écouter offline.

      [Parcourir contenus] [OK]
      """

  Scénario: Contenu supprimé puis utilisateur re-télécharge
    Étant donné que le contenu 4 a été supprimé pendant offline
    Et que l'utilisateur a vu la notification
    Quand l'utilisateur se reconnecte et browse les contenus
    Alors le contenu 4 n'apparaît plus dans la liste
    Et l'utilisateur ne peut pas le re-télécharger (supprimé définitivement)

  Scénario: Historique suppressions conservé 7 jours
    Étant donné que 3 contenus ont été supprimés le 1er février
    Quand l'utilisateur consulte l'historique des suppressions le 7 février
    Alors l'historique est toujours visible
    Quand l'utilisateur consulte l'historique le 9 février (7+ jours)
    Alors l'historique a été purgé automatiquement

  # Statistiques côté API

  Scénario: API - Comptabilisation contenus supprimés pendant offline
    Étant donné que 1000 utilisateurs étaient offline pendant 7 jours
    Et que 150 contenus ont été supprimés pendant cette période
    Quand l'API génère les métriques de synchronisation
    Alors les statistiques affichent:
      | métrique                          | valeur |
      | Utilisateurs reconnectés          | 1000   |
      | Contenus supprimés détectés       | 4500   |
      | Moyenne contenus supprimés/user   | 4.5    |
      | Users affectés (≥1 suppression)   | 850    |

  # Performance

  Scénario: Requête GET /offline/validate - Performance optimisée
    Étant donné qu'un utilisateur a 50 contenus offline
    Quand l'API reçoit GET /offline/validate avec la liste des 50 IDs
    Alors la requête SQL vérifie l'existence des contenus en batch:
      """sql
      SELECT id FROM contents WHERE id IN (1,2,3,...,50) AND deleted_at IS NULL
      """
    Et la réponse est générée en <200ms
    Et Redis cache les résultats pour éviter requêtes répétées
