_Assistant_Lead_Tech/80_bmad/process_llm_et_parallelisation.md

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
• Synchronisation obligatoire .md ↔ sprint-status
• Multi-sessions LLM sur une même story 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.

---

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

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

Règle de branche

• Si plusieurs stories sont techniquement liées, elles restent sur la même branche tant que leur séparation n'est pas réellement sûre
• Des branches séparées ne sont justifiées que si chaque story peut être testée, reviewée et mergée indépendamment
• En cas de doute, préférer une seule branche avec plusieurs commits propres plutôt que deux branches artificiellement parallèles

---

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

---

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

---