mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 21:41:42 +02:00
172 lines
6.9 KiB
Markdown
172 lines
6.9 KiB
Markdown
# 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.
|