Exécutions et preuves externes
Suivez les exécutions asynchrones, interprétez leur résultat et récupérez des preuves sûres à durée de vie limitée.
run.trigger met le travail en file et renvoie immédiatement. Suivez chaque runId renvoyé avec run.get ; récupérez run.evidence lorsque vous avez besoin des faits qui étayent un résultat.
Suivre une exécution avec un curseur
Le premier appel run.get n’a besoin que de l’identifiant de l’exécution :
1{2 "runId": "jh7examplerunid"3}Conservez son cursor numérique. Pour attendre un changement, envoyez le même identifiant, ce curseur et waitMs :
1{2 "runId": "jh7examplerunid",3 "cursor": 42,4 "waitMs": 250005}L’adaptateur HTTP interroge une fois par seconde et renvoie dès que le curseur augmente, que l’exécution atteint un statut terminal ou que l’attente expire. waitMs est borné entre 0 et 25000 millisecondes ; une valeur supérieure est ramenée à 25000. Une réponse avec timedOut: true est une réussite : aucune modification n’est survenue pendant la fenêtre. Répétez avec le même curseur ou cessez d’attendre ; ne la traitez pas comme une erreur API.
La réponse contient aussi la progression, l’état de chaque étape, la disponibilité des preuves et next. next est un conseil, jamais une autorité : décidez à partir de status, verdict, validity, de la progression et des étapes.
Statut, verdict et validité
Ces champs sont distincts. status décrit l’état d’exécution, verdict le résultat visible par le client lorsqu’il existe et validity indique si l’exécution a pu être évaluée.
status | verdict | validity | Signification |
|---|---|---|---|
queued | Absent | not_evaluated | En attente de démarrage. |
running | Absent | not_evaluated | Exécution en cours. |
retrying | Absent | not_evaluated | Nouvelle tentative en cours, sans résultat final. |
passing | passed | valid | Exécution terminée avec un verdict positif. |
failed | failed | valid | Exécution terminée ayant démontré un échec. |
unverified | unverified | valid | Exécution terminée sans preuve de réussite ou d’échec. |
canceled | unverified | valid | Exécution annulée sans résultat vérifié. |
invalid | unverified | invalid | L’exécution n’a pas pu produire une évaluation valide. |
passing, failed, unverified, canceled et invalid sont terminaux pour l’attente longue. Dans la réponse, next vaut wait pour queued, running ou retrying, retry pour invalid, evidence pour failed, unverified ou une exécution positive mais instable, et none sinon.
Preuves externes
Appelez POST /api/v1/run.evidence avec runId et, facultativement, un filtre numérique step. La réponse contient le statut, le verdict et la validité de l’exécution, ainsi que les preuves sûres pour chaque étape incluse :
- indice de l’étape, action rédigée et cible facultative ;
- statut d’étape
passed,failedouskippedet motif ; - faits observés, attente rédigée, source du verdict et preuve de la postcondition ;
- nombre de récupérations et diagnostic avec catégorie et action suggérée ;
- noms d’actions neutralisés et cibles ;
- liens de capture d’écran, d’image ou de vidéo avec leur expiration ;
- durée de l’étape.
Les preuves externes n’incluent jamais l’identité du modèle ou du fournisseur, les prompts, les jetons ou coûts, les erreurs brutes du runner, les noms d’outils internes, les détails internes du runner ni les arbres d’interface bruts.
Liens média signés
Chaque média renvoyé par run.evidence possède une url signée et un expiresAt. L’URL appelle :
GET /api/v1/evidence/<id>?kind=<screenshot|frame|video>&exp=<epoch-ms>&sig=<signature>Le lien est valide 15 minutes et ne demande pas d’identifiant Bearer, car la signature porte l’autorisation de courte durée. Une requête valide redirige avec 302 vers l’URL de stockage temporaire. Une signature invalide ou expirée renvoie 403 ; un média absent renvoie 404. Rappelez run.evidence pour obtenir de nouveaux liens au lieu de modifier les paramètres.
Valeurs d’environnement et secrets
Les cibles d’environnement peuvent stocker des valeurs d’exécution nommées. environment.list et environment.get ne renvoient que runtimeValueNames, jamais les valeurs. Dans une étape de saisie UI, référencez-en une par son nom :
1{2 "action": "fill",3 "target": "Password",4 "valueSpec": {5 "kind": "environment",6 "variable": "LOGIN_PASSWORD"7 }8}Pour un secret référencé, Autonomy transmet la valeur au runner via le canal de récupération authentifié par TLS juste avant l’exécution. Le runner la conserve uniquement en mémoire. Le modèle voit un espace réservé {{env.LOGIN_PASSWORD}}, et le harnais ne substitue la valeur qu’au moment d’envoyer l’action de saisie. La valeur est ajoutée à la suppression des traces, diagnostics, journaux, preuves externes et mémoire de playbook ; elle n’est jamais écrite sur disque ni renvoyée par une route du runner.
Si une valeur référencée manque, l’exécution échoue de manière fermée avant le début des étapes avec un diagnostic environment. Le runner de nouvelle génération prend en charge cette substitution ; le runner stable refuse de réclamer les exécutions dont les étapes référencent des valeurs d’environnement plutôt que de s’exécuter sans le secret.
Les valeurs d’exécution des cibles API sont distinctes : run.trigger peut les transmettre dans targets.api.runtimeValues, tandis que les liaisons d’identifiants API continuent de résoudre {{env.NAME}} depuis l’environnement hôte du runner.