# Review de capitalisation — 2026-03-19 Source revue : `95_a_capitaliser.md` Périmètre de comparaison : `10_*`, `40_decisions_et_archi.md`, `90_debug_et_postmortem.md` ## Méthode - L’exemple de format présent en tête de `95_a_capitaliser.md` n’est pas traité comme une proposition. - Les entrées ont été triées selon 5 statuts : `duplicate`, `near-duplicate`, `candidate`, `too-local`, `unclear`. - Aucun contenu n’a été intégré dans les fichiers de connaissance validée. --- ## duplicate Aucune entrée classée `duplicate`. --- ## near-duplicate ### 2026-03-16 — app-template-resto **Cible proposée :** `10_backend_patterns_valides.md` **Titre :** Transaction obligatoire pour les opérations auth multi-étapes **Verdict :** `near-duplicate` **Pourquoi :** - Recouvre fortement des principes déjà validés dans : - `10_backend_patterns_valides.md` → `Token à usage unique — génération, hash et invalidation atomique` - `40_decisions_et_archi.md` → `Idempotence et gestion des retries pour les opérations sensibles` - L’apport utile existe, mais la proposition actuelle est une spécialisation auth/password-reset d’un invariant plus large : opérations sensibles multi-écritures = transaction. **Recommandation :** - À fusionner si intégration future, sous une formulation plus générique : transaction pour opérations sensibles multi-étapes, avec exemple auth. ### 2026-03-16 — app-template-resto **Cible proposée :** `10_backend_patterns_valides.md` **Titre :** Isolation des guards purs des modules server-only **Verdict :** `near-duplicate` **Pourquoi :** - Quasi même famille d’idée que : - `server-only` réservé aux modules avec APIs Next.js exclusivement serveur - `Server Action Next.js — isoler la logique pure dans un module injectable` - Le cœur du savoir est le même : isoler la logique pure, limiter `server-only` aux bords runtime-only. **Recommandation :** - Ne pas intégrer seul. - À absorber dans une entrée fusionnée sur `server-only` / testabilité / extraction de logique pure. ### 2026-03-16 — app-template-resto / code-review story 1.11 **Cible proposée :** `10_backend_risques_et_vigilance.md` **Titre :** `server-only` dans les repositories bloque les tests unitaires **Verdict :** `near-duplicate` **Pourquoi :** - Même problème racine que les propositions précédentes sur `server-only`. - Le risque est réel, mais il double essentiellement un futur pattern plus général sur la frontière runtime-only. - La mitigation par stub `server-only` en test ne doit pas être capitalisée comme pratique de référence. **Recommandation :** - Ne pas intégrer sous cette forme. - Si capitalisation ultérieure : reformuler le risque autour de “mélanger logique pure et dépendances runtime-only nuit à la testabilité”. --- ## candidate ### 2026-03-16 — app-template-resto **Cible proposée :** `10_backend_patterns_valides.md` **Titre :** `server-only` réservé aux modules avec APIs Next.js exclusivement serveur **Verdict :** `candidate` **Pourquoi :** - Savoir réutilisable, concret, testable, avec périmètre clair. - Pas trouvé tel quel dans les fichiers validés. - Complète utilement les patterns backend existants sur testabilité et séparation des responsabilités. **Réserve :** - À intégrer seulement après fusion avec les autres entrées proches sur `server-only` et Server Actions, pour éviter trois patterns quasi redondants. ### 2026-03-16 — app-template-resto **Cible proposée :** `10_backend_patterns_valides.md` **Titre :** Suppression de session idempotente (P2025) **Verdict :** `candidate` **Pourquoi :** - Cas réutilisable au-delà du projet : révocation/logout/suppression concurrente. - Complète les principes généraux d’idempotence déjà présents avec un exemple Prisma actionnable. - Suffisamment concret pour mériter potentiellement un pattern dédié si d’autres cas analogues existent. **Réserve :** - Bien cadrer le contexte technique (`Prisma`, suppression de session/révocation) pour éviter d’en faire une règle trop générale. ### 2026-03-16 — app-template-resto **Cible proposée :** `10_backend_patterns_valides.md` **Titre :** Server Action Next.js — isoler la logique pure dans un module injectable **Verdict :** `candidate` **Pourquoi :** - Le pattern est clair, réutilisable, et dépasse le cas local. - Il apporte une couture explicite entre runtime Next.js et logique testable. - Aucun équivalent direct n’est déjà capitalisé dans les fichiers validés. **Réserve :** - À fusionner avec les deux autres entrées `server-only` pour produire une seule entrée robuste : frontière runtime-only fine, orchestration en bord, logique pure injectable/testable. --- ## too-local ### 2026-03-10 — app-alexandrie **Cible proposée :** `10_backend_patterns_valides.md` **Titre :** Progression V1 calculée sans persistance dédiée **Verdict :** `too-local` **Pourquoi :** - Le raisonnement est intéressant, mais reste très lié à un arbitrage produit/modélisation métier V1. - Réutilisabilité trop faible en l’état : dépend du type de progression, du domaine, et du niveau d’anticipation produit. - Même conclusion que la revue déjà présente dans `95_a_capitaliser.md` : utile, mais pas encore assez universel pour mémoire durable. ### 2026-03-16 — app-template-resto **Cible proposée :** `10_backend_risques_et_vigilance.md` **Titre :** Divergence schéma / spec story **Verdict :** `too-local` **Pourquoi :** - Le problème relève surtout d’un défaut de process de story/review, pas d’un risque backend durable au bon niveau d’abstraction. - Trop attaché au contexte BMAD/story-writing et à Prisma sur ce cas précis. - Mieux traité dans des conventions de review ou de rédaction projet que dans la base Lead Tech durable. --- ## unclear Aucune entrée classée `unclear`. --- ## Intégré ### 2026-03-19 - Intégré dans `10_backend_patterns_valides.md` : - `Next.js runtime-only — orchestration en bord et logique pure testable` - Cette intégration absorbe les propositions proches suivantes : - `Isolation des guards purs des modules server-only` - ``server-only` réservé aux modules avec APIs Next.js exclusivement serveur` - `Server Action Next.js — isoler la logique pure dans un module injectable` - La proposition `server-only dans les repositories bloque les tests unitaires` n’a pas été intégrée comme risque autonome ; son signal utile est couvert par le pattern fusionné ci-dessus. --- ## Synthèse - **Candidates solides après fusion :** - famille `server-only` / Server Actions / logique pure testable - suppression de session idempotente (`P2025`) si on assume un pattern Prisma ciblé - **À ne pas intégrer en l’état :** - progression V1 sans persistance dédiée - divergence schéma / spec story - **Point principal de déduplication :** - trois entrées parlent en pratique du même sujet : frontière runtime Next.js (`server-only`) vs logique pure testable.