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>

90_debug_et_postmortem.md

@@ -220,3 +220,113 @@ npm install -g <package>@latest
 - `npm root -g`
 - `npm ls -g --depth=0 <package>` | npm list -g @openai/codex --depth=0
 - <package> --version
+
+---
+
+## Sub-agents Claude Code — `Write` indisponible dans la sandbox `Explore`
+
+### Contexte
+
+Workflow BMAD `testarch-test-review` sur RL799_V2 (24-04-2026) utilisant 4 sub-agents `subagent_type=Explore` pour évaluer 4 dimensions qualité en parallèle. Chaque sub-agent devait écrire un fichier JSON dans `/tmp/`.
+
+### Symptômes
+
+- Les 4 sub-agents ont terminé leur analyse avec succès mais **aucun n'a réussi à écrire son fichier JSON**
+- Messages de retour : *"Je rencontre une limitation d'outillage… je suis en mode READ-ONLY… je génère le rapport directement en texte."*
+
+### Cause
+
+Le sub-agent type `Explore` n'a pas accès à l'outil `Write` dans sa sandbox (spec : "Tools: All tools except Agent, ExitPlanMode, Edit, Write, NotebookEdit"). Non documenté clairement dans les workflows TEA qui demandent pourtant d'écrire en JSON.
+
+### Correctif / règle à retenir
+
+1. **Ne pas demander aux sub-agents `Explore` d'utiliser `Write`** — briefer explicitement "retourne le JSON en bloc dans ta réponse finale"
+2. **L'orchestrateur matérialise** les fichiers de sortie pour le compte des sub-agents
+3. **Alternative** : utiliser `subagent_type=general-purpose` qui a accès à tous les tools (mais plus cher en tokens et moins spécialisé pour l'exploration)
+
+Extrait de brief corrigé pour futur usage :
+
+```
+Ta mission : analyse X dans les fichiers Y.
+Format de sortie : JSON structuré selon le schéma ci-dessous.
+IMPORTANT : retourne le JSON directement dans ta réponse finale, entre blocs ```json```.
+Ne tente pas d'écrire de fichier (Write indisponible dans ta sandbox).
+L'orchestrateur matérialisera le fichier à partir de ton retour.
+```
+
+---
+
+## Effet iceberg en CI — patcher en cascade jusqu'au fond du puits
+
+### Contexte
+
+Quand un fix CI structurant rétablit un pipeline qui foirait depuis longtemps, **plusieurs bugs latents en aval peuvent apparaître en cascade** : ils étaient tous présents avant, juste invisibles parce que le runner s'arrêtait à l'échec amont. Vécu sur RL799_V2 le 30-04 / 01-05-2026, 8 étages d'iceberg fixés en cascade.
+
+### Symptômes
+
+| # | Phase | Symptôme | Cause | Fix |
+|---|---|---|---|---|
+| 1 | CI tests | `Cannot find module '@org/shared'` | `dist/lib` non bâti avant `test:api` | Build workspace en amont |
+| 2 | CI tests | `Module '@prisma/client' has no exported member 'X'` | Client Prisma non généré | Inverser `prisma generate` → `pnpm build` |
+| 3 | CI tests | `Seed incomplet : 0 users / N attendus` | Étape seed manquante | Ajouter `prisma db seed` après `prisma migrate deploy` |
+| 4 | CI tests | `<env> non configuré (requis hors dev)` | Variable d'env applicative manquante en CI | Définir au bloc `env:` du job |
+| 5 | CI tests | 14×500 sur endpoints qui chiffrent | `ENCRYPTION_KEY` manquante | Idem |
+| 6 | CI tests (PDF) | `Could not find Chrome` | Puppeteer cherche son cache local absent du runner | `PUPPETEER_EXECUTABLE_PATH=/usr/bin/google-chrome-stable` |
+| 7 | CD prod (migrate) | `Cannot find module '/app/scripts/check-node-version.mjs'` | `pnpm run prisma:migrate` appelle un script absent de l'image API | Appel direct du binaire Prisma |
+| 8 | CI tests | Test attend `50,00 €` reçoit `1,19 €` | `waitForNotification` mal scopé (filtre par `type` mais pas par `recipientId`) — masquée par les étages 1-7 | Re-run OU patch chirurgical du `where:` |
+
+Chaque étage masquait le suivant. Aucun n'était nouveau — tous présents avant la session, mais invisibles à cause des étages amont.
+
+### Cause
+
+- **Local ≠ CI** : en local, `dist/` traîne, le client Prisma est généré, la DB est seedée d'une session précédente, le `.env` est complet. Le bug est invisible
+- **Pipeline early-exit** : un échec à l'étape N ne laisse rien tourner aux étapes N+1, N+2, …
+- **Effet additif des sessions** : plus le pipeline est cassé depuis longtemps, plus le code applicatif a évolué sans validation CI
+
+### Correctif / règle à retenir
+
+1. **Validation locale stricte avant push CI structurant** : simuler les conditions CI vierges (`rm -rf node_modules/.prisma packages/*/dist apps/*/.next` + relancer la chaîne complète)
+2. **Lecture honnête des nouveaux failures** : après un fix CI structurant, ne pas présumer que les nouveaux failures sont des régressions du fix. Probablement des bugs latents
+3. **Tableau iceberg** : noter au fil de la session le tableau (étage / symptôme / cause / fix). Ne pas se laisser submerger par "ça casse encore"
+4. **Push après chaque étage** : ne pas attendre d'avoir tout fixé. Chaque fix structurant mérite son commit thématique
+5. **Ne pas stopper trop tôt** : un seul push ne révèle qu'un étage. Tant qu'il y a des bugs latents, le pipeline cassera
+
+### Signal pour repérer un effet iceberg
+
+- Le pipeline était cassé depuis ≥ 1 semaine
+- Le fix d'aujourd'hui touche une étape **précoce** du workflow (install, build, generate, migrate)
+- Les commits récents ont ajouté des features sans valider en CI
+- Sentiment vague de "ça pourrait casser plein d'autres trucs" — c'est probablement vrai
+
+---
+
+## Prisma migrate inclut les diffs cosmétiques (RenameIndex)
+
+### Contexte
+
+`prisma migrate dev --create-only --name add_lodge_settings` peut générer une migration qui contient (1) le changement attendu mais aussi (2) un side-effect cosmétique pré-existant entre le schema Prisma et la DB qui n'avait jamais été nettoyé. RL799_V2 — migration `20260427120920_add_lodge_settings` qui ramassait un `ALTER INDEX … RENAME TO …` orphelin.
+
+### Symptômes
+
+- Migration thématique qui contient un rename d'index sans rapport avec le scope de la story
+- Un dev qui regarde la migration ne comprend pas pourquoi cet `ALTER INDEX` est là
+
+### Options et décision
+
+| Option | Pro | Con |
+|---|---|---|
+| Garder le rename dans la migration thématique avec commentaire | la prochaine `prisma migrate dev` ne re-générera pas ce rename | le commit "thématique" contient un side-effect cosmétique |
+| Retirer le rename | commit propre | la prochaine migration thématique l'inclura à nouveau → piège pour le prochain dev |
+| Migration de cleanup séparée | plus propre | nécessite 2 migrations + 2 PRs |
+
+**Décision recommandée** : option 1 avec commentaire explicite dans le `.sql` :
+
+```sql
+-- RenameIndex (réalignement DB ↔ schema, dérive cosmétique pré-existante)
+ALTER INDEX "tronc_entries_tenue_idx" RENAME TO "tronc_entries_tenue_id_idx";
+```
+
+### Correctif / règle à retenir
+
+- **Préventif** : `prisma migrate diff` régulièrement (CI/CD ou pré-commit) pour détecter la dérive AVANT qu'elle ne pollue une migration thématique
+- **Curatif** : inspecter manuellement le SQL généré par `--create-only` avant de l'appliquer en migration thématique