scripts/mcp_token_report.py scanne un transcript Claude Code (.jsonl) et mesure
la consommation réelle des appels MCP leadtech en condition d'usage :
- nombre d'appels par tool (get_guidance, validate_plan, validate_patch, ...)
- tokens des résultats MCP injectés dans le contexte
- part dans l'input non caché + totaux session (input/output/cache)
Usage: python3 mcp_token_report.py --project RL799_V2 (dernier transcript du projet)
Validé sur transcript simulé (3 appels = pattern d'une story dev): détection + comptage OK.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Un appel get_guidance par défaut passe de ~3800 à ~2280 tokens (-40%) en gardant
un mix patterns/risques équilibré (3 must_do + 3 red_flags) et confidence HIGH sur
un cas backend réaliste. Les agents qui veulent plus peuvent toujours passer max_items.
Mesuré: lire toute la base = ~131k tokens ; 1 appel ciblé à 6 = ~2,3k (~98% d'économie).
Défaut aligné dans server.get_guidance et knowledge.search_knowledge.
79 tests passent, aucune régression.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Capture le design abouti d'un MCP central:
- besoin: 1 instance, lecture+écriture, sans clone local sur chaque machine
- hébergement NUC en HTTP (FastMCP streamable-http), exposition via Tailscale (pas de WAN)
- écriture centralisée: ALLOW_WRITE=1 côté NUC, plus de conflit multi-machine
- workflow capitalisation à seuil: accumulation -> triage_capitalization() au-delà de N -> rapport -> validation humaine
- source de vérité données: Git (origin), NUC = clone de référence
Statut: PISTE non figée (pas dans 40_decisions_et_archi.md). Reste-à-faire listé.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Le role Curator de la doc rollout n'avait pas d'agent BMAD dedie, ce
qui laissait planer un doute sur ses points d'invocation. Clarification :
- Pas d'agent BMAD Curator. Le role est execute par l'humain.
- Les autres agents (dev, qa, architect, sm, pm, ux-designer) ecrivent
directement dans 95_a_capitaliser.md via leurs memories — pas besoin
de propose_capitalization en critical_action.
- Le triage est manuel via le skill capitalisation-triage et le tool
MCP triage_capitalization() pour la pre-analyse heuristique.
- propose_capitalization reste utile en interactif quand l'humain veut
formaliser une entree.
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.
MaksTinyWorkshop