docs: document email-mcp validation boundaries

README.md

@@ -35,6 +35,31 @@ Le flux typique côté application est :
 4. Charger `mcp.toml` avec `manifest`.
 5. Exécuter l'auto-update avec `update` si nécessaire.
 
+## Validation Avec `email-mcp`
+
+La migration de [`email-mcp`](../email-mcp) sert de cas réel de validation du
+framework.
+
+Ce qui est aujourd'hui mutualisé et utilisé tel quel par `email-mcp` :
+
+- la résolution du profil actif via `cli`
+- le stockage JSON versionné de la config via `config`
+- l'accès au wallet natif et aux secrets via `secretstore`
+- le chargement de `mcp.toml` via `manifest`
+- l'exécution du flux d'auto-update via `update`
+
+Ce qui reste volontairement spécifique à l'application cliente :
+
+- l'arbre de commandes et les alias métier (`config`, `setup`, `mcp`, `update`)
+- les prompts interactifs et la validation métier des champs saisis
+- le découpage entre données de config et secrets, ainsi que le nommage des secrets
+- l'assemblage runtime entre config, secrets, services métier et serveur MCP
+- le mapping final des erreurs techniques vers des messages utilisateur adaptés
+
+Ces limites sont des choix explicites : le framework fournit des briques
+réutilisables, mais ne force pas une couche de bootstrap unique ni un contrat
+applicatif trop spécifique à un premier consommateur.
+
 ## Manifeste `mcp.toml`
 
 Le package `manifest` cherche automatiquement `mcp.toml` dans le répertoire
@@ -323,5 +348,5 @@ func run(ctx context.Context, flagProfile string) error {
 ## Limites Actuelles
 
 - le manifeste gère uniquement la section `[update]`
-- le framework ne fournit pas encore d'interface unique de bootstrap
+- le framework ne fournit pas d'interface unique de bootstrap applicatif
 - l'auto-update reste volontairement simple et ne supporte pas encore de scripts externes