Align BMAD paths with new knowledge structure and automate project registry sync

This commit is contained in:
MaksTinyWorkshop
2026-03-28 10:18:24 +01:00
parent 75c3303271
commit 9fe3ad027e
24 changed files with 671 additions and 28 deletions

View File

@@ -0,0 +1,57 @@
# Patch de déplacement — CLAUDE.md projet
Date : <YYYY-MM-DD>
Source : `95_a_capitaliser.md`
Motif : proposition pertinente mais trop spécifique projet
---
## Cible projet
Projet : `<nom_projet>`
Chemin résolu : `</srv/projects/<nom_projet>/CLAUDE.md | chemin attendu>`
Section cible : `<Leçons apprises | Points sensibles | Patterns critiques appliqués dans ce projet>`
Type d'insertion : `<ajout en fin de section | fusion avec item existant | remplacement item obsolète>`
## Texte à intégrer (format conforme CLAUDE.md projet)
### Option A — Leçons apprises (par défaut)
```md
- <apprentissage court, factuel, orienté action>
```
### Option B — Points sensibles (si vigilance continue)
```md
- <zone de risque à surveiller> (<LOW | MEDIUM | HIGH>)
```
### Option C — Pattern critique projet (si règle locale stable)
````md
### <Nom du pattern spécifique projet>
<Règle locale concise + pourquoi elle existe dans ce projet>
```typescript
// exemple minimal (optionnel)
```
````
## Vérification de conformité
- [ ] Rédaction en français
- [ ] Contenu spécifique au projet (pas inter-projets)
- [ ] Formulation exploitable en review future (checklist mentale claire)
- [ ] Pas de conflit avec une règle globale existante
- [ ] Section cible cohérente avec la nature du contenu
- [ ] Style aligné avec le `CLAUDE.md` réel du projet (phrases courtes, concret, zéro théorie)
## Règles d'écriture
- Préférer des bullets courtes et actionnables pour `Leçons apprises` et `Points sensibles`.
- Éviter les paragraphes longs non opérables.
- Mentionner la stack/zone concernée seulement si cela aide la relecture.
- Si une règle est locale à un écran/module précis, conserver le nom technique exact (`route`, `store`, `module`) pour éviter l'ambiguïté.
- Ne pas copier-coller un texte knowledge global tel quel dans le projet; adapter au contexte du repo.

View File

@@ -0,0 +1,22 @@
# Patch d'intégration — Knowledge globale (index)
Date : <YYYY-MM-DD>
Source : `95_a_capitaliser.md`
Mode : intégration manuelle validée
---
## Choix du template selon la cible
- Si la cible est `knowledge/**/patterns/*.md` : utiliser `capitalisation_patch_knowledge_pattern.md`
- Si la cible est `knowledge/**/risques/*.md` : utiliser `capitalisation_patch_knowledge_risque.md`
- Si la cible est un fichier global racine (`10_conventions_redaction.md`, `40_decisions_et_archi.md`, `90_debug_et_postmortem.md`) : adapter le template le plus proche et conserver la checklist de conformité.
---
## Règle de routage rapide
1. Le contenu décrit une pratique recommandée, avec contexte d'usage et limites → `Pattern`
2. Le contenu décrit d'abord un piège, ses symptômes et sa mitigation → `Risque`
En cas de doute, préférer `Risque` pour éviter de promouvoir un pseudo-pattern non stabilisé.

View File

@@ -0,0 +1,57 @@
# Patch d'intégration — Knowledge globale — Pattern
Date : <YYYY-MM-DD>
Source : `95_a_capitaliser.md`
Type : `Pattern`
---
## Cible
Fichier : `<knowledge/<domaine>/patterns/<theme>.md>`
Type de patch : `<ajout | fusion | remplacement>`
## Texte à intégrer (structure de référence)
````md
<a id="pattern-<slug>"></a>
## Pattern : <Nom du pattern>
### Synthèse
- **Objectif** : <résultat recherché>
- **Contexte** : <stack / architecture>
- **Quand l'utiliser** : <cas d'usage>
- **Quand l'éviter** : <limites>
### Analyse
- **Avantages** :
- ...
- **Limites / vigilance** :
- ...
### Validation
- Validé le : <DD-MM-YYYY>
- Contexte technique : <stack> — <projet source> <DD-MM-YYYY>
### Implémentation (exemple minimal)
```typescript
// exemple concret court
```
### Checklist
- [ ] <critère de vérification 1>
- [ ] <critère de vérification 2>
````
## Vérification de conformité
- [ ] Le contenu décrit un pattern réutilisable inter-projets
- [ ] Structure alignée avec les patterns existants (`Synthèse`, `Analyse`, `Validation`, `Implémentation`, `Checklist`)
- [ ] Exemples concrets, pas de théorie vague
- [ ] Terminologie alignée avec le fichier cible
- [ ] Pas de doublon exact ou sémantique

View File

@@ -0,0 +1,44 @@
# Patch d'intégration — Knowledge globale — Risque
Date : <YYYY-MM-DD>
Source : `95_a_capitaliser.md`
Type : `Risque`
---
## Cible
Fichier : `<knowledge/<domaine>/risques/<theme>.md>`
Type de patch : `<ajout | fusion | remplacement>`
## Texte à intégrer (structure de référence)
```md
<a id="risque-<slug>"></a>
## <Titre du risque>
### Risques
- <risque principal>
- <impact concret>
### Symptômes
- <signal observable 1>
- <signal observable 2>
### Bonnes pratiques / mitigations
- <mitigation actionnable 1>
- <mitigation actionnable 2>
- Contexte technique : <stack> — <projet source> <DD-MM-YYYY>
```
## Vérification de conformité
- [ ] Le contenu documente d'abord un piège (pas un pattern prescriptif)
- [ ] Structure alignée avec les risques existants (`Risques`, `Symptômes`, `Bonnes pratiques / mitigations`)
- [ ] Mitigations testables en review/dev
- [ ] Terminologie alignée avec le fichier cible
- [ ] Pas de doublon exact ou sémantique

View File

@@ -0,0 +1,62 @@
# Rapport de tri — 95_a_capitaliser.md
Date d'analyse : <YYYY-MM-DD>
Analysé par : <agent>
Source : `95_a_capitaliser.md`
---
## Résumé
- Total propositions : <N>
- `INTEGRER_KNOWLEDGE` : <N>
- `A_DEPLACER_CLAUDE_PROJET` : <N>
- `REJETER` : <N>
---
## Détail par proposition
### <DATE — PROJET> — <titre court>
Décision : <INTEGRER_KNOWLEDGE | A_DEPLACER_CLAUDE_PROJET | REJETER>
Confiance : <HIGH | MEDIUM | LOW>
Justification :
- Nouveauté : <DOUBLON_EXACT | DOUBLON_SEMANTIQUE | COMPLEMENT | NOUVEAU>
- Portée : <GLOBAL | PROJET>
- Motif principal : <1 phrase>
Action proposée :
- Si `INTEGRER_KNOWLEDGE` :
- Fichier : `<knowledge/... .md>`
- Patch logique : `<ajout | fusion | remplacement>`
- Texte final proposé :
```md
## <Titre>
<Rédaction finale courte, factuelle, orientée mitigation>
```
- Si `A_DEPLACER_CLAUDE_PROJET` :
- Projet : `<nom_projet>`
- Fichier : `</srv/projects/<nom>/CLAUDE.md ou chemin attendu>`
- Section : `<Leçons apprises | Points sensibles>`
- Texte final proposé :
```md
- <Leçon projet concise et actionnable>
```
- Si `REJETER` :
- Raison : `<doublon | bruit | non actionnable>`
---
## Choix d'action
1. Suivre les recommandations : intégrer les entrées retenues + purger `95_a_capitaliser.md` pour les éléments traités.
2. Ajuster avant intégration : appliquer les modifications demandées puis proposer une version finale.
3. N'intégrer que les entrées `INTEGRER_KNOWLEDGE`.
4. N'intégrer aucune entrée : conserver le rapport uniquement.

View File

@@ -59,12 +59,12 @@ architecture, les agents DOIVENT lire les fichiers Lead_tech correspondants.
| Type de tâche | Fichiers à lire en priorité | | Type de tâche | Fichiers à lire en priorité |
| ----------------------- | --------------------------------------------------------------------------------- | | ----------------------- | --------------------------------------------------------------------------------- |
| Backend (API, services) | `10_backend_patterns_valides.md`, `10_backend_risques_et_vigilance.md` | | Backend (API, services) | `knowledge/backend/patterns/README.md`, `knowledge/backend/risques/README.md` |
| Frontend / mobile | `10_frontend_patterns_valides.md`, `10_frontend_risques_et_vigilance.md` | | Frontend / mobile | `knowledge/frontend/patterns/README.md`, `knowledge/frontend/risques/README.md` |
| UX / design | `10_ux_patterns_valides.md`, `10_ux_risques_et_vigilance.md` | | UX / design | `knowledge/ux/patterns/README.md`, `knowledge/ux/risques/README.md` |
| Architecture / design | `40_decisions_et_archi.md` | | Architecture / design | `40_decisions_et_archi.md` |
| Debug / investigation | `90_debug_et_postmortem.md` | | Debug / investigation | `90_debug_et_postmortem.md` |
| n8n / automatisations | `10_n8n_patterns_valides.md`, `10_n8n_nodes_a_risques.md` | | n8n / automatisations | `knowledge/n8n/patterns/README.md`, `knowledge/n8n/risques/README.md` |
Règle : **si un pattern Lead_tech existe et couvre le besoin, l'appliquer Règle : **si un pattern Lead_tech existe et couvre le besoin, l'appliquer
directement sans réinventer**. directement sans réinventer**.
@@ -88,9 +88,7 @@ Ils y contribuent activement en remontant les apprentissages.
Le fichier cible pour toutes les propositions est : Le fichier cible pour toutes les propositions est :
``` `$LEADTECH/95_a_capitaliser.md`
$LEADTECH/95_a_capitaliser.md
```
`$LEADTECH` est une variable d'environnement définie automatiquement sur Mac `$LEADTECH` est une variable d'environnement définie automatiquement sur Mac
et sur le NUC via `scripts/aliases.sh`. Elle pointe vers le repo Lead_tech et sur le NUC via `scripts/aliases.sh`. Elle pointe vers le repo Lead_tech
@@ -125,7 +123,7 @@ Un apprentissage mérite d'être remonté si :
DATE — PROJET DATE — PROJET
FILE_UPDATE_PROPOSAL FILE_UPDATE_PROPOSAL
Fichier cible : <10_backend_patterns_valides.md | 10_frontend_patterns_valides.md | 10_ux_patterns_valides.md | 10_backend_risques_et_vigilance.md | 10_frontend_risques_et_vigilance.md | 10_ux_risques_et_vigilance.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md> Fichier cible : <knowledge/backend/patterns/<theme>.md | knowledge/backend/risques/<theme>.md | knowledge/frontend/patterns/<theme>.md | knowledge/frontend/risques/<theme>.md | knowledge/ux/patterns/<theme>.md | knowledge/ux/risques/<theme>.md | knowledge/n8n/patterns/general.md | knowledge/n8n/risques/general.md | knowledge/product/patterns/general.md | knowledge/product/risques/<theme>.md | knowledge/workflow/risques/story-tracking.md | 10_conventions_redaction.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md>
Pourquoi : Pourquoi :
<raison en 1-2 phrases> <raison en 1-2 phrases>
@@ -140,7 +138,7 @@ Exemple :
2026-03-08 — app-alexandrie 2026-03-08 — app-alexandrie
FILE_UPDATE_PROPOSAL FILE_UPDATE_PROPOSAL
Fichier cible : 10_backend_patterns_valides.md Fichier cible : knowledge/backend/patterns/nestjs.md
Pourquoi : Pourquoi :
L'ordre d'enregistrement des guards NestJS a causé request.user undefined L'ordre d'enregistrement des guards NestJS a causé request.user undefined
@@ -156,7 +154,7 @@ qui lit request.user.
Les agents peuvent **écrire librement** dans `95_a_capitaliser.md`. Les agents peuvent **écrire librement** dans `95_a_capitaliser.md`.
Ils ne doivent **jamais écrire directement** dans les fichiers de connaissance Ils ne doivent **jamais écrire directement** dans les fichiers de connaissance
validée (`10_*`, `40_*`, `90_*`). validée (`knowledge/*`, `10_*`, `40_*`, `90_*`).
La validation et l'intégration finale sont faites **par le développeur**. La validation et l'intégration finale sont faites **par le développeur**.

View File

@@ -18,7 +18,7 @@ critical_actions: []
# Add persistent memories for the agent # Add persistent memories for the agent
memories: memories:
- "When a reusable analysis pattern, requirements anti-pattern, or domain insight emerges, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <10_product_patterns_valides.md | 10_backend_patterns_valides.md | 40_decisions_et_archi.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files." - "When a reusable analysis pattern, requirements anti-pattern, or domain insight emerges, write a proposal to $LEADTECH/95_a_capitaliser.md (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <knowledge/product/patterns/general.md | knowledge/product/risques/<theme>.md | knowledge/backend/patterns/<theme>.md | 40_decisions_et_archi.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
# Example: # Example:
# memories: # memories:
# - "User prefers detailed technical explanations" # - "User prefers detailed technical explanations"

View File

@@ -18,7 +18,7 @@ critical_actions: []
# Add persistent memories for the agent # Add persistent memories for the agent
memories: memories:
- "When a reusable pattern, difficult bug fix, anti-pattern, or architecture decision emerges during architecture or technical design, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <40_decisions_et_archi.md | 10_backend_patterns_valides.md | 10_backend_risques_et_vigilance.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files." - "When a reusable pattern, difficult bug fix, anti-pattern, or architecture decision emerges during architecture or technical design, write a proposal to $LEADTECH/95_a_capitaliser.md (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <40_decisions_et_archi.md | knowledge/backend/patterns/<theme>.md | knowledge/backend/risques/<theme>.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
# Example: # Example:
# memories: # memories:
# - "User prefers detailed technical explanations" # - "User prefers detailed technical explanations"

View File

@@ -14,11 +14,12 @@ persona:
principles: [] principles: []
# Add custom critical actions (appended after standard config loading) # Add custom critical actions (appended after standard config loading)
critical_actions: [] critical_actions:
- "Before any development task, run: `bash $LEADTECH/scripts/sync-projects-conf.sh --project-root {project-root} --sync-existing`"
# Add persistent memories for the agent # Add persistent memories for the agent
memories: memories:
- "When a reusable pattern, difficult bug fix, anti-pattern, or architecture decision emerges during implementation, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <10_backend_patterns_valides.md | 10_frontend_patterns_valides.md | 10_backend_risques_et_vigilance.md | 10_frontend_risques_et_vigilance.md | 90_debug_et_postmortem.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files." - "When a reusable pattern, difficult bug fix, anti-pattern, or architecture decision emerges during implementation, write a proposal to $LEADTECH/95_a_capitaliser.md (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <knowledge/backend/patterns/<theme>.md | knowledge/frontend/patterns/<theme>.md | knowledge/backend/risques/<theme>.md | knowledge/frontend/risques/<theme>.md | 90_debug_et_postmortem.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
# Example: # Example:
# memories: # memories:
# - "User prefers detailed technical explanations" # - "User prefers detailed technical explanations"

View File

@@ -18,7 +18,7 @@ critical_actions: []
# Add persistent memories for the agent # Add persistent memories for the agent
memories: memories:
- "When a product decision, prioritization pattern, or recurring friction is identified, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <10_product_patterns_valides.md | 40_decisions_et_archi.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files." - "When a product decision, prioritization pattern, or recurring friction is identified, write a proposal to $LEADTECH/95_a_capitaliser.md (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <knowledge/product/patterns/general.md | knowledge/product/risques/<theme>.md | 40_decisions_et_archi.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
# Example: # Example:
# memories: # memories:
# - "User prefers detailed technical explanations" # - "User prefers detailed technical explanations"

View File

@@ -14,11 +14,12 @@ persona:
principles: [] principles: []
# Add custom critical actions (appended after standard config loading) # Add custom critical actions (appended after standard config loading)
critical_actions: [] critical_actions:
- "Before any QA/review/test task, run: `bash $LEADTECH/scripts/sync-projects-conf.sh --project-root {project-root} --sync-existing`"
# Add persistent memories for the agent # Add persistent memories for the agent
memories: memories:
- "When a reusable test pattern, tricky bug, or quality anti-pattern is identified, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <target file> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files." - "When a reusable test pattern, tricky bug, or quality anti-pattern is identified, write a proposal to $LEADTECH/95_a_capitaliser.md (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <knowledge/frontend/patterns/tests.md | knowledge/frontend/risques/tests.md | knowledge/workflow/risques/story-tracking.md | 90_debug_et_postmortem.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
# Example: # Example:
# memories: # memories:
# - "User prefers detailed technical explanations" # - "User prefers detailed technical explanations"

View File

@@ -14,11 +14,12 @@ persona:
principles: [] principles: []
# Add custom critical actions (appended after standard config loading) # Add custom critical actions (appended after standard config loading)
critical_actions: [] critical_actions:
- "Before any implementation task, run: `bash $LEADTECH/scripts/sync-projects-conf.sh --project-root {project-root} --sync-existing`"
# Add persistent memories for the agent # Add persistent memories for the agent
memories: memories:
- "When a reusable pattern, difficult bug fix, anti-pattern, or architecture decision emerges during implementation, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <10_backend_patterns_valides.md | 10_frontend_patterns_valides.md | 10_backend_risques_et_vigilance.md | 10_frontend_risques_et_vigilance.md | 90_debug_et_postmortem.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files." - "When a reusable pattern, difficult bug fix, anti-pattern, or architecture decision emerges during implementation, write a proposal to $LEADTECH/95_a_capitaliser.md (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <knowledge/backend/patterns/<theme>.md | knowledge/frontend/patterns/<theme>.md | knowledge/backend/risques/<theme>.md | knowledge/frontend/risques/<theme>.md | 90_debug_et_postmortem.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
# Example: # Example:
# memories: # memories:
# - "User prefers detailed technical explanations" # - "User prefers detailed technical explanations"

View File

@@ -18,7 +18,7 @@ critical_actions: []
# Add persistent memories for the agent # Add persistent memories for the agent
memories: memories:
- "When a process improvement, recurring friction, or architecture decision emerges during sprint work, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <target file> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files." - "When a process improvement, recurring friction, or architecture decision emerges during sprint work, write a proposal to $LEADTECH/95_a_capitaliser.md (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <knowledge/workflow/risques/story-tracking.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
# Example: # Example:
# memories: # memories:
# - "User prefers detailed technical explanations" # - "User prefers detailed technical explanations"

View File

@@ -18,7 +18,7 @@ critical_actions: []
# Add persistent memories for the agent # Add persistent memories for the agent
memories: memories:
- "When a reusable documentation pattern, writing convention, or recurring documentation friction emerges, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <10_conventions_redaction.md | 40_decisions_et_archi.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files." - "When a reusable documentation pattern, writing convention, or recurring documentation friction emerges, write a proposal to $LEADTECH/95_a_capitaliser.md (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <10_conventions_redaction.md | 40_decisions_et_archi.md | knowledge/workflow/risques/story-tracking.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
# Example: # Example:
# memories: # memories:
# - "User prefers detailed technical explanations" # - "User prefers detailed technical explanations"

View File

@@ -18,7 +18,7 @@ critical_actions: []
# Add persistent memories for the agent # Add persistent memories for the agent
memories: memories:
- "When a reusable UX/UI pattern, interaction anti-pattern, or UX decision emerges, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <10_ux_patterns_valides.md | 10_ux_risques_et_vigilance.md | 40_decisions_et_archi.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files." - "When a reusable UX/UI pattern, interaction anti-pattern, or UX decision emerges, write a proposal to $LEADTECH/95_a_capitaliser.md (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <knowledge/ux/patterns/<theme>.md | knowledge/ux/risques/<theme>.md | 40_decisions_et_archi.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
# Example: # Example:
# memories: # memories:
# - "User prefers detailed technical explanations" # - "User prefers detailed technical explanations"

View File

@@ -18,7 +18,7 @@ critical_actions: []
# Add persistent memories for the agent # Add persistent memories for the agent
memories: memories:
- "As the orchestrating agent, when any cross-cutting pattern, process improvement, recurring friction, or architectural decision emerges across the project, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <10_backend_patterns_valides.md | 10_frontend_patterns_valides.md | 10_product_patterns_valides.md | 10_ux_patterns_valides.md | 10_backend_risques_et_vigilance.md | 10_frontend_risques_et_vigilance.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files." - "As the orchestrating agent, when any cross-cutting pattern, process improvement, recurring friction, or architectural decision emerges across the project, write a proposal to $LEADTECH/95_a_capitaliser.md (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <knowledge/backend/patterns/<theme>.md | knowledge/frontend/patterns/<theme>.md | knowledge/product/patterns/general.md | knowledge/ux/patterns/<theme>.md | knowledge/backend/risques/<theme>.md | knowledge/frontend/risques/<theme>.md | knowledge/product/risques/<theme>.md | knowledge/ux/risques/<theme>.md | knowledge/workflow/risques/story-tracking.md | 10_conventions_redaction.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
# Example: # Example:
# memories: # memories:
# - "User prefers detailed technical explanations" # - "User prefers detailed technical explanations"

View File

@@ -18,7 +18,7 @@ critical_actions: []
# Add persistent memories for the agent # Add persistent memories for the agent
memories: memories:
- "When a reusable test pattern, tricky bug, or quality anti-pattern is identified, write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md (NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <target file> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files." - "When a reusable test pattern, tricky bug, or quality anti-pattern is identified, write a proposal to $LEADTECH/95_a_capitaliser.md (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <knowledge/frontend/patterns/tests.md | knowledge/frontend/risques/tests.md | knowledge/backend/risques/general.md | knowledge/workflow/risques/story-tracking.md | 90_debug_et_postmortem.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
# Example: # Example:
# memories: # memories:
# - "User prefers detailed technical explanations" # - "User prefers detailed technical explanations"

View File

@@ -13,9 +13,12 @@
<critical>Tasks marked complete but not done = CRITICAL finding</critical> <critical>Tasks marked complete but not done = CRITICAL finding</critical>
<critical>Acceptance Criteria not implemented = HIGH severity finding</critical> <critical>Acceptance Criteria not implemented = HIGH severity finding</critical>
<critical>Do not review files that are not part of the application's source code. Always exclude the _bmad/ and _bmad-output/ folders from the review. Always exclude IDE and CLI configuration folders like .cursor/ and .windsurf/ and .claude/</critical> <critical>Do not review files that are not part of the application's source code. Always exclude the _bmad/ and _bmad-output/ folders from the review. Always exclude IDE and CLI configuration folders like .cursor/ and .windsurf/ and .claude/</critical>
<critical>Before starting review, synchronize Lead_tech project registry via: `bash $LEADTECH/scripts/sync-projects-conf.sh --project-root {project-root} --sync-existing`.</critical>
<step n="1" goal="Load story and discover changes"> <step n="1" goal="Load story and discover changes">
<action>Run: `bash $LEADTECH/scripts/sync-projects-conf.sh --project-root {project-root} --sync-existing`</action>
<action if="sync command fails">Output warning and continue review if repository state is still analyzable.</action>
<action>Use provided {{story_path}} or ask user which story file to review</action> <action>Use provided {{story_path}} or ask user which story file to review</action>
<action>Read COMPLETE story file</action> <action>Read COMPLETE story file</action>
<action>Set {{story_key}} = extracted key from filename (e.g., "1-2-user-authentication.md" → "1-2-user-authentication") or story <action>Set {{story_key}} = extracted key from filename (e.g., "1-2-user-authentication.md" → "1-2-user-authentication") or story
@@ -229,7 +232,7 @@
Review all findings for: anti-patterns found, recurring issues, architecture decisions confirmed or invalidated during this review. Review all findings for: anti-patterns found, recurring issues, architecture decisions confirmed or invalidated during this review.
</output> </output>
<action>For EACH candidate (aim for 1-3): write a proposal to ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ONLY — NEVER inside the project repo. FORMAT = "DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: &lt;target&gt; / Pourquoi: &lt;reason&gt; / Proposition: &lt;content&gt;"</action> <action>For EACH candidate (aim for 1-3): write a proposal to $LEADTECH/95_a_capitaliser.md ONLY (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md) — NEVER inside the project repo. FORMAT = "DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: &lt;knowledge/backend/patterns/&lt;theme&gt;.md | knowledge/backend/risques/&lt;theme&gt;.md | knowledge/frontend/patterns/&lt;theme&gt;.md | knowledge/frontend/risques/&lt;theme&gt;.md | knowledge/ux/patterns/&lt;theme&gt;.md | knowledge/ux/risques/&lt;theme&gt;.md | knowledge/n8n/patterns/general.md | knowledge/n8n/risques/general.md | knowledge/product/patterns/general.md | knowledge/product/risques/&lt;theme&gt;.md | knowledge/workflow/risques/story-tracking.md | 10_conventions_redaction.md | 40_decisions_et_archi.md | 90_debug_et_postmortem.md&gt; / Pourquoi: &lt;reason&gt; / Proposition: &lt;content&gt;"</action>
<action if="nothing worth capitalizing">Output explicitly: "Rien à capitaliser pour cette review." — do NOT skip silently</action> <action if="nothing worth capitalizing">Output explicitly: "Rien à capitaliser pour cette review." — do NOT skip silently</action>
</step> </step>

View File

@@ -11,8 +11,11 @@
other instruction.</critical> other instruction.</critical>
<critical>Do NOT schedule a "next session" or request review pauses unless a HALT condition applies. Only Step 6 decides completion.</critical> <critical>Do NOT schedule a "next session" or request review pauses unless a HALT condition applies. Only Step 6 decides completion.</critical>
<critical>User skill level ({user_skill_level}) affects conversation style ONLY, not code updates.</critical> <critical>User skill level ({user_skill_level}) affects conversation style ONLY, not code updates.</critical>
<critical>Before any implementation work, synchronize Lead_tech project registry via: `bash $LEADTECH/scripts/sync-projects-conf.sh --project-root {project-root} --sync-existing`.</critical>
<step n="1" goal="Find next ready story and load it" tag="sprint-status"> <step n="1" goal="Find next ready story and load it" tag="sprint-status">
<action>Run: `bash $LEADTECH/scripts/sync-projects-conf.sh --project-root {project-root} --sync-existing`</action>
<action if="sync command fails">Output warning and continue only if story work can proceed safely.</action>
<check if="{{story_path}} is provided"> <check if="{{story_path}} is provided">
<action>Use {{story_path}} directly</action> <action>Use {{story_path}} directly</action>
<action>Read COMPLETE story file</action> <action>Read COMPLETE story file</action>

View File

@@ -6,6 +6,16 @@
## Instructions ## Instructions
### Step -1: Sync Lead_tech project registry
Before any test generation work, run:
```bash
bash $LEADTECH/scripts/sync-projects-conf.sh --project-root {project-root} --sync-existing
```
If the command fails, report the warning and continue only if test generation can proceed safely.
### Step 0: Detect Test Framework ### Step 0: Detect Test Framework
Check project for existing test framework: Check project for existing test framework:

View File

@@ -63,7 +63,7 @@ resolve_base_path() {
esac esac
} }
while IFS='|' read -r name stack scope state; do while IFS='|' read -r name stack scope state || [ -n "${name:-}" ]; do
[[ -z "$name" || "$name" == \#* ]] && continue [[ -z "$name" || "$name" == \#* ]] && continue
if [ "$name" = "$PROJECT_NAME" ]; then if [ "$name" = "$PROJECT_NAME" ]; then

212
scripts/sync-projects-conf.sh Executable file
View File

@@ -0,0 +1,212 @@
#!/usr/bin/env bash
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
LEADTECH_ROOT="${LEADTECH:-$(cd "$SCRIPT_DIR/.." && pwd)}"
PROJECTS_CONF="${PROJECTS_CONF:-$LEADTECH_ROOT/_projects.conf}"
PROJECT_ROOT=""
PROJECT_NAME=""
STACK_OVERRIDE=""
SCOPE_OVERRIDE=""
STATE_OVERRIDE=""
SYNC_EXISTING="false"
usage() {
cat <<USAGE
Usage: sync-projects-conf.sh [options]
Options:
--project-root <path> Project root directory (default: current directory)
--project-name <name> Project name override (default: basename project-root)
--stack <value> Stack override
--scope <value> Scope override (perso|mindleaf|lab|archive)
--state <value> State override
--sync-existing Update existing line (safe mode: preserve scope/state unless explicit override)
-h, --help Show help
USAGE
}
while [ $# -gt 0 ]; do
case "$1" in
--project-root)
PROJECT_ROOT="$2"
shift 2
;;
--project-name)
PROJECT_NAME="$2"
shift 2
;;
--stack)
STACK_OVERRIDE="$2"
shift 2
;;
--scope)
SCOPE_OVERRIDE="$2"
shift 2
;;
--state)
STATE_OVERRIDE="$2"
shift 2
;;
--sync-existing)
SYNC_EXISTING="true"
shift
;;
-h|--help)
usage
exit 0
;;
*)
echo "Erreur: option inconnue: $1" >&2
usage >&2
exit 1
;;
esac
done
PROJECT_ROOT="${PROJECT_ROOT:-$PWD}"
if [ ! -d "$PROJECT_ROOT" ]; then
echo "Erreur: project-root introuvable: $PROJECT_ROOT" >&2
exit 1
fi
if [ ! -f "$PROJECTS_CONF" ]; then
echo "Erreur: _projects.conf introuvable: $PROJECTS_CONF" >&2
exit 1
fi
trim() {
local s="$1"
# shellcheck disable=SC2001
s="$(echo "$s" | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//')"
printf '%s' "$s"
}
infer_stack() {
local root="$1"
local out=()
if [ -f "$root/pnpm-workspace.yaml" ]; then
out+=("pnpm monorepo")
fi
if [ -f "$root/package.json" ]; then
if grep -Eq '"@nestjs/' "$root/package.json"; then out+=("NestJS"); fi
if grep -Eq '"next"' "$root/package.json"; then out+=("Next.js"); fi
if grep -Eq '"expo"' "$root/package.json"; then out+=("Expo"); fi
if grep -Eq '"react-native"' "$root/package.json"; then out+=("React Native"); fi
if grep -Eq '"prisma"|"@prisma/' "$root/package.json"; then out+=("Prisma"); fi
fi
if [ -f "$root/prisma/schema.prisma" ] && grep -qi 'provider *= *"postgresql"' "$root/prisma/schema.prisma"; then
out+=("PostgreSQL")
fi
if [ -f "$root/CLAUDE.md" ]; then
local from_claude
from_claude="$(awk '
BEGIN {in_stack=0}
/^## Stack/ {in_stack=1; next}
/^## / {if (in_stack) exit}
in_stack && /^- / {sub(/^- /, ""); print}
' "$root/CLAUDE.md" | paste -sd ' + ' -)"
from_claude="$(trim "$from_claude")"
if [ -n "$from_claude" ]; then
printf '%s' "$from_claude"
return
fi
fi
if [ ${#out[@]} -eq 0 ]; then
printf '%s' "stack-a-completer"
else
local joined
joined="$(printf '%s\n' "${out[@]}" | awk '!seen[$0]++' | paste -sd ' + ' -)"
printf '%s' "$joined"
fi
}
infer_scope() {
local root="$1"
case "$root" in
*"/__Mindleaf/"*) printf '%s' "mindleaf" ;;
*"/Labs/"*) printf '%s' "lab" ;;
*"/Archives_Projets/"*) printf '%s' "archive" ;;
*) printf '%s' "perso" ;;
esac
}
PROJECT_NAME="${PROJECT_NAME:-$(basename "$PROJECT_ROOT")}"
STACK_INFERRED="$(infer_stack "$PROJECT_ROOT")"
SCOPE_INFERRED="$(infer_scope "$PROJECT_ROOT")"
STACK="${STACK_OVERRIDE:-$STACK_INFERRED}"
SCOPE="${SCOPE_OVERRIDE:-$SCOPE_INFERRED}"
STATE="${STATE_OVERRIDE:-dev}"
if ! [[ "$SCOPE" =~ ^(perso|mindleaf|lab|archive)$ ]]; then
echo "Erreur: scope invalide '$SCOPE' (attendu: perso|mindleaf|lab|archive)" >&2
exit 1
fi
if grep -q "^${PROJECT_NAME}|" "$PROJECTS_CONF"; then
if [ "$SYNC_EXISTING" != "true" ]; then
echo "OK: projet déjà présent dans _projects.conf: $PROJECT_NAME"
exit 0
fi
existing_line="$(grep "^${PROJECT_NAME}|" "$PROJECTS_CONF" | head -n 1)"
IFS='|' read -r _ existing_stack existing_scope existing_state <<EOF
$existing_line
EOF
# Safe sync defaults for existing entries:
# - stack: preserve existing unless explicit override, or existing is placeholder
# - scope/state: keep existing unless explicitly overridden
if [ -n "$STACK_OVERRIDE" ]; then
TARGET_STACK="$STACK_OVERRIDE"
elif [ -z "$existing_stack" ] || [ "$existing_stack" = "stack-a-completer" ]; then
if [ "$STACK_INFERRED" = "stack-a-completer" ] || [ -z "$STACK_INFERRED" ]; then
TARGET_STACK="$existing_stack"
else
TARGET_STACK="$STACK_INFERRED"
fi
else
TARGET_STACK="$existing_stack"
fi
if [ -n "$SCOPE_OVERRIDE" ]; then
TARGET_SCOPE="$SCOPE_OVERRIDE"
else
TARGET_SCOPE="$existing_scope"
fi
if [ -n "$STATE_OVERRIDE" ]; then
TARGET_STATE="$STATE_OVERRIDE"
else
TARGET_STATE="$existing_state"
fi
if ! [[ "$TARGET_SCOPE" =~ ^(perso|mindleaf|lab|archive)$ ]]; then
echo "Erreur: scope invalide '$TARGET_SCOPE' (attendu: perso|mindleaf|lab|archive)" >&2
exit 1
fi
tmp="$(mktemp)"
awk -F'|' -v OFS='|' -v n="$PROJECT_NAME" -v st="$TARGET_STACK" -v sc="$TARGET_SCOPE" -v et="$TARGET_STATE" '
$0 ~ /^#/ || NF < 4 { print; next }
$1 == n { print $1, st, sc, et; next }
{ print }
' "$PROJECTS_CONF" > "$tmp"
mv "$tmp" "$PROJECTS_CONF"
echo "OK: projet synchronisé dans _projects.conf: $PROJECT_NAME"
exit 0
fi
last_char="$(tail -c 1 "$PROJECTS_CONF" 2>/dev/null || true)"
if [ -n "$last_char" ]; then
echo >> "$PROJECTS_CONF"
fi
printf '%s|%s|%s|%s\n' "$PROJECT_NAME" "$STACK" "$SCOPE" "$STATE" >> "$PROJECTS_CONF"
echo "OK: projet ajouté à _projects.conf: $PROJECT_NAME"

View File

@@ -0,0 +1,172 @@
---
name: capitalisation-triage
description: Analyse et trie les propositions de `95_a_capitaliser.md` pour décider si elles doivent être intégrées dans la base globale `Lead_tech` ou déplacées vers le `CLAUDE.md` du projet source. Utiliser ce skill quand il faut: (1) détecter les doublons avec `knowledge/`, (2) filtrer ce qui est réellement global et réutilisable, (3) préparer des propositions dintégration propres par fichier cible, et (4) router les apprentissages trop spécifiques vers la mémoire projet.
---
# Objectif
Décider, pour chaque `FILE_UPDATE_PROPOSAL` de `95_a_capitaliser.md`, lune des issues suivantes:
- `INTEGRER_KNOWLEDGE`: à intégrer dans `knowledge/` ou un fichier global racine
- `A_DEPLACER_CLAUDE_PROJET`: pertinent mais trop spécifique au projet
- `REJETER`: bruit, redondance, ou formulation non exploitable
# Entrées à lire systématiquement
1. `95_a_capitaliser.md`
2. `knowledge/<domaine>/(patterns|risques)/README.md` correspondant au sujet
3. Le fichier cible indiqué dans chaque proposition
4. `_projects.conf`
5. `70_templates/projet_CLAUDE.md`
6. `10_conventions_redaction.md`
# Workflow opératoire
1. Extraire les blocs `FILE_UPDATE_PROPOSAL` de `95_a_capitaliser.md`.
2. Pour chaque bloc, identifier:
- `project_name`
- `target_file`
- idée centrale (1 phrase)
- signal technique principal (bug, anti-pattern, pattern, décision)
3. Vérifier lexistence dun doublon dans la base:
- dabord dans `target_file`
- puis dans les fichiers voisins du même domaine (via le `README.md` dindex)
4. Classer le niveau de nouveauté:
- `DOUBLON_EXACT`: déjà documenté explicitement
- `DOUBLON_SEMANTIQUE`: même règle exprimée autrement
- `COMPLEMENT`: ajoute une nuance utile à une règle existante
- `NOUVEAU`: absent de la base
5. Évaluer la portée:
- `GLOBAL`: réutilisable inter-projets
- `PROJET`: dépend trop du contexte local
6. Décider le routage final (`INTEGRER_KNOWLEDGE`, `A_DEPLACER_CLAUDE_PROJET`, `REJETER`).
7. Reformuler tous les textes retenus pour respecter les conventions de rédaction actives.
# Règles de décision (obligatoires)
## 1) Filtre doublon (priorité absolue)
Si `DOUBLON_EXACT` ou `DOUBLON_SEMANTIQUE` sans nouvelle mitigation concrète: `REJETER`.
Si doublon partiel avec amélioration exploitable (ex: condition manquante, contre-exemple utile): `COMPLEMENT` possible vers `INTEGRER_KNOWLEDGE`.
## 2) Test de globalité
Classer `GLOBAL` seulement si la proposition respecte au moins 3 critères:
- décrit un mécanisme technique générique (pas une feature nommée)
- sapplique à plusieurs repos/projets du même stack
- reste valable hors contexte temporel local
- réduit clairement un risque de bug/régression
- propose une mitigation actionnable en review/dev
Sinon classer `PROJET`.
## 3) Routage des infos spécifiques
Si `PROJET` mais pertinent: router vers `CLAUDE.md` du projet source, section:
- `Leçons apprises` (par défaut)
- ou `Points sensibles` si risque récurrent et critique
Résoudre le chemin projet via `_projects.conf`.
Sur Linux NUC, destination attendue: `/srv/projects/<project_name>/CLAUDE.md`.
Sur macOS, destination attendue: `/Volumes/TeraSSD/Projets_Dev/<project_name>/CLAUDE.md`, ou demander une confirmation si le projet est introuvable.
Si le projet est introuvable ou sans `CLAUDE.md`, produire une proposition prête à coller et le signaler explicitement.
# Heuristiques de spécificité projet
Indicateurs forts `PROJET`:
- noms de routes, écrans, composants, modules internes nommés
- dépendance à une version précise dun outil non généralisée
- wording produit/UI local (langue, copy, labels métier)
- apprentissage valable uniquement pour une architecture locale
Indicateurs forts `GLOBAL`:
- piège structurel du framework
- invariant de robustesse (erreur, contrat, navigation, session, etc.)
- règle de validation applicable en code review partout
# Conformité rédactionnelle (obligatoire avant proposition finale)
Avant de proposer l'intégration effective:
- Vérifier la langue: documentation en français, identifiants de code en anglais.
- Respecter la structure du fichier cible (sections, style, niveau de détail).
- Préférer une rédaction factuelle, courte, orientée risque/mitigation.
- Éviter les formulations vagues ou non testables.
- Harmoniser le vocabulaire avec les entrées déjà présentes dans le fichier cible.
# Format de sortie attendu
Retourner un rapport court avec un bloc par proposition:
```md
## <DATE — PROJET> — <titre court>
Décision : <INTEGRER_KNOWLEDGE | A_DEPLACER_CLAUDE_PROJET | REJETER>
Confiance : <HIGH | MEDIUM | LOW>
Justification :
- Nouveauté : <DOUBLON_EXACT | DOUBLON_SEMANTIQUE | COMPLEMENT | NOUVEAU>
- Portée : <GLOBAL | PROJET>
- Motif principal : <1 phrase>
Action proposée :
- Si INTEGRER_KNOWLEDGE :
- Fichier : <chemin exact>
- Patch logique : <ajout/remplacement/fusion>
- Texte final proposé : <version courte prête à intégrer>
- Si A_DEPLACER_CLAUDE_PROJET :
- Projet : <nom>
- Fichier : <chemin CLAUDE.md résolu ou attendu>
- Section : <Leçons apprises | Points sensibles>
- Texte final proposé : <version projet>
- Si REJETER :
- Raison : <doublon/bruit/non-actionnable>
```
# Contraintes de qualité
- Ne jamais inventer un fichier cible absent de la taxonomie Lead_tech.
- Ne jamais promouvoir en global une règle purement locale.
- Préférer une reformulation courte, testable, orientée mitigation.
- Si une proposition est mal formulée mais utile, la réécrire au lieu de la rejeter.
# Sortie décisionnelle utilisateur (obligatoire)
Après le rapport de tri, toujours proposer un menu d'action:
```md
Choix d'action :
1. Suivre les recommandations : intégrer les entrées retenues + purger `95_a_capitaliser.md` pour les éléments traités.
2. Ajuster avant intégration : appliquer mes modifications sur les entrées ciblées, puis me re-soumettre la version finale.
3. N'intégrer que les entrées `INTEGRER_KNOWLEDGE` (sans déplacement projet pour l'instant).
4. N'intégrer aucune entrée : conserver le rapport uniquement.
```
Si l'utilisateur choisit l'option 2, demander les modifications ciblées et réémettre une proposition consolidée avant tout patch.
# Commandes utiles (optionnel)
```bash
# lire la base en ciblant le domaine
find knowledge -maxdepth 3 -type f | sort
# ouvrir le fichier projet depuis son nom
scripts/resolve-project-path.sh <project_name>
```