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_201_RELEASE_SCOPE.md](V0_201_RELEASE_SCOPE.md)  
**Version précédente** : [V0_103_RELEASE_SCOPE.md](V0_103_RELEASE_SCOPE.md)

---

## 1. Règle d'or

> **Avant d'ajouter quoi que ce soit : vérifier si c'est dans le scope v0.201.**  
> Si non → ne pas ajouter. Créer un ticket pour une version ultérieure.

---

## 2. Pendant la phase v0.201 (jusqu'au tag)

### 2.1 Autorisé

- **Corrections de bugs** sur les features IN SCOPE
- **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.201
- **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

### 2.3 Cas limite

| Situation | Action |
|-----------|--------|
| Bug dans une feature HORS SCOPE | Corriger si blocant pour une feature IN SCOPE. 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.102+. |

---

## 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 ?**
   - 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 → **STOP.** Hors scope v0.101.
   - Correction, refactoring, test → OK si lié à une feature IN SCOPE.

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.201 (voir [V0_201_RELEASE_SCOPE.md](V0_201_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 (sauf correctif bug critique)
- Les tests échouent
- Elle introduit une dépendance non justifiée

---

## 5. Proposer une feature pour APRÈS v0.101

### 5.1 Template

Utiliser le template [Feature request](.github/ISSUE_TEMPLATE/feature_request.md) avec :

- **Alignement scope** : cocher "Hors scope v0.201 — pour v0.202+"
- **Justification** : pourquoi cette feature est nécessaire
- **Effort estimé** : S / M / L / XL
- **Dépendances** : quelles features v0.101 doivent être stables avant

### 5.2 Workflow

1. Créer une issue avec le template
2. **Ne pas implémenter** tant que v0.201 n'est pas taguée
3. Une fois v0.201 stable, prioriser les issues "v0.202" dans un nouveau document de scope

---

## 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.201

### 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 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_201_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_202_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 — Recherche, Métadonnées, Analytics (en cours)

---

## 8. Rappel pour les contributeurs

- **Cursor / IA** : Les règles dans `.cursorrules` rappellent de vérifier le scope avant toute modification.
- **Humains** : Lire [V0_201_RELEASE_SCOPE.md](V0_201_RELEASE_SCOPE.md) avant de coder.
- **En doute ?** Ouvrir une issue "Scope clarification" plutôt que de coder.