mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 13:31:43 +02:00
ajout capitalisation dans workflows
This commit is contained in:
MaksTinyWorkshop
106
70_templates/tempate_a_capitaliser.md
Normal file
106
70_templates/tempate_a_capitaliser.md
Normal file
@@ -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 :
|
||||
<raison pour laquelle ce savoir mérite d'être capitalisé>
|
||||
|
||||
Proposition :
|
||||
<contenu suggéré à intégrer dans le fichier cible>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 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.
|
||||
@@ -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
|
||||
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user