Files
roadwave/docs/domains/content/features/radio-live/interdictions-moderation-live.feature
jpgiannetti 5e5fcf4714 refactor(docs): réorganiser la documentation selon principes DDD
Réorganise la documentation du projet selon les principes du Domain-Driven Design (DDD) pour améliorer la cohésion, la maintenabilité et l'alignement avec l'architecture modulaire du backend.

**Structure cible:**
```
docs/domains/
├── README.md (Context Map)
├── _shared/ (Core Domain)
├── recommendation/ (Supporting Subdomain)
├── content/ (Supporting Subdomain)
├── moderation/ (Supporting Subdomain)
├── advertising/ (Generic Subdomain)
├── premium/ (Generic Subdomain)
└── monetization/ (Generic Subdomain)
```

**Changements effectués:**

Phase 1: Création de l'arborescence des 7 bounded contexts
Phase 2: Déplacement des règles métier (01-19) vers domains/*/rules/
Phase 3: Déplacement des diagrammes d'entités vers domains/*/entities/
Phase 4: Déplacement des diagrammes flux/états/séquences vers domains/*/
Phase 5: Création des README.md pour chaque domaine
Phase 6: Déplacement des features Gherkin vers domains/*/features/
Phase 7: Création du Context Map (domains/README.md)
Phase 8: Mise à jour de mkdocs.yml pour la nouvelle navigation
Phase 9: Correction automatique des liens internes (script fix-markdown-links.sh)
Phase 10: Nettoyage de l'ancienne structure (regles-metier/, diagrammes/, features/)

**Configuration des tests:**
- Makefile: godog run docs/domains/*/features/
- scripts/generate-bdd-docs.py: features_dir → docs/domains

**Avantages:**
 Cohésion forte: toute la doc d'un domaine au même endroit
 Couplage faible: domaines indépendants, dépendances explicites
 Navigabilité améliorée: README par domaine = entrée claire
 Alignement code/docs: miroir de backend/internal/
 Onboarding facilité: exploration domaine par domaine
 Tests BDD intégrés: features au plus près des règles métier

Voir docs/REFACTOR-DDD.md pour le plan complet.
2026-02-07 17:15:02 +01:00

53 lines
2.3 KiB
Gherkin

# language: fr
@api @radio-live @moderation @mvp
Fonctionnalité: Interdictions et modération des lives
En tant que plateforme
Je veux modérer les lives en temps réel
Afin de prévenir les contenus inappropriés
Scénario: Détection automatique de mots interdits
Étant donné un live en cours avec transcription automatique
Quand un mot interdit est détecté
Alors une alerte est envoyée aux modérateurs
Et le segment est marqué pour review
Et un événement "LIVE_FORBIDDEN_WORD_DETECTED" est enregistré
Scénario: Coupure immédiate du live par modérateur
Étant donné un modérateur qui détecte du contenu inapproprié
Quand il clique sur "Couper le live"
Alors le live est stoppé immédiatement
Et les auditeurs voient "Live interrompu par modération"
Et le créateur reçoit une notification avec raison
Et un événement "LIVE_CUT_BY_MODERATOR" est enregistré
Scénario: Suspension temporaire du droit de faire des lives
Étant donné un créateur "alice@roadwave.fr" qui enfreint les règles
Quand un modérateur applique une sanction
Alors le créateur ne peut plus lancer de live pendant X jours
Et ses replays restent accessibles (si conformes)
Et un événement "LIVE_SUSPENSION_APPLIED" est enregistré
Scénario: Signalement en temps réel par les auditeurs
Étant donné un auditeur qui détecte du contenu problématique
Quand il clique sur "Signaler"
Alors le signalement est envoyé immédiatement aux modérateurs
Et inclut le timestamp exact du problème
Et un événement "LIVE_REPORTED_BY_USER" est enregistré
Scénario: Délai obligatoire de 7 secondes (broadcast delay)
Étant donné un live en cours
Alors un délai de 7 secondes est appliqué
Et permet de couper le flux si nécessaire
Et les auditeurs ne perçoivent pas le délai
Et un événement "LIVE_BROADCAST_DELAY_ACTIVE" est enregistré
Scénario: Historique des infractions du créateur
Étant donné un modérateur qui évalue un créateur
Alors il voit l'historique:
| Date | Infraction | Sanction |
| 2026-01-15 | Langage inapproprié | Avertissement |
| 2025-12-10 | Spam | Suspension 3j |
Et un événement "CREATOR_INFRACTION_HISTORY_VIEWED" est enregistré