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

@@ -5,8 +5,8 @@ bucket: risques
 tags: [prisma, transactions, tenant, schema, race-condition]
 applies_to: [implementation, review, debug, architecture]
 severity: high
-validated_on: 2026-03-23
-source_projects: [app-template-resto, app-alexandrie]
+validated_on: 2026-04-07
+source_projects: [app-template-resto, app-alexandrie, RL799_V2]
 ---
 
 # Backend — Risques & vigilance : Prisma
@@ -338,3 +338,49 @@ if (cursor) {
 3. **Signal review** : tout cast `as EnumType` sur une valeur issue de Prisma = dette à corriger immédiatement.
 
 - Contexte technique : Prisma / PostgreSQL — app-alexandrie 31-03-2026
+
+---
+
+<a id="risque-migration-manuelle-hors-git"></a>
+## Migration appliquée manuellement hors git
+
+### Risques
+
+- Une migration Prisma appliquée via DDL direct + `migrate resolve --applied` produit un fichier `migration.sql` qui peut rester untracked dans git
+- Quiconque clone le repo et lance `prisma migrate deploy` n'a pas la migration
+
+### Symptômes
+
+- `??` (untracked) dans `git status` sur le dossier `prisma/migrations/`
+- `prisma migrate status` rapporte un drift entre le schéma et l'état de la DB
+
+### Bonnes pratiques / mitigations
+
+Checklist minimale après `prisma migrate resolve --applied` :
+- `git status` → vérifier que `prisma/migrations/<nom>/migration.sql` est présent et tracké
+- `git add prisma/migrations/<nom>/` si untracked
+- Valider que `prisma migrate status` rapporte la migration comme appliquée sans drift
+
+- Contexte technique : Prisma / migrations manuelles — RL799_V2 02-04-2026
+
+---
+
+<a id="risque-relation-1-1-sans-unique"></a>
+## Relation 1:1 métier sans contrainte `@unique` en DB
+
+### Risques
+
+- Un mapping métier 1:1 (ex: planche tracée → document généré) implémenté avec un simple index + `findFirst` crée un risque de backlinks non déterministes en cas d'incohérence de données
+
+### Symptômes
+
+- Champ de référence nullable seulement indexé, puis lecture via `findFirst`
+- Le code suppose l'unicité mais la base ne l'impose pas
+
+### Bonnes pratiques / mitigations
+
+- Poser une contrainte `@unique` (nullable) sur la référence quand la relation métier est 1:1
+- Préférer `findUnique` / lecture déterministe
+- **Signal review** : si le code suppose l'unicité, la base doit l'imposer explicitement
+
+- Contexte technique : Prisma / contraintes DB — RL799_V2 06-04-2026