senke/veza
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
veza/docs/SCOPE_CONTROL.md

6.1 KiB
Raw Blame History

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_302_RELEASE_SCOPE.md
Version précédente : V0_301_RELEASE_SCOPE.md

1. Règle d'or

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

2. Pendant la phase v0.302 (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.302
  • 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.302

2.3 Cas limite

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

    • 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.302.
    • 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.302 (voir V0_302_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.203

5.1 Template

Utiliser le template Feature request avec :

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

5.2 Workflow

  1. Créer une issue avec le template
  2. Ne pas implémenter tant que v0.302 n'est pas taguée
  3. Une fois v0.302 stable, prioriser les issues "v0.303" dans V0_303_RELEASE_SCOPE.md

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.202

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_302_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_302_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, C2, P2 (groupes avancés, push, appels, rich presence) — en préparation

8. Rappel pour les contributeurs

  • Cursor / IA : Les règles dans .cursorrules rappellent de vérifier le scope avant toute modification.
  • Humains : Lire V0_302_RELEASE_SCOPE.md avant de coder.
  • En doute ? Ouvrir une issue "Scope clarification" plutôt que de coder.