# Contrôle du scope — Anti-scope-creep **Objectif** : Éviter toute dérive de scope. Chaque modification doit être intentionnelle et traçable. **Référence active** : [V0_803_RELEASE_SCOPE.md](V0_803_RELEASE_SCOPE.md) **Version précédente** : [V0_802_RELEASE_SCOPE.md](archive/V0_802_RELEASE_SCOPE.md) --- ## 1. Règle d'or > **Avant d'ajouter quoi que ce soit : vérifier si c'est dans le scope v0.803.** > Si non → ne pas ajouter. Créer un ticket pour une version ultérieure. --- ## 2. Pendant la phase v0.803 (jusqu'au tag) ### 2.1 Autorisé - **Corrections de bugs** sur les features IN SCOPE v0.803 - **Stabilisation** : tests, refactoring sans changement de comportement - **Nettoyage** : suppression de code mort, consolidation - **Documentation** : mise à jour des docs existantes - **Sécurité** : correctifs de vulnérabilités identifiées - **Accessibilité** : corrections a11y sur composants existants ### 2.2 Interdit - **Nouvelles features** hors scope v0.803 - **Nouvelles routes** ou pages hors scope - **Nouvelles dépendances** (sauf correctif sécurité) - **Changements de comportement** sur les features HORS SCOPE - **"Améliorations"** non liées à un bug identifié ou une feature IN SCOPE v0.803 ### 2.3 Cas limite | Situation | Action | |-----------|--------| | Bug dans une feature HORS SCOPE | Corriger si blocant pour une feature IN SCOPE v0.803. Sinon : ticket pour plus tard. | | Dépendance obsolète/vulnérable | Mettre à jour. Documenter dans la PR. | | Refactoring qui change une API interne | Autorisé si 0 impact sur le contrat public et tests passent. | | "Petite amélioration UX" | **Non.** Créer un ticket pour v0.803+. | --- ## 3. Processus de validation avant commit ### 3.1 Checklist pré-commit (dans la tête) 1. **Mon changement modifie-t-il une feature IN SCOPE v0.803 ?** - Oui → Continuer. S'assurer qu'il n'y a pas de régression. - Non → **STOP.** Est-ce une correction de bug ? Si oui, la feature est-elle IN SCOPE ? 2. **Mon changement ajoute-t-il du code ?** - Nouvelle route, nouveau composant, nouveau service → Vérifier V0_803_RELEASE_SCOPE. Si hors scope → **STOP.** - Correction, refactoring, test → OK si lié à une feature IN SCOPE v0.803. 3. **Mes tests passent-ils ?** - `npm test -- --run` (frontend) - `go test ./...` (backend) - Aucune régression sur les tests existants. ### 3.2 Conventions de commit Format : `type(scope): description` - `fix(auth): correct token refresh loop` ✅ - `fix(playlists): pagination boundary check` ✅ - `test(player): add coverage for seek` ✅ - `refactor(tracks): extract upload validation` ✅ - `feat(chat): add typing indicator` ❌ (nouvelle feature) - `chore: update deps` → OK si correctif sécurité, sinon éviter **Commits réguliers** : 1 commit = 1 changement logique. Pas de méga-commits. --- ## 4. Processus PR ### 4.1 Vérification scope (obligatoire) Dans chaque PR, le relecteur doit valider : - [ ] Le changement est dans le scope v0.803 (voir [V0_803_RELEASE_SCOPE.md](V0_803_RELEASE_SCOPE.md)) - [ ] Aucune nouvelle feature ajoutée - [ ] Aucune régression sur les flows critiques - [ ] Les tests passent - [ ] La description explique le *pourquoi* (bug, stabilisation, nettoyage) ### 4.2 Rejet automatique Une PR sera rejetée si : - Elle ajoute une nouvelle route, page ou feature - Elle modifie le comportement d'une feature HORS SCOPE v0.803 (sauf correctif bug critique) - Les tests échouent - Elle introduit une dépendance non justifiée --- ## 5. Proposer une feature pour APRÈS v0.702 ### 5.1 Template Utiliser le template [Feature request](.github/ISSUE_TEMPLATE/feature_request.md) avec : - **Alignement scope** : cocher "Hors scope v0.803 — pour v0.804+" - **Justification** : pourquoi cette feature est nécessaire - **Effort estimé** : S / M / L / XL - **Dépendances** : quelles features v0.802 doivent être stables avant ### 5.2 Workflow 1. Créer une issue avec le template 2. **Ne pas implémenter** tant que v0.803 n'est pas taguée 3. Une fois v0.803 stable, prioriser les issues post-v0.803 dans le scope suivant --- ## 6. Gestion des exceptions ### 6.1 Urgence sécurité Si une vulnérabilité critique est identifiée : - Correctif autorisé **immédiatement** - Documenter dans la PR - Pas besoin d'être dans le scope v0.703 ### 6.2 Blocage production Si un bug bloque un déploiement ou un flow critique : - Correctif autorisé - La feature concernée doit être IN SCOPE v0.803 ou dépendance directe d'une feature IN SCOPE ### 6.3 Décision collégiale Pour tout cas ambigu : - Ouvrir une issue "Scope clarification" - Décision documentée dans l'issue - Mise à jour de V0_803_RELEASE_SCOPE.md si le scope est étendu (exception rare) --- ## 7. Après le tag d'une version 1. **Créer** le document de scope de la version suivante (ex: `V0_702_RELEASE_SCOPE.md`) 2. **Définir** explicitement les nouvelles features autorisées 3. **Mettre à jour** la référence active dans ce document (section header) 4. **Reprendre** ce processus avec le nouveau document de scope 5. **Archiver** l'ancien document dans `docs/archive/` une fois obsolète **Historique des versions** : - v0.101 : Stabilisation, freeze fonctionnel (taguée) - v0.102 : Déblocage Coming Soon, renforcement coeur produit (taguée) - v0.103 : Complétion Phase 1 Fondation — Auth A1/A4, Profils B1-B3 (taguée) - v0.201 : Phase 2 Contenu — Lot E Métadonnées (BPM, key, lyrics, tags) — taguée - v0.202 : Phase 2 Contenu — Lots G, H, F, C, D — taguée - v0.203 : Phase 2 Contenu — D1, K, L (queue collaborative, recherche enrichie, Social Trending) — taguée - v0.301 : Phase 3 Social — P0, C1, P1, S1 (Chat Server fix, typing, read receipts, présence, social enrichi) — taguée - v0.302 : Phase 3 Social — S2, N1, P2 (groupes avancés, push, rich presence) — taguée - v0.303 : Phase 3 Social — C2 (Chat appels WebRTC 1-to-1) — taguée - v0.401 : Phase 4 Commerce — M1, M2, M3 (Marketplace catalogue, licences, seller enrichi) — taguée - v0.402 : Phase 4 Commerce — P1, P2 (Checkout Hyperswitch production-ready, codes promo) — taguée - v0.403 : Phase 4 Commerce — P3, R1, F1, R2 (Payout, reviews, factures, remboursements) — taguée - v0.404 : Phase 4bis — Stabilisation post-audit (sécurité, infra, nettoyage) — taguée - v0.501 : Phase 5 — Streaming & Cloud (HLS production, Cloud storage MVP, Gear avancé) — taguée - v0.502 : Phase 5 — Chat Server Rewrite (Rust → Go) — taguée - v0.503 : Phase 5 — Stream Server E2E + Chat Hardening + Cleanup — taguée - v0.601 : Phase 6 — Production Readiness & Commerce — taguée - v0.602 : Phase 6+ — Payout, Dette Technique & Tests E2E — taguée - v0.603 : Phase 6+ — Transfer automatique Stripe Connect, Commission plateforme, Dette technique — taguée - v0.604 : Phase 6+ — absorbé par v0.701 - v0.701 : Phase 7 — Retry Transfers, Admin Dashboard, Deep Health — taguée - v0.702 : Phase 7 — Reviews, Factures, Remboursements & Product Detail — taguée - v0.703 : Phase 7 — Go Live & Streaming Complet — taguée - v0.801 : Phase 8 — UX/UI Polish, Accessibilité & PWA — taguée - v0.802 : Phase 8 — Cloud avancé, Gear documents/repairs, Tags suggest — taguée --- ## 8. Rappel pour les contributeurs - **Cursor / IA** : Les règles dans `.cursorrules` rappellent de vérifier le scope avant toute modification. - **Humains** : Lire [V0_803_RELEASE_SCOPE.md](V0_803_RELEASE_SCOPE.md) avant de coder. - **En doute ?** Ouvrir une issue "Scope clarification" plutôt que de coder.