# BMAD — Articulation avec Lead_tech

BMAD fournit une méthode de travail basée sur des agents spécialisés.

Le repository `Lead_tech` fournit :

- la mémoire inter-projets
- les conventions globales
- les patterns validés
- les décisions d'architecture

---

# Principe

BMAD ne remplace pas `Lead_tech`.

BMAD s'appuie dessus.

---

# Répartition des responsabilités

## Lead_tech

Contient :

- patterns validés
- décisions d'architecture
- conventions globales
- playbooks
- post-mortems

## Projet

Contient :

- le code
- les règles spécifiques
- l'architecture locale
- les conventions propres au projet

## Agents BMAD

Responsables de :

- cadrer
- implémenter
- reviewer
- améliorer le code
- **capitaliser les apprentissages vers Lead_tech**

---

# Lecture obligatoire avant de travailler

Avant d'introduire un nouveau pattern, une nouvelle convention ou une nouvelle
architecture, les agents DOIVENT lire les fichiers Lead_tech correspondants.

| Type de tâche           | Fichiers à lire en priorité                                                       |
| ----------------------- | --------------------------------------------------------------------------------- |
| Backend (API, services) | `knowledge/backend/patterns/README.md`, `knowledge/backend/risques/README.md`    |
| Frontend / mobile       | `knowledge/frontend/patterns/README.md`, `knowledge/frontend/risques/README.md`  |
| UX / design             | `knowledge/ux/patterns/README.md`, `knowledge/ux/risques/README.md`              |
| Architecture / design   | `40_decisions_et_archi.md`                                                        |
| Debug / investigation   | `90_debug_et_postmortem.md`                                                       |
| n8n / automatisations   | `knowledge/n8n/patterns/README.md`, `knowledge/n8n/risques/README.md`            |

Règle : **si un pattern Lead_tech existe et couvre le besoin, l'appliquer
directement sans réinventer**.

---

# Hiérarchie de contexte

1. contraintes techniques réelles
2. règles du projet (`CLAUDE.md` projet)
3. règles globales (`Lead_tech`)

---

# Communication bi-directionnelle — Capitalisation

Les agents BMAD ne se contentent pas de lire Lead_tech.
Ils y contribuent activement en remontant les apprentissages.

## Zone de capitalisation

Le fichier cible pour toutes les propositions est :

`$LEADTECH/95_a_capitaliser.md`

`$LEADTECH` est une variable d'environnement définie automatiquement sur Mac
et sur le NUC via `scripts/aliases.sh`. Elle pointe vers le repo Lead_tech
de la machine courante.

En pratique :
- Mac : `~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md`
- NUC : `/srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md`

## Quand capitaliser

Un apprentissage mérite d'être remonté si :

- un bug difficile a été résolu
- un anti-pattern a été identifié
- un pattern réutilisable a émergé
- une décision d'architecture structurante a été prise
- une contrainte technique inattendue a été rencontrée

## À quel moment dans le workflow BMAD

| Moment                        | Action                                                  |
| ----------------------------- | ------------------------------------------------------- |
| Fin d'une story               | Vérifier si un pattern réutilisable a émergé            |
| Résolution d'un bug difficile | Écrire une entrée dans `95_a_capitaliser.md`            |
| Choix d'architecture notable  | Proposer une entrée dans `40_decisions_et_archi.md`     |
| Fin de sprint / milestone     | Relire `95_a_capitaliser.md` et valider ou supprimer    |

## Format de la proposition

```
DATE — PROJET

FILE_UPDATE_PROPOSAL
Fichier cible : <knowledge/backend/patterns/<theme>.md | knowledge/backend/risques/<theme>.md | knowledge/frontend/patterns/<theme>.md | knowledge/frontend/risques/<theme>.md | knowledge/ux/patterns/<theme>.md | knowledge/ux/risques/<theme>.md | knowledge/n8n/patterns/general.md | knowledge/n8n/risques/general.md | knowledge/product/patterns/general.md | knowledge/product/risques/<theme>.md | knowledge/workflow/risques/story-tracking.md | 10_conventions_redaction.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md>

Pourquoi :
<raison en 1-2 phrases>

Proposition :
<contenu suggéré>
```

Exemple :

```
2026-03-08 — app-alexandrie

FILE_UPDATE_PROPOSAL
Fichier cible : knowledge/backend/patterns/nestjs.md

Pourquoi :
L'ordre d'enregistrement des guards NestJS a causé request.user undefined
dans EmailVerifiedGuard lors de l'implémentation de l'auth.

Proposition :
Toujours enregistrer AuthGuard en premier dans providers[] avant tout guard
qui lit request.user.
```

## Règle importante

Les agents peuvent **écrire librement** dans `95_a_capitaliser.md`.

Ils ne doivent **jamais écrire directement** dans les fichiers de connaissance
validée (`knowledge/*`, `10_*`, `40_*`, `90_*`).

La validation et l'intégration finale sont faites **par le développeur**.

---

# Résumé du flux complet

```
Lead_tech
  ↓ (lecture avant implémentation)
Agent BMAD
  ↓ (implémentation)
Apprentissage détecté
  ↓
$LEADTECH/95_a_capitaliser.md
  ↓ (validation humaine)
Lead_tech (fichier approprié)
```