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/patterns/README.md

@@ -16,3 +16,4 @@ Avant toute proposition backend, identifie le fichier dont le nom et la descript
 | `multi-tenant.md` | Multi-tenant, isolation, feature flags | 403 vs 404, repository tenant-aware, tenantId dans updates, helper tenant partagé, feature flag tenant, EN enforcement |
 | `nextjs.md` | Next.js App Router, Server Actions, isolation | Runtime-only logique pure, server-only isolation, utilitaires purs sans server-only, réutiliser champ V1, validation URL externe |
 | `async.md` | Jobs async, webhooks sortants, queues | Exécution asynchrone outbox light, webhooks sortants HMAC + retries idempotents |
+| `general.md` | Architecture générale, helpers, RBAC | Helper auth centralisé enrichissable |

knowledge/backend/patterns/contracts.md

@@ -5,8 +5,8 @@ bucket: patterns
 tags: [contracts, zod, api, error-codes, monorepo]
 applies_to: [analysis, implementation, review, architecture]
 severity: high
-validated_on: 2026-03-20
-source_projects: [app-alexandrie]
+validated_on: 2026-04-07
+source_projects: [app-alexandrie, RL799_V2]
 ---
 
 # Backend — Patterns : Contracts
@@ -147,3 +147,23 @@ return res.status(200).json({
 
 - **4xx** = erreur technique ou de sécurité (401 non authentifié, 403 accès interdit, 404 introuvable)
 - **200 + flag métier** = état métier normal que le client doit interpréter pour le rendu
+
+---
+
+<a id="pattern-coherence-result-repository"></a>
+## Pattern : Cohérence du pattern Result dans un repository
+
+- Objectif : garantir une sémantique uniforme du retour d'erreur dans un même fichier repository.
+- Contexte : repository utilisant le pattern `{ ok: true; data } | { ok: false }` pour certaines fonctions.
+- Quand l'utiliser : dès qu'un repository a au moins une fonction utilisant le pattern Result.
+- Risque si ignoré : retourner `null` sur erreur dans une fonction alors que les voisines retournent `{ ok: false }` crée une ambiguïté sémantique (null = pas trouvé vs null = erreur) et empêche le service d'adapter sa réponse HTTP (404 vs 500).
+- Validé le : 03-04-2026
+- Contexte technique : TypeScript / Prisma — RL799_V2 story 6A.5
+
+### Règle
+
+Quand un repository utilise le pattern `{ ok: true; data } | { ok: false }` pour certaines fonctions, **toutes** les fonctions du même fichier doivent utiliser le même pattern.
+
+### Signal review
+
+- `catch { return null }` dans un repository qui utilise `{ ok: false }` ailleurs

knowledge/backend/patterns/general.md

@@ -0,0 +1,35 @@
+---
+title: Backend — Patterns : Général
+domain: backend
+bucket: patterns
+tags: [auth, helpers, architecture, rbac]
+applies_to: [implementation, review, architecture]
+severity: medium
+validated_on: 2026-04-07
+source_projects: [RL799_V2]
+---
+
+# Backend — Patterns : Général
+
+> Extrait de la base de connaissance Lead_tech. Voir `knowledge/backend/patterns/README.md` pour l'index complet.
+
+---
+
+<a id="pattern-helper-auth-centralise-enrichissable"></a>
+## Pattern : Helper d'authentification centralisé enrichissable
+
+- Objectif : éviter la duplication de logique RBAC dans chaque service en centralisant un seul `requireRoleAccess` dans `lib/authHelpers.ts`.
+- Contexte : chaque nouveau service réimplémentait `requireRoleAccess` localement avec des variations subtiles (certains retournaient `{ email }`, d'autres `{ email, role }`).
+- Quand l'utiliser : dès qu'un endpoint nécessite une vérification de rôle ou d'authentification.
+- Validé le : 07-04-2026
+- Contexte technique : backend / RBAC — RL799_V2 epics 7-8-9
+
+### Règle
+
+- Un seul `requireRoleAccess` dans `lib/authHelpers.ts`, retournant toutes les infos du token utiles (email, role, sub).
+- Quand un service a besoin d'une info supplémentaire : enrichir le helper centralisé, pas le copier.
+- Le retour riche est rétrocompatible : les consommateurs existants utilisent ce dont ils ont besoin via destructuring.
+
+### Signal review
+
+- Tout service qui importe `verifyToken` directement ET fait son propre check RBAC est suspect de duplication.