mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-05-18 08:18:15 +02:00
a7b96919a6
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.
50 lines
2.4 KiB
Markdown
50 lines
2.4 KiB
Markdown
# 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.yaml` ou des regles hardcodees dans `server.py`
|
|
|
|
## Fichiers
|
|
|
|
- `phase2_log.md` — log cumulatif des stories observees (tableau recap + notes detaillees)
|
|
- `template_releve_story.md` — modele a copier-coller dans `phase2_log.md` pour chaque nouvelle story
|
|
|
|
## Quand alimenter
|
|
|
|
Pour chaque story BMAD qui declenche au moins un appel `validate_plan` ou `validate_patch` strict :
|
|
|
|
1. Copier le template `template_releve_story.md`
|
|
2. Le coller dans `phase2_log.md` sous la section "Notes detaillees"
|
|
3. Remplir au fur et a mesure (entree story / fin de dev / fin de review)
|
|
4. 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.
|