From 1b2ed6ff4e744745ca97c5e2899e95a4c3de658d Mon Sep 17 00:00:00 2001 From: MaksTinyWorkshop Date: Tue, 10 Mar 2026 13:30:32 +0100 Subject: [PATCH] ajout capitalisation dans workflows --- 70_templates/tempate_a_capitaliser.md | 106 ++++++++++++++++++++++++++ 95_a_capitaliser.md | 71 ++++++++++++++++- 2 files changed, 174 insertions(+), 3 deletions(-) create mode 100644 70_templates/tempate_a_capitaliser.md diff --git a/70_templates/tempate_a_capitaliser.md b/70_templates/tempate_a_capitaliser.md new file mode 100644 index 0000000..1ff1370 --- /dev/null +++ b/70_templates/tempate_a_capitaliser.md @@ -0,0 +1,106 @@ +# 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.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` + +Ce fichier ne doit donc **jamais devenir une documentation permanente**. + +--- + +# 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 : + + +Proposition : + +``` + +--- + +# Exemple + +``` +2026-03-08 — portfolio + +FILE_UPDATE_PROPOSAL +Fichier cible : 10_backend_patterns_valides.md + +Pourquoi : +Ordre d'enregistrement des Guards NestJS causant un bug +`request.user undefined` observé à plusieurs reprises. + +Proposition : + +## Ordre des Guards NestJS + +Toujours enregistrer `AuthGuard` avant les Guards dépendants +(`EmailVerifiedGuard`, `RoleGuard`, etc.). + +Sinon `request.user` peut être undefined dans les guards suivants. +``` + +--- + +# Règles + +1. Les agents peuvent **proposer librement** ici. +2. Les propositions doivent rester **courtes et factuelles**. +3. La validation et l'intégration finale dans `Lead_tech` + sont faites **manuellement**. +4. Une fois intégrée, la proposition doit être **supprimée de ce fichier**. +5. 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_tech` cohérent et fiable. diff --git a/95_a_capitaliser.md b/95_a_capitaliser.md index 0830e5f..6759abb 100644 --- a/95_a_capitaliser.md +++ b/95_a_capitaliser.md @@ -7,7 +7,7 @@ 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 +Une fois relues et confirmées, les propositions doivent être **déplacées** vers les fichiers appropriés : - `10_backend_patterns_valides.md` @@ -76,11 +76,76 @@ Sinon `request.user` peut être undefined dans les guards suivants. 2. Les propositions doivent rester **courtes et factuelles**. 3. La validation et l'intégration finale dans `Lead_tech` sont faites **manuellement**. -4. Une fois intégrée, la proposition doit être **supprimée - de ce fichier**. +4. Une fois intégrée, la proposition doit être **supprimée de ce fichier**. +5. La structure de ce fichier est **restaurée à son état initial** (voir `70_templates/template_a_capitaliser.md`). + +2026-03-10 — app-alexandrie + +FILE_UPDATE_PROPOSAL +Fichier cible : 10_backend_patterns_valides.md + +Pourquoi : +Pattern réutilisable pour exposer une progression V1 sans ouvrir trop tôt un domaine `achievements` ou `analytics`, tout en gardant une couture propre vers des contributions futures. + +Proposition : + +## Progression V1 calculée sans persistance dédiée + +Pour une feature de progression minimum viable : +- garder l'agrégat dans le domaine métier déjà source de vérité (`content`, `billing`, etc.) +- calculer les compteurs période (`thisWeek`, `thisMonth`) côté base avec `count`/agrégations filtrées +- centraliser le catalogue d'objectifs en code explicite et testable +- prévoir une couture zéro-safe pour les sources futures (`contributions`, `posts`, etc.) au lieu d'inventer les tables en avance + +Évite le scope creep vers un module `achievements` prématuré et garde un contrat stable. + +2026-03-10 — app-alexandrie + +FILE_UPDATE_PROPOSAL +Fichier cible : 10_frontend_patterns_valides.md + +Pourquoi : +Pattern frontend/mobile utile pour brancher un écran récapitulatif serveur sans dupliquer la logique réseau dans l'écran et sans navigation impérative via `store.getState()`. + +Proposition : + +## Écran récapitulatif branché sur store de domaine existant + +Quand une vue récapitulative dépend d'un domaine déjà présent : +- étendre le `service` et le `store` existants au lieu de créer un nouveau domaine artificiel +- laisser l'écran purement déclaratif avec états `loading / error / empty / nominal` +- déclencher le chargement via `useEffect` et actions du store +- réserver `refresh` à une action idempotente du store +- ajouter le point d'entrée depuis l'écran parent naturel (`library`, `profile`, etc.) au lieu de refondre la navigation globale + +Réduit les régressions et garde le comportement async testable. --- +2026-03-10 — app-alexandrie + +FILE_UPDATE_PROPOSAL +Fichier cible : 10_frontend_patterns_valides.md + +Pourquoi : +Le pull-to-refresh mobile sur listes paginées a besoin d’une vraie idempotence côté store, sinon on crée des doublons et des courses réseau invisibles. Le pattern a été validé ici avec Zustand sans introduire de lib de cache serveur. + +Proposition : +Pattern "Refresh idempotent sur store de liste paginée" : conserver une promesse de refresh en vol partagée, refuser les refresh concurrents, remplacer atomiquement la liste à la fin du refresh, et dédupliquer les items par identifiant au merge des pages suivantes. + +--- + +2026-03-10 — app-alexandrie + +FILE_UPDATE_PROPOSAL +Fichier cible : 10_frontend_risques_et_vigilance.md + +Pourquoi : +Un écran gated par des droits distants peut tomber dans un faux état `loading` infini si l’erreur de chargement des entitlements laisse les données à `null` et relance automatiquement l’effet. Le défaut a été détecté en review sur la Bibliothèque mobile. + +Proposition : +Risque "Loading infini sur écran gated" : si un écran dépend d’un store d’entitlements ou d’autorisations, distinguer explicitement `loading`, `error`, `ready`, et bloquer les retries automatiques en boucle après erreur tant qu’un retry utilisateur ou une nouvelle condition d’entrée n’a pas eu lieu. + # Rôle dans l'architecture ```