Das Ticket wird zum Pull Request. Polylane erledigt das Graben dazwischen.
Auf die WartelisteEs prüft zuerst, was sich geändert hat. Die Hälfte der Tickets führt zurück zu einer Änderung, die jemand gemacht hat.
SQS visibility timeout lowered on checkout-events
VisibilityTimeout on checkout-events dropped from 120s to 15s. Consumers that hold a message longer than 15 seconds will see it delivered twice; the dead-letter queue threshold is unchanged.
SetQueueAttributes CloudTrail · deploy-bot · 12:41:02Z attached to this record's delta window Theorien werden getestet, nicht geglaubt. Bestätigt nur mit Belegen aus deinen echten Systemen.
Hyperdrive pool exhaustion after deploy 9f3c2a1
Confidence: strong · 3 of 3 passes
Upstream PlanetScale degradation
Confidence: definitive · 3 of 3 passes
Cold-start regression in the new isolate
Confidence: weak · 2 of 3 passes
Der Fix kommt bereit zum Review. Grundursache, Validierung und Diff inklusive.
Cap retries on the checkout webhook worker #491
polylanemain from polylane/autofix/chat/k3x9f2-4e7d21a 
Retries on the checkout webhook worker were unbounded: a failing delivery re-queued itself forever and amplified load on payments-api. This caps delivery at 5 attempts with exponential backoff and dead-letters the payload after the last one.
What changed
worker/deliver.ts gains MAX_DELIVERY_ATTEMPTS = 5 and backoff between attempts; exhausted payloads land in checkout-webhooks-dlq instead of re-queueing.
Validation
npm test — 214 passed. A forced failing delivery stopped after 5 attempts and appeared in the dead-letter queue.
So funktioniert Polylane. Es lernt dein System, beobachtet es, untersucht und handelt.
-
Es lernt zuerst dein System
Der Context Graph kartiert jede Ressource und Abhängigkeit über deine Clouds, Repos und Observability-Provider. Agenten denken über echte Topologie nach, nicht über Vermutungen.
-
Erkennung ohne Schwellenwerte
Eingebaute Checks für jeden Provider, plus Checks aus deinen eigenen gespeicherten Queries und Dashboards. Ein statistischer Durchgang und ein Agent entscheiden gemeinsam, und eine Verbesserung löst nie ein Issue aus.
-
Untersuchungen mit Belegen
Jede Behauptung verweist zurück auf die Query, die Logzeile oder den Änderungseintrag dahinter. Ein Urteil ohne Belege fällt auf unentschieden zurück.
-
Schreibzugriff wird verdient, nie vorausgesetzt
Konten verbinden sich nur lesend. Rollbacks sind standardmäßig aus, ratenbegrenzt und protokolliert. Codeänderungen gehen durch dein normales Review.
-
Es wird jede Woche schärfer
Memories, tägliche Notizen und Monitoring-Queries, gegen echte Daten neu bestätigt: Die Untersuchung im Juli lernt von der im Juni.
Es steckt sich in das, was du schon betreibst. Nur lesend verbinden und loslegen.
Fragen.
Wie übergebe ich Polylane ein Ticket?
Starte einen Thread in der Konsole, über die CLI oder aus deinem Editor über den MCP-Server, und beschreib den Bug. Agenten übernehmen von dort mit dem vollen Kontext des Workspace: dem Graph, der Telemetrie, den Änderungseinträgen und dem Code.
Was, wenn es die Ursache nicht findet?
Dann sagt es das. Untersuchungen enden gelöst, diagnostiziert oder unentschieden: Eine Untersuchung, die keine Daten erreichen konnte, bestätigt nie, und alles, was eine menschliche Entscheidung braucht, wird zu einer Eskalation, nicht zu einer nörgelnden Schleife.
Lernt es aus vergangenen Tickets?
Ja. Bestätigte Befunde werden als Memories gespeichert und in späteren Threads nach Bedeutung abgerufen, und tägliche Notizen führen ein laufendes Protokoll dessen, was passiert ist. Die Untersuchung im Juli lernt von der im Juni.
Wer schreibt den Fix?
Standardmäßig Polylanes Autofix: erst untersucht, geschrieben und validiert, mit der Begründung dabei. Oder gib die Umsetzung an Devin, Cursor oder Factory. So oder so prüfst du ihn.
Mit welchen Repositories funktioniert es?
GitHub-Repositories, verbunden über die GitHub-App. Der Fix landet auf einem Branch im Repo hinter dem betroffenen Service, mit der Untersuchung aus der Änderung verlinkt.