Met en place le squelette d'observabilite pour suivre le rollout Phase 2 partielle sur les 10-20 prochaines stories BMAD. Trois fichiers dans 80_bmad/observability/ : - README.md : flux operationnel + criteres de promotion vers Phase 3 + criteres de retour en arriere vers Phase 1 - template_releve_story.md : modele a copier-coller par story - phase2_log.md : log cumulatif (tableau recap + compteurs par regle + notes detaillees) Suivi tenu a la main pour l'instant. Une automatisation (script qui scanne les sections 'Leadtech MCP Gates' dans les stories des projets de _projects.conf) sera consideree apres 10 stories releves manuellement, si le format est juge stable. rollout_bmad_advisory.md reference le nouveau dossier dans sa section Observabilite.
Observabilite Leadtech MCP — Phase 2 partielle
Ce dossier sert a tracer l'observation des gates Leadtech MCP sur les stories BMAD reelles, pour decider :
- de l'extension du strict a d'autres gates (Phase 3)
- du retour en arriere si un gate produit trop de faux positifs
- de l'ajustement de
gates.yamlou des regles hardcodees dansserver.py
Fichiers
phase2_log.md— log cumulatif des stories observees (tableau recap + notes detaillees)template_releve_story.md— modele a copier-coller dansphase2_log.mdpour chaque nouvelle story
Quand alimenter
Pour chaque story BMAD qui declenche au moins un appel validate_plan ou validate_patch strict :
- Copier le template
template_releve_story.md - Le coller dans
phase2_log.mdsous la section "Notes detaillees" - Remplir au fur et a mesure (entree story / fin de dev / fin de review)
- A la cloture, reporter la ligne synthese dans le tableau recap en tete de
phase2_log.md
Criteres de promotion vers Phase 3
Avant de promouvoir un gate advisory en blocant strict, attendre que les criteres suivants soient atteints sur au moins 10 stories dans le domaine concerne :
- Faux positifs : < 10% des declenchements
- Vrai positifs : au moins 1 cas ou le gate a evite une regression reelle
- Stabilite formulation : pas de cas ou la regle declenche sur un texte ambigu (extrait partiel, formulation libre)
- Comprehension agent : pas de cas ou l'agent BMAD a mal interprete le
blocking_issue(ex: tente de contourner via reformulation)
Candidats a la promotion (cf. mcp/leadtech_bmad_mcp/docs/rollout_bmad_advisory.md) :
backend_request_id(validate_plan / validate_patch)backend_auth_guard(validate_patch)
Criteres de retour en arriere (Phase 1)
Si un gate strict actif produit :
- > 30% de faux positifs sur 5 stories consecutives, OU
- > 50% d'overrides humains non justifies, OU
- un blocage durable d'un projet sans valeur ajoutee
→ retirer le strict_only: true correspondant dans gates.yaml (ou retirer la regle hardcodee de server.py) et documenter le retour en arriere dans 40_decisions_et_archi.md.
Pas d'automatisation pour l'instant
Le log est tenu a la main par l'humain. Une automatisation (script qui scanne les sections Leadtech MCP Gates dans les stories des projets de _projects.conf) sera consideree apres 10 stories releves manuellement, si le format est juge stable.