2026-09-16 21:30:02 +02:00
1 changed files with 1 additions and 1 deletions
@@ -66,7 +66,7 @@ Titre : `FEATURE N.M — <Nom>` (ou `FEATURE — <Nom>` si le repo ne numérote

 1. **Clôture** : une issue FEATURE ne se ferme que si **toutes** ses STORY et tous ses critères d'acceptation sont cochés. FEATURE abandonnée ou déléguée → `Reviewed/Won't Fix` ou `Status/Abandoned` + commentaire expliquant pourquoi. Une issue fermée en violation est **rouverte avec un commentaire** — ne coche jamais une case à la place du dev sans preuve.
 2. **Pas de travail sans issue** : l'issue existe avant le code, et le commit/la PR la référence. Du travail "déjà fait, non tracé" est un signal à remonter.
-3. **Milestones = FEATURE de l'EPIC uniquement** : bugs, dette technique, infra, CI, renommages → hors milestone d'EPIC (ils faussent la progression), avec `type/*` + `area/*`.
+3. **Milestones = FEATURE de l'EPIC uniquement** : dans un **dépôt produit** (GAM00X, PRJ00X), les bugs, la dette technique, l'infra, la CI et les renommages vont hors milestone d'EPIC (ils faussent la progression métier), avec `type/*` + `area/*`. Dans un **dépôt outil** (`RF_*` : design system, thème, outillage interne), l'outil *est* le produit : il a ses propres EPIC décrivant son périmètre, et la règle ne s'y oppose pas — ce sont ses propres bugs et sa propre dette qui restent hors milestone.
 4. **Promotion** : quand une EPIC en cadrage lointain se rapproche du développement, promeus **toute l'EPIC** — découpe chacune de ses FEATURE en STORY + critères, retire `cadrage/lointain`. Jamais une FEATURE isolée pendant que ses sœurs restent en cadrage (si ça arrive, signale l'incohérence et demande quoi faire).
 5. **Numérotation** : nouvelle FEATURE = numéro suivant dans son EPIC ; nouvelle EPIC = numéro suivant du repo. Jamais de renumérotation.