JavaScript-API

Repeato ermöglicht die Ausführung von JavaScript mit Skript-Schritten. Während ein Test oder Batch ausgeführt wird, sind die folgenden globalen Variablen verfügbar.

Für maschinenlesbare Dokumentation nutze die rohe Markdown-Referenz oder die TypeScript-Deklarationen. Siehe JavaScript-Rezepte für vollständige, ausführbare Beispiele.

Globale Variablen

data

Typ: object

Ein Objekt, mit dem Daten zwischen Schritten geteilt werden können.

data.scannedText

Typ: string

Die vom zuletzt ausgeführten Auf Text prüfen -Schritt gescannte Zeichenfolge.

workspaceDir

Typ: string

Das Verzeichnis des aktuellen Arbeitsbereichs.

currentStepIndex

Typ: number

Der nullbasierte Index des aktuell ausgeführten Schritts.

testDir

Typ: string

Das Verzeichnis des aktuellen Tests.

testRunDir

Typ: string

Das Verzeichnis des aktuellen Testlaufs.

axios

Typ: AxiosInstance

Der Axios-HTTP-Client.

const response = await axios.get('https://example.com')

log()

Signatur

log(message: object)

Protokolliert eine Nachricht oder ein Objekt.

sleep()

Signatur

sleep(milliseconds: number): Promise<void>

Verzögert die Ausführung um die angegebene Anzahl an Millisekunden.

getResponse()

Signatur

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

Sendet eine GET-Anfrage an einen Host.

sendPost()

Signatur

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

Sendet eine POST-Anfrage.

showDialog()

Signatur

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

Zeigt einen Dialog an, dessen Inhalt Markdown unterstützt, einschließlich formatiertem Text, Links und Bildern. Die optionalen Callbacks werden ausgeführt, wenn die entsprechende Aktion erfolgt. Die zurückgegebene Dialoginstanz kann mit cancel() oder confirm().

batchRunner

Steuert den aktuellen Test-Batch und stellt Hooks für den Batch-Lebenszyklus bereit.

batchRunner.testBatch

Typ: TestBatch

Der aktuelle Test-Batch.

batchRunner.currentExceptionHandlerIndex

Typ: number

Der Index des aktuellen Exception-Handlers.

batchRunner.currentTestIndex

Typ: number

Der Index des aktuellen Tests.

batchRunner.batchRun

Typ: BatchRun

Der aktuelle Batch-Lauf. Verwende log(batchRunner.batchRun) um alle Eigenschaften zu prüfen.

batchRunner.isPlaying

Typ: boolean

Gibt an, ob der Batch-Runner gerade läuft.

batchRunner.runMode

Typ: string

Der aktuelle Ausführungsmodus.

batchRunner.stop()

stop(): Promise<void>

Stoppt den Batch-Runner.

batchRunner.createBatchRunExport()

Signatur

createBatchRunExport(): Promise<string>

Erstellt einen Export des aktuellen Batch-Laufs im batchRuns -Ordner des Arbeitsbereichs und gibt dessen Pfad zurück.

batchRunner.uploadReport()

Signatur

uploadReport(dirPath: string): Promise<string>

Lädt den Bericht unter dirPath in die Repeato Cloud hoch und gibt die URL des Berichts zurück.

batchRunner.setTestBatchById()

Signatur

batchRunner.setTestBatchById(batchId: string)

Legt den Test-Batch für den Batch-Runner fest.

batchRunner.setRunMode()

Signatur

batchRunner.setRunMode(mode: string)

Legt den Ausführungsmodus auf alle Tests oder nur fehlgeschlagene Tests fest.

batchRunner.setRunMode('AllTests')
batchRunner.setRunMode('OnlyFailed')

batchRunner.addOnBatchStart()

Signatur

batchRunner.addOnBatchStart(key: string, callback: (batch: Batch) => void)

Registriert einen Callback, der unmittelbar vor dem Start des Batches ausgeführt wird.

batchRunner.addOnTestFail()

Signatur

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

Registriert einen Callback, der ausgeführt wird, wenn ein Test fehlschlägt.

batchRunner.addOnTestSuccess()

Signatur

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

Registriert einen Callback, der ausgeführt wird, wenn ein Test erfolgreich ist.

batchRunner.addOnBatchCompleted()

Signatur

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

Registriert einen Callback, der ausgeführt wird, wenn der Batch abgeschlossen ist – unabhängig davon, ob er erfolgreich war oder fehlgeschlagen ist.

batchRunner.removeOnBatchStart()

Signatur

batchRunner.removeOnBatchStart(key: string)

Entfernt einen registrierten Callback mit addOnBatchStart().

batchRunner.removeOnTestFail()

Signatur

batchRunner.removeOnTestFail(key: string)

Entfernt einen registrierten Callback mit addOnTestFail().

batchRunner.removeOnTestSuccess()

Signatur

batchRunner.removeOnTestSuccess(key: string)

Entfernt einen registrierten Callback mit addOnTestSuccess().

batchRunner.removeOnBatchCompleted()

Signatur

batchRunner.removeOnBatchCompleted(key: string)

Entfernt einen registrierten Callback mit addOnBatchCompleted().

batchRunner.testRunner

Typ: TestRunner

Bietet Zugriff auf alle testRunner Eigenschaften und Methoden zu. Verwende log(batchRunner.testRunner) um sie zu prüfen.

testRunner

Steuert die Ausführung des aktuellen Tests und stellt Hooks für den Lebenszyklus von Schritten bereit.

testRunner.currentTest

Typ: Test

Der aktuelle Test. Verwende log(testRunner.currentTest) um alle Eigenschaften zu prüfen.

testRunner.currentTestRun

Typ: TestRun

Der aktuelle Testlauf. Verwende log(testRunner.currentTestRun) um alle Eigenschaften zu prüfen.

testRunner.currentTestRun.partial ist ein synchron lesbarer, schreibgeschützter boolescher Wert auf allen Plattformen in Skript-Schritten und Callbacks der erweiterten Konfiguration. Er ist bei der Ausführung einzelner Schritte und bei „Bis hier ausführen“ wahr, ohne Geräteinteraktion oder andere Seiteneffekte. Teilweise ausgeführte Testläufe behalten ihre Schrittergebnisse, können aber weder erfolgreich sein noch als Referenzläufe dienen; wasSuccessful bleibt falsch. Bei älteren gespeicherten Testläufen gilt standardmäßig partial: false.

testRunner.lastStepResult

Typ: StepResult

Das Ergebnis des zuvor ausgeführten Schritts. Verwende log(testRunner.lastStepResult) um alle Eigenschaften zu prüfen.

Nachweis der semantischen Klickübereinstimmung

In Skriptschritten und Callbacks der erweiterten Konfiguration step.semanticAgreement ist ein synchrones, schreibgeschütztes Konfigurations-Flag für Klicks (standardmäßig false; bei anderen Schritttypen nicht vorhanden). Konfiguriere es über den Klick-Editor von Studio oder MCP. Aktivierte Klicks erfordern eine aktuelle Hierarchie mit einem eindeutig sichtbaren semantischen Ziel, das den vorgeschlagenen Tap-Punkt enthält. Andernfalls wird der Tap abgelehnt, und Geräte ohne nutzbare Hierarchie/Locatoren können keine Übereinstimmung feststellen.

stepResult.semanticAgreement ist eine synchrone Abfrage ohne Seiteneffekte. Das Feld ist vorhanden, wenn die Prüfung ein Ziel ausgewertet hat, und enthält agreed, reason, candidateCount, und ein optionales Ziel bounds, aufgelöst locators oder ein mehrdeutiges locatorType. Begrenzungen verwenden normalisierte Koordinaten von 0 bis 1. Fehlende Nachweise bedeuten nicht, dass die Übereinstimmung bestätigt wurde. Dies erfasst die geometrische Übereinstimmung, nicht die tatsächliche Zustellung des Events oder geschäftliche Ergebnisse.

Nachweis des vorherigen Klicks prüfen

const agreement = testRunner.lastStepResult?.semanticAgreement
if (agreement) log(agreement)

Ausführungsnachweise und Warnungen für Klicks

In Script-Schritten und der erweiterten Konfiguration stepResult.executionEvidence ist eine synchrone, schreibgeschützte optionale Eigenschaft, die für neu ausgeführte Matching-/Klickergebnisse vor Step-Completed-Callbacks verfügbar ist. Sie gibt gespeicherte Ausführungsdaten oder undefined bei älteren Ergebnissen zurück, ohne Seiteneffekte auf dem Gerät. Enthalten sind der effektive searchedRegion, requestedLocators, matchSource, optional resolvedLocator, matchedBoundssowie der tatsächlich versuchte tapPointund Zeitstempel/Status der Weiterleitung. Begrenzungen und Tipp-Punkte verwenden normalisierte Koordinaten des gesamten Frames von 0 bis 1; die Breite/Höhe des Quellframes werden in Pixeln des verarbeiteten Bildes angegeben. Koordinatenklicks haben weder eine Suchregion noch aufgelöste Elementbegrenzungen.

sourceFrame identifiziert einen Screenshot, der dem Ergebnis zugeordnet ist. Das phase unterscheidet die exakte Worker-Eingabe matching_frame von einem gelesenen Screenshot after_locator_resolution (dieser ist nicht die für die Auflösung des Locators verwendete Hierarchie). receivedAt ist ein ISO-Zeitstempel für den Empfang/das Lesen durch den Client, kein Zeitstempel der Aufnahme durch den Anbieter; matchedAt erfasst den Abschluss des Workers, sofern bekannt. Screenshots sind Dateinamen relativ zum normalen Ausführungsverzeichnis und werden über die Screenshot-API des Laufs oder die MCP-Artefaktmetadaten abgerufen. Fehlende Felder bleiben null. Matching-Puffer werden nicht inline im Ergebnis gespeichert.

tapStatus ist not_dispatched, dispatching, completed (der Treiberbefehl wurde aufgelöst) oder unknown (ein nach der Weiterleitung abgelehnter Befehl wurde möglicherweise teilweise angewendet). Der Abschluss einer Weiterleitung beweist weder die Zustellung des Events noch das gewünschte Ergebnis in der App. Ein Matching-Frame ist historisch; der physische Bildschirm kann sich vor dem Tippen ändern. Bei einer unklaren Weiterleitung wird kein automatischer Wiederholungsversuch durchgeführt.

stepResult.warnings ist ein schreibgeschütztes Array von Warnungscodes. Ein erfolgreicher Locator-Fallback behält success: true und fügt hinzu fingerprint_fallback_used; Warnungen verhindern das Tippen nicht mehr. Optionale fehlgeschlagene Schritte können weiterhin success: undefinedhaben. Von Locators abgeleitete Begrenzungen verwenden deren Mittelpunkt, ohne einen aufgezeichneten Fingerabdruck-Offset anzuwenden; Fingerabdruck-/OCR-Klicks behalten ihr konfiguriertes Offset-Verhalten bei.

Ausführungsdaten prüfen, ohne einen neuen Screenshot aufzunehmen

const result = testRunner.lastStepResult
if (result?.executionEvidence) {
  log(result.executionEvidence)
  log(result.warnings)
}

Gespeicherte Fehlerhierarchie

In Script-Schritten und der erweiterten Konfiguration stepResult.failureEvidence ist ein optionaler, schreibgeschützter persistierter Wert. Das Lesen erfolgt synchron und gibt den gespeicherten Nachweis oder undefined zurück und hat keine Auswirkungen auf das Gerät. Repeato Studio erfasst ihn nach fehlgeschlagenen Schritten (einschließlich optionaler Fehler) und nachdem addOnStepCompleted Callbacks abgeschlossen sind. Diese Callbacks sehen diese Erfassung noch nicht; spätere Script-Schritte oder Testfehler-Callbacks können sie prüfen, sobald die Ausführung fortgesetzt wird. Bei erfolgreichen und älteren Ergebnissen kann sie fehlen.

failureEvidence.hierarchy enthält status (captured, unavailable oder capture_failed), data (die vollständige JSON-serialisierbare Treiberhierarchie oder null), sowie capturedAt (einen ISO-Zeitstempel oder null ). Für die Erfassung ist ein verbundenes Gerät mit Hierarchieunterstützung erforderlich; dafür gilt ein Zeitlimit von drei Sekunden. Fehlende Hierarchieunterstützung, eine Trennung, ein Timeout oder Serialisierungsfehler lassen den Test nicht zusätzlich fehlschlagen. Die Erfassung erfolgt nach der fehlgeschlagenen Aktion und unabhängig von deren Screenshot. Eine leere Hierarchie ist nicht dasselbe wie nicht verfügbare Daten.

Der Nachweis umfasst außerdem die Klassifizierung, sofern verfügbar die Suchphasen und den Zeitpunkt der Erfassung. Unbekannt bleiben die Sichtbarkeit der Tastatur, IME-Grenzen, der Scroll-Offset, das Vordergrundpaket und die Übermittlung des Taps. Hierarchieattribute und Grenzen behalten die treiberspezifische Struktur und Einheiten bei; sie sind nicht normalisierte Touch-Koordinaten im Bereich 0–1. Hierarchien können eingegebenen Text enthalten. Nachweise bleiben in der normalen Ausführungsstruktur erhalten. Jeder Test behält höchstens fünf Durchläufe und schützt dabei den Referenzlauf; fehlgeschlagene oder unterbrochene Ergebnisse sowie Screenshots bleiben erhalten, bis der zugehörige Durchlauf entfernt wird. Manuelle Exporte können eine Kopie länger aufbewahren. MCP repeato_get_step_result gibt das vollständige Ergebnis-JSON aus den aufbewahrten Testdurchläufen zurück, einschließlich dieser Hierarchie.

Gespeicherten Fehlernachweis prüfen, ohne das Gerät zu kontaktieren

const evidence = testRunner.lastStepResult?.failureEvidence
if (evidence?.hierarchy.status === 'captured') {
  log(evidence.hierarchy.data)
}

testRunner.currentStepIndex

Typ: number

Der nullbasierte Index des aktuellen Schritts.

testRunner.setNextStepId()

Signatur

testRunner.setNextStepId(id: string)

Legt anhand der ID den nächsten auszuführenden Schritt fest.

testRunner.setNextStepId('AH23D6')

testRunner.setNextStepIndex()

Signatur

testRunner.setNextStepIndex(index: number)

Legt den nächsten auszuführenden Schritt anhand seines nullbasierten Index fest.

testRunner.goBackBy()

Signatur

testRunner.goBackBy(stepCount: number)

Geht um stepCount Schritte zurück und setzt die Ausführung dort fort.

testRunner.addOnScreenshotSaved()

Signatur

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

Registriert einen Listener, der ausgeführt wird, sobald ein Screenshot gespeichert wurde.

testRunner.addOnStepCompleted()

Signatur

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

Registriert einen Callback, der bei jedem abgeschlossenen Schritt ausgeführt wird.

testRunner.removeOnScreenshotSaved()

Signatur

testRunner.removeOnScreenshotSaved(key: string)

Entfernt einen registrierten Listener mit addOnScreenshotSaved().

testRunner.removeOnStepCompleted()

Signatur

testRunner.removeOnStepCompleted(key: string)

Entfernt einen registrierten Callback mit addOnStepCompleted().

testRunner.setScaleInvariantMatchingEnabled()

Signatur

testRunner.setScaleInvariantMatchingEnabled(enabled: boolean)

Aktiviert oder deaktiviert die skalierungsinvariante Übereinstimmung. Sie ist standardmäßig aktiviert.

deviceConnector

Bietet Informationen zum aktuell verbundenen Gerät und sendet Befehle an dieses Gerät.

deviceConnector.selectedDeviceData

Typ: DeviceData

Alle Daten zum aktuell verbundenen Gerät. Verwende log(deviceConnector.selectedDeviceData) um ihn zu prüfen.

deviceConnector.sendString()

Signatur

sendString(value: string): Promise<void>

Sendet eine Zeichenfolge an das Gerät. Die zu testende App muss ein fokussiertes Eingabefeld haben, um die Daten zu empfangen.

deviceConnector.clearText()

Signatur

clearText(): Promise<void>

Verfügbar in Skriptschritten und der erweiterten Konfiguration mit einem verbundenen Gerät und einem fokussierten Eingabefeld. Leert dieses Feld asynchron und wird ohne Wert aufgelöst; es wird kein Ersatztext eingegeben.

Cloud-Android verwendet das Auswahlmenü für langes Drücken im Eingabefeld und „Alle auswählen“, gefolgt von Backspace und einer Prüfung auf ein leeres Feld. Dafür ist genau ein inspizierbares, fokussiertes EditText-Element sowie ein verfügbares Auswahlsteuerelement erforderlich; ADB wird nicht verwendet. Das Leeren unter Cloud-iOS wird nicht unterstützt. Fehlender Fokus, nicht verfügbare Steuerelemente, nicht unterstützte Geräte und Timeouts des Anbieters führen zur Ablehnung des Promise. Ein Fehler kann den Status des Eingabefelds oder der Auswahl verändern. Prüfe daher den Bildschirm, bevor du es erneut versuchst.

Verwendung nach dem Fokussieren eines Eingabefelds

await deviceConnector.clearText()
await deviceConnector.sendString('Replacement text')

deviceConnector.sendClick()

Signatur

sendClick(xPercentage: number, yPercentage: number): Promise<void>

Sendet ein Touch-Ereignis an das Gerät. Die Koordinaten reichen von 0 bis 1; sendClick(0.5, 0.5) tippt auf die Bildschirmmitte.

deviceConnector.sendDown()

Signatur

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

Sendet ein Touch-Down-Ereignis. Jede sendDown() benötigt ein sendUp(); kombiniere es mit sendMove() um eine Ziehbewegung zu simulieren.

deviceConnector.sendMove()

Signatur

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

Sendet ein Bewegungsereignis. Verwende sendDown() zuerst und beende die Ziehbewegung mit sendUp().

deviceConnector.sendUp()

Signatur

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

Sendet ein Touch-Up-Ereignis.

deviceConnector.sendAdbCommand()

Signatur

sendAdbCommand(command: string): Promise<string>

Sendet einen Android-Debug-Bridge-(ADB-)Befehl.

deviceConnector.addOnDeviceLog()

Signatur

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

Registriert einen Callback, der für jede von der zu testenden App gesendete Logzeile ausgeführt wird.

deviceConnector.sendIdbCommand()

Signatur

sendIdbCommand(command: string): Promise<string>

Sendet einen iOS-Development-Bridge-(IDB-)Befehl.

await deviceConnector.sendIdbCommand('list-targets')

deviceConnector.takeScreenshot()

Signatur

takeScreenshot(filepath: string): Promise<void>

Erstellt einen Screenshot und speichert ihn unter filepath.

deviceConnector.setClipboard()

Signatur

setClipboard(content: string): Promise<void>

Setzt die Zwischenablage des Geräts auf eine Zeichenfolge.

deviceConnector.getClipboard()

getClipboard(): Promise<string>

Ruft den Inhalt der Zwischenablage des Geräts ab.

deviceConnector.vision()

Signatur

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

Sendet eine Eingabeaufforderung und einen Screenshot des aktuellen Gerätebildschirms an das Vision-Modul. Übergib eine Region, um den Screenshot auf einen Teil des Bildschirms zu beschränken.

audioTools

Bietet Text-to-Speech, Audiowiedergabe und Audioaufnahme.

audioTools.say()

Signatur

audioTools.say(text: string)

Wandelt den angegebenen Text in Audio um.

audioTools.playAudio()

Signatur

playAudio(url: string): Promise<number>

Spielt Audio von der angegebenen URL ab.

audioTools.stopAudio()

audioTools.stopAudio()

Stoppt die aktuell laufende Audiowiedergabe.

audioTools.recordAudio()

Signatur

recordAudio(duration: number): Promise<string>

Nimmt Audio für die angegebene Dauer in Millisekunden auf und gibt die URL der temporären Aufnahme zurück.

OCR- und Locator-Ausführungsnachweise

testRunner.lastStepResult.executionEvidence ist ein synchroner, schreibgeschützter Snapshot. Das optionale ocr -Objekt speichert den zuletzt vollständig erkannten recognizedText, auch wenn der Vergleich fehlschlägt, sowie Engine, erwarteten Text, Operator, Anzahl vollständig verarbeiteter Frames und Abschlusszeit. Der Status unterscheidet no_frame_processed, no_completed_frame, engine_error, no_text, no_match und matched. Fehlt eine abgeschlossene Ausgabe, ist der Wert null, während eine abgeschlossene Erkennung ohne Text eine leere Zeichenfolge liefert. Die Quellframe-Referenz verweist auf den untersuchten Screenshot, sofern verfügbar. Ein später Worker-Abschluss aktualisiert kein bereits zurückgegebenes Timeout-Ergebnis. Das Warten auf ruhende Animationen benötigt höchstens ein Viertel des Suchzeitbudgets oder eine Sekunde; die restliche Zeit bleibt für die Erkennung. OCR-Laufzeit und Erkennungsgenauigkeit hängen von Engine und Geräteinhalt ab.

executionEvidence.locatorResults speichert Kandidaten der Hierarchie-Locators und Ablehnungsgründe. Native Hierarchie-Fallbacks erfordern genau ein aktiviertes, bedienbares Steuerelement innerhalb des konfigurierten normalisierten Suchbereichs. Statische Beschriftungen, mehrdeutige Steuerelemente und bekanntermaßen von der Tastatur verdeckte Tippstellen werden abgelehnt. Android unterstützt einen exakten hint -Locator. Fehlende Tastaturnachweise bleiben unbekannt. Ein Treffer und eine abgeschlossene Eingabeübermittlung beweisen nicht das Ergebnis in der App.

Für Textschritte lässt sich expectedFocusHint in Studio oder über MCP konfigurieren. Vor dem Löschen oder Tippen bei Aufzeichnung und Wiedergabe liest diese optionale Prüfung die Gerätehierarchie asynchron und verlangt genau ein fokussiertes editierbares Feld mit diesem exakten Hinweistext. Wenn die Hierarchie fehlt oder der Fokus nicht übereinstimmt, schlägt sie vor jeder Textänderung fehl. Sie verändert den Fokus nicht. step.expectedFocusHint selbst liest die konfigurierte Erwartung synchron. Natives Android stellt Hinweistexte bereit, wenn App oder Anbieter sie liefern; andere Plattformen stellen sie möglicherweise nicht bereit.

Nachweise für Navigationsschritte

In Skriptschritten und der erweiterten Konfiguration stellen Navigationsschritte synchrone, schreibgeschützte goal, startCondition, inputReferences und maxActions Eigenschaften. Andere Schritttypen lassen sie aus. Die optionale Startbedingung muss vor jeder Aktion überprüft werden. Eingabeverweise wählen vorhandene data Felder. Die Navigation sendet die ausgewählten Namen und aufgelösten Werte an den Anbieter in state.inputData und in den Entscheidungsnachweisen gespeichert. Wähle keine Geheimnisse aus. Vom Laufzeitmodul eingegebene Werte stammen weiterhin aus den bereitgestellten Daten und werden nicht vom Modell erzeugt. maxActions akzeptiert 1–100 und verwendet standardmäßig 20. Für die Navigation werden ein Gerät mit Hierarchie und Screenshots, ein konfigurierter OpenRouter-Schlüssel und das unterstützte Entscheidungsmodell benötigt. Das geerbte Schritt-Timeout ist das gesamte Ausführungsbudget in Sekunden (Standard: 60, Maximum: 300).

Nach der Ausführung stepResult.executionEvidence.navigation ist ein synchrones, schreibgeschütztes optionales Objekt, das vor Abschluss-Callbacks verfügbar ist. Es hat keine Auswirkungen auf das Gerät und fehlt bei anderen oder älteren Ergebnissen. Es enthält model (das festgelegte aufgelöste Modell), requestedModel, status, elapsedMs, actionCount, modelCalls, und trace. Jeder Trace-Eintrag enthält die Operation, die Nummer des dynamischen Ziels, den Status, die verstrichenen Millisekunden und optional goalConfidence, operationConfidence, visibilityDecision (VISIBLE/HIDDEN/UNCERTAIN), visibilityConfidence, inputReferencesowie den exakten Dateinamen des Beobachtungs-Screenshots im Testlaufverzeichnis. Zielnummern gelten nur für diese Beobachtung; sie sind keine wiederverwendbaren Locatoren. Die passende Nachweisquelle ist navigation; einzelne Aktionen werden im Navigationstrace statt in den Tap-Feldern der obersten Ebene aufgezeichnet.

Eine Zielbewertung, ein Timeout, eine Abbruchaktion, eine ungültige Startbedingung, ein unsicheres Ziel, ein instabiler Bildschirm, fehlender Fortschritt oder ein erschöpftes Budget beendet den Schritt, ohne den Test automatisch erneut auszuführen. Die Zielerkennung ist eine Modellbewertung; behalte eine separate gewöhnliche Assertion für das endgültige Geschäftsergebnis bei. Die Geometrie der Hierarchie verwendet normalisierte Koordinaten von 0 bis 1. Screenshots und sichtbare Seiteninhalte werden an den konfigurierten Modellanbieter gesendet. Verwende daher für Benchmarks Demodaten und halte Geheimnisse aus Zielen heraus.

Mehrere Ergebnisse aus der Navigation

In Skriptschritten und der erweiterten Konfiguration von Studio und CLI testRun.stepResults ist dies eine chronologische flache Liste. Ein Navigationsschritt kann mehrere tatsächliche Ergebnisse mit derselben step.iderzeugen: informative Beobachtungen, gefolgt von einem abschließenden Ergebnis. Lies diese Felder synchron; das Lesen hat keine Nebenwirkungen. resultKind ist intermediate oder final; ältere geladene Ergebnisse verwenden standardmäßig final. Optionales executionId fasst eine Ausführung zusammen, sequence ordnet ihre Ergebnisse und elapsedMs misst die Millisekunden seit Beginn dieser Navigation. Ein Zwischen- executionEvidence.navigationObservation zeichnet Operation, Status, Ziel sowie optionale Fehler- oder Referenzdetails auf. Der Screenshot zeigt die Beobachtung des Modells vor der Aktion, nicht eine Bestätigung danach. screenshot ist ein optionaler Dateiname relativ zum Testlaufverzeichnis; ein nicht verfügbares Bild wird nicht künstlich erzeugt.

testRun.getStepResultsByStepId(stepId) gibt synchron alle Ergebnisse dieses Schritts in der aufgezeichneten Reihenfolge zurück, ohne den Lauf zu ändern. getStepResultByStepId(stepId) gibt das letzte abschließende Ergebnis oder undefined vor dem Abschluss zurück. getSuccessfulStepResults() enthält nur erfolgreiche abschließende Ergebnisse. testRunner.lastStepResult und Step-completed-Callbacks beziehen sich weiterhin auf das endgültige Ergebnis, nicht auf Zwischenentscheidungen. Zwischenergebnisse erhöhen nicht die Anzahl erfolgreicher, fehlgeschlagener oder optionaler Schritte. Bestehende historische Läufe behalten das ursprüngliche Einzelergebnis; der Viewer wandelt alte JSON-Traces nicht in erfundene Ergebnisse um.

Für neue Navigation-Beobachtungen, executionEvidence.navigationObservation.decisionInput ist eine synchrone, schreibgeschützte Momentaufnahme der strukturierten Modellanfrage: Status, Fragen, Modell/Anbieter und gespeicherte Screenshot-Referenz. Das Lesen hat keine Nebenwirkungen. Autorisierungsdaten und Inline-Bilddaten sind ausgeschlossen; in älteren Läufen fehlt die Momentaufnahme. Nur explizit ausgewählte inputReferences werden aufgelöst und als Zuordnung von Namen zu String-Werten in decisionInput.state.inputData aufgenommen. Diese Werte werden an den konfigurierten Navigationsanbieter übertragen und in den Ausführungsnachweisen gespeichert. Wähle keine Geheimnisse aus. Das gesamte data-Objekt und nicht zugehörige Felder sind ausgeschlossen. Der Screenshot kann außerdem sichtbare Feldinhalte zeigen. Unabhängige Assertions für erwartete Ergebnisse sind nicht enthalten. Der Batch Run Viewer zeigt diese Momentaufnahme in einem aufklappbaren Bereich „Decision input“ an. Der abschließende Trace lässt doppelte Eingabedaten aus; prüfe die tatsächlichen Zwischenergebnisse jeder Entscheidung.

Neue Navigation-Zwischenergebnisse stellen optionale executionEvidence.navigationObservation.decisionOutput: den exakt empfangenen JSON-Body des Modells bereit, der vor der lokalen Antwortvalidierung gespeichert wird. Dabei handelt es sich in Studio und CLI um eine synchrone, schreibgeschützte Momentaufnahme, die auch über MCP-Ausführungs-/Ergebnis-Tools verfügbar ist. Das Lesen hat keine Nebenwirkungen. Autorisierungs-Header werden nicht gespeichert. Bei älteren Ergebnissen und Anfragen ohne empfangene JSON-Antwort fehlt dieses Feld; fehlende Ausgaben werden niemals aus der ausgeführten Aktion rekonstruiert. Der Viewer zeigt sie im selben aufklappbaren Baum wie die Decision-Eingabe an. Der abschließende Trace lässt doppelte Eingabe-/Ausgabe-Bodies aus.

Optional decisionMetrics speichert lokal requestDurationMs (Abruf über JSON-Dekodierung, ohne Bildkodierung), requestBytes (UTF-8-JSON-Body einschließlich Base64-Bild, ohne HTTP-Header), structuredBytes (UTF-8-Serialisierung von Modell, strukturiertem Status, Fragen und Anbieter ohne Bild) und imageBytes (JPEG-/PNG-Bytes vor Base64). Größen entsprechen weder dem Token-Verbrauch noch den abgerechneten Kosten. Der tatsächliche Verbrauch bleibt, sofern vom Anbieter bereitgestellt, in decisionOutput. Diese Felder haben dieselbe Verfügbarkeit und dasselbe schreibgeschützte Verhalten wie decisionOutput.

Bei der Navigation wird ein eingehender JPEG-Screenshot unverändert mit dem passenden JPEG-Medientyp gesendet; andere Frames behalten die PNG-Normalisierung bei. Das Bild wird dabei weder skaliert noch verlustbehaftet komprimiert. Die gespeicherte Beobachtung bleibt exakt das ursprüngliche Quellbild.

Der Abschluss der Navigation erfordert derzeit eine Modellzielwahrscheinlichkeit von mindestens 0,70; eine explizite Startbedingung erfordert bei der ersten Entscheidung weiterhin 0,85. Diese gemeinsame Ausführungsrichtlinie für Studio, CLI und MCP stellt den Aufgabenerfolg nicht unabhängig fest. Behalte explizite Ergebnisaussagen bei, insbesondere für Buchungen, Speichervorgänge oder erwartete Fehlerzustände. Die Wahrscheinlichkeiten sind Einschätzungen des Modells und keine Garantie. Das Experiment zur Abschlussrichtlinie und die Regressionen werden im Iterationsprotokoll von Studio dokumentiert.

Navigationsentscheidungen vom Typ TYPE_TEXT wählen das bearbeitbare Ziel und die benannte Datenreferenz gemeinsam in einer Auswahl aus. Der Runner validiert das Paar anhand seiner aktuellen Auswahl, überprüft den Fokus und – wenn ein Klick zum Fokussieren erforderlich ist – die Sichtbarkeit des Ziels oder die Erreichbarkeit durch den Treiber. Anschließend löst er den bereitgestellten Wert lokal auf, bevor er ihn eingibt. Die ausgewählten Referenznamen und erwarteten Zeichenfolgenwerte werden ebenfalls übertragen in decisionInput.state.inputData und in den Nachweisen gespeichert; nicht zugehörige Testdaten werden ausgeschlossen. Die gespeicherte Beobachtung enthält weiterhin die Kandidaten-ID in target und den bestehenden Datenpfad in inputReference bereit; ältere Modellausgaben verwendeten separate Köpfe für Ziel und Eingabe. Das Lesen dieser Informationen erfolgt synchron und ohne Nebenwirkungen. Die gemeinsame Auswahl garantiert nicht, dass das gewählte Feld-/Referenzpaar semantisch korrekt ist.

Die Navigation akzeptiert derzeit höchstens 250 lokal gefilterte sichtbare Kandidaten, einschließlich statischem Text und interaktiven Steuerelementen. Größere Beobachtungen schlagen explizit fehl, ohne Ziele stillschweigend abzuschneiden. Dies ist eine Ausführungsressourcenbegrenzung, keine Mindestanzahl von Elementen und keine Modellanforderung. Die bestehenden Zeitüberschreitungs- und Aktionsbudgets gelten weiterhin.

Native GPT-6-Luna-Decisions-Adapter

Setze REPEATO_NAVIGATION_MODEL=gpt-6-luna und OPENAI_API_KEY vor dem Start von Studio/CLI/MCP. Jev bleibt die Standardeinstellung. GPT-6 Luna verwendet POST https://api.openai.com/v1/decisions, mit demselben gefilterten Zustand, dem ursprünglichen Screenshot und denselben Bedeutungen der Fragen. Interne Legacy-noul-Fragen werden auf native Prädikatfragen abgebildet; feste Kriterien auf native Auswahlwerte/-beschreibungen. Dieser Adapter verwendet weder die Generierung von Responses-JSON noch eine Reasoning-Einstellung, ein Ausgabe-Token-Limit, generierte Koordinaten-/Textwerte oder einen Modell-Fallback. Vorhandene Abbruch-/Deadline-, Sichtbarkeits-, Aktualitäts-, Fokus- und Budgetregeln sowie unabhängige Ergebnisaussagen bleiben anwendbar.

Raw navigationObservation.decisionOutput behält den nativen API-Body vor der Validierung bei. Der Adapter ordnet das Antworten-Array anhand jedes eindeutigen Fragnamens zu, validiert Typen, Wahrscheinlichkeitsbereiche und zulässige Werte und überträgt die Prädikatwahrscheinlichkeit in die bestehenden Ziel-/Startprüfungen (0,70/0,85 unverändert). Eine erforderliche Ablehnung sowie doppelte, fehlende oder unbekannte Namen und ungültige Auswahlmöglichkeiten führen ohne Dispatch zum Fehlschlag. Konfidenzen und Wahrscheinlichkeiten stammen aus der API und werden nicht erfunden. Eine gleichwertige Wahrscheinlichkeitskalibrierung verschiedener Modelle wird nicht vorausgesetzt. Jedes zurückgegebene Modell muss gpt-6-luna entsprechen; lässt die API die Modellidentität weg, bleibt das aufgelöste Modell null, statt erfunden zu werden.

decisionInput.api ist openai-decisions; requestOptions.questions protokolliert die exakt zugeordneten Wire-Fragen, während Zustand und Screenshot-Referenz die gemeinsamen Belege rekonstruieren. Das ausschließlich für Jev geltende Provider-Feld fehlt. Lesevorgänge sind synchron und haben keine Nebenwirkungen. Für GPT serialisiert structuredBytes die native Anfrage mit einer leeren Bild-URL; Bild-Bytes werden separat gemeldet. Fehlende Provider-Kosten sind unbekannt, nicht null. Vorhandene historische openai-responses Berichte bleiben unverändert und dürfen nicht als native-Decisions-Läufe bezeichnet werden.

Der offizieller Decisions-Leitfaden dokumentiert Text-/Bildeingaben sowie Prädikat-/Auswahlantworten. Die Verfügbarkeit von Live-Modell/Konto erfordert weiterhin einen erfolgreichen Preflight. Alle Ausführungsnachweise bleiben über die vorhandenen MCP-Lauf-/Ergebnis-Tools zugänglich; ein separater MCP-Aktionsendpunkt ist nicht erforderlich.

Native Decisions bewahrt einzelne Ablehnungen oder nicht verfügbaren spekulativen Heads, ohne Antworten zu erfinden: Der gemeinsame Executor lehnt eine Ablehnung ab, wenn sie für die gewählte Operation, das Ziel, den zutreffenden Start oder die Sichtbarkeit des gewählten Ziels erforderlich ist. Eine nicht verwendete abgelehnte Head bricht keine andere, unabhängig verifizierte Operation ab. Native Auswahl-Arrays erfordern mindestens zwei Einträge; ein Head mit einer realen Option enthält eine ausdrückliche Enthaltung für „keine zutreffende Auswahl“. Dieser reservierte Wert kann keinen Dispatch auslösen und bleibt in der rohen API-Ausgabe erhalten; wird er ausgewählt, wird dieser Head als nicht verfügbar behandelt.

Für TYPE_TEXTNavigation kann ein eindeutig zugeordnetes, fokussiertes und aktiviertes editierbares Feld aus der aktuellen Hierarchie wiederverwenden. Dadurch werden der Fokus-Klick und die Bestätigung der Sichtbarkeit im Modell übersprungen. Identität, sofern vorhanden, Rolle, Beschriftung und Begrenzungen müssen übereinstimmen. Der Fokus wird vor Textänderungen erneut geprüft, und der resultierende Feldwert muss exakt mit der angegebenen Referenz übereinstimmen. Dadurch wird keine visuelle Sichtbarkeit festgestellt. Das optionale schreibgeschützte Beobachtungsfeld focusClickDispatched ist false wenn der vorhandene Fokus wiederverwendet wurde und true wenn ein Fokus-Klick ausgelöst wurde. In älteren Durchläufen fehlt dieses Feld. Das Auslesen in Studio- oder CLI-Skript-Schritten sowie in der erweiterten Konfiguration erfolgt synchron und ohne Seiteneffekte. Der Viewer zeigt keine Klickmarkierung an, wenn dieses Feld false.

Browser Navigation behandelt ein natives Date-Steuerelement als ein bearbeitbares Ziel und blendet die internen Segmentkandidaten aus. Übergib Datumsangaben als YYYY-MM-DD-Zeichenfolgen in inputReferences. Der asynchrone Runner klickt lokal auf die nativen englischen Segmente für Jahr, Monat und Tag, gibt die übergebenen Bestandteile ein und überprüft das vollständige ISO-Datum, bevor er fortfährt. Dabei werden ein aktuelles Ziel, Segmentgrenzen und der Fokus geprüft; ungültige Datumsangaben, nicht unterstützte Segmente, deaktivierte Steuerelemente oder abweichende Werte führen zum Fehlschlag. Dieser reine Browser-Pfad fügt keine Android-/iOS-Unterstützung für Date-Picker hinzu. Segmentklicks sind intern Teil einer einzelnen TYPE_TEXT-Modellaktion; das bestehende Aktionsbudget zählt diese Aktion einmal. Eine Änderung des DOM-Werts oder die Bereitstellung von Browser Host ist nicht erforderlich.

Die Browser-Navigation bietet ausführbare Steuerelemente, sobald mindestens 50 % ihrer Rechteckfläche innerhalb des normalisierten Viewports liegen. Für andere Knoten bleibt die Filterung des vollständigen Rechtecks bestehen. Ein teilweise abgeschnittenes Ziel behält seine ursprünglichen Grenzen bei und stellt clickPoint (normalisierte x/y-Koordinaten) bereit – den Mittelpunkt des sichtbaren Rechtecks. Die Ausführung und die Markierung im Bericht verwenden diesen Punkt. Dieser geometrische Anteil ist kein Beleg dafür, dass keine Overlays vorhanden sind: Die Sichtbarkeitsprüfung des Screenshots muss einen nicht verdeckten clickPoint erkennen, und aktuelle Prüfungen der Erreichbarkeit und Tastatur bleiben bestehen. Ein Host-Hit-Test für den ursprünglichen Mittelpunkt wird nicht als positiver Beleg für einen anderen Punkt wiederverwendet. Die Filterung nativer Ziele bleibt unverändert. CLICK-Auswahlen beschreiben außerdem ausdrücklich ausgewählte erwartete Werte, die bereits mit bearbeitbaren Feldern übereinstimmen; nicht zugehörige aktuelle Feldinhalte werden nicht gesendet.

Neue veraltete Navigation-Beobachtungen enthalten optional hierarchyChanges mit comparison=„hierarchy_paths“, totalChanges und einem changes-Array. Jeder Eintrag identifiziert einen JSON-Pointer-Pfad, den Änderungstyp sowie verfügbare Vorher-/Nachher-Werte aus der Hierarchie der ursprünglichen Anfrage und der Hierarchie der aktuellen Dispatch-Prüfung. Dies ist ein pfadbasierter Strukturvergleich, keine abgeleitete Elementidentität oder kausale Diagnose. Bearbeitbare Inhalte und value-Eigenschaften werden redigiert; ihre Änderungen bleiben protokolliert. Die Daten werden lokal gespeichert, nicht in die Model-Eingabe aufgenommen und sind über executionEvidence.navigationObservation in Script-Schritten, der erweiterten Konfiguration sowie bestehenden MCP-Ausführungs-/Ergebnis-Tools synchron und ohne Seiteneffekte lesbar. Ältere Berichte enthalten das Feld nicht; im Viewer wird ausdrücklich darauf hingewiesen, dass der Vergleich nicht aufgezeichnet wurde. Die bestehende Erkennung veralteter Navigation und das Verhalten ohne Dispatch bleiben unverändert.