Untersuchen und beheben

Autofix

Von Agents geschriebene Fixes kommen als Pull Requests in deinem Repository an. Du reviewst und mergst; Polylane erinnert dich und räumt auf, was niemand anfasst.

Ein Autofix ist ein Pull Request, den Polylane öffnet, um etwas zu lösen, das es gefunden hat. Der Agent untersucht zuerst, schreibt dann die Änderung auf einen Branch und öffnet den Pull Request auf GitHub; der Merge liegt bei dir.

Was es leistet

Autofixes starten an drei Stellen. Du bittest in einem Thread um einen, zum Beispiel „öffne einen Pull Request, der das behebt“. Ein Fix-Run landet bei einer bestätigten Ursache in einem verbundenen Repository und öffnet den Fix im selben Thread. Oder Polylane schlägt von sich aus einen vor, etwa die Observability-Verbesserungen, die es entwirft, wenn ein Repository erstmals verbunden wird.

So funktioniert es

Untersuchen: Der Agent sammelt Kontext aus der Topologie, der Telemetrie und dem betroffenen Repository.
Branch: Er erstellt einen Branch gegen den Basis-Branch des Repositories.
Fix: Der Executor schreibt die Änderung und pusht Commits.
Pull Request: Er öffnet den Pull Request, der beschreibt, was falsch war und was sich geändert hat, verlinkt mit dem Thread oder Issue dahinter.
Dein Review: Dein normales Code-Review und deine Continuous Integration entscheiden über den Merge. Ihn zu schließen ist ein gültiges Ergebnis, und Polylane hält es fest.

Status

Status	Beschreibung
`started`	Der Run läuft.
`branch_pushed`	Commits sind auf dem Branch, und der Pull Request wird gleich geöffnet.
`approval_required`	Der Workspace fragt, bevor automatische Fixes starten, dieser Run wartet also darauf, dass ihn jemand aus seinem Thread startet.
`pr_opened`	Der Pull Request ist offen und wartet auf dein Review.
`merged`	Du hast den Pull Request gemergt.
`closed`	Der Pull Request wurde ohne Merge geschlossen, von dir oder von Polylane.
`failed`	Der Executor konnte keinen Fix erzeugen.
`no_fix_needed`	Der Agent kam zu dem Schluss, dass nichts zu ändern war.
`already_in_flight`	Ein anderer Run oder ein offener Pull Request deckt denselben Fix bereits ab.
`quota_exhausted`	Der Workspace kann gerade keinen weiteren Run starten.
`disabled`	Autofix ist für den Workspace ausgeschaltet.
`plan_rejected`	Die Anfrage wurde abgelehnt, bevor ein Run startete.
`unreachable`	Polylane kann das Repository nicht mehr lesen, zum Beispiel nachdem die GitHub App entfernt oder gesperrt wurde.
`expired`	Der Run ist über sein Zeitfenster hinaus hängen geblieben und wurde abgeschlossen.

Ein übersprungener Run lässt sich aus seiner Übersicht mit Run anyway starten, ein abgelaufener oder fehlgeschlagener mit Run again und ein zurückgehaltener mit Approve and run. Unter Settings > Workspace hält die Karte Autofix den Schalter Open autofix pull requests für den gesamten Workspace und Fixes Polylane starts on its own, wo Ask first automatische Fixes zurückhält, bis sie jemand startet.

Offen gebliebene Pull Requests

Ein Pull Request, den Polylane öffnet, wartet nicht ewig. Nach einer Woche ohne Aktivität schickt der wöchentliche Durchlauf eine Erinnerung per E-Mail und in Slack und hinterlässt dieselbe Notiz als Kommentar am Pull Request; wenn niemand um ein Review gebeten wurde, werden die Owner des berührten Codes gefragt. Ein Pull Request, an dem nach der Erinnerung eine weitere Woche nichts passiert, wird von Polylane mit einem erklärenden Kommentar geschlossen, und der Branch bleibt, sodass ein erneutes Öffnen die Änderung so zurückbringt, wie sie ist.

Pull Requests, die geöffnet werden, während ein Repository verbunden wird, sind von Erinnerungen und Schließungen ausgenommen.

Executors

Der Executor ist der Coding-Agent, der den Diff schreibt. Der eigene Executor von Polylane braucht keine Einrichtung; du kannst Autofixes stattdessen über einen Coding-Agent leiten, den du bereits nutzt:

Devin

Delegate autofix implementation to Devin cloud agents

Cursor

Delegate autofix implementation to Cursor cloud agents

Factory

Delegate autofix implementation to Factory droids

Conductor

Delegate autofix implementation to Conductor cloud agents

Local coding agent

Map your stack from the coding agent on your machine

Amp

Delegate autofix implementation to Amp agents

Verbinde Devin, Cursor, Factory oder Conductor unter Settings > Integrations mit deinem eigenen API-Schlüssel und schalte dann Use Devin for all autofixes (oder den entsprechenden Schalter auf der Seite von Cursor, Factory oder Conductor) ein, um ihn zum Executor für jeden Autofix im Workspace zu machen. Wird diese Integration entfernt oder deaktiviert, fallen Autofixes auf den Polylane-Executor zurück.

Wo du es findest

Lies einen Autofix in dem Thread, der ihn erzeugt hat. Die Lineage in der Seitenleiste des Threads zeigt den Autofix und seinen Pull request, und der Autofix-Knoten öffnet die Tabs Overview, Diff, Session, Timeline und Properties. Approve and run, Run again und der Schließgrund liegen in seiner Übersicht.

Verwandt

Fix-Runs für die Runs, die eine bestätigte Ursache an Autofix übergeben.
Pull-Request-Reviews für die Prüfung, die jeder Pull Request vor dem Merge bekommt.
Repositories, um den Code zu verbinden, in den Autofixes schreiben.
GitHub für die Code-Host-Verbindung, über die Autofixes schreiben.

Escalations

Die eine Liste dessen, was Agents von dir brauchen: ein Datensatz pro Anliegen, so oft es auch wiederkehrt, erledigt, wenn du dich darum gekümmert hast.

Aus deinen Tools arbeiten

Frag aus deinem Coding-Agent, Terminal oder deiner CI nach der Produktion: ein MCP-Server, eine CLI und ein Plugin, das beides installiert.