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/nestjs.md

@@ -2,10 +2,10 @@
 title: Backend — Risques & vigilance : NestJS
 domain: backend
 bucket: risques
-tags: [nestjs, controllers, guards, providers, review]
+tags: [nestjs, controllers, guards, providers, review, injection, tsx-watch, mode-degrade]
 applies_to: [implementation, review, debug]
 severity: high
-validated_on: 2026-03-30
+validated_on: 2026-06-25
 source_projects: [app-alexandrie]
 ---
 
@@ -144,3 +144,50 @@ if (user.sessionStatus === 'BLOCKED') throw new HttpException(...);
 - **Règle** : définir une whitelist explicite des writes autorisés même en état bloqué.
 
 - Contexte technique : NestJS / guard statut — app-alexandrie 30-03-2026
+
+---
+
+<a id="risque-bootstrap-ok-injection-cassee-tsx-watch"></a>
+## Bootstrap NestJS OK mais injection runtime cassée sous `tsx watch`
+
+### Risques
+
+- En dev, un serveur NestJS peut afficher `Nest application successfully started` et exposer ses routes, tout en cassant à la **première requête** : des dépendances injectées (`Reflector`, services consommés par les guards globaux) arrivent à `undefined` au runtime.
+- Le symptôme initial ressemble à un problème réseau/mobile alors que la cause réelle est l'injection backend.
+
+### Symptômes
+
+- `GET /` ou une route d'auth répond `500` alors que le bootstrap est nominal
+- Stack runtime du type `Cannot read properties of undefined (reading 'getAllAndOverride')`
+- Les guards globaux (`AuthGuard`, guards basés sur `Reflector`) sont les premiers à tomber
+
+### Bonnes pratiques / mitigations
+
+- Ne pas conclure trop vite à un problème réseau dès que le port écoute : traiter « le port écoute » et « les requêtes fonctionnent » comme **deux validations distinctes**.
+- Tester immédiatement `GET /`, l'endpoint OpenAPI et une route publique métier, puis lire la stack runtime **après le premier hit** (pas seulement les logs de bootstrap).
+- Si un lanceur `tsx watch` est utilisé avec NestJS, vérifier explicitement la compatibilité avec l'injection runtime ; en cas de doute, expliciter les injections critiques avec `@Inject(...)` sur guards et services exposés dès le premier hit.
+
+- Contexte technique : NestJS / tsx watch / injection — app-alexandrie 01-04-2026
+
+---
+
+<a id="risque-writemodeguard-bloque-endpoints-support"></a>
+## Guard d'écriture en mode dégradé bloque les endpoints de support
+
+### Risques
+
+- Un guard global qui refuse toutes les écritures (`POST/PUT/PATCH/DELETE`) quand un service critique est down (ex : Redis) bloque aussi les endpoints dont l'utilité est **maximale en panne** : soumission de ticket de support, feedback, remontée de logs d'erreur client.
+- Cas typique : un endpoint de ticketing (`POST /support/...`) devient inaccessible précisément au moment où l'utilisateur veut signaler le dysfonctionnement qu'il subit.
+
+### Symptômes
+
+- Soumission de ticket de support impossible quand le service de quota/cache est indisponible
+- Le guard rejette des routes qui devraient rester ouvertes en mode dégradé
+
+### Bonnes pratiques / mitigations
+
+- Lors de l'ajout d'un guard d'écriture en mode dégradé, **recenser explicitement les endpoints critiques qui doivent rester disponibles** : support, feedback, logs d'erreur client.
+- Whitelister ces préfixes dès la création du guard — pas lors de la code review d'une story ultérieure. Exemple de whitelist : `/auth`, `/billing/.../webhooks`, `/support`.
+- **Why** : un service de ticketing bloqué quand le backend dysfonctionne est contre-productif — l'utilisateur ne peut pas signaler le problème qu'il est en train de subir.
+
+- Contexte technique : NestJS / guard mode dégradé — app-alexandrie 01-04-2026