Valider le framework en migrant email-mcp dessus #10

New issue

Closed

opened 2026-04-13 14:35:47 +00:00 by thibaud-lclr · 2 comments

thibaud-lclr commented

2026-04-13 14:35:47 +00:00

(Migrated from gitea.lclr.dev)

La prochaine vraie validation du framework sera sa capacité à absorber email-mcp sans tordre son design métier.

Objectif : utiliser la migration de email-mcp comme banc d’essai pour fermer les trous du framework.

À couvrir :

identifier précisément ce qui doit être mutualisé et ce qui doit rester spécifique à email-mcp
suivre les écarts bloquants au fur et à mesure de la migration
éviter d’introduire des abstractions trop spécifiques à Graylog

Critères d’acceptation :

email-mcp peut s’appuyer sur le framework pour sa CLI, sa config et/ou ses secrets là où c’est pertinent
les limitations restantes sont documentées comme choix explicites plutôt que comme manques implicites

La prochaine vraie validation du framework sera sa capacité à absorber `email-mcp` sans tordre son design métier. Objectif : utiliser la migration de `email-mcp` comme banc d’essai pour fermer les trous du framework. À couvrir : - identifier précisément ce qui doit être mutualisé et ce qui doit rester spécifique à `email-mcp` - suivre les écarts bloquants au fur et à mesure de la migration - éviter d’introduire des abstractions trop spécifiques à Graylog Critères d’acceptation : - `email-mcp` peut s’appuyer sur le framework pour sa CLI, sa config et/ou ses secrets là où c’est pertinent - les limitations restantes sont documentées comme choix explicites plutôt que comme manques implicites

thibaud-lclr commented

2026-04-13 15:41:41 +00:00

(Migrated from gitea.lclr.dev)

Je vois cette issue comme une issue de validation pour v1.1, pas comme une méta-issue qui doit attendre la livraison complète de v1.2 et v1.3.

L'idée est plutôt : utiliser la migration de email-mcp comme banc d'essai pour confirmer que les fondations actuelles du framework sont assez saines pour être réutilisées, puis faire remonter explicitement les écarts découverts pendant cette migration.

Concrètement :

#10 peut être traitée dès maintenant dans v1.1
les besoins révélés côté CLI / bootstrap / diagnostics peuvent alimenter v1.2
les besoins révélés côté manifeste / update / scaffolding peuvent alimenter v1.3
en revanche, #10 ne devrait pas être interprétée comme bloquée par la livraison exhaustive de toutes ces issues

Autrement dit, le bon résultat attendu ici est :

identifier ce qui est déjà mutualisable pour email-mcp
documenter ce qui doit rester spécifique
ouvrir ou rattacher les manques restants aux milestones suivantes, au lieu de les garder implicites dans cette issue

Je laisse donc l'issue ouverte pour servir de fil conducteur pendant la migration, mais son rôle est bien de valider les foundations et de dispatcher les suites, pas d'attendre que tout v1.2 / v1.3 soit terminé.

Je vois cette issue comme une issue de validation pour `v1.1`, pas comme une méta-issue qui doit attendre la livraison complète de `v1.2` et `v1.3`. L'idée est plutôt : utiliser la migration de `email-mcp` comme banc d'essai pour confirmer que les fondations actuelles du framework sont assez saines pour être réutilisées, puis faire remonter explicitement les écarts découverts pendant cette migration. Concrètement : - `#10` peut être traitée dès maintenant dans `v1.1` - les besoins révélés côté CLI / bootstrap / diagnostics peuvent alimenter `v1.2` - les besoins révélés côté manifeste / update / scaffolding peuvent alimenter `v1.3` - en revanche, `#10` ne devrait pas être interprétée comme bloquée par la livraison exhaustive de toutes ces issues Autrement dit, le bon résultat attendu ici est : - identifier ce qui est déjà mutualisable pour `email-mcp` - documenter ce qui doit rester spécifique - ouvrir ou rattacher les manques restants aux milestones suivantes, au lieu de les garder implicites dans cette issue Je laisse donc l'issue ouverte pour servir de fil conducteur pendant la migration, mais son rôle est bien de valider les foundations et de dispatcher les suites, pas d'attendre que tout `v1.2` / `v1.3` soit terminé.

thibaud-lclr commented

2026-04-13 18:00:12 +00:00

(Migrated from gitea.lclr.dev)

Bilan de validation :

s'appuie bien sur le framework pour la resolution de profil, la config, le secret store, le manifeste et l'update.
Le reste est reste specifique a l'application, ce qui confirme qu'on n'a pas force d'abstraction metier prematuree dans le framework.
Aucun nouveau manque structurant n'a emerge pendant la migration qui justifierait une issue supplementaire immediate.

Conclusion : l'issue a rempli son role de validation. La PR de documentation du README n'apporte pas assez de valeur produit et est fermee au profit de cette trace dans l'issue.

Bilan de validation : - s'appuie bien sur le framework pour la resolution de profil, la config, le secret store, le manifeste et l'update. - Le reste est reste specifique a l'application, ce qui confirme qu'on n'a pas force d'abstraction metier prematuree dans le framework. - Aucun nouveau manque structurant n'a emerge pendant la migration qui justifierait une issue supplementaire immediate. Conclusion : l'issue a rempli son role de validation. La PR de documentation du README n'apporte pas assez de valeur produit et est fermee au profit de cette trace dans l'issue.