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

skills/capitalisation-triage/SKILL.md

@@ -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 d’inté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`, l’une 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 l’existence d’un doublon dans la base:
+
+- d’abord dans `target_file`
+- puis dans les fichiers voisins du même domaine (via le `README.md` d’index)
+
+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)
+- s’applique à 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 d’un 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>
+```