Aller au contenu

API JavaScript

Repeato vous permet d’exécuter du JavaScript à l’aide des étapes de script. Les variables globales suivantes sont disponibles pendant l’exécution d’un test ou d’un lot.

Pour une documentation lisible par machine, utilisez la référence Markdown brute ou les déclarations TypeScript. Voir Recettes JavaScript pour des exemples complets et exécutables.

Type : object

Un objet que vous pouvez utiliser pour partager des données entre les étapes.

Type : string

Chaîne scannée par la dernière étape Vérifier le texte exécutée.

Type : string

Répertoire de l’espace de travail actuel.

Type : number

Index de base zéro de l’étape en cours d’exécution.

Type : string

Le répertoire du test actuel.

Type : string

Le répertoire de l’exécution de test actuelle.

Type : AxiosInstance

Client HTTP Axios.

const response = await axios.get('https://example.com')
Signature
log(message: object)

Consigne un message ou un objet.

Signature
sleep(milliseconds: number): Promise<void>

Retarde l’exécution du nombre de millisecondes indiqué.

Signature
getResponse(host: string, path: string, headers?: object): Promise<string>

Envoie une requête GET à un hôte.

Signature
sendPost(
host: string,
path: string,
body: string | object,
acceptHeader?: string,
headers?: object,
): Promise<string>

Envoie une requête POST.

Signature
showDialog({
title,
content,
onConfirm,
onClose,
}: {
title: string
content: string
onConfirm?: () => void
onClose?: () => void
}): { cancel: Function; confirm: Function }

Affiche une boîte de dialogue dont le contenu prend en charge Markdown, notamment le texte mis en forme, les liens et les images. Les rappels facultatifs s’exécutent lorsque l’action correspondante a lieu. L’instance de boîte de dialogue renvoyée peut être fermée à l’aide de cancel() ou confirm().

Contrôle le lot de tests actuel et fournit des hooks pour son cycle de vie.

Type : TestBatch

Lot de tests actuel.

Type : number

Index du gestionnaire d’exceptions actuel.

Type : number

Index du test actuel.

Type : BatchRun

Exécution du lot actuelle. Utilisez log(batchRunner.batchRun) pour inspecter toutes les propriétés.

Type : boolean

Indique si l’exécuteur de lots est en cours d’exécution.

Type : string

Mode d’exécution actuel.

stop(): Promise<void>

Arrête l’exécuteur de lots.

Signature
createBatchRunExport(): Promise<string>

Crée une exportation de l’exécution du lot actuel dans le batchRuns dossier de l’espace de travail et renvoie son chemin.

Signature
uploadReport(dirPath: string): Promise<string>

Téléverse le rapport situé à dirPath vers le cloud Repeato et renvoie l’URL du rapport.

Signature
batchRunner.setTestBatchById(batchId: string)

Définit le lot de tests de l’exécuteur de lots.

Signature
batchRunner.setRunMode(mode: string)

Définit le mode d’exécution sur tous les tests ou uniquement les tests échoués.

batchRunner.setRunMode('AllTests')
batchRunner.setRunMode('OnlyFailed')
Signature
batchRunner.addOnBatchStart(key: string, callback: (batch: Batch) => void)

Enregistre un rappel qui s’exécute juste avant le début du lot.

Signature
batchRunner.addOnTestFail(
key: string,
callback: (test: Test, testRun: TestRun, stepResult: StepResult) => void,
)

Enregistre un rappel qui s’exécute lorsqu’un test échoue.

Signature
batchRunner.addOnTestSuccess(
key: string,
callback: (test: Test, testRun: TestRun) => void,
)

Enregistre un rappel qui s’exécute lorsqu’un test réussit.

Signature
batchRunner.addOnBatchCompleted(
key: string,
callback: (batchRun: BatchRun) => void,
)

Enregistre un rappel qui s’exécute lorsque le lot se termine, qu’il réussisse ou échoue.

Signature
batchRunner.removeOnBatchStart(key: string)

Supprime un rappel enregistré avec addOnBatchStart().

Signature
batchRunner.removeOnTestFail(key: string)

Supprime un rappel enregistré avec addOnTestFail().

Signature
batchRunner.removeOnTestSuccess(key: string)

Supprime un rappel enregistré avec addOnTestSuccess().

Signature
batchRunner.removeOnBatchCompleted(key: string)

Supprime un rappel enregistré avec addOnBatchCompleted().

Type : TestRunner

Donne accès à tous les testRunner propriétés et méthodes. Utilisez log(batchRunner.testRunner) pour les inspecter.

Contrôle l’exécution du test actuel et expose les hooks du cycle de vie des étapes.

Type : Test

Le test actuel. Utilisez log(testRunner.currentTest) pour inspecter toutes les propriétés.

Type : TestRun

L’exécution de test actuelle. Utilisez log(testRunner.currentTestRun) pour inspecter toutes les propriétés.

testRunner.currentTestRun.partial est un booléen synchrone en lecture seule sur toutes les plateformes, disponible dans les étapes de script et les callbacks de configuration avancée. Il vaut vrai pour l’exécution d’une seule étape ou l’exécution jusqu’ici, sans interaction avec l’appareil ni autre effet de bord. Les exécutions partielles conservent leurs résultats d’étapes, mais ne peuvent ni réussir ni devenir des exécutions de référence ; wasSuccessful reste faux. Les anciennes exécutions enregistrées utilisent par défaut partial: false.

Type : StepResult

Le résultat de l’étape précédemment exécutée. Utilisez log(testRunner.lastStepResult) pour inspecter toutes les propriétés.

Cliquer sur les éléments de preuve de l’accord sémantique

Section intitulée « Cliquer sur les éléments de preuve de l’accord sémantique »

Dans les étapes Script et les callbacks de configuration avancée, step.semanticAgreement est un indicateur de configuration synchrone et en lecture seule pour les clics (false par défaut ; absent pour les autres types d’étapes). Configurez-le via l’éditeur de clics de Repeato Studio ou MCP. Les clics activés nécessitent une hiérarchie récente avec une cible sémantique visible et unique contenant le point de tap proposé ; en cas d’échec, le tap est refusé, et les appareils sans hiérarchie ni localisateurs utilisables ne peuvent pas établir l’accord.

stepResult.semanticAgreement est une lecture synchrone sans effets secondaires. Il est présent lorsque le garde-fou a évalué une cible et contient agreed, reason, candidateCount, ainsi qu’une cible bounds, résolue locators ou une cible ambiguë locatorType. Les limites utilisent des coordonnées normalisées de 0 à 1. L’absence d’éléments de preuve ne signifie pas que l’accord a été validé. Cela consigne l’accord géométrique, et non la livraison effective de l’événement ni les résultats métier.

Inspecter les éléments de preuve du clic précédent
const agreement = testRunner.lastStepResult?.semanticAgreement
if (agreement) log(agreement)

Dans les étapes Script et la configuration avancée, stepResult.executionEvidence est une propriété facultative, synchrone et en lecture seule, disponible sur les résultats de correspondance/clic nouvellement exécutés avant les callbacks de fin d’étape. Elle renvoie les faits d’exécution enregistrés ou undefined pour les résultats plus anciens, sans effet secondaire sur l’appareil. Elle inclut searchedRegion, requestedLocators, matchSource, facultatif resolvedLocator, matchedBounds, la tentative réelle tapPointainsi que les horodatages et statuts de distribution. Les limites et les points de tap utilisent des coordonnées normalisées sur l’image complète, de 0 à 1 ; la largeur et la hauteur de l’image source correspondent aux pixels de l’image traitée. Les clics par coordonnées n’ont ni région de recherche ni limites d’élément résolues.

sourceFrame identifie une capture d’écran associée au résultat. Son phase distingue exactement l’entrée du worker matching_frame d’une capture d’écran lue after_locator_resolution (qui n’est pas la hiérarchie utilisée pour résoudre le locator). receivedAt est un horodatage ISO de réception/lecture côté client, et non un horodatage de capture du fournisseur ; matchedAt enregistre la fin du worker lorsqu’elle est connue. Les captures d’écran sont des noms de fichiers relatifs au répertoire d’exécution normal, récupérés via l’API de captures d’écran de l’exécution ou les métadonnées d’artefact MCP. Les champs manquants restent à null. Les buffers de correspondance ne sont pas intégrés directement au résultat.

tapStatus est not_dispatched, dispatching, completed (la commande du pilote a été résolue), ou unknown (une commande rejetée après sa distribution peut avoir été partiellement appliquée). La fin d’une distribution ne prouve ni la livraison de l’événement ni le résultat souhaité dans l’application. Une image correspondante est historique ; l’écran physique peut changer avant le tap. Aucune nouvelle tentative automatique n’est effectuée en cas de distribution incertaine.

stepResult.warnings est un tableau en lecture seule de codes d’avertissement. Un repli de locator réussi conserve success: true et ajoute fingerprint_fallback_used ; les avertissements n’empêchent plus son tap. Les étapes facultatives ayant échoué peuvent toujours avoir success: undefined . Les limites dérivées d’un locator utilisent leur centre sans appliquer de décalage de fingerprint enregistré ; les clics par fingerprint/OCR conservent le comportement de décalage configuré.

Inspecter les faits d’exécution sans prendre de nouvelle capture d’écran
const result = testRunner.lastStepResult
if (result?.executionEvidence) {
log(result.executionEvidence)
log(result.warnings)
}

Dans les étapes Script et la configuration avancée, stepResult.failureEvidence est une valeur persistante facultative, en lecture seule. Sa lecture est synchrone, renvoie les éléments de preuve stockés ou undefined et n’a aucun effet côté appareil. Repeato Studio la capture après les étapes en échec (y compris les échecs facultatifs), une fois que les addOnStepCompleted rappels sont terminés. Ces rappels ne voient pas encore cette capture ; les étapes Script suivantes ou les rappels d’échec du test peuvent l’examiner lorsque l’exécution se poursuit. Les résultats réussis et les résultats plus anciens peuvent ne pas l’inclure.

failureEvidence.hierarchy contient status (captured, unavailable ou capture_failed), data (la hiérarchie complète du pilote sérialisable en JSON ou null), et capturedAt (un horodatage ISO ou null ). La capture nécessite un appareil connecté prenant en charge les hiérarchies et est soumise à un délai de trois secondes. L’absence de prise en charge des hiérarchies, la déconnexion, l’expiration du délai ou les erreurs de sérialisation n’entraînent pas l’échec supplémentaire du test. La capture a lieu après l’action en échec, séparément de sa capture d’écran. Une hiérarchie vide est distincte de données indisponibles.

Les éléments de preuve comprennent également la classification, les étapes de recherche lorsqu’elles sont disponibles et le minutage de la capture. La visibilité inconnue du clavier, les limites de l’IME, le décalage de défilement, le package au premier plan et la transmission des appuis restent inconnus. Les attributs et les limites de la hiérarchie conservent la structure et les unités propres au pilote ; ils ne sont pas coordonnées tactiles normalisées entre 0 et 1. Les hiérarchies peuvent contenir le texte saisi. Les éléments de preuve restent dans la structure d’exécution normale. Chaque test conserve au maximum cinq exécutions, en protégeant l’exécution de référence ; les résultats échoués ou interrompus ainsi que les captures d’écran sont conservés jusqu’à l’éviction de leur exécution. Les exportations manuelles peuvent conserver une copie plus longtemps. MCP repeato_get_step_result renvoie le JSON complet des résultats, y compris cette hiérarchie, à partir des exécutions de test conservées.

Examiner les éléments de preuve d’un échec stockés sans contacter l’appareil
const evidence = testRunner.lastStepResult?.failureEvidence
if (evidence?.hierarchy.status === 'captured') {
log(evidence.hierarchy.data)
}

Type : number

L’index de base zéro de l’étape actuelle.

Signature
testRunner.setNextStepId(id: string)

Définit par ID l’étape à exécuter ensuite.

testRunner.setNextStepId('AH23D6')
Signature
testRunner.setNextStepIndex(index: number)

Définit l’étape à exécuter ensuite à l’aide de son index commençant à zéro.

Signature
testRunner.goBackBy(stepCount: number)

Recule de stepCount étapes et reprend l’exécution à partir de là.

Signature
testRunner.addOnScreenshotSaved(
key: string,
listener: (stepResult: StepResult, screenshotPath: string) => void,
)

Enregistre un écouteur qui s’exécute dès qu’une capture d’écran a été enregistrée.

Signature
testRunner.addOnStepCompleted(
key: string,
callback: (stepResult: StepResult) => void,
)

Enregistre un callback qui s’exécute chaque fois qu’une étape se termine.

Signature
testRunner.removeOnScreenshotSaved(key: string)

Supprime un écouteur enregistré avec addOnScreenshotSaved().

Signature
testRunner.removeOnStepCompleted(key: string)

Supprime un rappel enregistré avec addOnStepCompleted().

Signature
testRunner.setScaleInvariantMatchingEnabled(enabled: boolean)

Active ou désactive la correspondance indépendante de l’échelle. Elle est activée par défaut.

Fournit des informations sur l’appareil actuellement connecté et lui envoie des commandes.

Type : DeviceData

Toutes les données liées à l’appareil actuellement connecté. Utilisez log(deviceConnector.selectedDeviceData) pour l’inspecter.

Signature
sendString(value: string): Promise<void>

Envoie une chaîne à l’appareil. L’application testée doit disposer d’un champ de saisie actif pour recevoir les données.

Signature
clearText(): Promise<void>

Disponible dans les étapes Script et la configuration avancée avec un appareil connecté et un champ de saisie actif. Efface ce champ de manière asynchrone et se résout sans valeur ; ne saisit pas de texte de remplacement.

Sur Android cloud, utilise le menu de sélection par appui prolongé du champ de saisie et l’option Tout sélectionner, puis appuie sur Retour arrière et vérifie que le champ est vide. Nécessite un EditText actif et inspectable, ainsi qu’un contrôle de sélection disponible ; aucun ADB n’est utilisé. L’effacement sur iOS cloud n’est pas pris en charge. L’absence de focus, les contrôles indisponibles, les appareils non pris en charge et les délais d’expiration du fournisseur rejettent la promesse. Un échec peut modifier l’état du champ ou de la sélection ; inspectez donc l’écran avant de réessayer.

Utilisation après avoir activé un champ de saisie
await deviceConnector.clearText()
await deviceConnector.sendString('Replacement text')
Signature
sendClick(xPercentage: number, yPercentage: number): Promise<void>

Envoie un événement tactile à l’appareil. Les coordonnées vont de 0 vers 1; sendClick(0.5, 0.5) tape au centre de l’écran.

Signature
sendDown(xPercentage: number, yPercentage: number): Promise<void>

Envoie un événement d’appui tactile. Chaque sendDown() nécessite un sendUp() ; combinez-le avec sendMove() pour simuler un geste de glissement.

Signature
sendMove(xPercentage: number, yPercentage: number): Promise<void>

Envoie un événement de déplacement. Utilisez sendDown() en premier, puis terminez le glissement avec sendUp().

Signature
sendUp(xPercentage: number, yPercentage: number): Promise<void>

Envoie un événement de relâchement tactile.

Signature
sendAdbCommand(command: string): Promise<string>

Envoie une commande Android Debug Bridge (ADB).

Signature
deviceConnector.addOnDeviceLog(
listenerName: string,
callback: (log: string) => void,
)

Enregistre un callback qui s’exécute pour chaque ligne de journal envoyée par l’application testée.

Signature
sendIdbCommand(command: string): Promise<string>

Envoie une commande iOS Development Bridge (IDB).

await deviceConnector.sendIdbCommand('list-targets')
Signature
takeScreenshot(filepath: string): Promise<void>

Prend une capture d’écran et l’enregistre à l’emplacement filepath.

Signature
setClipboard(content: string): Promise<void>

Définit le contenu du presse-papiers de l’appareil sur une chaîne.

getClipboard(): Promise<string>

Récupère le contenu du presse-papiers de l’appareil.

Signature
vision(
prompt: string,
region: { x: number; y: number; width: number; height: number } | undefined,
): Promise<string>

Envoie une invite et une capture d’écran de l’écran actuel de l’appareil au module de vision. Transmettez une région pour limiter la capture à une partie de l’écran.

Fournit la synthèse vocale, la lecture audio et l’enregistrement audio.

Signature
audioTools.say(text: string)

Convertit le texte fourni en audio.

Signature
playAudio(url: string): Promise<number>

Lit l’audio depuis l’URL fournie.

audioTools.stopAudio()

Arrête la lecture audio en cours.

Signature
recordAudio(duration: number): Promise<string>

Enregistre de l’audio pendant la durée indiquée en millisecondes et renvoie l’URL de l’enregistrement temporaire.

Preuves d’exécution OCR et des localisateurs

Section « Preuves d’exécution OCR et des localisateurs »

testRunner.lastStepResult.executionEvidence est un instantané synchrone en lecture seule. Son objet facultatif ocr conserve le dernier texte entièrement reconnu dans recognizedText, même lorsque la comparaison échoue, ainsi que le moteur, le texte attendu, l’opérateur, le nombre d’images traitées et l’heure de fin. Le statut distingue no_frame_processed, no_completed_frame, engine_error, no_text, no_match et matched. En l’absence de sortie terminée, la valeur est null, tandis qu’une reconnaissance terminée sans texte produit une chaîne vide. La référence à l’image source identifie la capture examinée lorsqu’elle est disponible. Une fin tardive du processus de travail ne modifie pas un résultat de délai dépassé déjà renvoyé. L’attente de stabilisation des animations consomme au plus un quart du budget de recherche ou une seconde, laissant le temps restant à la reconnaissance. La durée et la précision de l’OCR dépendent du moteur et du contenu de l’appareil.

executionEvidence.locatorResults enregistre les candidats des localisateurs de hiérarchie et les motifs de rejet. Les mécanismes de repli de hiérarchie native exigent un seul contrôle activé et actionnable dans la région de recherche normalisée configurée ; les libellés statiques, les contrôles ambigus et les points de toucher connus comme masqués par le clavier sont rejetés. Android prend en charge un localisateur exact de hint . En l’absence de preuves sur le clavier, son état reste inconnu. Une correspondance et l’envoi terminé d’une saisie ne prouvent pas le résultat dans l’application.

Les étapes de texte peuvent configurer expectedFocusHint dans Studio ou via MCP. Avant d’effacer ou de saisir pendant l’enregistrement et la relecture, cette vérification facultative lit la hiérarchie de l’appareil de manière asynchrone et exige exactement un champ modifiable ayant le focus et ce texte indicatif exact. Elle échoue avant toute modification si la hiérarchie est indisponible ou si le focus ne correspond pas. Elle ne change pas le focus. step.expectedFocusHint est lui-même une lecture synchrone de l’attente configurée. Android natif expose les textes indicatifs fournis par l’application ou le fournisseur ; les autres plateformes peuvent ne pas les exposer.

Dans les étapes de script et la configuration avancée, les étapes de navigation exposent des propriétés synchrones en lecture seule goal, startCondition, inputReferences et maxActions propriétés. Les autres types d’étapes les omettent. La condition de démarrage facultative doit être vérifiée avant toute action. Les références d’entrée sélectionnent les éléments existants data champs. La navigation envoie les noms sélectionnés et les valeurs résolues au fournisseur dans state.inputData et enregistrées dans les éléments de preuve de la décision. Ne sélectionnez pas de secrets. Les valeurs saisies par l’environnement d’exécution proviennent toujours des données fournies et ne sont pas générées par le modèle. maxActions accepte les valeurs de 1 à 100 et vaut 20 par défaut. La navigation nécessite un appareil avec hiérarchie et captures d’écran, une clé OpenRouter configurée et le modèle de décision pris en charge. Le délai d’expiration hérité de l’étape correspond à son budget total d’exécution en secondes (60 par défaut, 300 maximum).

Après l’exécution, stepResult.executionEvidence.navigation est un objet facultatif, synchrone et en lecture seule, disponible avant les rappels de fin. Il n’a aucun effet secondaire sur l’appareil et est absent des autres résultats ou des anciens résultats. Il contient model (le modèle résolu et épinglé), requestedModel, status, elapsedMs, actionCount, modelCalls et trace. Chaque entrée de trace comprend l’opération, le numéro de cible dynamique, l’état, le temps écoulé en millisecondes, l’élément facultatif goalConfidence, operationConfidence, visibilityDecision (VISIBLE/MASQUÉE/INCERTAINE), visibilityConfidence, inputReference et le nom de fichier exact de la capture d’écran d’observation dans le répertoire d’exécution du test. Les numéros de cible s’appliquent uniquement à cette observation ; ils ne sont pas réutilisables comme sélecteurs. La source de preuve correspondante est navigation ; les actions individuelles sont enregistrées dans la trace de navigation plutôt que dans les champs de tapotement de premier niveau.

Un jugement sur l’objectif, un dépassement de délai, une annulation, une condition de démarrage invalide, une cible non sécurisée, un écran instable, une absence de progression ou l’épuisement du budget met fin à l’étape sans relancer automatiquement le test. La reconnaissance de l’objectif relève du jugement du modèle ; conservez une assertion ordinaire distincte pour le résultat métier final. La géométrie de la hiérarchie utilise des coordonnées normalisées de 0 à 1. Les captures d’écran et le contenu visible de la page sont envoyés au fournisseur de modèle configuré ; utilisez donc des données de démonstration pour les benchmarks et n’incluez pas de secrets dans les objectifs.

Dans les étapes de script et la configuration avancée de Studio et de la CLI, testRun.stepResults est une liste plate et chronologique. Une étape de navigation peut produire plusieurs résultats réels avec le même step.id : des observations informatives suivies d’un résultat final. Lisez ces champs de manière synchrone ; leur lecture n’a aucun effet secondaire. resultKind est intermediate ou final ; les résultats chargés plus anciens prennent par défaut la valeur final . Les éléments facultatifs executionId regroupent une exécution, sequence ordonne ses résultats, et elapsedMs mesure les millisecondes écoulées depuis le début de cette exécution de navigation. L’élément intermédiaire executionEvidence.navigationObservation enregistre l’opération, l’état, la cible et les détails facultatifs d’erreur ou de référence. Sa capture d’écran correspond à l’observation du modèle avant l’action, et non à une confirmation après l’action. screenshot est un nom de fichier facultatif relatif au répertoire d’exécution du test ; une image indisponible n’est pas générée artificiellement.

testRun.getStepResultsByStepId(stepId) renvoie de manière synchrone tous les résultats de cette étape dans l’ordre enregistré, sans modifier l’exécution. getStepResultByStepId(stepId) renvoie le dernier résultat final ou undefined avant la fin. getSuccessfulStepResults() inclut uniquement les résultats finaux réussis. testRunner.lastStepResult et les rappels de fin d’étape font toujours référence au résultat final, et non aux décisions intermédiaires. Les résultats intermédiaires n’augmentent pas les compteurs d’étapes réussies, échouées ou facultatives. Les exécutions historiques existantes conservent leur résultat unique d’origine ; le visualiseur ne convertit pas les traces JSON héritées en résultats inventés.

Pour les nouvelles observations de Navigation, executionEvidence.navigationObservation.decisionInput est un instantané synchrone, en lecture seule, de la requête structurée adressée au modèle : état, questions, modèle/fournisseur et référence de capture d’écran enregistrée. Sa lecture n’a aucun effet secondaire. Il exclut les autorisations et les octets d’image intégrés, et est absent des exécutions plus anciennes. Seules les inputReferences explicitement sélectionnées sont résolues et incluses sous forme de mappage nom-valeur chaîne dans decisionInput.state.inputData. Ces valeurs sont transmises au fournisseur de navigation configuré et conservées dans les éléments de preuve de l’exécution ; ne sélectionnez pas de secrets. L’intégralité de l’objet de données et les champs sans rapport sont exclus. La capture d’écran peut également afficher le contenu visible des champs. Les assertions indépendantes de résultat attendu ne sont pas incluses. Le Batch Run Viewer affiche cet instantané dans une section extensible « Entrée de décision ». La trace finale omet les charges utiles d’entrée en double ; consultez les résultats intermédiaires réels de chaque décision.

Les nouveaux résultats intermédiaires de Navigation exposent des éléments facultatifs executionEvidence.navigationObservation.decisionOutput : le corps JSON exact reçu du modèle, enregistré avant la validation locale de la réponse. Il s’agit d’un instantané synchrone en lecture seule dans Studio et CLI, également accessible via les outils d’exécution et de résultat MCP ; sa lecture n’a aucun effet secondaire. Les en-têtes d’autorisation ne sont jamais enregistrés. Les anciens résultats et les requêtes sans réponse JSON reçue ne l’incluent pas ; les sorties manquantes ne sont jamais reconstituées à partir de l’action exécutée. Le visualiseur l’affiche dans le même arbre dépliable que l’entrée de Decision. La trace finale omet les corps d’entrée et de sortie en double.

Facultatif decisionMetrics enregistre localement requestDurationMs (récupéré via le décodage JSON, à l’exclusion de l’encodage de l’image), requestBytes (corps JSON UTF-8 incluant l’image en base64, à l’exclusion des en-têtes HTTP), structuredBytes (sérialisation UTF-8 du modèle, de l’état structuré, des questions et du fournisseur, sans l’image), et imageBytes (octets JPEG/PNG avant encodage en base64). Les tailles ne correspondent ni à l’utilisation de jetons ni aux coûts facturés. L’utilisation réelle, lorsqu’elle est fournie par le prestataire, reste dans decisionOutput. Ces champs partagent la même disponibilité et le même comportement en lecture seule que decisionOutput.

La navigation envoie une capture d’écran JPEG entrante sans modification, avec son type MIME JPEG correspondant ; les autres images conservent la normalisation PNG. Cela ne redimensionne pas l’image et n’ajoute aucune compression avec perte. L’observation enregistrée reste exactement l’image source.

La finalisation de la navigation nécessite actuellement une probabilité d’objectif du modèle d’au moins 0,70 ; une condition de démarrage explicite nécessite toujours 0,85 lors de la première décision. Cette politique d’exécution commune à Studio/CLI/MCP n’établit pas indépendamment la réussite de la tâche. Conservez des assertions explicites sur le résultat, en particulier pour les réservations, les enregistrements ou les états d’erreur attendus. Ces probabilités correspondent aux évaluations du modèle et ne constituent pas une garantie. L’expérimentation sur la politique de finalisation et les régressions sont suivies dans le journal d’itération de Studio.

Les décisions de navigation TYPE_TEXT sélectionnent ensemble la cible modifiable et la référence de données nommée, en un seul choix. L’exécuteur valide la paire par rapport à ses choix actuels, vérifie le focus et, lorsqu’un clic de mise au point est nécessaire, la visibilité de la cible ou l’accessibilité via le pilote, puis résout localement la valeur fournie avant la saisie. Les noms des références sélectionnées et les valeurs de chaîne attendues sont également transmis dans decisionInput.state.inputData et conservés dans les éléments de preuve ; les données de test sans rapport sont exclues. L’observation persistante expose néanmoins l’ID du candidat dans target et le chemin de données existant dans inputReference; les anciennes sorties du modèle utilisaient des têtes distinctes pour la cible et la saisie. La lecture de ces éléments est synchrone et n’a aucun effet secondaire. La sélection conjointe ne garantit pas que la paire champ/référence choisie soit sémantiquement correcte.

La navigation accepte actuellement au maximum 250 candidats visibles filtrés localement, y compris le texte statique et les contrôles interactifs. Les observations plus importantes échouent explicitement, sans tronquer silencieusement les cibles. Il s’agit d’une limite de ressources d’exécution, et non d’un nombre minimal d’éléments ni d’une exigence du modèle. Les délais et budgets d’actions existants restent applicables.

Définissez REPEATO_NAVIGATION_MODEL=gpt-6-luna et OPENAI_API_KEY avant de démarrer Studio/CLI/MCP. Jev reste la valeur par défaut. GPT-6 Luna utilise POST https://api.openai.com/v1/decisions, avec le même état filtré, la capture d’écran d’origine et le sens des questions préservé. Les anciennes questions internes noul sont converties en questions de prédicat natives ; les critères fixes sont convertis en valeurs/descriptions de choix natives. Cet adaptateur ne génère ni JSON Responses, ni coordonnées/valeurs de texte générées, et n’utilise ni paramètre de raisonnement, ni limite de jetons de sortie, ni solution de repli du modèle. Les mécanismes existants d’annulation/d’échéance, de visibilité, d’actualisation, de focus, de budgets et les assertions indépendantes de résultat restent applicables.

Brut navigationObservation.decisionOutput conserve le corps de l’API native avant validation. L’adaptateur associe le tableau de réponses à chaque nom de question unique, valide les types, les plages de probabilités et les valeurs autorisées, puis mappe la probabilité du prédicat dans les vérifications existantes de l’objectif et du démarrage (0.70/0.85 inchangées). Un refus obligatoire, des noms dupliqués, manquants ou inconnus, ainsi que des choix invalides, échouent sans dispatch. Les niveaux de confiance et les probabilités proviennent de l’API, sans valeurs inventées. L’équivalence de calibration des probabilités entre différents modèles n’est pas présumée. Tout modèle renvoyé doit correspondre à gpt-6-luna ; si l’API omet l’identité du modèle, le modèle résolu reste null au lieu d’être fabriqué.

decisionInput.api est openai-decisions; requestOptions.questions enregistre les questions filaires exactement converties, tandis que l’état et la référence de la capture d’écran reconstituent les éléments de preuve partagés. Le champ de fournisseur réservé à Jev est absent. Les lectures sont synchrones et sans effets secondaires. Pour GPT, structuredBytes sérialise la requête native avec une URL d’image vide ; les octets de l’image sont signalés séparément. Lorsque le coût du fournisseur est manquant, il est inconnu et non nul. Les rapports historiques existants openai-responses restent inchangés et ne doivent pas être étiquetés comme des exécutions natives de Decisions.

L’étape guide officiel de Decisions documente les entrées texte/image ainsi que les réponses de type prédicat/choix. La disponibilité réelle du modèle/du compte nécessite toujours un précontrôle réussi. Toutes les preuves d’exécution restent accessibles via les outils MCP existants d’exécution/résultat ; aucun point de terminaison d’action MCP distinct n’est requis.

Native Decisions conserve les refus individuels ou les têtes spéculatives indisponibles sans inventer de réponses : l’exécuteur partagé rejette un refus s’il est requis pour l’opération sélectionnée, l’objectif, le démarrage applicable ou la visibilité de la cible sélectionnée. Un refus inutilisé n’annule pas une autre opération vérifiée indépendamment. Les tableaux de choix natifs exigent au moins deux entrées ; une tête avec une seule option réelle inclut une abstention explicite indiquant qu’aucun choix ne s’applique. Cette valeur réservée ne peut pas être dispatchée et est conservée dans la sortie brute de l’API ; si elle est sélectionnée, cette tête est considérée comme indisponible.

Pour les TYPE_TEXTLa navigation peut réutiliser un champ éditable, ciblé et activé, identifié de manière unique dans la hiérarchie fraîche. Elle ignore alors le clic de mise au point et la validation de visibilité du modèle. L’identité, lorsqu’elle est disponible, le rôle, le libellé et les limites doivent correspondre. La mise au point est vérifiée à nouveau avant les modifications de texte, et la valeur résultante du champ doit correspondre exactement à la référence fournie. Cela n’établit pas la visibilité visuelle. Le champ d’observation facultatif en lecture seule focusClickDispatched est false lorsque la mise au point existante a été réutilisée et true lorsqu’un clic de mise au point a été envoyé. Les exécutions plus anciennes ne l’incluent pas. Sa lecture dans les étapes de script de Studio ou de CLI et dans la configuration avancée est synchrone et sans effets secondaires. Le visualiseur n’affiche pas de marqueur de clic lorsque ce champ est false.

Browser Navigation traite un contrôle Date natif comme une seule cible modifiable et omet ses candidats de segments internes. Fournissez les dates sous forme de chaînes YYYY-MM-DD dans inputReferences. L’exécuteur asynchrone clique localement sur les segments natifs anglais Year, Month et Day, saisit les parties fournies et vérifie la date ISO complète avant de continuer. Il vérifie que la cible est à jour, les limites des segments et le focus ; les dates non valides, les segments non pris en charge, les contrôles désactivés ou les incohérences de valeur entraînent un échec. Ce parcours réservé au navigateur n’ajoute pas la prise en charge des sélecteurs de date Android/iOS. Les clics sur les segments sont internes à une seule action TYPE_TEXT du modèle ; le budget d’actions existant ne compte cette action qu’une seule fois. Aucune modification de la valeur du DOM ni aucun déploiement de Browser Host n’est requis.

La navigation du navigateur propose des contrôles actionnables lorsqu’au moins 50 % de leur surface rectangulaire se trouve dans la fenêtre normalisée. Les autres nœuds conservent le filtrage sur l’ensemble du rectangle. Un candidat partiellement tronqué conserve ses limites d’origine et expose clickPoint (x/y normalisés), le centre du rectangle visible. Le déclenchement et le marqueur du rapport utilisent ce point. Cette fraction géométrique ne garantit pas l’absence de superpositions : la vérification de visibilité de la capture d’écran doit identifier un point de clic dégagé, et les vérifications récentes d’accessibilité et du clavier restent nécessaires. Le test de collision de l’hôte pour le centre d’origine n’est pas réutilisé comme preuve positive pour un autre point. Le filtrage des cibles natives reste inchangé. Les choix CLICK décrivent également explicitement les valeurs attendues sélectionnées qui correspondent déjà aux champs modifiables ; le contenu actuel sans rapport des champs n’est pas envoyé.

Les nouvelles observations de navigation obsolètes incluent une hiérarchie `hierarchyChanges` facultative avec `comparison=“hierarchy_paths”`, `totalChanges` et un tableau `changes`. Chaque entrée identifie un chemin de pointeur JSON, un type de changement ainsi que les valeurs avant/après disponibles issues de la hiérarchie de la requête d’origine et de la hiérarchie fraîche de vérification du dispatch. Il s’agit d’une comparaison structurelle basée sur les chemins, et non d’une identification d’éléments déduite ni d’un diagnostic causal. Les contenus modifiables et les propriétés de valeur sont masqués ; leurs changements restent enregistrés. Ces données sont stockées localement, ne sont pas ajoutées à l’entrée du modèle et peuvent être lues de manière synchrone, sans effets secondaires, via `executionEvidence.navigationObservation` dans les étapes Script, la configuration avancée et les outils MCP existants d’exécution et de résultats. Les anciens rapports n’incluent pas ce champ et l’interface indique explicitement que la comparaison n’a pas été enregistrée. La détection existante des éléments obsolètes et le comportement sans dispatch restent inchangés.

FR