docs: document email-mcp validation boundaries #13

Closed
thibaud-lclr wants to merge 2 commits from refs/pull/13/head into main
Showing only changes of commit df4ad36700 - Show all commits

View file

@ -35,12 +35,9 @@ Le flux typique côté application est :
4. Charger `mcp.toml` avec `manifest`. 4. Charger `mcp.toml` avec `manifest`.
5. Exécuter l'auto-update avec `update` si nécessaire. 5. Exécuter l'auto-update avec `update` si nécessaire.
## Validation Avec `email-mcp` ## Frontières Du Framework
La migration de [`email-mcp`](../email-mcp) sert de cas réel de validation du Ce qui est mutualisé par le framework :
framework.
Ce qui est aujourd'hui mutualisé et utilisé tel quel par `email-mcp` :
- la résolution du profil actif via `cli` - la résolution du profil actif via `cli`
- le stockage JSON versionné de la config via `config` - le stockage JSON versionné de la config via `config`
@ -58,7 +55,7 @@ Ce qui reste volontairement spécifique à l'application cliente :
Ces limites sont des choix explicites : le framework fournit des briques 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 réutilisables, mais ne force pas une couche de bootstrap unique ni un contrat
applicatif trop spécifique à un premier consommateur. applicatif trop spécifique à une application donnée.
## Manifeste `mcp.toml` ## Manifeste `mcp.toml`