mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 21:41:42 +02:00
bmad: wire leadtech mcp pilot into agent customizations
This commit is contained in:
MaksTinyWorkshop
@@ -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"
|
||||
|
||||
@@ -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"
|
||||
|
||||
@@ -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"
|
||||
|
||||
@@ -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"
|
||||
|
||||
@@ -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"
|
||||
|
||||
@@ -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:
|
||||
|
||||
@@ -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:
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
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