Capitalise nouveaux patterns backend/frontend/BMAD et externalise les templates du post-install BMAD

80_bmad/process_llm_et_parallelisation.md

@@ -0,0 +1,98 @@
+# BMAD — Process LLM et parallélisation
+
+Ce fichier capitalise les règles opératoires spécifiques au développement BMAD
+assisté par LLM quand plusieurs stories, branches ou sessions peuvent avancer
+en parallèle.
+
+Dernière mise à jour : 10-03-2026
+
+---
+
+## Index
+
+- [Métadonnées de parallélisation dans le template story](#process-parallel-safe-template-story)
+- [Synchronisation obligatoire `.md` ↔ `sprint-status`](#process-sync-story-md-sprint-status)
+- [Multi-sessions LLM sur une même story sans handoff](#process-multi-sessions-sans-handoff)
+
+---
+
+## Règle d'or
+
+Le fichier de story reste la source de vérité partagée entre sessions.
+Si l'état réel du code, du `.md` et du sprint diverge, la story n'est pas sous contrôle.
+
+---
+
+<a id="process-parallel-safe-template-story"></a>
+## Convention : métadonnées de parallélisation dans le template story
+
+- Objectif : rendre explicite si une story peut être développée en parallèle d'une autre.
+- Quand l'utiliser : sur tout template de story BMAD utilisé par plusieurs agents ou sessions.
+- Avantage :
+  - réduit les collisions entre branches
+  - évite les faux parallélismes
+  - rend les dépendances visibles avant implémentation
+- Limites / vigilance :
+  - `Parallel-safe: true` ne remplace pas une vérification humaine du périmètre réel
+
+### Champs recommandés
+
+```txt
+Status: ready-for-dev
+Parallel-safe: false
+Depends-on: ~
+Can-run-with: ~
+```
+
+### Règles
+
+- `Parallel-safe: true` seulement si la story peut avancer sur une branche séparée sans dépendre d'un code non mergé
+- `Depends-on` documente une dépendance de code réelle
+- `Can-run-with` documente les stories compatibles en exécution parallèle
+
+---
+
+<a id="process-sync-story-md-sprint-status"></a>
+## Convention : synchronisation obligatoire `.md` ↔ `sprint-status`
+
+- Objectif : éviter qu'une story soit considérée terminée alors que ses artefacts d'état divergent.
+- Quand l'utiliser : sur toute clôture de story.
+- Risque si ignoré :
+  - story marquée `done` dans le sprint mais encore `ready-for-dev` dans son fichier
+  - reprise erronée par une autre session
+
+### Règles
+
+- une story n'est `done` que si son fichier `.md` est à `Status: done`
+- `sprint-status.yaml` ne passe à `done` qu'en dernier
+- toute divergence `.md` ↔ `sprint-status` doit être traitée comme une anomalie détectable par script
+
+### Ordre obligatoire
+
+1. mettre à jour le fichier de story `.md`
+2. mettre à jour `sprint-status.yaml` en dernier
+
+---
+
+<a id="process-multi-sessions-sans-handoff"></a>
+## Anti-pattern : multi-sessions LLM sur une même story sans handoff
+
+### Risques
+
+- code déjà modifié alors que la story semble encore `ready-for-dev`
+- duplication de travail ou écrasement de modifications
+- diagnostic faussé par un état documentaire obsolète
+
+### Symptômes
+
+- la story indique un état de départ, mais le repo contient déjà l'implémentation partielle
+- plusieurs sessions avancent sur la même story sans trace de reprise
+- les diffs ne correspondent plus au statut affiché
+
+### Bonnes pratiques / mitigations
+
+- une session LLM ne travaille que sur une story active à la fois
+- toute reprise commence par la lecture complète du fichier `.md`
+- avant d'agir, vérifier la cohérence entre état du code, état du `.md` et état du sprint
+
+---