Files
_Assistant_Lead_Tech/80_bmad/integration_mcp_sidecar.md
Claude 18fc130ad6 docs(mcp-rollout): align rollout doc with Phase 2 partielle reality
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.
2026-05-07 07:40:34 +00:00

2.4 KiB

BMAD — Integration MCP Sidecar (Lead_tech)

Ce document decrit le cablage du serveur MCP leadtech-bmad-mcp dans BMAD.

Positionnement

  • BMAD reste le systeme d'orchestration.
  • Le MCP Lead_tech est un appui: guidance, controles qualite, capitalisation.
  • Le MCP ne pilote ni branche, ni statut, ni execution des stories.

Points d'injection

  1. Entrée story (Analyst)
  • Appel: get_guidance(domain, task_type="analysis", story_text=...)
  • Sortie injectee dans la story:
    • Patterns a appliquer
    • Risques a eviter
    • Gates de validation
  1. Pre-implementation (Builder)
  • Appel: validate_plan(domain, plan_text, agent_role="builder", strict=true)
  • Regle: HALT si blocking_issues non vide, override humain trace.
  1. Post-patch (Builder)
  • Appel: validate_patch(domain, diff_text, changed_files, strict=true)
  • Regle: HALT avant statut review si blocking_issues non vide.
  • Resultat ajoute au Dev Agent Record et a Leadtech MCP Gates.
  1. Review (Reviewer)
  • Appel: emit_checklist(agent_role="reviewer", domain, story_text)
  • Appel: validate_patch(domain, diff_text, changed_files, strict=false) (advisory, le blocage a deja eu lieu cote dev).
  • Option: relancer validate_patch sur le diff final de PR.
  1. Cloture et apprentissage (Curator)
  • Appel: propose_capitalization(...) en dry_run=true par defaut.
  • Revue periodique: triage_capitalization().

Statut de rollout

  • Phase 1 (advisory only): achevee.
  • Phase 2 (3 blocages stricts cibles): statut actuel.
    • validate_patch: patch sans fichier source = artefacts BMAD seuls.
    • validate_patch: sessions sans expiresAt visible.
    • validate_plan: plan backend sans reference aux contrats partages.
  • Phase 3 (elargissement): a evaluer apres observation des faux positifs sur 10 a 20 stories.

Documents operationnels associes :

  • mcp/leadtech_bmad_mcp/docs/rollout_bmad_advisory.md
  • mcp/leadtech_bmad_mcp/docs/pilot_bmad_10_stories.md

Traceabilite

Chaque story BMAD doit contenir une section Leadtech MCP Gates avec:

  • timestamp
  • tool appele
  • resume des must_do, red_flags, blocking_issues
  • decision humaine associee

Contraintes de securite

  • LEADTECH_MCP_ALLOW_WRITE=0 en environnement normal.
  • Ecriture activee ponctuellement uniquement pour:
    • propose_capitalization(dry_run=false)
    • route_to_project_memory(dry_run=false)
  • Jamais d'ecriture directe dans knowledge/* par tool MCP.