feat: ajout couverture UX/UI dans Lead_tech

- 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

00_INDEX.md

@@ -30,6 +30,7 @@ Patterns éprouvés en production ou en projets réels.
 
 - `10_backend_patterns_valides.md`
 - `10_frontend_patterns_valides.md`
+- `10_ux_patterns_valides.md`
 
 ---
 
@@ -43,6 +44,7 @@ Situations connues pouvant entraîner :
 
 - `10_backend_risques_et_vigilance.md`
 - `10_frontend_risques_et_vigilance.md`
+- `10_ux_risques_et_vigilance.md`
 
 ---
 

10_ux_patterns_valides.md

@@ -0,0 +1,70 @@
+# Patterns UX/UI validés
+
+Ce fichier contient **uniquement** des patterns UX/UI :
+
+- observés en conditions réelles,
+- validés sur des projets livrés,
+- utiles à réutiliser sur d'autres produits.
+
+Objectif : éviter de redélibérer sur des sujets déjà tranchés et capitaliser
+ce qui fonctionne du point de vue utilisateur.
+
+Dernière mise à jour : 2026-03-08
+
+---
+
+## Règle d'or
+
+Si ce n'est pas **validé par l'usage ou l'expérience projet**, ça n'a pas sa place ici.
+
+- Pas de "bonnes pratiques" génériques
+- Pas de conseils théoriques sans contexte
+- Toujours préciser le contexte (type d'app, audience, plateforme)
+
+---
+
+## Périmètre couvert
+
+- Patterns d'interaction (navigation, feedback, états)
+- Formulaires et flows critiques (auth, onboarding, checkout)
+- Gestion des états vides, d'erreur et de chargement
+- Accessibilité au niveau design
+- Conventions de design system
+- Décisions UX structurantes validées
+
+---
+
+## Format standard d'un pattern
+
+## Pattern : <Nom clair>
+
+- Objectif : …
+- Contexte : …
+- Quand l'utiliser : …
+- Quand l'éviter : …
+- Avantage : …
+- Limites / vigilance : …
+- Validé le : DD-MM-YYYY
+- Contexte produit : (obligatoire) ex. `App mobile / auth` ou `Webapp B2B / dashboard`
+
+### Description
+
+(comportement attendu, logique d'interaction, règles visuelles clés)
+
+### Checklist (si pertinente)
+
+---
+
+## Index
+
+_(à remplir au fil des validations)_
+
+---
+
+## Notes importantes
+
+- On préfère 5 patterns solides à 50 "guidelines de design".
+- Un pattern UX = une décision d'interaction assumée + son cadre d'application.
+- La frontière avec `10_frontend_patterns_valides.md` :
+  ce fichier traite **l'intention UX et le comportement attendu**,
+  le fichier frontend traite **l'implémentation technique**.

10_ux_risques_et_vigilance.md

@@ -0,0 +1,47 @@
+# Risques et anti-patterns UX/UI
+
+Ce fichier recense les **erreurs UX récurrentes**, les pièges connus
+et les anti-patterns observés en conditions réelles.
+
+Objectif : ne pas répéter les mêmes erreurs de conception d'un projet à l'autre.
+
+Dernière mise à jour : 2026-03-08
+
+---
+
+## Règle d'or
+
+Chaque entrée doit être **issue d'un problème réel**, pas d'une opinion.
+
+- Toujours préciser l'impact observé (abandon, confusion, support, bug signalé)
+- Toujours proposer l'alternative correcte
+
+---
+
+## Périmètre couvert
+
+- Anti-patterns d'interaction
+- Pièges sur les flows critiques (auth, onboarding, formulaires)
+- Erreurs fréquentes sur les états (vide, erreur, chargement)
+- Accessibilité — erreurs courantes
+- Décisions UX qui semblent bonnes mais posent problème
+
+---
+
+## Format standard
+
+## Anti-pattern : <Nom clair>
+
+- Problème : …
+- Impact observé : …
+- Contexte : …
+- À éviter parce que : …
+- Alternative correcte : …
+- Observé le : DD-MM-YYYY
+- Contexte produit : ex. `App mobile / onboarding` ou `Webapp / formulaire`
+
+---
+
+## Index
+
+_(à remplir au fil des observations)_

70_templates/projet_CLAUDE.md

@@ -309,7 +309,7 @@ En pratique :
 DATE — PROJET
 
 FILE_UPDATE_PROPOSAL
-Fichier cible : <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>
+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 en 1-2 phrases>

80_bmad/articulation_avec_lead_tech.md

@@ -58,9 +58,10 @@ 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) | `10_backend_patterns_valides.md`, `10_backend_risques_et_vigilance.md`           |
 | Frontend / mobile       | `10_frontend_patterns_valides.md`, `10_frontend_risques_et_vigilance.md`         |
+| UX / design             | `10_ux_patterns_valides.md`, `10_ux_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`                        |
@@ -124,7 +125,7 @@ Un apprentissage mérite d'être remonté si :
 DATE — PROJET
 
 FILE_UPDATE_PROPOSAL
-Fichier cible : <nom_du_fichier>
+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 en 1-2 phrases>

95_a_capitaliser.md

@@ -29,7 +29,7 @@ Chaque proposition doit suivre ce format :
 DATE — PROJET
 
 FILE_UPDATE_PROPOSAL
-Fichier cible : <nom_du_fichier>
+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é>

_AI_INSTRUCTIONS.md

@@ -15,8 +15,10 @@ une solution dans leur domaine respectif.
 | ------------------------------------- | ---------------------------------------------- |
 | `10_backend_patterns_valides.md`      | Patterns backend validés en conditions réelles |
 | `10_frontend_patterns_valides.md`     | Patterns frontend/mobile validés               |
+| `10_ux_patterns_valides.md`           | Patterns UX/UI validés                         |
 | `10_backend_risques_et_vigilance.md`  | Risques et anti-patterns backend               |
 | `10_frontend_risques_et_vigilance.md` | Risques et anti-patterns frontend              |
+| `10_ux_risques_et_vigilance.md`       | Risques et anti-patterns UX/UI                 |
 | `40_decisions_et_archi.md`            | Décisions techniques (mini-ADR)                |
 | `90_debug_et_postmortem.md`           | Post-mortems et bugs capitalisés               |
 
@@ -63,8 +65,10 @@ Après validation, le contenu est déplacé vers le fichier approprié :
 
 - `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`
 

scripts/post-bmad-install.sh

@@ -103,7 +103,10 @@ build_memory() {
     bmm-pm)
       echo "When a product decision, prioritization pattern, or recurring friction is identified, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — ${PROJECT_NAME} / FILE_UPDATE_PROPOSAL / Fichier cible: <target file> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
       ;;
-    bmm-tech-writer|bmm-ux-designer)
+    bmm-ux-designer)
+      echo "When a reusable UX/UI pattern, interaction anti-pattern, or UX decision emerges, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — ${PROJECT_NAME} / FILE_UPDATE_PROPOSAL / Fichier cible: <10_ux_patterns_valides.md | 10_ux_risques_et_vigilance.md | 40_decisions_et_archi.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
+      ;;
+    bmm-tech-writer)
       echo "${base}, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/projects/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — ${PROJECT_NAME} / FILE_UPDATE_PROPOSAL / Fichier cible: <target file> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
       ;;
   esac
@@ -141,7 +144,7 @@ Format :
 DATE — ${PROJECT_NAME}
 
 FILE_UPDATE_PROPOSAL
-Fichier cible : <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>
+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 en 1-2 phrases>