veza/docs/SCOPE_CONTROL.md

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
Version précédente : 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)
• 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 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 avant de coder.
• En doute ? Ouvrir une issue "Scope clarification" plutôt que de coder.