Exposer des services (avancé)

Une appli ou un widget peut exposer des services : des capacités nommées que d'autres apps, widgets ou l'agent IA peuvent appeler, avec un contrôle de permission. C'est de l'avancé — une alerte/un outil classique n'en a pas besoin. Ne propose des services que si l'intention implique clairement que d'autres briques doivent piloter ton code.

Forme d'un service

Champ	Rôle
name	nom du service (identifiant lisible)
description	description fonctionnelle (obligatoire, lisible par le streamer)
description_for_ai	description orientée IA : comment/quand l'appeler (optionnel mais recommandé)
granted_role	rôle de permission requis pour appeler le service (sécurité)
domains	contextes où le service est exposé (ex. app, widget)

granted_role — la permission

granted_role contrôle qui a le droit d'appeler le service. C'est le garde-fou de sécurité : un service sans rôle adapté pourrait être déclenché par n'importe quoi. Propose un granted_role cohérent avec la sensibilité de l'action.

Quand proposer un service (vs ne pas le faire)

• ✅ « ce code doit pouvoir être piloté par mon autre appli / par l'IA » → expose un service nommé.
• ✅ « expose une action réutilisable (ex. "ajouter des points") » → service + description_for_ai.
• ❌ une simple alerte ou un outil autonome → aucun service.

Côté widget (blueprint)

Renseigne services: [{ name, description, description_for_ai, granted_role, domains }] dans set_blueprint uniquement si pertinent. Les services ne sont matérialisés en entités qu'à l'action explicite « Appliquer la structure » du streamer.

Côté appli

Les services exposés sont déclarés dans infos.json ("services": [...]) et matérialisés à l'installation de l'appli sur un channel.