mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 21:41:42 +02:00
108 lines
3.8 KiB
Markdown
108 lines
3.8 KiB
Markdown
# 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 :
|
||
Pattern réutilisable validé sur un projet réel.
|
||
|
||
Proposition :
|
||
|
||
## Nom du pattern
|
||
|
||
Description courte, factuelle, orientée réutilisation.
|
||
```
|
||
|
||
---
|
||
|
||
# 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`).
|
||
|
||
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 :
|
||
Pour une capacité admin mince sur mobile, une route dédiée légère branchée sur le domaine existant et un refresh explicite du store après mutation permettent de rester testable et robuste sans lancer un back-office séparé.
|
||
|
||
Proposition :
|
||
Pattern "UI admin légère sur domaine existant" : pour une action interne simple (publication, activation, modération légère), ajouter une route dédiée minimale qui réutilise le service/store métier existant, afficher le statut courant, bloquer les actions concurrentes avec un flag `isUpdating*`, et déclencher un refresh explicite des vues impactées après succès au lieu d’un `fire-and-forget`.
|