# 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

### 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

---

<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

---
