5.1 KiB
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.md10_frontend_patterns_valides.md10_ux_patterns_valides.md10_product_patterns_valides.md10_n8n_patterns_valides.md10_backend_risques_et_vigilance.md10_frontend_risques_et_vigilance.md10_ux_risques_et_vigilance.md10_n8n_risques_et_vigilance.md10_conventions_redaction.md40_decisions_et_archi.md90_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
- Les agents peuvent proposer librement ici.
- Les propositions doivent rester courtes et factuelles.
- La validation et l'intégration finale dans
Lead_techsont faites manuellement. - Une fois intégrée, la proposition doit être supprimée de ce fichier.
- 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_techcohérent et fiable.