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