cli/doctor: ajouter des checks génériques réutilisables pour profils et secrets #24

Closed
opened 2026-04-14 14:23:49 +00:00 by thibaud-lclr · 0 comments
thibaud-lclr commented 2026-04-14 14:23:49 +00:00 (Migrated from gitea.lclr.dev)

Problème: le moteur doctor est bon, mais les intégrations doivent encore écrire des checks personnalisés très proches d un binaire à l autre (profil résolu complet, secret présent via sources, etc.). Proposition: enrichir cli.DoctorOptions avec des checks génériques optionnels ou exposer des helpers dédiés, par exemple: check champs requis résolus depuis des FieldSpec, check secret requis (avec provenance env/secret), check erreur de résolution formatée. Critères d acceptation: un binaire peut composer un doctor complet avec moins de code custom, les messages restent explicites, et la flexibilité des checks custom est conservée. Contexte: cas observé dans email-mcp (doctorProfileCheck et doctorPasswordCheck).

Problème: le moteur doctor est bon, mais les intégrations doivent encore écrire des checks personnalisés très proches d un binaire à l autre (profil résolu complet, secret présent via sources, etc.). Proposition: enrichir cli.DoctorOptions avec des checks génériques optionnels ou exposer des helpers dédiés, par exemple: check champs requis résolus depuis des FieldSpec, check secret requis (avec provenance env/secret), check erreur de résolution formatée. Critères d acceptation: un binaire peut composer un doctor complet avec moins de code custom, les messages restent explicites, et la flexibilité des checks custom est conservée. Contexte: cas observé dans email-mcp (doctorProfileCheck et doctorPasswordCheck).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: AI/mcp-framework#24
No description provided.