Anatomie d'une config

Une config tient en un fichier YAML. Ce guide le parcourt dans l'ordre de la version cible ; ce qui n'existe pas encore aujourd'hui le dit, et renvoie à la cible.

station:                   # STATION — qui elle est
  id: teranga
  name: Teranga Kitchen
  identity: {...}           # AUTH — les fournisseurs qui prouvent une donnée (un code)
global: {...}               #   sa langue, sa devise
domain: {...}

apis:      [...]            # SOURCES — ce que le tenant expose
catalog:   {...}            #   d'où vient la recherche du catalogue

                            # CONTEXTE — les rooms et les sessions : la plateforme les tient

submit_guard: {...}         # POLITIQUES — les gardes ; le submit guard de la station

skills:    [...]            # CAPACITÉS — ce que voit l'agent : ce qui peut être proposé, choisi, exécuté
playbooks: [...]            #   les parcours

agent:                      # AGENT — sa voix, son modèle
  portals:
    web: {...}              #   le site du tenant : le widget, son thème, ses textes
mcp: {...}

Le comportement se règle surtout dans les sources, les politiques et les capacités. Si une station se comporte mal, c'est là qu'il faut chercher d'abord ; puis dans agent, qui change ce que lit le modèle.

Le plan du guide

	page	ce qu'on y règle aujourd'hui
1	Anatomie	la forme du fichier
2	Station	station.id, station.name, domain, la langue, la devise
3	Sources	apis, catalog
4	Contexte	ce que la plateforme tient : rooms, sessions, sélection, fil de conversation
5	Auth	identifies: true : une donnée tapée identifie la room ; station.identity.providers : un code la prouve
6	Politiques	les select guards (form, require, check, update) et leurs conditions, le submit guard, d'où viennent les valeurs, combien de temps tout est gardé
7	Capacités	skills, playbooks, le submit
8	Agent et portails	agent, agent.portals.web, mcp
9	Vérifier et publier	ce que Core dit au chargement, les tests

Deux règles qui valent pour tout le fichier

• Chaque clé est lue. Une clé que Core ne connaît pas est refusée au chargement, avec son chemin (agent.portals.web.widget.theme.primary_colour) : elle ferait croire qu'elle a un effet. Une faute de frappe est donc détectée, dans un fichier comme par l'API du provisioner.
• Chaque référence est vérifiée au chargement. Un appel du submit qui nomme une opération absente des apis, une tâche qui nomme une skill inconnue, une condition qui lit un champ non déclaré : la station refuse de démarrer, avec un message qui dit où et quoi corriger. Voir Vérifier et publier.

L'ordre d'écriture

Chaque couche ne cite que celle du dessous. On écrit donc de bas en haut :

1. apis — ce que le tenant expose ;
2. skills — sur ces opérations ;
3. playbooks — sur ces skills ;
4. submit_guard — ce qu'on exige avant d'exécuter.