_Assistant_Lead_Tech/96_review_capitalisation.md

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.