mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 21:41:42 +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:
102
60_playbooks/capitaliser_un_apprentissage.md
Normal file
102
60_playbooks/capitaliser_un_apprentissage.md
Normal file
@@ -0,0 +1,102 @@
|
||||
# Playbook — Capitaliser un apprentissage
|
||||
|
||||
Ce playbook décrit **quand et comment transformer un apprentissage
|
||||
projet en connaissance globale dans `Lead_tech`.**
|
||||
|
||||
---
|
||||
|
||||
# Principe
|
||||
|
||||
Tous les apprentissages découverts dans un projet ne doivent pas
|
||||
être ajoutés directement dans la base de connaissance globale.
|
||||
|
||||
On utilise le workflow suivant :
|
||||
|
||||
```
|
||||
Projet
|
||||
↓
|
||||
Observation / apprentissage
|
||||
↓
|
||||
Proposition
|
||||
↓
|
||||
95_a_capitaliser.md
|
||||
↓
|
||||
Validation
|
||||
↓
|
||||
Lead_tech
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Quand capitaliser
|
||||
|
||||
Un apprentissage mérite d'être capitalisé lorsqu'il :
|
||||
|
||||
- résout un bug difficile
|
||||
- révèle un anti-pattern
|
||||
- définit un pattern réutilisable
|
||||
- documente une contrainte technique
|
||||
- formalise une décision d'architecture
|
||||
|
||||
---
|
||||
|
||||
# Où écrire selon le type de savoir
|
||||
|
||||
| Type de savoir | Destination |
|
||||
| ----------------------- | ------------------------------------- |
|
||||
| Pattern backend validé | `10_backend_patterns_valides.md` |
|
||||
| Pattern frontend validé | `10_frontend_patterns_valides.md` |
|
||||
| Anti-pattern backend | `10_backend_risques_et_vigilance.md` |
|
||||
| Anti-pattern frontend | `10_frontend_risques_et_vigilance.md` |
|
||||
| Décision d'architecture | `40_decisions_et_archi.md` |
|
||||
| Bug / postmortem | `90_debug_et_postmortem.md` |
|
||||
|
||||
---
|
||||
|
||||
# Procédure
|
||||
|
||||
1. Identifier un apprentissage dans un projet
|
||||
|
||||
2. Ajouter une proposition dans :
|
||||
|
||||
```
|
||||
95_a_capitaliser.md
|
||||
```
|
||||
|
||||
3. Utiliser le format :
|
||||
|
||||
```
|
||||
DATE — PROJET
|
||||
|
||||
FILE_UPDATE_PROPOSAL
|
||||
Fichier cible : ...
|
||||
|
||||
Pourquoi : ...
|
||||
|
||||
Proposition : ...
|
||||
```
|
||||
|
||||
4. Attendre validation
|
||||
|
||||
5. Déplacer la proposition vers le fichier cible
|
||||
|
||||
6. Supprimer l'entrée du fichier `95_a_capitaliser.md`
|
||||
|
||||
---
|
||||
|
||||
# Bonnes pratiques
|
||||
|
||||
- privilégier les exemples concrets
|
||||
- éviter les règles théoriques
|
||||
- préférer les patterns validés en production
|
||||
- garder les propositions courtes
|
||||
|
||||
---
|
||||
|
||||
# Objectif
|
||||
|
||||
Maintenir une base de connaissance :
|
||||
|
||||
- fiable
|
||||
- réutilisable
|
||||
- validée par l'expérience
|
||||
Reference in New Issue
Block a user