# language: fr
Fonctionnalité: API - Pas de dégradation temporelle
  En tant qu'API backend
  Je veux que les jauges n'évoluent que par les actions utilisateur
  Afin d'avoir un comportement prévisible sans automatisme caché

  Contexte:
    Étant donné que l'API RoadWave est disponible
    Et que la base de données PostgreSQL est accessible

  Scénario: API ne dégrade jamais les jauges automatiquement
    Étant donné qu'un utilisateur "user123" a une jauge "Économie" à 80% en base
    Et que la colonne updated_at = "2026-01-01T10:00:00Z"
    Quand 30 jours s'écoulent sans activité
    Et je GET /api/v1/users/user123/interest-gauges le "2026-02-01T10:00:00Z"
    Alors le statut de réponse est 200
    Et la jauge "Économie" est toujours à 80%
    Et aucune dégradation temporelle n'a été appliquée
    Et la colonne updated_at n'a pas changé

  Scénario: Aucun cron job de dégradation n'existe
    Étant donné que le système vérifie les tâches cron planifiées
    Quand je liste tous les cron jobs du backend
    Alors aucun job nommé "degrade_interest_gauges" n'existe
    Et aucun job périodique ne modifie la table interest_gauges
    Et aucune ressource CPU n'est consommée pour la dégradation

  Scénario: API GET jauges après 6 mois d'inactivité
    Étant donné qu'un utilisateur "user123" a les jauges suivantes:
      | catégorie    | niveau | updated_at          |
      | Automobile   | 75%    | 2025-08-01T10:00:00 |
      | Voyage       | 60%    | 2025-08-01T10:00:00 |
      | Musique      | 45%    | 2025-08-01T10:00:00 |
    Et qu'il ne se connecte pas pendant 6 mois
    Quand je GET /api/v1/users/user123/interest-gauges le "2026-02-01T10:00:00Z"
    Alors le statut de réponse est 200
    Et les jauges sont exactement les mêmes:
      | catégorie    | niveau |
      | Automobile   | 75%    |
      | Voyage       | 60%    |
      | Musique      | 45%    |
    Et aucune modification n'a été appliquée

  Scénario: Évolution par actions utilisateur uniquement
    Étant donné qu'un utilisateur "user123" a une jauge "Économie" à 80%
    Et qu'il skip 50 contenus "Économie" en 1 an
    Quand je calcule l'évolution via les events
    Alors la jauge "Économie" descend via les skips:
      | action          | impact | nouveau_niveau |
      | 50 skips × -0.5%| -25%   | 55%            |
    Et la dégradation vient des actions, pas du temps
    Et la colonne updated_at reflète la date du dernier skip

  Scénario: API POST réinitialiser centres d'intérêt
    Étant donné qu'un utilisateur "user123" a des jauges personnalisées:
      | catégorie    | niveau |
      | Automobile   | 75%    |
      | Voyage       | 60%    |
      | Économie     | 34%    |
      | Sport        | 88%    |
    Quand je POST /api/v1/users/user123/interest-gauges/reset
      """json
      {
        "confirmation": true
      }
      """
    Alors le statut de réponse est 200
    Et la réponse contient:
      """json
      {
        "message": "Vos centres d'intérêt ont été réinitialisés",
        "previous_gauges_saved": true,
        "new_gauges": {
          "all_categories": 50
        }
      }
      """
    Et en base de données, toutes les jauges de "user123" sont à 50%:
      | catégorie          | niveau |
      | Automobile         | 50     |
      | Voyage             | 50     |
      | Économie           | 50     |
      | Sport              | 50     |
      | Musique            | 50     |
      | Technologie        | 50     |
      | Santé              | 50     |
      | Politique          | 50     |
      | Cryptomonnaie      | 50     |
      | Culture générale   | 50     |
      | Famille            | 50     |
      | Amour              | 50     |

  Scénario: API sauvegarde jauges précédentes avant réinitialisation
    Étant donné qu'un utilisateur "user123" a des jauges personnalisées
    Quand je POST /api/v1/users/user123/interest-gauges/reset
      """json
      {
        "confirmation": true
      }
      """
    Alors le statut de réponse est 200
    Et une ligne est insérée dans interest_gauges_snapshots:
      | user_id | snapshot_type | snapshot_date       | gauges_json                  |
      | user123 | manual_reset  | 2026-02-02T14:00:00 | {"Automobile": 75, "Voyage": 60, ...} |
    Et l'historique permet de restaurer si besoin

  Scénario: API rejette réinitialisation sans confirmation
    Quand je POST /api/v1/users/user123/interest-gauges/reset
      """json
      {
        "confirmation": false
      }
      """
    Alors le statut de réponse est 400
    Et la réponse contient:
      """json
      {
        "error": "CONFIRMATION_REQUIRED",
        "message": "Vous devez confirmer la réinitialisation"
      }
      """
    Et les jauges ne sont pas modifiées

  Scénario: API recommandations après réinitialisation
    Étant donné qu'un utilisateur "user123" avait "Économie" à 85%
    Et qu'il réinitialise ses jauges (toutes à 50%)
    Quand je POST /api/v1/recommendations
      """json
      {
        "user_id": "user123",
        "latitude": 48.8566,
        "longitude": 2.3522,
        "limit": 10
      }
      """
    Alors le statut de réponse est 200
    Et les recommandations utilisent 50% pour toutes les catégories
    Et plus aucun biais "Économie" n'est appliqué
    Et la géolocalisation redevient le critère principal

  Scénario: Historique d'écoute conservé après réinitialisation
    Étant donné qu'un utilisateur "user123" a écouté 500 contenus
    Et que la table listening_history contient 500 lignes pour "user123"
    Quand je POST /api/v1/users/user123/interest-gauges/reset
    Alors le statut de réponse est 200
    Et la table listening_history conserve toujours les 500 lignes
    Et aucune donnée d'historique n'est supprimée
    Et l'utilisateur peut toujours consulter ses anciens contenus écoutés

  Scénario: API GET historique après réinitialisation
    Étant donné qu'un utilisateur "user123" a réinitialisé ses jauges
    Quand je GET /api/v1/users/user123/listening-history
    Alors le statut de réponse est 200
    Et la réponse contient tous les anciens contenus écoutés
    Et l'historique est intact

  Scénario: API enregistre timestamp réinitialisation
    Étant donné qu'un utilisateur "user123" réinitialise ses jauges
    Quand je POST /api/v1/users/user123/interest-gauges/reset
    Alors en base de données, la table users est mise à jour:
      | user_id | interest_gauges_reset_at | reset_count |
      | user123 | 2026-02-02T14:00:00Z    | 1           |
    Et un compteur permet de tracker les réinitialisations multiples

  Scénario: API permet réinitialisations multiples
    Étant donné qu'un utilisateur "user123" a déjà réinitialisé une fois
    Quand je POST /api/v1/users/user123/interest-gauges/reset une 2ème fois
    Alors le statut de réponse est 200
    Et le reset_count passe à 2
    Et toutes les jauges reviennent à 50%

  Scénario: API n'envoie jamais de suggestion de réinitialisation
    Étant donné qu'un utilisateur "user123" n'a pas utilisé l'app depuis 1 an
    Quand je GET /api/v1/users/user123/notifications
    Alors le statut de réponse est 200
    Et aucune notification "Réinitialiser vos centres d'intérêt" n'est présente
    Et le système ne suggère jamais de réinitialisation automatique

  Scénario: API GET statistiques respect historique utilisateur
    Étant donné qu'un utilisateur "user123" aime "Cryptomonnaie" depuis 2 ans
    Et que sa jauge est à 90%
    Et qu'il n'a pas écouté de contenu "Cryptomonnaie" depuis 6 mois
    Quand je GET /api/v1/users/user123/interest-gauges
    Alors le statut de réponse est 200
    Et la jauge "Cryptomonnaie" est toujours à 90%
    Et la réponse contient:
      """json
      {
        "gauges": [
          {
            "category": "Cryptomonnaie",
            "level": 90,
            "last_updated": "2025-08-02T10:00:00Z",
            "days_since_update": 183,
            "preserved": true
          }
        ]
      }
      """
    Et le système respecte l'historique des goûts

  Scénario: API métrique temps écoulé sans modifier la jauge
    Étant donné qu'un utilisateur "user123" a une jauge "Sport" à 65%
    Et que la dernière modification date de 90 jours
    Quand je GET /api/v1/users/user123/interest-gauges/sport
    Alors le statut de réponse est 200
    Et la réponse contient:
      """json
      {
        "category": "Sport",
        "level": 65,
        "last_updated": "2025-11-03T12:00:00Z",
        "days_since_update": 90
      }
      """
    Et la métrique days_since_update est informative uniquement
    Et elle ne modifie jamais la jauge

  Scénario: Requête SQL n'utilise jamais de calcul temporel
    Étant donné que je trace les requêtes SQL du backend
    Quand je GET /api/v1/users/user123/interest-gauges
    Alors la requête SQL exécutée est:
      """sql
      SELECT category, level, updated_at
      FROM interest_gauges
      WHERE user_id = $1
      """
    Et aucune clause WHERE avec date/timestamp n'est présente
    Et aucune fonction NOW(), CURRENT_TIMESTAMP, ou DATEDIFF n'est utilisée
    Et le calcul est minimal (simple SELECT)

  Scénario: API coût CPU minimal - pas de calcul de dates
    Étant donné que 10000 utilisateurs consultent leurs jauges simultanément
    Quand les requêtes /api/v1/users/{id}/interest-gauges sont exécutées
    Alors aucun calcul de date n'est nécessaire
    Et aucun appel à time.Now() ou time.Since() n'est fait
    Et le coût CPU par requête est < 1ms
    Et aucune dégradation de performance liée aux dates

  Scénario: API pas de risque de bug fuseau horaire
    Étant donné qu'aucune logique temporelle n'existe
    Quand un utilisateur change de fuseau horaire (Paris → Tokyo)
    Alors ses jauges ne sont pas affectées
    Et aucun bug de conversion UTC/local ne peut survenir
    Et le comportement reste déterministe

  Scénario: Audit log réinitialisation manuelle
    Étant donné qu'un utilisateur "user123" réinitialise ses jauges
    Quand je POST /api/v1/users/user123/interest-gauges/reset
    Alors une ligne est insérée dans audit_log:
      | user_id | action                  | timestamp           | details                    |
      | user123 | interest_gauges_reset  | 2026-02-02T14:00:00 | {"previous_snapshot_id": 42} |
    Et l'audit permet de tracer toutes les réinitialisations

  Scénario: API empêche réinitialisation trop fréquente
    Étant donné qu'un utilisateur "user123" a réinitialisé il y a 10 minutes
    Quand je POST /api/v1/users/user123/interest-gauges/reset
    Alors le statut de réponse est 429
    Et la réponse contient:
      """json
      {
        "error": "RATE_LIMIT_EXCEEDED",
        "message": "Vous ne pouvez réinitialiser qu'une fois par heure",
        "retry_after_seconds": 3000
      }
      """

  Scénario: API documentation endpoints réinitialisation
    Quand je GET /api/v1/openapi.json
    Alors le endpoint POST /api/v1/users/{id}/interest-gauges/reset est documenté:
      """yaml
      /users/{id}/interest-gauges/reset:
        post:
          summary: Réinitialise toutes les jauges à 50%
          description: |
            Remet toutes les jauges d'intérêt à leur valeur par défaut (50%).
            Cette action est manuelle et requiert une confirmation.
            Les jauges précédentes sont sauvegardées.
          requestBody:
            required: true
            content:
              application/json:
                schema:
                  type: object
                  properties:
                    confirmation:
                      type: boolean
                      description: Doit être true
          responses:
            200:
              description: Réinitialisation réussie
            400:
              description: Confirmation manquante
            429:
              description: Trop de réinitialisations
      """
