mirror of https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech synced 2026-06-28 01:53:40 +02:00

Files

T

MaksTinyWorkshop a1d0aba98d docs(observability): record Phase 2 chain validation (TEST-OBS-001)

Validation bout-en-bout de la chaîne MCP <-> BMAD 6.9 :
- serveur leadtech-bmad testé sur Mac (handshake 7 tools / 6 resources OK)
- gates Phase 2 stricts vérifiés (backend_contracts + backend_session_expires_at
  se déclenchent sur cas non conforme, 0 faux positif sur plan conforme)
- MCP déclaré dans Claude Code pour app-alexandrie et RL799_V2

Story TEST-OBS-001 enregistrée comme ligne T0 (validation de chaîne, factice,
HORS décompte des 10 stories produit). Le compteur réel Phase 3 démarre intact
à la première vraie story.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-25 01:20:25 +02:00

phase2_log.md

docs(observability): record Phase 2 chain validation (TEST-OBS-001)

2026-06-25 01:20:25 +02:00

README.md

feat(observability): scaffold Phase 2 tracking for Leadtech MCP rollout

2026-05-07 08:06:04 +00:00

template_releve_story.md

feat(observability): scaffold Phase 2 tracking for Leadtech MCP rollout

2026-05-07 08:06:04 +00:00

README.md

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 :

Copier le template template_releve_story.md
Le coller dans phase2_log.md sous 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.