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

@@ -555,3 +555,41 @@ Trois cas typiques quand l'erreur apparaît après extraction :
 **Recommandation outillage** : `vue-tsc` plutôt que `tsc` pur en typecheck (cf. `risque-templates-vue-references-orphelines`). Ce genre de divergence aurait été détecté **avant** le refactor.
 
 - Contexte technique : Vue 3 / Volar / `vue-tsc` — RL799_V2 29-04-2026
+
+---
+
+<a id="risque-fallback-catch-all-mapping-statut-db-ui"></a>
+## Fallback catch-all dans le mapping statut DB → UI
+
+### Risques
+
+- Un mapping statut DB → statut UI avec un `return` catch-all final accepte implicitement **toute** nouvelle valeur d'enum DB sans alerte
+- Une nouvelle valeur (ex : `pending`) atterrit alors dans la branche par défaut (ex : rendue comme `processing`) avec un libellé incorrect, violant silencieusement le contrat d'affichage
+
+### Symptômes
+
+- Une valeur d'enum DB non explicitement gérée affiche le mauvais état UI (ex : "En cours…" au lieu de "En attente")
+- L'ajout d'une valeur d'enum côté DB ne déclenche aucune erreur de compile ni de test ; le mauvais libellé passe inaperçu
+
+### Bonnes pratiques / mitigations
+
+```ts
+// ❌ Le catch-all masque silencieusement "pending" sous "processing"
+function dbStatusToUiStatus(s: DBStatus): UIStatus {
+  if (s === "ready") return "ready";
+  if (s === "failed") return "failed";
+  return "processing"; // "pending" atterrit ici sans libellé correct
+}
+
+// ✅ Mapping exhaustif : un if par valeur d'enum
+function dbStatusToUiStatus(s: DBStatus): UIStatus {
+  if (s === "ready") return "ready";
+  if (s === "failed") return "failed";
+  if (s === "pending") return "pending";
+  return "processing";
+}
+```
+
+- Règle : chaque valeur de l'enum DB doit avoir son propre `if` dans le mapping. Éviter le `return` catch-all final qui absorbe les valeurs non prévues.
+
+- Contexte technique : frontend / mapping statut DB → UI — app-template-resto 25-06-2026