mcp: clean tracked artifacts and document rollout

README.md

@@ -21,6 +21,8 @@ Lead_tech est un dépôt de **mémoire technique partagée** : patterns validés
 
 Il est conçu pour fonctionner en tandem avec un copilote IA qui le consulte avant de vous répondre, vous évitant de répéter les mêmes erreurs et de re-expliquer votre contexte à chaque session.
 
+Depuis mars 2026, le repo peut aussi exposer cette doctrine sous forme de **serveur MCP sidecar** pour des workflows BMAD. L'objectif n'est pas de remplacer la lecture des Markdown, mais de rendre la consultation, les gates et la capitalisation actionnables par tool call.
+
 ---
 
 ## Comment ça marche — le modèle mental
@@ -138,6 +140,7 @@ Lead_tech/
 ├── 60_playbooks/           # Procédures opérationnelles réutilisables
 ├── 70_templates/           # Modèles de fichiers (CLAUDE.md projet, patches knowledge…)
 ├── 80_bmad/                # Documentation de l'articulation BMAD ↔ Lead_tech
+├── mcp/                    # Serveurs MCP sidecar et prototypes associés
 ├── scripts/                # Automatisations (sync IA, bootstrap projet, secrets…)
 ├── skills/                 # Skills custom pour Claude Code / Codex
 ├── 10_conventions_redaction.md   # Conventions de documentation technique
@@ -151,6 +154,60 @@ Lead_tech/
 
 ---
 
+## MCP Sidecar BMAD
+
+Le prototype actuel vit dans `mcp/leadtech_bmad_mcp/`.
+
+Il expose deux types de primitives :
+
+- **guidance** : retrouver les patterns, risques et docs globaux pertinents pour une story
+- **gates** : valider un plan, un diff, ou la checklist attendue selon le rôle BMAD
+- **capitalisation** : proposer des ajouts dans `95_a_capitaliser.md` et aider au tri
+- **resources** : lire l'index Lead_tech, les docs globaux, les entrées de connaissance, et les projets actifs
+
+Le positionnement visé est volontairement sobre :
+
+- BMAD garde l'orchestration
+- Lead_tech garde la doctrine
+- le MCP sidecar fournit une couche d'interactivité et de contrôle qualité
+
+Voir :
+
+- `80_bmad/integration_mcp_sidecar.md`
+- `mcp/leadtech_bmad_mcp/README.md`
+
+### Niveau de maturité actuel
+
+Ce sidecar est déjà utile pour un **rollout advisory**.
+
+Il est pertinent dès maintenant pour :
+
+- injecter des patterns/risques en entrée de story
+- faire un contrôle "pré-plan" et "post-patch"
+- sécuriser la capitalisation sans donner un accès d'écriture direct à `knowledge/`
+
+Avant un usage plus strict en production, il est recommandé d'ajouter :
+
+- un score de pertinence plus riche que le simple comptage de tokens
+- des gates paramétrables par domaine critique
+- des métadonnées structurées sur les fichiers `knowledge/`
+- une vraie stratégie de versioning et de compatibilité pour les tools MCP
+
+### Roadmap conseillée
+
+1. Stabiliser le contrat MCP actuel.
+   Geler les noms de tools/resources, formaliser leurs inputs/outputs, et documenter les cas limites.
+2. Ajouter des métadonnées structurées à la base de connaissance.
+   Exemple : `domain`, `bucket`, `tags`, `severity`, `applies_to`, `validated_on`, `source_projects`.
+3. Introduire un index de recherche compilé.
+   Un petit pipeline local qui prépare un index JSON/SQLite sera plus robuste et plus rapide qu'un scan Markdown brut à chaque appel.
+4. Distinguer clairement `advisory` et `enforced gates`.
+   Un mode "conseil" pour l'adoption et un mode "blocant" limité à quelques règles à forte valeur.
+5. Journaliser l'usage.
+   Conserver pour chaque story les tools appelés, leurs recommandations, et la décision humaine associée.
+
+---
+
 ## Pour qui ?
 
 - **Devs solos** qui veulent capitaliser leur expérience et ne plus debugger deux fois le même problème