Le registre listait "app-rl799" mais le dossier disque, le repo GitHub
(RL799_V2.git), le worktree actif et l'usage courant utilisent tous "RL799_V2".
Le renommage "app-rl799" n'avait été répercuté nulle part → resolve-project-path.sh
retournait un chemin inexistant pour ce projet.
Correction: app-rl799 → RL799_V2 dans _projects.conf (aligne le registre sur la
réalité, sans toucher au dossier/repo). Les 3 projets résolvent maintenant correctement.
Bug: bmad-init-project.sh symlinkait .claude/ EN ENTIER. Or Claude Code a besoin
d'un .claude réel (settings.local.json, worktrees/) — le symlink échouait donc
silencieusement ("existe déjà, ignoré"), et les skills BMAD n'arrivaient JAMAIS
côté Claude Code. Conséquence: BMAD 6.9 + customisations .toml inactifs dans les
projets via Claude Code (seul Codex/.agents fonctionnait, lui étant symlinkable).
Fix:
- .agents/ reste un symlink complet (Codex n'y écrit pas)
- .claude/ reste un dossier RÉEL ; on symlinke seulement .claude/skills et
.claude/commands vers la base centralisée → à jour sans écraser les fichiers
propres à Claude Code
- ajout de custom/ + scripts/ aux modules _bmad symlinkés (resolver de customisation)
Validé: resolve_customization.py résout désormais les overrides (.toml gates MCP +
capitalisation) depuis .claude/skills dans RL799_V2 et app-alexandrie.
- Suppression de 3 fichiers *.tmp versionnés (résidus install BMAD 6.0.4, vides)
- Ajout de *.tmp au .gitignore
- Déduplication: entrée "Prisma init au chargement = casse build Next.js"
était dupliquée à l'identique dans risques/prisma.md ET risques/nextjs.md
→ conservée dans nextjs.md (risque Next.js), retirée de prisma.md
- Déduplication: pattern "Tests de styles RN sans renderer JSX" dupliqué dans
patterns/tests.md ET patterns/design-tokens.md → conservé dans tests.md
- Correction README backend/risques : retrait des entrées fantômes de la ligne
prisma.md ("init module build" déplacé vers nextjs ; "suppression champ .map()"
qui vit en réalité dans general.md)
Audit complet de la base : aucun doublon d'ancre restant, liens non cassés,
README synchronisés, format risques/patterns constant. Branches obsolètes
mcp_test et mcp_v1 supprimées (mergées dans main).
Le buffer 95_a_capitaliser.md contenait ~273 propositions accumulées localement
(RL799_V2 + app-alexandrie, mai-juin 2026). Toutes triées et intégrées :
- backend → knowledge/backend/ (f1b7834)
- frontend → knowledge/frontend/ (5f5c872)
- workflow + ux → knowledge/ (81fde91)
- post-mortems + ADR → 90_/40_ (2a06429)
Le buffer est purgé. Restent 3 entrées jugées trop spécifiques au projet lors du
triage, conservées avec une note de routage pour intégration manuelle dans les
CLAUDE.md des projets concernés :
- RL799_V2 : centre d'aide in-app + taux de présence borné par initiatedAt
- app-alexandrie : tronc commun vs extension premium (formation Skool)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Intégration des propositions ciblant les fichiers racine validés.
90_debug_et_postmortem.md (9 post-mortems) :
- type métier dupliqué dans package shared + bridge ; flakiness "socket hang up" e2e
(recyclage de port éphémère) ; rtk masque la sortie des CLI build/test ; vi.spyOn sur
module ESM ; `as const` → TS2769 (jose) ; échec massif suite = template DB corrompu ;
séparer 2 chantiers mélangés (barrel partagé) ; modèle Prisma fantôme (migration sans
model) + variante effet iceberg CI
40_decisions_et_archi.md (4 ADR) :
- CI e2e mobile pas un prérequis prod ; vérifier le modèle de données réel avant spec ;
segmenter l'auth par sensibilité d'action ; IdP Keycloak auth-only + RBAC local (Proposed)
Dédupliqué vs knowledge/ déjà écrit : les ADR/post-mortems apportent l'angle narratif/décisionnel
(le "pourquoi"/"récit de debug"), complémentaire des règles réutilisables en knowledge/, avec
cross-références. Blocs déjà couverts ailleurs (113 liste/détail) non réintégrés.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Triage et intégration des propositions workflow et UX du buffer 95_a_capitaliser.md.
WORKFLOW :
- risques/story-tracking.md : 24 risques de suivi de story (enabler AC non-bloquant,
tests plumbing vs scénario, reformat hors scope, xit sans story de suivi, re-scope mid-PR,
statut migré non vérifié, périmètre auto-déclaré vs git diff, composant/page livré sans
câblage — reciblages venus de backend #21 et frontend #257)
- patterns/general.md : audit cartographique pré-chantier, Go/No-Go par lot, sub-agent review
fresh-context, sweep read-only délégué (#156), revue adverse de spec, audit-first migration
UX (domaine amorcé — était vide) :
- patterns/general.md : 9 patterns (mount-based read, fiche détail single-scroll, FAB étendu,
ligne de contexte filtres, état read-only caché, avatar par hash, audit a11y touch targets)
- risques/general.md : 5 risques (bouton retour dans ScrollView #108, lien sans handler,
wording cross-écran divergent, token sans détection, padding multi-écrans)
- READMEs ux/workflow mis à jour
Vérifié : aucun doublon d'ancre/titre, fichiers racine 40_/90_ non modifiés (propositions
réservées pour validation séparée). Source 95_ non purgée (purge en fin de capitalisation).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Transforme le MCP leadtech-bmad de stdio local en service HTTP central
conteneurisé, accessible depuis tout périphérique du tailnet.
- server.main(): transport piloté par LEADTECH_MCP_TRANSPORT (stdio par
défaut → aucune régression locale; streamable-http pour le central).
Host/port via LEADTECH_MCP_HOST/_PORT.
- _build_transport_security(): whitelist d'hôtes via LEADTECH_MCP_ALLOWED_HOSTS
pour lever la protection anti-DNS-rebinding (HTTP 421) derrière le sidecar.
- Dockerfile (python:3.11-slim, build index au démarrage, lance le serveur HTTP).
- docker-compose.yml: service mcp (réseau interne, aucun port publié) +
sidecar tailscale (tailscale serve TLS MagicDNS). user 1000:1000 pour
l'écriture dans le bind-mont. ALLOW_WRITE=1 sur l'instance centrale.
- tailscale/serve.json, .env.example, mcp.config.http.example.json.
- .gitignore: ignore le .env (secrets), garde .env.example.
- docs/design_nuc_tailscale.md: statut passé à IMPLÉMENTÉ + URL réelle.
Validé: handshake MCP initialize HTTPS via tailnet → 200, 7 tools listables,
écriture 95_a_capitaliser.md confirmée, 79 tests verts.
scripts/mcp_token_report.py scanne un transcript Claude Code (.jsonl) et mesure
la consommation réelle des appels MCP leadtech en condition d'usage :
- nombre d'appels par tool (get_guidance, validate_plan, validate_patch, ...)
- tokens des résultats MCP injectés dans le contexte
- part dans l'input non caché + totaux session (input/output/cache)
Usage: python3 mcp_token_report.py --project RL799_V2 (dernier transcript du projet)
Validé sur transcript simulé (3 appels = pattern d'une story dev): détection + comptage OK.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Un appel get_guidance par défaut passe de ~3800 à ~2280 tokens (-40%) en gardant
un mix patterns/risques équilibré (3 must_do + 3 red_flags) et confidence HIGH sur
un cas backend réaliste. Les agents qui veulent plus peuvent toujours passer max_items.
Mesuré: lire toute la base = ~131k tokens ; 1 appel ciblé à 6 = ~2,3k (~98% d'économie).
Défaut aligné dans server.get_guidance et knowledge.search_knowledge.
79 tests passent, aucune régression.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Capture le design abouti d'un MCP central:
- besoin: 1 instance, lecture+écriture, sans clone local sur chaque machine
- hébergement NUC en HTTP (FastMCP streamable-http), exposition via Tailscale (pas de WAN)
- écriture centralisée: ALLOW_WRITE=1 côté NUC, plus de conflit multi-machine
- workflow capitalisation à seuil: accumulation -> triage_capitalization() au-delà de N -> rapport -> validation humaine
- source de vérité données: Git (origin), NUC = clone de référence
Statut: PISTE non figée (pas dans 40_decisions_et_archi.md). Reste-à-faire listé.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Validation bout-en-bout de la chaîne MCP <-> BMAD 6.9 :
- serveur leadtech-bmad testé sur Mac (handshake 7 tools / 6 resources OK)
- gates Phase 2 stricts vérifiés (backend_contracts + backend_session_expires_at
se déclenchent sur cas non conforme, 0 faux positif sur plan conforme)
- MCP déclaré dans Claude Code pour app-alexandrie et RL799_V2
Story TEST-OBS-001 enregistrée comme ligne T0 (validation de chaîne, factice,
HORS décompte des 10 stories produit). Le compteur réel Phase 3 démarre intact
à la première vraie story.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Migration des modules via l'installer officiel (Quick update, en place) :
- core/bmm 6.0.4 -> 6.9.0
- tea 1.5.3 -> 1.19.0
- cis 0.1.8 -> 0.2.1
Portage des customisations Lead_tech vers le nouveau mécanisme d'overrides
(_bmad/custom/<skill>.toml, couche "team" résolue par resolve_customization.py) :
- 6 agents directs (analyst, architect, dev, pm, tech-writer, ux-designer)
- module tea
- workflows: dev-story, create-story, code-review, quick-dev, qa-generate-e2e-tests
- agents disparus en 6.9 reportés vers leurs workflows hôtes
(QA -> code-review, SM -> create-story, quick-flow-solo-dev -> quick-dev)
- règle de capitalisation 95_a_capitaliser factorisée dans
_bmad/custom/leadtech-capitalisation.md (référencée via persistent_facts)
Nettoyage du legacy 6.0.4 :
- suppression des 17 *.customize.yaml (non lus par 6.9)
- suppression des .bak générés par l'installer (contenu porté en .toml)
- suppression de 17 skills orphelins dans .agents/skills (anciens noms, .agents/.claude réalignés 66=66)
- suppression des coquilles de workflows disparus
Tous les overrides validés par le resolver officiel (12/12 JSON valide,
base préservée + ajouts Lead_tech). Le cœur (couche customize.toml) n'est plus modifié,
donc les updates 6.x futurs ne pourront plus écraser ces customisations.
Note env: resolve_customization.py exige Python >=3.11 (uv installé, python3 -> 3.12.13).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Met en place le squelette d'observabilite pour suivre le rollout
Phase 2 partielle sur les 10-20 prochaines stories BMAD.
Trois fichiers dans 80_bmad/observability/ :
- README.md : flux operationnel + criteres de promotion vers Phase 3
+ criteres de retour en arriere vers Phase 1
- template_releve_story.md : modele a copier-coller par story
- phase2_log.md : log cumulatif (tableau recap + compteurs par regle
+ notes detaillees)
Suivi tenu a la main pour l'instant. Une automatisation (script qui
scanne les sections 'Leadtech MCP Gates' dans les stories des projets
de _projects.conf) sera consideree apres 10 stories releves
manuellement, si le format est juge stable.
rollout_bmad_advisory.md reference le nouveau dossier dans sa section
Observabilite.
Le role Curator de la doc rollout n'avait pas d'agent BMAD dedie, ce
qui laissait planer un doute sur ses points d'invocation. Clarification :
- Pas d'agent BMAD Curator. Le role est execute par l'humain.
- Les autres agents (dev, qa, architect, sm, pm, ux-designer) ecrivent
directement dans 95_a_capitaliser.md via leurs memories — pas besoin
de propose_capitalization en critical_action.
- Le triage est manuel via le skill capitalisation-triage et le tool
MCP triage_capitalization() pour la pre-analyse heuristique.
- propose_capitalization reste utile en interactif quand l'humain veut
formaliser une entree.
Deux agents BMAD avaient critical_actions vide alors qu'ils opèrent
sur des domaines couverts par la base Lead_tech.
- ux-designer : get_guidance(domain='ux', task_type='analysis').
Commentaire explicite : knowledge/ux/ est encore vide (index README
sans entrée), wiring en place pour s'activer dès qu'un pattern UX
validé sera promu via 95_a_capitaliser.md. Le smoke test retourne
2 matched_docs depuis les README index — utile dès maintenant.
- pm : get_guidance(domain='product', task_type='analysis') sur
roadmap, prioritization, epic-level decisions. Smoke test :
confidence HIGH, 3 matched_docs sur knowledge/product/.
Les workflows dev-story appellent validate_plan/validate_patch en
strict=true depuis le commit 355d613, mais les customize.yaml
correspondants disaient encore strict=false. Le workflow surcharge le
customize au moment de l'exécution, donc pas de bug fonctionnel — mais
la lecture du customize seul donnait une fausse impression du rollout.
Changements :
- bmm-dev : strict=true sur validate_plan et validate_patch + memory
Phase 2 partielle remplaçant la mention 'advisory-first'.
- bmm-quick-flow-solo-dev : idem, quick-flow ne contourne pas le strict.
- bmm-qa : strict=false maintenu volontairement (le blocage a déjà eu
lieu côté dev) avec commentaire YAML qui explique le choix, et memory
reformulée pour Phase 2.
Audit santé du chantier mcp_v1 a montré un écart entre la doc rollout
(advisory only) et l'implémentation réelle (workflows dev-story et
create-story en strict=true, personas dev.md et sm.md avec hard-blocker
sur blocking_issues). Décision : aligner la doc sur l'implem.
Changements :
- rollout_bmad_advisory.md : réécrit pour décrire la Phase 2 partielle
avec les 3 blocages stricts effectivement actifs (artefacts BMAD seuls,
sessions sans expiresAt, plan backend sans contracts).
- integration_mcp_sidecar.md : points d'injection mis à jour avec
strict=true sur dev, advisory sur QA, statut Phase 2.
- mcp_v1.md et README.md : statut 'advisory-first' / 'prototype' →
'Phase 2 partielle'.
- 40_decisions_et_archi.md : nouvel ADR retraçant le choix.
Note : les customize.yaml invoquent encore strict=false, surchargés par
les workflows. Cohérence interne à traiter dans un prochain commit si
besoin.
Le repo Lead_tech n'a pas à héberger CLAUDE.md/AGENTS.md.
sync-ai-instructions génère maintenant ~/.claude/CLAUDE.md directement
et ~/.codex/AGENTS.md reste un symlink vers celui-ci.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- aliases.sh : détection par uname au lieu de tester l'existence du dossier
- _AI_INSTRUCTIONS.md : placeholder {{LEADTECH}} pour tous les chemins
- sync-ai-instructions.sh : substitution {{LEADTECH}} → REPO_ROOT à la génération
- .gitignore : exclure CLAUDE.md et AGENTS.md (fichiers générés, machine-spécifiques)
MaksTinyWorkshop