capitalisation: intégration ~60 entrées RL799_V2 (triage 2026-05-02)

Triage du 95_a_capitaliser.md (~75 propositions) :
- 60 entrées intégrées dans knowledge/ (backend, frontend, workflow)
- 4 nouveaux fichiers : backend/patterns/tests.md, backend/risques/tests.md,
  frontend/patterns/general.md, workflow/patterns/general.md
- 6 doublons rejetés
- Mise à jour des READMEs index pour refléter les nouvelles entrées
- 95_a_capitaliser.md restauré à sa structure initiale
- 40_decisions_et_archi.md : décision mono-tenant déployable vs SaaS multi-tenant
- 90_debug_et_postmortem.md : sub-agents Write indisponible, effet iceberg CI,
  prisma migrate diffs cosmétiques

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

knowledge/workflow/risques/story-tracking.md

@@ -270,3 +270,47 @@ source_projects: [app-alexandrie, app-template-resto, RL799_V2]
 - Contexte technique : BMAD / traçabilité adaptation story — RL799_V2 15-04-2026
 
 ---
+
+<a id="risque-strategie-fix-suite-e2e-en-masse"></a>
+## Stratégie de fix d'une suite E2E qui rote en masse (post-refactor)
+
+### Risques
+
+- Quand un projet enchaîne plusieurs refactors UI/lifecycle sans run E2E entre chaque, on découvre souvent N fails (10-20) d'un coup
+- Tentation de fixer fail-by-fail dans l'ordre où ils apparaissent — erreur : on se disperse sur N causes-racines mélangées et chaque commit n'est pas reviewable
+- Sans capitalisation immédiate des patterns, on perd le bénéfice de la session pour les futurs refactors
+
+### Symptômes
+
+- 13 fails d'un coup après une période de refactor intense
+- Tentative de fix fail-par-fail qui produit un commit géant difficile à reviewer
+- Capitalisation reportée → patterns oubliés à la session suivante
+
+### Bonnes pratiques / mitigations
+
+**Process recommandé** :
+
+1. **Run complet en mode list** d'abord : `playwright test --reporter=list`. On veut **la liste exhaustive** des fails, pas un comptage one-shot par fichier (qui peut masquer des fails qui apparaissent uniquement quand on lance la suite entière à cause d'effets de bord seed).
+
+2. **Catégoriser par cause-racine** plutôt que par fichier (cf. `knowledge/frontend/risques/tests.md` — Tests E2E qui rotent — 6 causes-racines récurrentes) :
+   - testid changé sans MAJ tests
+   - label métier changé (lifecycle, statut)
+   - menu/dropdown conditionnel
+   - feature supprimée (query param, route)
+   - refactor visuel (texte → icône)
+   - cleanup post-test à rendre best-effort
+
+3. **1 commit = 1 cause-racine**. Pas "fix 19 fails" en un commit géant. Permet :
+   - Review plus simple (chaque commit a un thème clair)
+   - Revert chirurgical si une cause-racine s'avère mal diagnostiquée
+   - Capitalisation : chaque commit message documente le pattern
+
+4. **Validation entre commits** : run la suite complète après chaque commit pour savoir avant le push que le commit n'a pas régressé d'autres tests.
+
+5. **Capitaliser les patterns à > 2 occurrences** : si on voit le même type de fail 3 fois sur 3 fichiers différents, c'est un pattern. Le poser dans `knowledge/frontend/risques/tests.md` immédiatement, pas plus tard.
+
+**Anti-pattern à éviter** : "je fixe les 5 fails P1 d'abord, je verrai les P2 après". Si la cause-racine est la même (ex : labels lifecycle v3), on perd 30 min à re-comprendre quand on retourne sur les P2 plus tard. Mieux : grouper par cause-racine, pas par priorité.
+
+**Métrique de référence** : 19 fails fixés en 4 commits / ~3 h dont 1 h de capitalisation. Effort par fail : ~6 min de fix + 4 min de validation.
+
+- Contexte technique : Playwright / refactor UI — RL799_V2 25-04-2026