_Assistant_Lead_Tech/95_a_capitaliser.md

# Capitalisation en attente — Lead_tech

Ce fichier sert de **zone tampon de capitalisation**.

Les agents et les projets peuvent y déposer des propositions
d’amélioration de la base de connaissance globale (`Lead_tech`).

Le contenu de ce fichier **n'est pas encore validé**.

Une fois relues et confirmées, les propositions doivent être **déplacées**
vers les fichiers appropriés :

- `10_backend_patterns_valides.md`
- `10_frontend_patterns_valides.md`
- `10_ux_patterns_valides.md`
- `10_product_patterns_valides.md`
- `10_n8n_patterns_valides.md`
- `10_backend_risques_et_vigilance.md`
- `10_frontend_risques_et_vigilance.md`
- `10_ux_risques_et_vigilance.md`
- `10_n8n_risques_et_vigilance.md`
- `10_conventions_redaction.md`
- `40_decisions_et_archi.md`
- `90_debug_et_postmortem.md`

Ce fichier ne doit donc **jamais devenir une documentation permanente**.

---

2026-03-23 — app-alexandrie

FILE_UPDATE_PROPOSAL
Fichier cible : 10_backend_risques_et_vigilance.md

Pourquoi :
Pattern récurrent : les endpoints GET de lecture ne vérifient pas les droits d'accès au forum, alors que les endpoints d'écriture le font. Trouvé sur `getCategories` (4.5) — l'endpoint était exposé à tout utilisateur authentifié sans contrôle d'entitlements.

Proposition :
**VIGILANCE — Endpoints lecture sans contrôle d'accès (forum/ressource restreinte)**
Tout endpoint retournant des données liées à une ressource protégée (forum pack, contenu premium) doit appeler `assertForumAccess` ou équivalent, même pour les opérations GET. La règle "seuls les writes vérifient les droits" est un anti-pattern qui expose des données à des utilisateurs non autorisés. Checklist de review : pour chaque nouveau GET, vérifier qu'il passe bien par le guard/helper d'accès si la ressource appartient à un scope protégé.

---

2026-03-23 — app-alexandrie

FILE_UPDATE_PROPOSAL
Fichier cible : 10_backend_patterns_valides.md

Pourquoi :
Vérification d'unicité Prisma + race condition : une vérification `findUnique` avant `create` ne suffit pas en cas de requêtes concurrentes. Le catch sur `P2002` est le seul garde-fou fiable.

Proposition :
**PATTERN — Gestion de contrainte unique Prisma : toujours catch P2002**
Ne pas se fier uniquement à un `findUnique` pré-insertion pour garantir l'unicité. Toujours encapsuler le `create` dans un `try/catch` ciblant `err.code === 'P2002'` et relancer l'erreur métier appropriée. Cela couvre les race conditions entre requêtes concurrentes. Exemple validé : `createCategory` (4.5), `createThread` (4.2 aurait dû l'avoir aussi).

---

2026-03-23 — app-alexandrie

FILE_UPDATE_PROPOSAL
Fichier cible : 10_frontend_risques_et_vigilance.md

Pourquoi :
Store Zustand partagé entre plusieurs écrans d'un même type (ex: plusieurs forums) : les collections sans clé de contexte (ex: `categories: Category[]` sans `categoriesForumSlug`) causent des affichages de données périmées lors d'une navigation inter-forum.

Proposition :
**VIGILANCE — Store Zustand : collections sans clé de contexte**
Quand un store stocke des données qui dépendent d'un paramètre de navigation (forumSlug, threadId...), ne pas se contenter d'un guard `if (items.length > 0) return` — cela empêche le rechargement lors d'un changement de contexte. Soit stocker la clé de contexte avec les données (`categoriesForumSlug: string | null`), soit supprimer le guard et dépendre uniquement du changement de paramètre dans le useEffect.

# Format attendu

Chaque proposition doit suivre ce format :

```
DATE — PROJET

FILE_UPDATE_PROPOSAL
Fichier cible : <10_backend_patterns_valides.md | 10_frontend_patterns_valides.md | 10_ux_patterns_valides.md | 10_product_patterns_valides.md | 10_n8n_patterns_valides.md | 10_backend_risques_et_vigilance.md | 10_frontend_risques_et_vigilance.md | 10_ux_risques_et_vigilance.md | 10_n8n_risques_et_vigilance.md | 10_conventions_redaction.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md>

Pourquoi :
<raison pour laquelle ce savoir mérite d'être capitalisé>

Proposition :
<contenu suggéré à intégrer dans le fichier cible>
```

---

# Exemple

```
2026-03-08 — portfolio

FILE_UPDATE_PROPOSAL
Fichier cible : 10_backend_patterns_valides.md

Pourquoi :
Pattern réutilisable validé sur un projet réel.

Proposition :

## Nom du pattern

Description courte, factuelle, orientée réutilisation.
```

---

# Règles

1. Les agents peuvent **proposer librement** ici.
2. Les propositions doivent rester **courtes et factuelles**.
3. La validation et l'intégration finale dans `Lead_tech`
   sont faites **manuellement**.
4. Une fois intégrée, la proposition doit être **supprimée de ce fichier**.
5. La structure de ce fichier est **restaurée à son état initial** (voir `70_templates/template_a_capitaliser.md`).

---

_Aucune entrée pour le moment_

---

# Rôle dans l'architecture

```
Projet
  ↓
Proposition
  ↓
95_a_capitaliser.md
  ↓
Validation humaine
  ↓
Lead_tech
```

Ce mécanisme permet :

- d'éviter la pollution de la base de connaissance
- de capitaliser progressivement l'expérience des projets
- de garder `Lead_tech` cohérent et fiable.