mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-05-18 08:18:15 +02:00
docs(mcp-rollout): align rollout doc with Phase 2 partielle reality
Audit santé du chantier mcp_v1 a montré un écart entre la doc rollout (advisory only) et l'implémentation réelle (workflows dev-story et create-story en strict=true, personas dev.md et sm.md avec hard-blocker sur blocking_issues). Décision : aligner la doc sur l'implem. Changements : - rollout_bmad_advisory.md : réécrit pour décrire la Phase 2 partielle avec les 3 blocages stricts effectivement actifs (artefacts BMAD seuls, sessions sans expiresAt, plan backend sans contracts). - integration_mcp_sidecar.md : points d'injection mis à jour avec strict=true sur dev, advisory sur QA, statut Phase 2. - mcp_v1.md et README.md : statut 'advisory-first' / 'prototype' → 'Phase 2 partielle'. - 40_decisions_et_archi.md : nouvel ADR retraçant le choix. Note : les customize.yaml invoquent encore strict=false, surchargés par les workflows. Cohérence interne à traiter dans un prochain commit si besoin.
This commit is contained in:
@@ -18,26 +18,31 @@ Ce document decrit le cablage du serveur MCP `leadtech-bmad-mcp` dans BMAD.
|
||||
- `Gates de validation`
|
||||
|
||||
2. Pre-implementation (Builder)
|
||||
- Appel: `validate_plan(domain, plan_text, agent_role="builder")`
|
||||
- Regle: pas d'implementation tant que `blocking_issues` n'est pas vide.
|
||||
- Appel: `validate_plan(domain, plan_text, agent_role="builder", strict=true)`
|
||||
- Regle: HALT si `blocking_issues` non vide, override humain trace.
|
||||
|
||||
3. Post-patch (Builder)
|
||||
- Appel: `validate_patch(domain, diff_text, changed_files)`
|
||||
- Resultat ajoute au Dev Agent Record.
|
||||
- Appel: `validate_patch(domain, diff_text, changed_files, strict=true)`
|
||||
- Regle: HALT avant statut `review` si `blocking_issues` non vide.
|
||||
- Resultat ajoute au Dev Agent Record et a `Leadtech MCP Gates`.
|
||||
|
||||
4. Review (Reviewer)
|
||||
- Appel: `emit_checklist(agent_role="reviewer", domain, story_text)`
|
||||
- Appel: `validate_patch(domain, diff_text, changed_files, strict=false)` (advisory, le blocage a deja eu lieu cote dev).
|
||||
- Option: relancer `validate_patch` sur le diff final de PR.
|
||||
|
||||
5. Cloture et apprentissage (Curator)
|
||||
- Appel: `propose_capitalization(...)` en `dry_run=true` par defaut.
|
||||
- Revue periodique: `triage_capitalization()`.
|
||||
|
||||
## Mode de rollout recommande
|
||||
## Statut de rollout
|
||||
|
||||
- Phase 1: advisory only (aucun blocage automatique)
|
||||
- Phase 2: blocage sur `blocking_issues` uniquement
|
||||
- Phase 3: rules strictes sur domaines critiques (backend auth/contracts/sessions)
|
||||
- Phase 1 (advisory only): achevee.
|
||||
- Phase 2 (3 blocages stricts cibles): **statut actuel**.
|
||||
- `validate_patch`: patch sans fichier source = artefacts BMAD seuls.
|
||||
- `validate_patch`: sessions sans expiresAt visible.
|
||||
- `validate_plan`: plan backend sans reference aux contrats partages.
|
||||
- Phase 3 (elargissement): a evaluer apres observation des faux positifs sur 10 a 20 stories.
|
||||
|
||||
Documents operationnels associes :
|
||||
|
||||
|
||||
Reference in New Issue
Block a user