Couac détecté en usage réel : un agent invoquant /bmad-bmm-quick-spec échouait
("Tinkering...") car la commande pointe vers _bmad/bmm/workflows/.../workflow.md,
un chemin 6.0.4 qui n'existe pas en 6.9.
Diagnostic vérifié par install fraîche de référence (4 modules, mêmes outils) :
BMAD 6.9 fonctionne 100% par SKILLS et ne génère AUCUNE commande (.claude/commands = 0).
Les 62 .claude/commands/*.md de notre base étaient des fossiles 6.0.4 conservés par
le quick-update de migration, pointant vers une arborescence morte (bmm/workflows).
Réparation :
- suppression des 62 commandes fossiles de 80_bmad/base/.claude/commands/
- bmad-init-project.sh : ne symlinke plus .claude/commands (seulement skills/)
- symlinks commands cassés retirés des projets RL799_V2 + app-alexandrie
Le bon point d'entrée 6.9 pour le quick-spec est le skill bmad-quick-dev (complet,
résolu avec les overrides MCP/capitalisation). Aucun skill 6.9 ne référence bmm/workflows.
- 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).
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>
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.
MaksTinyWorkshop