diff --git a/95_a_capitaliser.md b/95_a_capitaliser.md
index 3ce34a8..e8eaf40 100644
--- a/95_a_capitaliser.md
+++ b/95_a_capitaliser.md
@@ -27,6 +27,46 @@ 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 :
diff --git a/scripts/bmad-init-project.sh b/scripts/bmad-init-project.sh
old mode 100755
new mode 100644
diff --git a/scripts/generate_project_claude.sh b/scripts/generate_project_claude.sh
old mode 100755
new mode 100644
diff --git a/scripts/mkproj.sh b/scripts/mkproj.sh
old mode 100755
new mode 100644
diff --git a/scripts/resolve-project-path.sh b/scripts/resolve-project-path.sh
old mode 100755
new mode 100644
diff --git a/scripts/sync-ai-instructions.sh b/scripts/sync-ai-instructions.sh
old mode 100755
new mode 100644