docs(frontend): capitalise navigation et primitives UI

knowledge/frontend/risques/general.md

@@ -84,3 +84,48 @@ function processLinks(content: string) {
 3. Wrapper le `TextInput` dans `KeyboardAvoidingView` avec `behavior={Platform.OS === 'ios' ? 'padding' : 'height'}`.
 
 - Contexte technique : React Native / Expo cross-platform — app-alexandrie 31-03-2026
+
+---
+
+<a id="risque-primitive-ui-couplee-contexte-parent"></a>
+## Primitive UI couplée au contexte parent (layout ou namespace métier)
+
+### Risques
+
+- Une primitive générique (`PageShell`, `ContentCard`, `SectionWrapper`) qui embarque des classes de surface, de largeur ou de namespace métier devient non réutilisable hors de son premier contexte
+- Le couplage reste silencieux au lint et au typecheck, puis force l'ajout progressif de props `variant`, `layout`, `width` ou de classes externes contradictoires
+
+### Symptômes
+
+- La primitive applique directement des classes comme `.card`, `.card--dashboard`, `.dashboard__item`, `.profile__card`
+- Le parent doit contourner le style natif de la primitive pour l'utiliser dans un autre écran
+- Les classes `namespace__element` fuitent dans des composants supposés agnostiques du domaine
+
+### Bonnes pratiques / mitigations
+
+- Une primitive pose le squelette sémantique ; le parent pose la surface visuelle (card, width, background, espacement de contexte)
+- Ne pas injecter de classes de namespace métier sur une primitive générique via `class`
+- Si une variation réutilisable existe vraiment, l'exprimer via une API explicite et bornée (`tone`, `variant`) plutôt que par des classes métier ad hoc
+- Contexte technique : Vue 3 / CSS modulaire — RL799_V2, 02-04-2026
+
+---
+
+<a id="risque-migration-partielle-composant-classes-legacy"></a>
+## Migration partielle vers un composant standard — classes legacy conservées
+
+### Risques
+
+- La coexistence de classes legacy (`.primary`, `.ghost`, `.danger`) et de classes du nouveau composant (`.app-btn--primary`, `.app-btn--ghost`) crée une ambiguïté durable de convention
+- Les nouveaux développements continuent d'utiliser l'ancien système faute de règle claire, ce qui ralentit la standardisation
+
+### Symptômes
+
+- Deux façons de produire la même affordance coexistent dans le même repo
+- Un composant dédié existe, mais des liens ou boutons continuent d'utiliser les anciennes classes globales
+
+### Bonnes pratiques / mitigations
+
+- Lorsqu'un composant standardise une affordance, supprimer en même temps les classes CSS globales équivalentes
+- Si un reliquat legacy doit rester temporairement, documenter explicitement son périmètre et sa date de sortie attendue
+- En review, traiter toute nouvelle utilisation d'une classe legacy équivalente comme une régression de standardisation
+- Contexte technique : Vue 3 / design system léger — RL799_V2, 02-04-2026