capitalisation: intégration 33 propositions RL799_V2 (triage 2026-04-07)

Backend: 21 entrées (general, prisma, contracts, auth, patterns)
Frontend: 9 entrées (navigation, tests, general, performance, patterns)
Workflow: 5 entrées (story-tracking)
Nouveau fichier: backend/patterns/general.md
95_a_capitaliser.md purgé.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

knowledge/backend/risques/auth.md

@@ -5,8 +5,8 @@ bucket: risques
 tags: [auth, guards, request-user, sessions, admin]
 applies_to: [implementation, review, debug]
 severity: high
-validated_on: 2026-03-24
-source_projects: [app-alexandrie]
+validated_on: 2026-04-07
+source_projects: [app-alexandrie, RL799_V2]
 ---
 
 # Backend — Risques & vigilance : Auth
@@ -234,3 +234,52 @@ it('retourne 403 si subscription inactive', async () => {
 - **Règle** : ne jamais tenter de surcharger un mock partagé dans un `it` — créer un `buildApp` isolé avec `app.close()` en fin de test
 
 - Contexte technique : NestJS / Jest e2e — app-alexandrie 24-03-2026
+
+---
+
+<a id="risque-champ-metier-absent-jwt"></a>
+## Champ métier absent du JWT — découplage silencieux frontend/backend
+
+### Risques
+
+- Le frontend lit un champ dans `decodeJwtPayload(token)` qui n'est jamais émis par le service d'authentification
+- Le comportement est silencieux — `undefined` est traité comme `''`, aucune erreur visible, l'UI se dégrade sans signal d'alerte
+
+### Symptômes
+
+- `decodeJwtPayload(token).field` retourne `undefined` pour tous les utilisateurs réels
+- Filtres de grade/rôle côté UI entièrement inopérants (rank=0, aucune tab affichée)
+
+### Bonnes pratiques / mitigations
+
+- Toute donnée lue via `decodeJwtPayload` côté frontend doit être explicitement émise dans le payload JWT côté backend
+- Lors de l'ajout d'un champ à `JwtPayload` (type TypeScript), vérifier immédiatement que le service d'authentification inclut ce champ à l'émission
+- Ajouter un test d'intégration login → decode qui vérifie la présence des champs critiques dans le token retourné
+- **Signal review** : un champ apparaît dans le type `JwtPayload` côté frontend sans modification correspondante dans `authService.ts`
+
+- Contexte technique : JWT / auth — RL799_V2 02-04-2026
+
+---
+
+<a id="risque-email-login-vs-contact-annuaire"></a>
+## Confusion email login / email de contact dans un endpoint annuaire
+
+### Risques
+
+- Le mapping de l'endpoint annuaire utilise `email: user.email` (email de login, toujours présent) alors que l'intention est d'exposer un email de contact optionnel
+- Même un utilisateur à bas privilège peut récupérer les emails de login de tous les membres
+
+### Symptômes
+
+- `email: user.email` dans le mapping d'un endpoint de type "annuaire" ou "liste membres"
+- Emails de connexion exposés à tous les utilisateurs authentifiés
+
+### Bonnes pratiques / mitigations
+
+- Dans tout endpoint annuaire ou profil public, distinguer explicitement :
+  - **email de login** : identifiant de compte, JAMAIS exposé à un tiers dans un endpoint annuaire
+  - **email de contact** : champ optionnel dans le profil ou la table directory, exposé uniquement s'il est renseigné
+- Si le modèle ne dispose pas encore d'un champ email de contact distinct, renvoyer `undefined` pour le champ email dans l'annuaire
+- **Signal review** : `email: user.email` dans le mapping d'un endpoint annuaire
+
+- Contexte technique : auth / annuaire — RL799_V2 02-04-2026