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/frontend/risques/general.md

@@ -129,3 +129,122 @@ function processLinks(content: string) {
 - Si un reliquat legacy doit rester temporairement, documenter explicitement son périmètre et sa date de sortie attendue
 - En review, traiter toute nouvelle utilisation d'une classe legacy équivalente comme une régression de standardisation
 - Contexte technique : Vue 3 / design system léger — RL799_V2, 02-04-2026
+
+---
+
+<a id="risque-aria-roles-sans-clavier"></a>
+## ARIA roles sans comportement clavier associé
+
+### Risques
+
+- Poser `role="menu"` / `role="menuitem"` sur un composant sans implémenter le pattern clavier donne une fausse impression d'accessibilité
+- Les rôles ARIA trompent les lecteurs d'écran et violent WCAG 2.1 (4.1.2 Name, Role, Value)
+
+### Symptômes
+
+- `role="menu"` sans fermeture via `Escape`
+- Pas de navigation `ArrowUp` / `ArrowDown` ni de roving tabindex
+
+### Bonnes pratiques / mitigations
+
+Poser `role="menu"` / `role="menuitem"` implique obligatoirement :
+- Fermeture via `Escape`
+- Navigation via `ArrowUp` / `ArrowDown`
+- Roving tabindex (`tabindex="0"` sur l'item actif, `-1` sur les autres)
+- Focus automatique du premier item à l'ouverture
+
+**Règle** : ne jamais poser un `role` ARIA de widget interactif sans implémenter le pattern clavier correspondant (cf. WAI-ARIA Authoring Practices)
+
+- Contexte technique : Vue 3 / accessibilité — RL799_V2 03-04-2026
+
+---
+
+<a id="risque-duplication-logique-metier-monorepo"></a>
+## Duplication de logique métier dans les composants UI (monorepo)
+
+### Risques
+
+- Dans un monorepo avec un package partagé (`shared`), les fonctions utilitaires métier (ex: conversion grade → rang) sont redéfinies localement dans les composants ou pages frontend
+- Ce type de duplication silencieuse provoque des divergences à terme
+
+### Symptômes
+
+- Fonction `switch/case` ou mapping identique à une fonction déjà exportée par `shared`
+- Même signature et même logique dans plusieurs fichiers de couches différentes (composant, page, service)
+
+### Bonnes pratiques / mitigations
+
+- Les fonctions utilitaires métier ne doivent jamais être redéfinies localement dans les composants ou pages frontend
+- Importer systématiquement depuis le package partagé (`@monrepo/shared` ou équivalent) plutôt que de copier-coller la logique
+- **Signal review** : grep des fonctions utilitaires existantes dans shared avant de valider un nouveau switch/case
+
+- Contexte technique : Vue 3 / monorepo — RL799_V2 06-04-2026
+
+---
+
+<a id="risque-event-listeners-globaux-modales"></a>
+## Event listeners globaux pour interactions modales
+
+### Risques
+
+- `window.addEventListener('keydown')` pour capturer Escape dans une modale crée un listener global qui peut confliter avec d'autres modales
+- Le listener fuit si le composant est mal démonté
+
+### Symptômes
+
+- `window.addEventListener('keydown', handler)` dans un composant modale
+- Cleanup dans `onBeforeUnmount` mais risque de fuite si le démontage échoue
+
+### Bonnes pratiques / mitigations
+
+- Utiliser `@keydown.escape` directement sur l'élément dialog avec `tabindex="-1"` + focus automatique à l'ouverture
+- Élimine le besoin de cleanup et scope l'interaction au composant
+- **Signal review** : dans tout composant modale, vérifier que les listeners clavier sont sur l'élément, pas sur `window`
+
+- Contexte technique : Vue 3 / modales — RL799_V2 06-04-2026
+
+---
+
+<a id="risque-boutons-imbriques"></a>
+## Boutons imbriqués dans les listes interactives
+
+### Risques
+
+- Un `<button>` ou `<a>` contenant un autre élément interactif (bouton, lien) est du HTML invalide
+- Casse l'accessibilité et produit un comportement imprévisible selon les navigateurs
+
+### Symptômes
+
+- `<button>` conteneur avec un `<button>` enfant (ex: étoile favori dans une carte cliquable)
+- Comportement de clic imprévisible, événements qui ne remontent pas correctement
+
+### Bonnes pratiques / mitigations
+
+- Utiliser un `<div>` conteneur avec des boutons séparés côte à côte
+- Si toute la ligne doit être cliquable, séparer la zone de clic principale (bouton content) de l'action secondaire (bouton étoile/action)
+- **Signal review** : dans tout composant liste avec actions inline, vérifier qu'aucun élément interactif n'est imbriqué dans un autre
+
+- Contexte technique : HTML / accessibilité — RL799_V2 06-04-2026
+
+---
+
+<a id="risque-fire-and-forget-sans-feedback"></a>
+## Fire-and-forget sans feedback sur actions non-critiques
+
+### Risques
+
+- Une action asynchrone non-critique (cache IndexedDB, analytics, sync) lancée en fire-and-forget sans feedback masque les échecs
+- L'utilisateur croit que l'action est faite (ex: document disponible hors-ligne) alors qu'elle a échoué
+
+### Symptômes
+
+- `.then(...).catch(() => {})` sur une action secondaire
+- `catch { /* ignore */ }` sans log ni feedback visuel
+
+### Bonnes pratiques / mitigations
+
+- Même si l'action est non-bloquante, afficher un feedback discret en cas d'échec (toast, badge absent)
+- L'utilisateur doit pouvoir distinguer "fait" de "échoué silencieusement"
+- **Signal review** : tout `.catch(() => {})` ou `catch { /* ignore */ }` mérite au minimum un log ou un feedback visuel
+
+- Contexte technique : frontend / actions async — RL799_V2 07-04-2026