Files
_Assistant_Lead_Tech/95_a_capitaliser.md
MaksTinyWorkshop 75bfa3cf8e refactor: renommer 10_n8n_nodes_a_risques → 10_n8n_risques_et_vigilance
Alignement sur la convention de nommage uniforme des fichiers de risques.
Mise à jour de toutes les références (index, instructions, templates, zone tampon).
2026-03-08 19:46:58 +01:00

2.5 KiB
Raw Blame History

Capitalisation en attente — Lead_tech

Ce fichier sert de zone tampon de capitalisation.

Les agents et les projets peuvent y déposer des propositions damé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.

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.