docs: document email-mcp validation boundaries #13
1 changed files with 3 additions and 6 deletions
|
|
@ -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`
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue