Précise la règle 3 : un dépôt-outil RF_* a droit à ses propres EPIC (#10)
Précision d'**une ligne** de `agile-master/SKILL.md` (règle 3), demandée par Baudouin. **Pourquoi.** La version publiée (PR #8, `1b71240`) dit qu'un milestone d'EPIC ne doit pas porter d'infra/CI, sans distinguer les types de dépôt. Un agent lisant cette règle signalerait à tort l'EPIC 1 qu'on vient de poser sur `RF_REVUE_CODE` comme une infraction. La ligne précise désormais : la règle vise l'infra d'un **dépôt produit** (GAM00X/PRJ00X) ; dans un **dépôt outil** `RF_*`, l'outil *est* le produit et a droit à ses propres EPIC. **Portée.** Une seule ligne (l. 69). `git diff` = 1 insertion / 1 suppression, rien d'autre. Le fichier résultant (10240 o) est identique à la skill `agile-master` installée sur la machine. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_014bjV2wNKfnvgavNeG7DHbJ Reviewed-on: #10 Reviewed-by: bbaudouin <b.baudouin@pm.me> Co-authored-by: george-claude <agent@raggaroth-factory.fr>
This commit was merged in pull request #10.
This commit is contained in:
@@ -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.
|
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.
|
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).
|
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.
|
5. **Numérotation** : nouvelle FEATURE = numéro suivant dans son EPIC ; nouvelle EPIC = numéro suivant du repo. Jamais de renumérotation.
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user