mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-07 05:51:41 +02:00
bmad: wire leadtech mcp pilot into agent customizations
This commit is contained in:
93
mcp/leadtech_bmad_mcp/docs/pilot_bmad_10_stories.md
Normal file
93
mcp/leadtech_bmad_mcp/docs/pilot_bmad_10_stories.md
Normal file
@@ -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.`
|
||||
Reference in New Issue
Block a user