docs(knowledge): capitalisation backend — intégration du triage local (mai-juin 2026)

Triage et intégration des propositions backend du buffer 95_a_capitaliser.md
(lot local RL799_V2 + app-alexandrie, mai-juin 2026), distinct de la capitalisation
remote antérieure (triage 2026-05-02).

~73 entrées intégrées sur knowledge/backend/, dont :
- patterns/auth.md : série "membrane d'auth fédérée BFF/OIDC" (9 patterns) + jose algo whitelist
- patterns/prisma.md : recette fusionnée "Migration String/Int → enum" (backfill + Cas A/B/C),
  row réactivable, endpoint replace atomique, updateMany conditionnel, etc.
- risques/general.md : 19 risques (epoch s vs ms, keepAliveTimeout=0, upsert+filtre liste,
  fail-safe catch-all, retrait asymétrique front/back, anti-énumération rate-limit, etc.)
- patterns/general, async, nestjs, contracts, tests + risques/auth, contracts, prisma, redis, stripe, tests
- compléments d'entrées existantes (authorize-after-fetch, P3014, cursor opaque, DI swc, Stripe v20...)
- README patterns/risques mis à jour

Doublons internes corrigés en relecture (suppression-champ .map() → general seul ;
e2e DB-based → tests.md seul). Doublons hors backend / entrées projet / rejets non intégrés.
Source 95_a_capitaliser.md non purgée à ce stade (purge en fin de capitalisation complète).

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

knowledge/backend/risques/contracts.md

@@ -259,3 +259,55 @@ const emailSchema = z
 **À auditer projet-wide** : grep tous les schémas avec ce pattern (`.email().toLowerCase().trim()`) et migrer en `.pipe()`.
 
 - Contexte technique : Zod 4 — RL799_V2 01-05-2026
+
+---
+
+<a id="risque-ac-affichage-champ-contract-zod"></a>
+## AC d'affichage livré « vert » mais champ absent du contract Zod
+
+### Risques
+
+- Un AC métier dit « afficher / truncate / preview de [champ] dans [carte/écran] » mais le champ n'est jamais ajouté au schéma Zod public correspondant → le user ne le voit jamais
+- Le service backend peut même charger le champ depuis la DB (`select: { bio: true }`) puis le jeter au mapping de réponse → invisible
+- Ni le typage ni les tests unit ne détectent l'absence : la code review est le seul filet
+
+### Symptômes
+
+- AC d'affichage livré « tout vert » (tests/typecheck/lint passent) mais l'écran ne montre rien
+- Variante : champ rendu côté UI mais jamais transmis par l'API → `undefined`/`null` silencieux à l'écran
+
+### Bonnes pratiques / mitigations
+
+Quand un AC mentionne « afficher / truncate / preview de [champ] dans [carte/écran] », vérifier la chaîne complète :
+
+1. **Le champ existe dans le schéma Zod public** (ex : AC « carte annuaire affiche bio truncate 80 char » → `DirectoryUserSchema` doit avoir `bio: z.string().nullable()`).
+2. **Le service backend l'expose dans le mapping de réponse** (pas seulement dans le `select` Prisma).
+3. **Le composant UI lit le champ.**
+
+Le contrat est la barrière minimale : si le champ n'y est pas, l'AC ne peut pas être satisfait.
+
+- Contexte technique : NestJS / Zod / contracts-first — app-alexandrie 28-05-2026
+
+---
+
+<a id="risque-schema-par-audience-pas-par-entite"></a>
+## Schéma par audience, pas par entité : vue admin réutilise le schéma public
+
+### Risques
+
+- Une vue ADMIN/back-office réutilise (ou `extend`) le schéma de la vue PUBLIQUE/utilisateur de la même entité → elle hérite d'un schéma qui masque délibérément les champs de gestion
+- L'admin ne peut pas distinguer les états (ex : leçons DRAFT vs PUBLISHED) car le contrat ampute l'info structurante (`status`, `body`, timestamps, flags internes)
+- Le service inclut correctement les données (pas de filtre status) mais le CONTRAT les supprime — bug invisible au typecheck et au test
+
+### Symptômes
+
+- Un détail admin `extend`/réutilise un schéma existant qui est en réalité la variante de rendu front
+- Un test qui ne peut asserter que la **présence** d'un élément, jamais son **état** (le champ d'état n'existe pas dans le schéma)
+- AC « prévisualiser avant publication » / « back-office » non satisfait alors que tout est vert
+
+### Bonnes pratiques / mitigations
+
+- Une vue admin/back-office et une vue publique de la MÊME entité ne partagent PAS le schéma de réponse par défaut : l'admin a besoin des champs de gestion (status, body brut, timestamps, flags) que la vue publique masque.
+- **Réflexe de revue** : quand un détail admin réutilise un schéma, vérifier que c'est bien la variante ADMIN (porte le statut/les champs éditoriaux), pas la variante de rendu front.
+
+- Contexte technique : NestJS / Zod / contracts-first — app-alexandrie 04-06-2026