capitalisation: triage 95_a_capitaliser + création domaine infra

Triage des 27 propositions du buffer de capitalisation (skill
capitalisation-triage), avec vérification des doublons contre la base.

Intégré dans knowledge/ (23 entrées):
- backend: redis (compensation incrBy non-atomique), nestjs (injection
  cassée sous tsx watch; guard write mode dégradé), async (test rollback
  pipeline multi-fichiers), contracts (idempotence POST), auth (disclosure
  comptes soft-deleted), prisma (index partial soft-delete), llm-providers
  (nouveau: OAuth vs API key, prompt caching).
- frontend: tests (garde-fous parking Later), navigation (fichiers
  non-route sous src/app Expo Router), general (type client vs payload
  backend), state (fallback catch-all mapping DB→UI).
- workflow: story-tracking (statut BMAD vs narratif obsolète).
- product: general (nouveau: doc feature store sans UI).
- infra: NOUVEAU DOMAINE (traefik, tailscale, docker, docker-networking,
  reverse-proxy-paths, sidecar tailscale) + 00_INDEX.md.

Autres:
- 90_debug_et_postmortem.md: post-mortem réseau Docker partagé hors compose.
- Rejeté 3 doublons (types enum contracts, getter PrismaService, $transaction).
- Buffer 95_a_capitaliser.md purgé et restauré à son état initial.
- _projects.conf: MAJ statuts epics + ajout app-rl799.

knowledge/backend/risques/prisma.md

@@ -2,10 +2,10 @@
 title: Backend — Risques & vigilance : Prisma
 domain: backend
 bucket: risques
-tags: [prisma, transactions, tenant, schema, race-condition]
+tags: [prisma, transactions, tenant, schema, race-condition, index, soft-delete, performance]
 applies_to: [implementation, review, debug, architecture]
 severity: high
-validated_on: 2026-04-07
+validated_on: 2026-06-25
 source_projects: [app-template-resto, app-alexandrie, RL799_V2]
 ---
 
@@ -619,3 +619,33 @@ const resolveDbUrl = (): string | undefined => {
 **Règle générale** : toute stratégie template-based doit auditer le chemin du `DB_URL` à travers les sub-processes de bootstrap. Le bootstrap ouvre une connexion sur la template, mais le seed transitif exécuté via un sub-process peut être sujet à des transformations agressives du DSN qui le redirigent ailleurs.
 
 - Contexte technique : Prisma / template database / Vitest — RL799_V2 01-05-2026
+
+---
+
+<a id="risque-index-partial-soft-delete-perf"></a>
+## Index partial sur colonnes soft-delete (nuance perf)
+
+### Risques
+
+- Un index plein sur une colonne soft-delete nullable (`deleted_at`) indexe **tous les NULL**, c'est-à-dire la quasi-totalité des lignes (les comptes actifs). L'index est volumineux et peu sélectif pour les requêtes qui ne ciblent que les lignes supprimées.
+- Distinct de l'index **unique** partiel déjà documenté (cf. `risque-prisma-unique-nullable`, qui traite de l'idempotence) : ici l'enjeu est purement la **performance / le coût d'indexation**.
+
+### Symptômes
+
+- `CREATE INDEX ... ON ("deleted_at")` sans clause `WHERE` sur une table où >99 % des lignes ont `deleted_at IS NULL`
+- Index gros pour un bénéfice quasi nul sur les requêtes « lister les comptes supprimés »
+
+### Bonnes pratiques / mitigations
+
+```sql
+-- ❌ Index plein — indexe la masse des NULL (lignes actives)
+CREATE INDEX "users_deleted_at_idx" ON "users"("deleted_at");
+
+-- ✅ Index partial — n'indexe que les lignes effectivement supprimées
+CREATE INDEX "users_deleted_at_idx" ON "users"("deleted_at")
+  WHERE "deleted_at" IS NOT NULL;
+```
+
+- **Règle** : pour une colonne soft-delete nullable à majorité `NULL`, préférer un index partial `WHERE deleted_at IS NOT NULL`.
+
+- Contexte technique : Prisma / PostgreSQL / index partial — app-alexandrie 13-04-2026