mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 21:41:42 +02:00
18341c10a1
- Création 10_ux_patterns_valides.md et 10_ux_risques_et_vigilance.md - Référencés dans 00_INDEX.md, _AI_INSTRUCTIONS.md, CLAUDE.md - Tableau de lecture BMAD mis à jour (ligne UX ajoutée) - Format Fichier cible mis à jour partout pour inclure les fichiers UX - post-bmad-install.sh : memory bmm-ux-designer pointe vers les bons fichiers
97 lines
2.2 KiB
Markdown
97 lines
2.2 KiB
Markdown
# Capitalisation en attente — Lead_tech
|
||
|
||
Ce fichier sert de **zone tampon de capitalisation**.
|
||
|
||
Les agents et les projets peuvent y déposer des propositions
|
||
d’amélioration de la base de connaissance globale (`Lead_tech`).
|
||
|
||
Le contenu de ce fichier **n'est pas encore validé**.
|
||
|
||
Une fois relues et confirmées, les propositions doivent être déplacées
|
||
vers les fichiers appropriés :
|
||
|
||
- `10_backend_patterns_valides.md`
|
||
- `10_frontend_patterns_valides.md`
|
||
- `10_backend_risques_et_vigilance.md`
|
||
- `10_frontend_risques_et_vigilance.md`
|
||
- `40_decisions_et_archi.md`
|
||
- `90_debug_et_postmortem.md`
|
||
|
||
Ce fichier ne doit donc **jamais devenir une documentation permanente**.
|
||
|
||
---
|
||
|
||
# Format attendu
|
||
|
||
Chaque proposition doit suivre ce format :
|
||
|
||
```
|
||
DATE — PROJET
|
||
|
||
FILE_UPDATE_PROPOSAL
|
||
Fichier cible : <10_backend_patterns_valides.md | 10_frontend_patterns_valides.md | 10_ux_patterns_valides.md | 10_backend_risques_et_vigilance.md | 10_frontend_risques_et_vigilance.md | 10_ux_risques_et_vigilance.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md>
|
||
|
||
Pourquoi :
|
||
<raison pour laquelle ce savoir mérite d'être capitalisé>
|
||
|
||
Proposition :
|
||
<contenu suggéré à intégrer dans le fichier cible>
|
||
```
|
||
|
||
---
|
||
|
||
# Exemple
|
||
|
||
```
|
||
2026-03-08 — portfolio
|
||
|
||
FILE_UPDATE_PROPOSAL
|
||
Fichier cible : 10_backend_patterns_valides.md
|
||
|
||
Pourquoi :
|
||
Ordre d'enregistrement des Guards NestJS causant un bug
|
||
`request.user undefined` observé à plusieurs reprises.
|
||
|
||
Proposition :
|
||
|
||
## Ordre des Guards NestJS
|
||
|
||
Toujours enregistrer `AuthGuard` avant les Guards dépendants
|
||
(`EmailVerifiedGuard`, `RoleGuard`, etc.).
|
||
|
||
Sinon `request.user` peut être undefined dans les guards suivants.
|
||
```
|
||
|
||
---
|
||
|
||
# Règles
|
||
|
||
1. Les agents peuvent **proposer librement** ici.
|
||
2. Les propositions doivent rester **courtes et factuelles**.
|
||
3. La validation et l'intégration finale dans `Lead_tech`
|
||
sont faites **manuellement**.
|
||
4. Une fois intégrée, la proposition doit être **supprimée
|
||
de ce fichier**.
|
||
|
||
---
|
||
|
||
# Rôle dans l'architecture
|
||
|
||
```
|
||
Projet
|
||
↓
|
||
Proposition
|
||
↓
|
||
95_a_capitaliser.md
|
||
↓
|
||
Validation humaine
|
||
↓
|
||
Lead_tech
|
||
```
|
||
|
||
Ce mécanisme permet :
|
||
|
||
- d'éviter la pollution de la base de connaissance
|
||
- de capitaliser progressivement l'expérience des projets
|
||
- de garder `Lead_tech` cohérent et fiable.
|