bmad: wire leadtech mcp pilot into agent customizations

2026-04-06 21:41:42 +02:00 · 2026-03-31 16:28:10 +02:00
parent 6adc35d0ac
commit 355d6130eb
9 changed files with 114 additions and 3 deletions
--- a/80_bmad/base/_bmad/_config/agents/bmm-analyst.customize.yaml
+++ b/80_bmad/base/_bmad/_config/agents/bmm-analyst.customize.yaml
@@ -14,11 +14,13 @@ persona:
  principles: []

 # Add custom critical actions (appended after standard config loading)
-critical_actions: []
+critical_actions:
+  - "At story entry, call Leadtech MCP `get_guidance(domain, task_type='analysis', story_text=...)` and copy a short summary into the story under `Leadtech MCP Gates`."

 # Add persistent memories for the agent
 memories:
  - "When a reusable analysis pattern, requirements anti-pattern, or domain insight emerges, write a proposal to $LEADTECH/95_a_capitaliser.md (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <knowledge/product/patterns/general.md | knowledge/product/risques/<theme>.md | knowledge/backend/patterns/<theme>.md | 40_decisions_et_archi.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
+  - "When Leadtech MCP is available, use it in advisory mode during analysis: call `get_guidance(...)`, keep the 2-5 most relevant must_do/red_flags, and document the human decision in `Leadtech MCP Gates`."
 # Example:
 # memories:
 #   - "User prefers detailed technical explanations"
--- a/80_bmad/base/_bmad/_config/agents/bmm-architect.customize.yaml
+++ b/80_bmad/base/_bmad/_config/agents/bmm-architect.customize.yaml
@@ -14,11 +14,13 @@ persona:
  principles: []

 # Add custom critical actions (appended after standard config loading)
-critical_actions: []
+critical_actions:
+  - "For architecture or design decisions, call Leadtech MCP `get_guidance(domain, task_type='architecture', story_text=...)` and use the returned docs as mandatory reading inputs."

 # Add persistent memories for the agent
 memories:
  - "When a reusable pattern, difficult bug fix, anti-pattern, or architecture decision emerges during architecture or technical design, write a proposal to $LEADTECH/95_a_capitaliser.md (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <40_decisions_et_archi.md | knowledge/backend/patterns/<theme>.md | knowledge/backend/risques/<theme>.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
+  - "When Leadtech MCP highlights architecture docs or red flags, reference them explicitly in the decision record instead of keeping the guidance implicit."
 # Example:
 # memories:
 #   - "User prefers detailed technical explanations"
--- a/80_bmad/base/_bmad/_config/agents/bmm-dev.customize.yaml
+++ b/80_bmad/base/_bmad/_config/agents/bmm-dev.customize.yaml
@@ -16,10 +16,13 @@ persona:
 # Add custom critical actions (appended after standard config loading)
 critical_actions:
  - "Before any development task, run: `bash $LEADTECH/scripts/sync-projects-conf.sh --project-root {project-root} --sync-existing`"
+  - "Before implementation, call Leadtech MCP `validate_plan(domain, plan_text, agent_role='builder', strict=false)` and record the result in `Leadtech MCP Gates`."
+  - "After producing a diff, call Leadtech MCP `validate_patch(domain, diff_text, changed_files, strict=false)` and record the result in the Dev Agent Record."

 # Add persistent memories for the agent
 memories:
  - "When a reusable pattern, difficult bug fix, anti-pattern, or architecture decision emerges during implementation, write a proposal to $LEADTECH/95_a_capitaliser.md (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <knowledge/backend/patterns/<theme>.md | knowledge/frontend/patterns/<theme>.md | knowledge/backend/risques/<theme>.md | knowledge/frontend/risques/<theme>.md | 90_debug_et_postmortem.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
+  - "Leadtech MCP is advisory-first: if `validate_patch(..., strict=false)` returns `blocking_issues`, do not mark the story `done` directly; move it to `review` unless the deviation is explicitly justified."
 # Example:
 # memories:
 #   - "User prefers detailed technical explanations"
--- a/80_bmad/base/_bmad/_config/agents/bmm-qa.customize.yaml
+++ b/80_bmad/base/_bmad/_config/agents/bmm-qa.customize.yaml
@@ -16,10 +16,12 @@ persona:
 # Add custom critical actions (appended after standard config loading)
 critical_actions:
  - "Before any QA/review/test task, run: `bash $LEADTECH/scripts/sync-projects-conf.sh --project-root {project-root} --sync-existing`"
+  - "During review, call Leadtech MCP `emit_checklist(agent_role='reviewer', domain, story_text)` and `validate_patch(domain, diff_text, changed_files, strict=false)` before accepting `done`."

 # Add persistent memories for the agent
 memories:
  - "When a reusable test pattern, tricky bug, or quality anti-pattern is identified, write a proposal to $LEADTECH/95_a_capitaliser.md (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <knowledge/frontend/patterns/tests.md | knowledge/frontend/risques/tests.md | knowledge/workflow/risques/story-tracking.md | 90_debug_et_postmortem.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
+  - "In advisory rollout, any Leadtech MCP `blocking_issues` during review requires an explicit accept/reject rationale in `Leadtech MCP Gates`; never accept `done` silently on a flagged story."
 # Example:
 # memories:
 #   - "User prefers detailed technical explanations"
--- a/80_bmad/base/_bmad/_config/agents/bmm-quick-flow-solo-dev.customize.yaml
+++ b/80_bmad/base/_bmad/_config/agents/bmm-quick-flow-solo-dev.customize.yaml
@@ -16,10 +16,12 @@ persona:
 # Add custom critical actions (appended after standard config loading)
 critical_actions:
  - "Before any implementation task, run: `bash $LEADTECH/scripts/sync-projects-conf.sh --project-root {project-root} --sync-existing`"
+  - "In quick-flow mode, still call Leadtech MCP `validate_plan(domain, plan_text, agent_role='builder', strict=false)` before coding and `validate_patch(domain, diff_text, changed_files, strict=false)` before declaring the story complete."

 # Add persistent memories for the agent
 memories:
  - "When a reusable pattern, difficult bug fix, anti-pattern, or architecture decision emerges during implementation, write a proposal to $LEADTECH/95_a_capitaliser.md (Mac: ~/AI_RULES/_Assistant_Lead_Tech/95_a_capitaliser.md ; NUC: /srv/helpers/_Assistant_Lead_Tech/95_a_capitaliser.md). Format: DATE — base / FILE_UPDATE_PROPOSAL / Fichier cible: <knowledge/backend/patterns/<theme>.md | knowledge/frontend/patterns/<theme>.md | knowledge/backend/risques/<theme>.md | knowledge/frontend/risques/<theme>.md | 90_debug_et_postmortem.md> / Pourquoi: <reason> / Proposition: <content>. Never write directly to Lead_tech validated files."
+  - "Quick-flow does not bypass advisory gates: if Leadtech MCP returns `blocking_issues`, the default outcome is `review`, not `done`."
 # Example:
 # memories:
 #   - "User prefers detailed technical explanations"
--- a/80_bmad/base/_bmad/_config/agents/bmm-sm.customize.yaml
+++ b/80_bmad/base/_bmad/_config/agents/bmm-sm.customize.yaml
@@ -14,7 +14,8 @@ persona:
  principles: []

 # Add custom critical actions (appended after standard config loading)
-critical_actions: []
+critical_actions:
+  - "During sprint follow-up, ensure active stories using Leadtech MCP keep a short `Leadtech MCP Gates` section with tool calls, findings, and human decision."

 # Add persistent memories for the agent
 memories:
--- a/80_bmad/integration_mcp_sidecar.md
+++ b/80_bmad/integration_mcp_sidecar.md
@@ -39,6 +39,11 @@ Ce document decrit le cablage du serveur MCP `leadtech-bmad-mcp` dans BMAD.
 - Phase 2: blocage sur `blocking_issues` uniquement
 - Phase 3: rules strictes sur domaines critiques (backend auth/contracts/sessions)

+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:
--- a/mcp/leadtech_bmad_mcp/README.md
+++ b/mcp/leadtech_bmad_mcp/README.md
@@ -103,6 +103,7 @@ Quickstart complet :

 - `docs/quickstart_dev_local.md`
 - `docs/rollout_bmad_advisory.md`
+- `docs/pilot_bmad_10_stories.md`

 ## Rebuild de l'index local

--- a/mcp/leadtech_bmad_mcp/docs/pilot_bmad_10_stories.md
+++ b/mcp/leadtech_bmad_mcp/docs/pilot_bmad_10_stories.md
@@ -0,0 +1,93 @@
+# leadtech-bmad-mcp — Pilote BMAD sur 10 stories
+
+Objectif : valider le sidecar en conditions reelles avant toute promotion de gates strictes.
+
+## Perimetre
+
+- 10 stories reelles
+- priorite aux stories `backend` et `workflow`
+- inclure au moins :
+  - 4 stories backend implementation
+  - 2 stories frontend/mobile
+  - 2 stories review/qa
+  - 2 stories avec risque de divergence story/code
+
+## Mode
+
+- advisory only
+- aucune story bloquee automatiquement
+- chaque story doit tracer ses appels MCP
+
+## Instrumentation minimale par story
+
+Section obligatoire :
+
+```txt
+Leadtech MCP Gates
+- timestamp
+- tools appeles
+- must_do
+- red_flags
+- blocking_issues
+- decision humaine
+```
+
+## Sequence par role
+
+### Analyst
+
+- appeler `get_guidance(domain, task_type="analysis", story_text=...)`
+- reporter 2-5 points utiles dans la story
+
+### Builder
+
+- appeler `validate_plan(..., strict=false)` avant implementation
+- appeler `validate_patch(..., strict=false)` apres diff
+- si `blocking_issues` > 0, viser `review`, pas `done`
+
+### Reviewer / QA
+
+- appeler `emit_checklist(...)`
+- relancer `validate_patch(..., strict=false)` sur le diff final
+- comparer la File List au diff reel si la story revendique `done`
+
+## Tableau de suivi recommande
+
+Pour chaque story, relever :
+
+- `story_id`
+- `domain`
+- `tools_called`
+- `blocking_count`
+- `red_flag_count`
+- `false_positive` (`yes/no`)
+- `bug_prevented` (`yes/no`)
+- `decision`
+- `notes`
+
+## Criteres de succes
+
+- les agents utilisent le sidecar sans friction majeure
+- les sorties sont jugees compréhensibles et actionnables
+- au moins 2 cas reels ou le MCP evite une regression, une omission ou un faux `done`
+- faux positifs faibles sur les gates candidates au mode strict
+
+## Criteres d'echec
+
+- vocabulaire MCP trop flou pour les agents BMAD
+- trop de faux positifs sur diff/plan partiels
+- section `Leadtech MCP Gates` souvent absente ou vide
+
+## Decision de sortie
+
+Apres 10 stories :
+
+1. classer chaque gate : `keep advisory`, `promote strict`, `drop/refine`
+2. promouvoir en strict seulement les gates a signal fort
+3. mettre a jour `config/gates.yaml` si une regle doit etre assouplie ou retiree
+
+## Gates candidates a surveiller pendant le pilote
+
+- `Patch sans fichier source: seulement des artefacts BMAD.`
+- `Session modifiee sans expiresAt visible dans le diff.`
+- `Plan backend sans reference aux contrats partages.`