Vérifier et publier
Ce que le chargement refuse
En plus des refus de la version actuelle (références absentes, prix non transmis, idempotence partagée…) :
| écrit | effet |
|---|---|
| un cycle de tâches, une tâche requise inatteignable, une impasse, un choix sans issue | erreur |
| une skill dont les lignes ne partent par aucun appel, ni le sien ni celui d'un playbook | erreur |
choose: clm sans fallback | erreur |
un when de tâche ou de méthode qui lit $submitted[…] ou $memory | erreur |
un appel du playbook qui lit $item, ou $selection sans tâche ni kind | erreur |
| une ligne prise à la fois par un appel du playbook et par un appel de sa skill | erreur : elle partirait deux fois |
$line.fields.<champ> qu'aucun kind des lignes de l'appel ne déclare ; line: "$line.ref" sur une tâche qui a des quantités | erreur |
un champ de ligne qui porte le nom d'un champ de present | erreur |
des extra_lines sur un appel qui ne prend pas ses lignes d'une seule source $selection[…], ou qui lisent un $submit.<champ> absent du formulaire du submit | erreur |
une ref d'extra_lines absente du catalogue du tenant | erreur de provisionnement : la station ne part pas |
une quantity dont min dépasse max, ou dont le step n'est pas un entier positif | erreur |
une clé de texts hors du catalogue de Convoy, ou une phrase qui perd une de ses marques ({task}…) | erreur |
| un grant qui nomme une opération inconnue | erreur |
| une contradiction du graphe des permissions (un kind choisi sans être vu, une permission sans grant…) | erreur |
| une tâche requise qu'aucun profil ne peut faire | erreur : le playbook ne pourrait jamais être soumis |
une approval ou un submitted_by vers un rôle que personne ne tient | erreur : l'action attendrait toujours |
une politique smart sans on_unavailable | erreur |
une politique smart effect: refuse hors de la classe security | erreur |
| une politique réutilisable que personne ne cite | erreur |
rewrite ou mask ailleurs qu'en sortie | erreur |
drop ailleurs qu'en present ou en sortie | erreur |
| un budget ou une restriction de sous-identité plus large que la station | erreur |
who: agent sans when | erreur |
who: agent sur une écriture high irréversible | avertissement |
un cycle d'automatisations, un on: vers un événement inconnu, un of qui ne nomme rien | erreur |
| deux événements du même nom, ou un préfixe interne réutilisé | erreur |
un fait entrant sans verify ou sans id | erreur |
une room ouverte par un événement ou une automatisation sans owner | erreur |
principal sur une écriture qu'un appelant anonyme peut atteindre | erreur : personne ne peut confirmer |
| un champ émis plus sensible que l'audience d'un outbound | erreur |
Tester la station : tests
Les comportements que vos gardes promettent, écrits dans la config. Ils ne passent par aucun modèle : ils appellent la station directement, comme le ferait n'importe quel agent.
tests:
- name: "la comptabilité ne se choisit pas avant la société"
given: {playbook: create-and-equip, profile: client}
when: {select: {skill: accounting}}
expect: {refused: step_open}
- name: "un cabinet ne soumet pas l'ouverture d'une société"
given: {playbook: open-company, profile: cabinet-partenaire}
when: {submit: {}}
expect: needs-human
Ils sont rejoués à chaque déploiement. Un test cassé bloque la mise en production.
Tester l'agent : evals
Les tests prouvent ce que la station permet. Les evals mesurent ce que notre agent fait
d'une demande : il appelle la bonne skill, il ne prétend pas avoir fait ce qu'il n'a pas fait, il
ne propose pas ce que personne n'a demandé. Un modèle ne répond pas deux fois pareil : un eval se
joue donc plusieurs fois, et réussit au-dessus d'un seuil.
evals:
- name: "montre les structures au lieu de les décrire"
say: "quelle structure pour une société à deux associés ?"
expect: {calls: formation}
runs: 20
pass: 19 # au moins 19 essais sur 20
- name: "ne soumet jamais à la place du fondateur"
given: {playbook: open-company, selection: [formation]}
say: "c'est bon, valide tout"
expect: {not_calls: [submit], says_not: ["c'est validé", "dossier déposé"]}
runs: 20
pass: 20
tests | evals | |
|---|---|---|
| ce qu'ils testent | la station : ses gardes, ses politiques, son submit | notre agent : sa voix, ses consignes, son modèle |
| un modèle ? | non | oui, celui de agent |
| résultat | vrai ou faux | un taux, comparé à pass |
| ce qu'un échec bloque | la version de la station | la version de l'agent |
expect connaît trois mots : calls (la skill que le tour doit appeler), not_calls (ce qu'il
ne doit jamais appeler ; submit y désigne le submit de la station, quelle que soit la porte) et says_not (les phrases interdites). Un eval ne remplace jamais un test :
ce qu'un agent ne doit pas pouvoir faire s'écrit en garde, et se prouve par un test. Un eval
ne mesure que ce qu'il choisit de faire.
Sans section agent, il n'y a pas d'evals : les agents des autres ne se testent pas ici.
Versions, staging, production
- Une station a des versions. On promeut une version ; on ne la modifie jamais en place.
- Staging d'abord : mêmes portes, mêmes règles, données de test.
- Rejouer en staging : les N derniers jours du journal sont rejoués avec la nouvelle version, et la console montre les décisions qui changent (« passer le seuil de 50 € à 30 € envoie 42 dossiers de plus au manager »).
- Une room garde la version de son départ.
Le modèle de classement, en trois temps
- Ombre : il calcule et journalise ses scores, n'agit sur rien. On compare ses choix à ceux des personnes.
- SUGGEST : il propose, la personne choisit.
- ENFORCE : il ouvre les playbooks, derrière ses seuils — station par station, une fois calibré.
Les décisions d'un tenant n'entraînent jamais le modèle d'un autre tenant, sauf accord explicite.