docs: update SCOPE_CONTROL.md and cursorrules to reference v0.501
FIN-03: Active scope now points to V0_501_RELEASE_SCOPE.md. Updated .cursorrules scope from v0.402 to v0.501.
This commit is contained in:
parent
f944abd336
commit
59d92366c9
2 changed files with 31 additions and 29 deletions
|
|
@ -1,10 +1,10 @@
|
|||
# Règles de Développement UI - Projet SaaS
|
||||
|
||||
## 0. Scope v0.402 (priorité absolue)
|
||||
## 0. Scope v0.501 (priorité absolue)
|
||||
|
||||
- **Référence** : `docs/V0_402_RELEASE_SCOPE.md` et `docs/SCOPE_CONTROL.md`
|
||||
- Avant toute modification : vérifier si le changement est **dans le scope v0.402**
|
||||
- **Autorisé v0.402** : lots P1, P2 (checkout Hyperswitch production-ready, codes promo)
|
||||
- **Référence** : `docs/V0_501_RELEASE_SCOPE.md` et `docs/SCOPE_CONTROL.md`
|
||||
- Avant toute modification : vérifier si le changement est **dans le scope v0.501**
|
||||
- **Autorisé v0.501** : lots S1, C1, G1 (HLS production, Cloud storage MVP, Gear avancé)
|
||||
- **Interdit** : nouvelles routes/pages hors scope, nouvelles dépendances (sauf correctif sécurité)
|
||||
- En cas de doute : ne pas ajouter. Créer une issue pour une version ultérieure.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,23 +1,23 @@
|
|||
# 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_403_RELEASE_SCOPE.md](V0_403_RELEASE_SCOPE.md)
|
||||
**Version précédente** : [V0_402_RELEASE_SCOPE.md](V0_402_RELEASE_SCOPE.md)
|
||||
**Référence active** : [V0_501_RELEASE_SCOPE.md](V0_501_RELEASE_SCOPE.md)
|
||||
**Version précédente** : [V0_404_RELEASE_SCOPE.md](archive/V0_404_RELEASE_SCOPE.md)
|
||||
|
||||
---
|
||||
|
||||
## 1. Règle d'or
|
||||
|
||||
> **Avant d'ajouter quoi que ce soit : vérifier si c'est dans le scope v0.403.**
|
||||
> **Avant d'ajouter quoi que ce soit : vérifier si c'est dans le scope v0.501.**
|
||||
> Si non → ne pas ajouter. Créer un ticket pour une version ultérieure.
|
||||
|
||||
---
|
||||
|
||||
## 2. Pendant la phase v0.403 (jusqu'au tag)
|
||||
## 2. Pendant la phase v0.501 (jusqu'au tag)
|
||||
|
||||
### 2.1 Autorisé
|
||||
|
||||
- **Corrections de bugs** sur les features IN SCOPE v0.403
|
||||
- **Corrections de bugs** sur les features IN SCOPE v0.501
|
||||
- **Stabilisation** : tests, refactoring sans changement de comportement
|
||||
- **Nettoyage** : suppression de code mort, consolidation
|
||||
- **Documentation** : mise à jour des docs existantes
|
||||
|
|
@ -26,20 +26,20 @@
|
|||
|
||||
### 2.2 Interdit
|
||||
|
||||
- **Nouvelles features** hors scope v0.403
|
||||
- **Nouvelles features** hors scope v0.501
|
||||
- **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.403
|
||||
- **"Améliorations"** non liées à un bug identifié ou une feature IN SCOPE v0.501
|
||||
|
||||
### 2.3 Cas limite
|
||||
|
||||
| Situation | Action |
|
||||
|-----------|--------|
|
||||
| Bug dans une feature HORS SCOPE | Corriger si blocant pour une feature IN SCOPE v0.403. Sinon : ticket pour plus tard. |
|
||||
| Bug dans une feature HORS SCOPE | Corriger si blocant pour une feature IN SCOPE v0.501. 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.403+. |
|
||||
| "Petite amélioration UX" | **Non.** Créer un ticket pour v0.501+. |
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -47,13 +47,13 @@
|
|||
|
||||
### 3.1 Checklist pré-commit (dans la tête)
|
||||
|
||||
1. **Mon changement modifie-t-il une feature IN SCOPE v0.403 ?**
|
||||
1. **Mon changement modifie-t-il une feature IN SCOPE v0.501 ?**
|
||||
- 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_403_RELEASE_SCOPE. Si hors scope → **STOP.**
|
||||
- Correction, refactoring, test → OK si lié à une feature IN SCOPE.
|
||||
- Nouvelle route, nouveau composant, nouveau service → Vérifier V0_501_RELEASE_SCOPE. Si hors scope → **STOP.**
|
||||
- Correction, refactoring, test → OK si lié à une feature IN SCOPE v0.501.
|
||||
|
||||
3. **Mes tests passent-ils ?**
|
||||
- `npm test -- --run` (frontend)
|
||||
|
|
@ -81,7 +81,7 @@ Format : `type(scope): description`
|
|||
|
||||
Dans chaque PR, le relecteur doit valider :
|
||||
|
||||
- [ ] Le changement est dans le scope v0.403 (voir [V0_403_RELEASE_SCOPE.md](V0_403_RELEASE_SCOPE.md))
|
||||
- [ ] Le changement est dans le scope v0.501 (voir [V0_501_RELEASE_SCOPE.md](V0_501_RELEASE_SCOPE.md))
|
||||
- [ ] Aucune nouvelle feature ajoutée
|
||||
- [ ] Aucune régression sur les flows critiques
|
||||
- [ ] Les tests passent
|
||||
|
|
@ -92,28 +92,28 @@ Dans chaque PR, le relecteur doit valider :
|
|||
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)
|
||||
- Elle modifie le comportement d'une feature HORS SCOPE v0.501 (sauf correctif bug critique)
|
||||
- Les tests échouent
|
||||
- Elle introduit une dépendance non justifiée
|
||||
|
||||
---
|
||||
|
||||
## 5. Proposer une feature pour APRÈS v0.303
|
||||
## 5. Proposer une feature pour APRÈS v0.501
|
||||
|
||||
### 5.1 Template
|
||||
|
||||
Utiliser le template [Feature request](.github/ISSUE_TEMPLATE/feature_request.md) avec :
|
||||
|
||||
- **Alignement scope** : cocher "Hors scope v0.403 — pour v0.404+"
|
||||
- **Alignement scope** : cocher "Hors scope v0.501 — pour v0.502+"
|
||||
- **Justification** : pourquoi cette feature est nécessaire
|
||||
- **Effort estimé** : S / M / L / XL
|
||||
- **Dépendances** : quelles features v0.303 doivent être stables avant
|
||||
- **Dépendances** : quelles features v0.501 doivent être stables avant
|
||||
|
||||
### 5.2 Workflow
|
||||
|
||||
1. Créer une issue avec le template
|
||||
2. **Ne pas implémenter** tant que v0.403 n'est pas taguée
|
||||
3. Une fois v0.403 stable, prioriser les issues "v0.404" dans V0_404_RELEASE_SCOPE.md
|
||||
2. **Ne pas implémenter** tant que v0.501 n'est pas taguée
|
||||
3. Une fois v0.501 stable, prioriser les issues "v0.502" dans V0_502_RELEASE_SCOPE.md
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -125,14 +125,14 @@ Si une vulnérabilité critique est identifiée :
|
|||
|
||||
- Correctif autorisé **immédiatement**
|
||||
- Documenter dans la PR
|
||||
- Pas besoin d'être dans le scope v0.403
|
||||
- Pas besoin d'être dans le scope v0.501
|
||||
|
||||
### 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.403 ou dépendance directe d'une feature IN SCOPE
|
||||
- La feature concernée doit être IN SCOPE v0.501 ou dépendance directe d'une feature IN SCOPE
|
||||
|
||||
### 6.3 Décision collégiale
|
||||
|
||||
|
|
@ -140,13 +140,13 @@ Pour tout cas ambigu :
|
|||
|
||||
- Ouvrir une issue "Scope clarification"
|
||||
- Décision documentée dans l'issue
|
||||
- Mise à jour de V0_403_RELEASE_SCOPE.md si le scope est étendu (exception rare)
|
||||
- Mise à jour de V0_501_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_403_RELEASE_SCOPE.md`)
|
||||
1. **Créer** le document de scope de la version suivante (ex: `V0_502_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
|
||||
|
|
@ -164,12 +164,14 @@ Pour tout cas ambigu :
|
|||
- 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) — en préparation
|
||||
- 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é) — 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_403_RELEASE_SCOPE.md](V0_403_RELEASE_SCOPE.md) avant de coder.
|
||||
- **Humains** : Lire [V0_501_RELEASE_SCOPE.md](V0_501_RELEASE_SCOPE.md) avant de coder.
|
||||
- **En doute ?** Ouvrir une issue "Scope clarification" plutôt que de coder.
|
||||
|
|
|
|||
Loading…
Reference in a new issue