Playwright-Integration in Ottili Coder

Überblick

Ottili Coder kann während eines Runs einen echten Browser über Playwright* steuern. Damit prüft Coder User Interfaces, erstellt Screenshots, füllt Formulare aus und führt Browser-Flows aus – statt nur Code zu lesen. Die Browser-Integration ist eine integrierte Coder-Fähigkeit: Sie läuft im Kontext eines Coder-Workspaces und teilt sich dieselbe Mission, dieselbe Task-Queue, dieselben Logs und denselben Audit-Trail wie der übrige Coder-Run.

Die Integration ist bewusst operationsnah gebaut: Jeder Browser-Lauf ist korrelationsgetreu, credit-metriert, freigabepflichtig für externe Ziele und resilient gegen langsame Abhängigkeiten. Sie meldet ehrlich, wenn eine Abhängigkeit nicht erreichbar ist, statt still einen Erfolg vorzutäuschen.

Was die Browser-Integration kann

• UI verifizieren*: Coder navigiert zu einer URL, prüft sichtbare Elemente und liest Texte sowie Zustände aus.
• Screenshots*: Einzelne Schritte oder ganze Seiten werden als Bild festgehalten.
• Formulare bedienen*: Klicks, Eingaben, Selects und Warte-Schritte werden als Sequenz ausgeführt.
• Flows ausführen*: Mehrere Schritte hintereinander – zum Beispiel Login → Navigation → Aktion → Screenshot.
• Code auswerten*: Über einen Evaluierungs-Schritt kann Coder Werte im Seitenkontext abfragen.

Die Engine arbeitet pro Aufruf zustandslos: Du übergibst eine Liste von Schritten, Coder führt sie gegen das konfigurierte Browser-Profil aus und gibt das Ergebnis zurück.

So funktioniert es

Die Browser-Integration ist an einen Coder-Workspace* gebunden. Pro Workspace existiert ein Browser-Profil, inklusive einer Standard-Playwright-Umgebung. Wenn du keinen expliziten profile_id angibst, verwendet Coder das Standard-Profil des Workspaces.

Ein Browser-Lauf wird über den Browser-Execute-Endpunkt der Ottili-Coder-Workspace-API angestoßen:

POST …/workspaces/{slug}/browser/execute

Der Request-Körper enthält:

• profile_id *(optional)* – welches Browser-Profil genutzt wird; ohne Angabe das Workspace-Standardprofil.
• steps – die auszuführende Schrittliste (siehe unten).
• timeout_ms – Gesamt-Timeout für den Lauf in Millisekunden.
• approval_ref *(optional)* – Freigabe-Referenz, sobald ein Schritt ein externes Ziel anspricht (siehe Freigaben).

Die Antwort enthält pro Schritt ein Ergebnis sowie eine correlation_id, mit der du den gesamten Lauf über die Plattform hinweg nachverfolgen kannst.

Schritte und Aktionen

Jeder Schritt ist ein Objekt mit einer action und optionalen Feldern (url, selector, text, key, timeout_ms). Unterstützte Aktionen:

• navigate – zu einer URL navigieren (relativ zur base_url des Profils oder absolut); optional wait_until.
• click – ein Element über einen selector anklicken.
• type – einen Wert (text) in ein Feld (selector) eingeben.
• press – eine Taste (key) drücken.
• wait_for – auf ein Element (selector) oder eine Dauer warten.
• snapshot – Titel, URL und sichtbaren Text der Seite erfassen (optional das HTML).
• screenshot – einen Screenshot des aktuellen Zustands erstellen (Format png, optional full_page).

Ein Profil kann allowed_origins definieren. Navigationen innerhalb erlaubter Origins laufen direkt; Ziele außerhalb erfordern eine Freigabe (siehe unten). Hinweis: Schon beim navigate prüft die Engine, ob die URL vom Profil erlaubt ist – sonst wird der Schritt mit einem klaren Fehler abgelehnt.

Credits und Abrechnung

Browser-Läufe sind credit-metriert*. Ein Lauf bucht ein begrenztes, gebundenes Budget aus dem geteilten Firmen-Credit-Wallet (Produktfläche ottili_coder). Die Abrechnung ist idempotent: Reservierung → Buchung bei Erfolg, Rückerstattung bei Fehler. Ein einzelner Lauf verbraucht nur ein kleines, begrenztes Budget – Browser-Starts sind ressourcenintensiv, daher ist das Budget bewusst niedrig gehalten.

Wenn das Wallet nicht erreichbar ist, bricht der Lauf nicht still ab: Coder meldet einen ehrlich degradierten Zustand (degraded) und führt den Lauf trotzdem aus, statt einen falschen Erfolg zu melden.

Freigaben für externe Navigation

Wenn ein Schritt zu einem Host außerhalb der allowed_origins des Profils navigiert, handelt es sich um einen geschützten externen Effekt*. Coder fragt dann das bestehende Freigabe-Modell ab:

• Ohne approval_ref wird der Lauf mit dem Hinweis blockiert, dass eine Freigabe nötig ist.
• Mit approval_ref prüft Coder, ob die Freigabe für genau diese Firma freigegeben (approved) ist. Eine Freigabe einer fremden Firma erfüllt die Bedingung nie.
• Ist der Freigabe-Dienst nicht erreichbar, gilt Fail-Safe: Der externe Schritt darf nicht ausgeführt werden.

So bleibt die Steuerung eines fremden Hosts immer freigabegesteuert, nie still.

Korrelations-ID und Observability

Jeder Browser-Lauf trägt eine stabile `X-Correlation-ID`*. Sie wird upstream (Dashboard, CLI oder Desktop) mitgetragen und bleibt über die gesamte Kette – Unified API, Credits, Freigaben und Audit – hinweg erhalten. Start, Ergebnis, Dauer und Fehler (ohne Secrets) werden in die Core-Telemetrie und strukturierte Logs geschrieben, sodass du einen einzelnen Browser-Lauf lückenlos nachverfolgen kannst.

Resilienz und degradierte Zustände

Jeder kreuzweise Aufruf (Credits, Freigabe) läuft über gebundene Timeouts und Circuit-Breaker. Eine langsame oder fehlgeschlagene Abhängigkeit kann einen Browser-Request nie unbegrenzt blockieren. Schlägt eine Abhängigkeit fehl, meldet Coder einen explizit wiederherstellbaren Zustand (degraded) – niemals einen stillen Erfolg und niemals einen unbehandelten 500-Fehler.

Status und Verfügbarkeit

Die Browser-Integration ist eine integrierte Coder-Fähigkeit* (verfügbar im Coder-Workspace). Voraussetzungen:

• Ein Coder-Workspace mit aktiviertem Browser-Profil.
• Ausreichend Credits im geteilten Firmen-Wallet.
• Für Navigationen außerhalb erlaubter Origins eine gültige Freigabe.

Sie ist derzeit kein eigener Abschnitt auf der öffentlichen Coder-Seite*; sie wird aus dem Coder-Workspace heraus genutzt. Die Fähigkeit entwickelt sich weiter – prüfe die Status- und Produktseiten für den aktuellen Stand. Wie Ottili ONE Reifestatus öffentlich kennzeichnet, beschreibt der Artikel [Feature-Status-Labels verstehen](/docs/understand-feature-status-labels).

Verwandte Artikel

• [Ottili Coder – Überblick](/docs/ottili-coder)
• [Coder-Modi](/docs/coder-modes)
• [Lokale, Cloud- und Hybrid-Runs](/docs/coder-local-cloud-hybrid-runs)
• [Sicherheit](/docs/coder-security)
• [Validierung](/docs/coder-validation)
• [Fehlerbehebung](/docs/coder-troubleshooting)
• [Feature-Status-Labels verstehen](/docs/understand-feature-status-labels)