mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 13:31:43 +02:00
feat: communication bi-directionnelle BMAD ↔ Lead_tech
- Ajout de $LEADTECH dans aliases.sh (variable d'env résolu Mac/NUC) - Refonte de 80_bmad/articulation_avec_lead_tech.md : lecture obligatoire par type de tâche, déclencheurs de capitalisation, chemin $LEADTECH explicite - Mise à jour du template projet_CLAUDE.md : section capitalisation actionnable - Ajout des fichiers 95_a_capitaliser.md et playbook capitaliser_un_apprentissage.md Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
MaksTinyWorkshop
@@ -1,4 +1,4 @@
|
||||
# BMAD — articulation avec Lead_tech
|
||||
# BMAD — Articulation avec Lead_tech
|
||||
|
||||
BMAD fournit une méthode de travail basée sur des agents spécialisés.
|
||||
|
||||
@@ -48,37 +48,129 @@ Responsables de :
|
||||
- implémenter
|
||||
- reviewer
|
||||
- améliorer le code
|
||||
- **capitaliser les apprentissages vers Lead_tech**
|
||||
|
||||
---
|
||||
|
||||
# Règle importante
|
||||
# Lecture obligatoire avant de travailler
|
||||
|
||||
Avant d'introduire :
|
||||
Avant d'introduire un nouveau pattern, une nouvelle convention ou une nouvelle
|
||||
architecture, les agents DOIVENT lire les fichiers Lead_tech correspondants.
|
||||
|
||||
- un nouveau pattern
|
||||
- une nouvelle convention
|
||||
- une nouvelle architecture
|
||||
| Type de tâche | Fichiers à lire en priorité |
|
||||
| ---------------------- | --------------------------------------------------------------------------------- |
|
||||
| Backend (API, services) | `10_backend_patterns_valides.md`, `10_backend_risques_et_vigilance.md` |
|
||||
| Frontend / mobile | `10_frontend_patterns_valides.md`, `10_frontend_risques_et_vigilance.md` |
|
||||
| Architecture / design | `40_decisions_et_archi.md` |
|
||||
| Debug / investigation | `90_debug_et_postmortem.md` |
|
||||
| n8n / automatisations | `10_n8n_patterns_valides.md`, `10_n8n_nodes_a_risques.md` |
|
||||
|
||||
les agents doivent vérifier la base `Lead_tech`.
|
||||
|
||||
---
|
||||
|
||||
# Capitalisation
|
||||
|
||||
Si un pattern devient réutilisable :
|
||||
|
||||
Proposer une mise à jour :
|
||||
|
||||
```
|
||||
FILE_UPDATE_PROPOSAL
|
||||
Fichier : …
|
||||
Pourquoi : …
|
||||
```
|
||||
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
|
||||
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/projects/_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 : <nom_du_fichier>
|
||||
|
||||
Pourquoi :
|
||||
<raison en 1-2 phrases>
|
||||
|
||||
Proposition :
|
||||
<contenu suggéré>
|
||||
```
|
||||
|
||||
Exemple :
|
||||
|
||||
```
|
||||
2026-03-08 — app-alexandrie
|
||||
|
||||
FILE_UPDATE_PROPOSAL
|
||||
Fichier cible : 10_backend_patterns_valides.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 (`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é)
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user