capitalisation: intégration 28 entrées knowledge + 2 CLAUDE.md RL799_V2 (triage branche mcp_v1)

28 nouvelles sections intégrées dans 12 fichiers knowledge (backend risques/patterns,
frontend risques/patterns, workflow risques). Couvre rate limiting, RGPD, CSP Next.js,
refresh token TOCTOU, catch-all Prisma, distinction 401/403, tests E2E Playwright, etc.

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

knowledge/backend/patterns/auth.md

@@ -239,3 +239,60 @@ try {
 - [ ] `P2025` absorbé silencieusement sur les suppressions de session
 - [ ] Effets de bord hors transaction documentés (cookie, email)
 - [ ] Tests couvrant le cas d'une session déjà expirée
+
+---
+
+<a id="pattern-scope-minimal-cookie-refresh"></a>
+## Pattern : Scope minimal du cookie refresh token
+
+- Objectif : limiter l'exposition du cookie refresh token au strict minimum.
+- Contexte : migration d'un stockage localStorage vers cookies httpOnly pour les tokens d'authentification.
+- Quand l'utiliser : dès qu'un refresh token est transmis via cookie.
+- Quand l'éviter : jamais.
+- Avantage :
+  - réduit la surface d'attaque — le cookie ne voyage qu'avec les requêtes de refresh
+  - évite l'envoi inutile du refresh token sur les endpoints auth (login, password, invitations)
+- Limites / vigilance :
+  - vérifier que le path est compatible avec le routing réel de l'endpoint de refresh
+- Validé le : 08-04-2026
+- Contexte technique : auth / cookies httpOnly — RL799_V2
+
+### Règle
+
+- Le cookie `refresh_token` doit avoir `Path=/api/auth/refresh` (pas `/api/auth`). Seul l'endpoint de refresh a besoin de recevoir ce cookie.
+- Plus le path est large, plus la surface d'attaque est grande (le cookie voyage avec chaque requête matchant le path).
+
+### Checklist
+
+- [ ] `Path=/api/auth/refresh` sur le cookie refresh token
+- [ ] `Path=/` uniquement pour l'access token (nécessaire sur toutes les routes API)
+- [ ] Vérifier que l'endpoint de refresh reçoit bien le cookie après changement de path
+
+---
+
+<a id="pattern-distinction-401-403"></a>
+## Pattern : Distinction stricte 401 vs 403
+
+- Objectif : permettre au frontend de réagir correctement aux erreurs d'authentification et d'autorisation.
+- Contexte : helper centralisé `requireRoleAccess` ou équivalent.
+- Quand l'utiliser : systématiquement sur tout helper d'authentification/autorisation.
+- Quand l'éviter : jamais.
+- Avantage :
+  - le frontend peut distinguer "session expirée → redirection login" de "permission manquante → message accès refusé"
+  - debug plus rapide en production
+- Limites / vigilance :
+  - la distinction doit être cohérente sur tous les endpoints — ne pas retourner 403 pour un token absent sur certains services
+- Validé le : 08-04-2026
+- Contexte technique : auth / RBAC — RL799_V2
+
+### Règle
+
+Le helper `requireRoleAccess` doit retourner :
+- **401 UNAUTHORIZED** : token absent, expiré, malformé, ou email manquant dans le payload
+- **403 FORBIDDEN** : token valide mais rôle non autorisé pour la ressource
+
+### Checklist
+
+- [ ] 401 pour tout problème de token (absent, expiré, malformé)
+- [ ] 403 uniquement quand le token est valide mais le rôle insuffisant
+- [ ] Frontend redirige vers `/login` sur 401, affiche "accès refusé" sur 403

knowledge/backend/patterns/contracts.md

@@ -167,3 +167,23 @@ Quand un repository utilise le pattern `{ ok: true; data } | { ok: false }` pour
 ### Signal review
 
 - `catch { return null }` dans un repository qui utilise `{ ok: false }` ailleurs
+
+---
+
+<a id="pattern-api-crypto-variantes-binaire-base64"></a>
+## Pattern : API crypto — variantes binaire et base64
+
+- Objectif : éviter un round-trip base64 coûteux en mémoire quand les données sont déjà en binaire.
+- Contexte : fonction crypto qui travaille en base64 pour la sérialisation (stockage DB, transport JSON) mais appelée aussi depuis des lectures fichier (binaire natif).
+- Quand l'utiliser : dès qu'une fonction crypto accepte uniquement du base64 mais est appelée avec des données binaires.
+- Quand l'éviter : si toutes les sources de données sont déjà en base64.
+- Validé le : 08-04-2026
+- Contexte technique : Node.js crypto / fichiers — RL799_V2 story 13-7
+
+### Règle
+
+Quand une fonction crypto travaille en base64 pour la sérialisation, prévoir une variante `*Buffer` qui accepte un `Buffer` natif pour les cas où les données sont déjà en binaire (lecture fichier, stream). Cela évite un double encodage (fichier → base64 → Buffer → déchiffrement).
+
+### Signal review
+
+- `buffer.toString('base64')` suivi immédiatement de `decrypt(base64String)` qui fait `Buffer.from(str, 'base64')` → round-trip inutile

knowledge/backend/patterns/general.md

@@ -33,3 +33,29 @@ source_projects: [RL799_V2]
 ### Signal review
 
 - Tout service qui importe `verifyToken` directement ET fait son propre check RBAC est suspect de duplication.
+
+---
+
+<a id="pattern-extension-service-par-type-rbac"></a>
+## Pattern : Extension d'un service existant par type avec RBAC granulaire
+
+- Objectif : éviter la duplication de service quand un nouveau besoin est fonctionnellement identique à un service existant mais avec des restrictions d'accès différentes.
+- Contexte : ajout d'un nouveau type de communication (ex: `vm`) avec restrictions RBAC spécifiques dans un service communications existant.
+- Quand l'utiliser : quand le nouveau besoin utilise le même modèle de données et le même CRUD que le service existant, seules les restrictions d'accès changent.
+- Quand l'éviter : quand le modèle de données diverge (champs spécifiques au nouveau type) — dans ce cas, un service dédié est préférable.
+- Validé le : 08-04-2026
+- Contexte technique : backend / architecture — RL799_V2 story 18-7
+
+### Règle
+
+Préférer étendre le service avec un nouveau type (enum/Set) et ajuster les restrictions RBAC par type, plutôt que dupliquer le service.
+
+### Avantages
+
+- Un seul repository, un seul endpoint, même format de réponse
+- Tests existants couvrent la non-régression
+- Moins de code à maintenir
+
+### Signal review
+
+- Nouveau service qui réplique le CRUD d'un service existant avec un filtre additionnel → candidat à la fusion par type