Build-Log. Was live ging, Woche für Woche.

Ein Agent vom Befund bis zum Pull Request

Jeder Befund, den Polylane erkennt, wird jetzt von einem einzigen Agenten-Run bearbeitet. Er liest die Belege mit nur lesenden Tools über deine Telemetrie und den Context Graph, entscheidet, ob es ein echtes Issue gibt, und wenn die bestätigte Ursache ein Codefehler in einem verbundenen Repository ist, schreibt er den Fix und öffnet den Pull Request im selben Run, ohne Übergabe zwischen Triage-, Untersuchungs- und Autofix-Stufen. Der Pull Request beginnt mit einer Affected-Zeile, die die Ressource, den verletzten Wert gegen seine Baseline und die Zahl der Abhängigen nennt, die ein Fehler erreicht, und seine Sicherheitsbegründung steht in einem sichtbaren Abschnitt Why it’s safe. Ist ein Fix außer Reichweite, hält der Run den Grund und einen klaren nächsten Schritt auf dem Issue fest, statt zu versanden.

Grafana Cloud und Logfire kommen zu den Observability-Integrationen

Verbinde Grafana Cloud, oder selbst gehostetes Grafana, mit einer Stack-URL und einem Service-Account-Token. Polylane fügt dem Stack einen Contact Point und eine Catch-all-Benachrichtigungsroute hinzu, sodass jede bestehende Alert-Regel und jede Regel, die du später anlegst, ohne Einrichtung pro Regel bei ihm ankommt. Verbinde Pydantic Logfire mit einem API-Schlüssel, und der Agent bekommt Tools, um von einer fehlschlagenden Route zum genauen Span zu kommen, der geworfen hat, plus nur lesendes SQL für alles andere; das Projekt wird wie bei den anderen Providern auf Fehlerrate, Request-Volumen und p95-Latenz beobachtet.

Außerdem diese Woche:

• Verworfene Issues bekommen einen zweiten Blick: Ein wiederkehrender Befund wird erneut triagiert, ein Verwerfen wird abgelehnt, wenn die Belege einen Incident auf einer kritischen Ressource nicht ausschließen, und ein „kein Incident“ von einer Person bleibt endgültig
• GitHub zu verbinden fragt einmal, ob Pull Requests geprüft werden sollen, und ein Pull Request, der ein bekanntes Issue behebt, bekommt ein grünes oder gelbes Urteil dazu, ob er es lösen sollte
• Ein Key questions-Tab auf jedem Cloud-Konto, jeder Integration und jeder eng beobachteten Ressource zeigt die Fragen, die Polylane an deine Telemetrie stellt, mit der Provider-Query hinter jeder
• Der Context Graph bekommt RDS-Read-Replicas und RDS Proxy, verknüpft Repositories mit den Kubernetes- und Railway-Workloads, die die Images ausführen, die sie bauen, und benennt S3-Buckets und RDS-Endpunkte aus Umgebungsvariablen, bevor das AWS-Konto verbunden ist
• Der AWS-Verbindungsdialog zeigt das erzeugte CloudFormation-Template mit Kopieren und Herunterladen, und il-central-1 ist verfügbar
• Tägliche Log-Trends werden als triagierte Issues angelegt, statt per E-Mail zu kommen
• Füg Bilder in den Chat-Composer der Konsole ein oder zieh sie hinein, und Checks haben ihre eigene Seite mit Kopierlink
• Slack-Antworten enden damit, wie lange der Run gedauert hat und wie viele Aktionen er ausgeführt hat, und der MCP-Server zeigt einen Zustimmungsbildschirm, bevor er einen Client autorisiert
• Die CLI verbindet Grafana Cloud, Mixpanel und OpenStatus mit polylane integration connect und Railway mit polylane cloud connect --provider railway und fragt beim Verbinden von GitHub, ob Pull Requests geprüft werden sollen (--no-pr-reviews lehnt ab)
• Und wie immer: Verbesserungen bei Zuverlässigkeit, Performance und Stabilität

Drei weitere Clouds und dein Issue-Tracker kommen in den Context Graph

Du kannst jetzt ClickHouse Cloud, Convex und Turso verbinden: Füg einen Token ein, und ihre Services, Projekte, Deployments und Datenbanken synchronisieren alle 15 Minuten in den Context Graph, mit Gesundheits-Checks und Agenten-Tools. Linear ist die erste Issue-Tracking-Integration: Der Agent liest deine Teams, Projekte und Issues in jedem Thread, legt Issues aus Untersuchungen an, mit der Beweiskette dabei, und aktualisiert Status, Priorität oder Zuständigen, wobei er dich vor jedem Schreibzugriff um Bestätigung bittet. Neue Ressourcen kommen bereits verdrahtet an: Sekundäre ClickHouse-Services verknüpfen sich mit ihrem Primary, Turso-Branches mit der Datenbank, von der sie abgezweigt wurden, und Supabase-Auth-, -Storage-, -Realtime- und -REST-Services mit der Postgres-Datenbank, die sie bedienen, sodass ein Fehler auf dem Primary alles erreicht, was davon abhängt.

Ein Blast Radius, überall

Die Blast-Radius-Engine hinter Pull-Request-Reviews antwortet jetzt überall: Issue-Slideovers, Änderungseinträge und Thread-Artefakte zeigen dieselbe nachgelagerte Reichweite, Agenten können danach fragen, und jeder Autofix-Pull-Request nennt das Tier der betroffenen Ressource und was ein Fehler dort erreichen würde. Der Graph, den sie abläuft, ist dichter: CloudFront-Distributionen verknüpfen sich mit ihren Origins und WAF-Web-ACLs, Security-Group-Regeln werden zu Erreichbarkeitskanten, R2-Buckets verknüpfen sich mit den Queues, die sie benachrichtigen, und Step-Functions-Definitionen ergeben eine Kante für jeden Service, den sie aufrufen. Ein neuer Connections-Tab auf jeder Ressource listet jede Kante mit ihrer Richtung, wie sie entdeckt wurde und den Belegen dahinter.

Außerdem diese Woche:

• Eine AWS-Verbindung deckt jetzt eine beliebige Menge Regionen ab, oder alle, mit CloudTrail und Alerts pro Region
• Autofix-Pull-Requests fordern ein Review vom Verantwortlichen der betroffenen Ressource an, nutzen standardmäßig Conventional Commits, enthalten ein Mermaid-Diagramm, wenn der Fix Struktur zu zeigen hat, und veralten nach 14 ruhigen Tagen, damit ein besserer Fix nicht länger zurückgehalten wird
• Du kannst pro Workspace einen Mindest-Schweregrad für die Untersuchungen setzen, die Polylane von selbst startet; neue Alerts werden von einem Agenten mit nur lesenden Tools triagiert, bevor sie zu Issues werden, und hängende Untersuchungen setzen sich von selbst fort
• Hypothesenkarten in einem Thread lauten Bestätigt, Widerlegt oder Unentschieden, und ein Thread, der auf deine Antwort wartet, sagt das
• Sag dem Slack-Agenten, er soll verschwinden, und er schaltet den Thread stumm, bis du ihn wieder @-erwähnst; die Channels-Seite listet jetzt jeden Channel in deinem Workspace mit einem Join-Button für die, in denen Polylane nicht ist
• Die Topologie-Seite aktualisiert sich live, ihre Suche ist Volltext über Namen, Aliase und Beschreibungen, und jedes Chart in einem Thread lässt sich als JSON, CSV oder PNG herunterladen
• Jeder Bericht, der an ein Mixpanel-Board gepinnt ist, wird zu einem täglichen Check
• Autofix-Runs nutzen Node 24 und wählen die Version aus .nvmrc, .node-version oder engines.node
• Die CLI verbindet ClickHouse, Convex, Turso und Linear, führt die AWS-Verbindung im Hintergrund aus, damit du derweil andere Clouds verbinden kannst, akzeptiert --region all und bietet direkt nach dem Verbinden der App Slack-Channels zum Beitreten an
• Und wie immer: Verbesserungen bei Zuverlässigkeit, Performance und Stabilität

Bau deinen Context Graph aus dem Terminal mit deinem eigenen Coding-Agenten

Führe polylane map aus, und die CLI startet den Coding-Agenten, den du ohnehin benutzt, um das aktuelle Repository zu kartieren: Topologie, erste Issues und ein Erststart-Thread landen in deinem Workspace, während das Terminal einen Herzschlag zeigt. Dein Rechner und sein Agent sind jetzt eine Verbindung wie GitHub oder AWS, sodass jeder Rechner seinen eigenen Ausschnitt des Graphen schreibt und keiner den eines anderen überschreiben kann. Während die Kartierung läuft, zeigt die Topology-Seite Fortschritt, Issues und Chat an Ort und Stelle, bietet in der Zwischenzeit deine Clouds zum Verbinden an und gibt dir einen widerrufbaren Teilen-Link. Einen Cloud-Coding-Agenten zu verbinden macht ihn zu deinem Autofix-Executor, und er bekommt automatisch Polylanes MCP-Server hinzugefügt, damit er Polylane abfragen kann, während er einen Fix schreibt.

Railway, Mixpanel und OpenStatus kommen in den Context Graph

Railway ist ein verbindbarer Cloud-Provider: Verbinde per OAuth oder Workspace-Token, und Polylane synchronisiert Projekte, Services und Deployments, beobachtet Deploys, liest Logs und prüft Service-Metriken auf Issues. Mixpanel ist die erste Produktanalytik-Integration, sodass du fragen kannst, ob die Registrierungen nach einem Deploy eingebrochen sind, und ein täglicher Check beobachtet Event-Volumen auf Tracking-Brüche. OpenStatus bringt Monitore und Statusseiten in den Graph, triagiert jeden Ausfall und jede Erholung als Alert und verknüpft jeden Monitor mit der Ressource, die er prüft. Datadog, Sentry, Better Stack, Honeycomb und Axiom verknüpfen jetzt die Ressourcen, die an sie berichten, im Graph, und der Agent kann Better-Stack-Statusberichte veröffentlichen und Incidents bestätigen oder lösen, jeweils hinter deiner Bestätigung.

Außerdem diese Woche:

• Ein Cloud-Konto oder eine Observability-Integration zu verbinden legt von selbst Issues an: Polylane liest die letzten 24 Stunden Fehlerlogs nach wiederkehrenden Mustern und führt die ersten Checks sofort aus
• Pull-Request-Reviews tragen ein Register jedes betrachteten Fehlermodus, markiert als bestätigt, plausibel oder widerlegt, mit einem Blast Radius, der die nachgelagerten Ressourcen nennt, die ein Fehler erreicht, und den Traffic-Anteil, den sie tragen; der Changes-Tab stellt es nativ dar
• Issues lassen sich leichter triagieren: eine Schweregrad-Spalte und ein Filter, Duplikate standardmäßig ausgeblendet, und der Alert, der ein Issue geöffnet hat, am Anfang seiner Abstammung gezeigt
• Autofix-Pull-Requests zeigen ihren vollständigen Diff in einem Slideover, melden ihr Ergebnis an den Thread zurück, der gefragt hat, und liefern kein angehobenes Limit oder Timeout mehr als Fix
• Slack-Antworten hängen Charts als Bilder an, und ein langer Slack-Zug verlinkt in die Konsole, damit du mitverfolgen kannst
• Verbinde MCP-Server, die sich mit eigenen HTTP-Headern authentifizieren, nicht nur mit einem Bearer-Token
• Die Suche im Infrastruktur-Graph wechselt zu einer Tabelle, sodass Ergebnisse als Zeilen lesbar sind
• Die CLI verbindet mehrere Clouds auf einmal mit --multi, vorausgewählt anhand der Marker deines Repos, grenzt die Auswahl mit --category observability ein und öffnet eine vorausgefüllte Seite für einen nur lesenden Cloudflare-Token in deinem Browser
• Und wie immer: Verbesserungen bei Zuverlässigkeit, Performance und Stabilität

Jedes Issue bekommt eine Ursache, und eine passende Antwort

Polylane klassifiziert jetzt, warum jedes Issue passiert ist: ein Codefehler, wacklige Infrastruktur, ein externer Client, erwartetes Verhalten oder unbekannt, jeweils mit einer Konfidenz, und antwortet passend. Ein Codefehler bekommt einen Fix. Ein wackliger CI-Fehler bekommt eine Anfrage, den Workflow erneut auszuführen, statt eines Patches, und ein bestandener Wiederholungslauf löst das Issue von selbst. Erwartetes Verhalten wird verworfen oder seine Alert-Signatur stummgeschaltet, mit dem Grund festgehalten, und alles Unsichere geht an eine Person. Die Issue-Seite zeigt das Urteil, jede Entscheidung und wer sie getroffen hat, und die Belege hinter einer Verletzung: die abweichende Metrik, die ursächlichen Logzeilen und den Trace.

Du entscheidest, wann Autofix läuft

Ein Schalter Open autofix pull requests sitzt jetzt auf dem Workspace und auf jedem Repository, und ein neuer Modus Ask first hält jeden maschinell ausgelösten Fix als wartenden Run zurück, bis du auf Approve and run klickst; Fixes, um die du in einem Thread bittest, werden nie zurückgehalten. Jeder laufende Autofix kann abgebrochen werden, bevor sein Pull Request aufgeht, aus der Konsole, dem Chat oder Slack. Pull Requests tragen ein severity:-Label und beginnen mit dem, was den Fix ausgelöst hat: der betroffenen Ressource, der verletzenden Metrik und den Logzeilen, die gefeuert haben. Jeder Patch durchläuft ein Datensicherheits-Review, sodass einer, der neue Daten in Logs, Exporte oder Analytics leiten würde, überarbeitet oder zurückgehalten wird.

Außerdem diese Woche:

• GitHub zu verbinden öffnet jetzt innerhalb einer Minute einen ersten Pull Request, der Polylane-Anweisungen zu AGENTS.md, Cursor-Regeln und deinen anderen Agenten-Anweisungsdateien hinzufügt, mit dem Observability-Pull-Request dahinter, abbrechbar aus der Konsole
• Eine tägliche E-Mail zu Log-Trends kommt nur an Tagen, an denen sich etwas geändert hat, etwa ein neues Fehler-Template oder ein Service, der weit über seinem normalen Volumen loggt, jeweils mit einem Investigate-Button
• Bitte den Agenten, einen CI-Run oder ein Release zu beobachten, und er hört auf zu pollen und wacht auf, wenn das GitHub-Event landet
• Absichtliche wiederkehrende Signale bekommen einen Fix, der das Verhalten in deinem Code explizit macht, statt eines stummgeschalteten Alerts, und Alert-Issues, die verstummen, lösen sich von selbst
• Der Slack-Agent spricht in der ersten Person, und Bilder, die ihm in Slack geschickt werden, erscheinen jetzt in der Konsole
• Der Konsolen-Chat faltet jede Denkphase und ihre Tool-Aufrufe in eine Zeile, bietet nach 30 Sekunden eine Quick answer-Pille und Try again nach einer unterbrochenen Antwort
• Abstammungsknoten zeigen beim Hovern eine Vorschau und lassen sich mit der Tastatur durchgehen, externe Services wie googleapis.com bekommen ein Wiki, und Autoscaling-Churn verstopft den Änderungs-Feed nicht mehr
• Das Erscheinungsbild-Menü bekommt eine System-Option
• Die CLI bekommt polylane scan, das Schlüsselrisiken über deine verbundenen Konten findet und dich eines zur Untersuchung auswählen lässt, und polylane autofix watch, das Pull-Request-URLs ausgibt, sobald sie aufgehen, und die Verbindungsassistenten nennen die genauen Token-Berechtigungen jedes Providers
• Und wie immer: Verbesserungen bei Zuverlässigkeit, Performance und Stabilität

Modal und Supabase kommen in den Context Graph

Füg das Token-Paar ein, das Modal für die CLI-Anmeldung ausgibt, und deine Environments, Apps, Funktionen, Sandboxes, Volumes und Queues erscheinen im Context Graph, mit App-Logs, die in einen Digest gelesen werden, Kosten- und Fehlervolumen-Checks, die Issues öffnen, und jedem Repository verknüpft mit der App, auf der seine CI modal deploy ausführt. Verbinde eine Supabase-Organisation per OAuth oder persönlichem Zugriffstoken, und die Datenbanken, Edge Functions, Branches, Buckets, Auth und Storage jedes Projekts synchronisieren alle 15 Minuten, mit Dashboards, Logs und Checks auf jedem. Der Agent bekommt für beide nur lesende Tools, sodass eine Untersuchung liest, was Modal oder Supabase gerade tut, statt was der letzte Sync festgehalten hat.

Sprich mit dem Agenten, während er arbeitet

Eine Nachricht mitten im Zug zu senden hat früher den Zug abgebrochen und Minuten Arbeit weggeworfen. Jetzt bleibt der Composer aktiv: Deine Nachricht wird beim nächsten Schritt des Agenten aufgenommen und im Transkript dort gezeigt, wo sie gelesen wurde. Eine Nachricht, die nie ankommt, sagt das, mit einer Wiederholung. Stoppen und Senden teilen sich einen Button, Esc stoppt den Zug, und in der Sprachbedienung hört der Agent auf, die Frage zu beantworten, die du überredet hast.

Außerdem diese Woche:

• Der Slack-Agent postet Approve- und Deny-Karten, wenn eine Änderung eine Freigabe braucht, zeigt seine Aufgabenliste in seiner Statusnachricht und schließt einen Pull Request, den er geöffnet hat, wenn du ihn darum bittest
• Reagiere mit einem Haken auf eine Incident-Karte in Slack, um sie zu lösen, oder mit einem Verbotsschild, um sie als kein Incident zu markieren; die Karte aktualisiert sich an Ort und Stelle, und die Zeitleiste hält fest, wer gehandelt hat
• Ein Channels-Tab auf der Slack-Integration listet jeden Channel, in dem Polylane ist, und der Agent speichert die Anweisungen eines Channels selbst, wenn du ihm sagst, wie er sich dort verhalten soll
• Autofix-Pull-Requests beginnen mit einem Before/After-Abschnitt, geschrieben aus dem Diff, ein Implementation-Tab zeigt den Thread, der den Patch geschrieben hat, und ein schwacher Plan wird abgelehnt, bevor er einen Run kostet
• Polylane prüft auf einen offenen Pull Request, bevor es eine Untersuchung ausgibt, und behält die Arbeit eines langsamen Autofix-Zugs, statt sie zu verwerfen
• Pull-Request-Reviews lassen sich pro Repository von der Repositories-Seite ein- oder ausschalten, gebündelt oder über eine ganze GitHub-Integration mit einem Schalter
• Veröffentlichte Karten geben dir jetzt nach etwa zwei Minuten einen Link als Entwurf, der sich unter derselben URL verfeinert, mit Problemen neben dem Graph gelistet und einem Investigate-Button auf jedem
• Die Registrierung legt sofort einen Workspace für dich an, Domain-Auto-Join ist standardmäßig aus, und ein Link in einen Workspace, in dem du nicht bist, bietet einen Beitrittsanfrage-Bildschirm
• Die CLI registriert dich mit Google, GitHub oder E-Mail über polylane auth signup, macht polylane cloud connect und polylane integration connect interaktiv, und polylane setup konfiguriert jetzt Cline, Roo Code, Goose, Pi und Warp
• Und wie immer: Verbesserungen bei Zuverlässigkeit, Performance und Stabilität

CI-Fehler werden zu Issues, Untersuchungen und Fixes

Jeder fehlschlagende GitHub-Actions-Run in einem verbundenen Repository wird jetzt zu einem Polylane-Issue. Wiederholte Fehler desselben Workflows falten sich zu einem Issue; ein grüner Run löst es, und ein Fehler innerhalb von 24 Stunden öffnet es wieder. Die Triage liest die fehlgeschlagenen Jobs, Schritte und Check-Annotationen, und wenn sie ein echtes Problem bestätigt, startet sie eine Untersuchung und stellt einen Autofix gegen den fehlschlagenden Branch in die Warteschlange. Der Fix landet als normaler Autofix-Pull-Request.

Folge der Kette vom Check zum Pull Request

Jedes Issue, jede Untersuchung, jeder Autofix und jeder Check kennt jetzt seine Nachbarn. Ein Abstammungsgraph im Overview-Tab des Issues zeichnet die ganze Kette, vom Check, der es ausgelöst hat, über die Untersuchung bis zum Autofix und seinem Pull Request. Ein Klick auf eine Karte öffnet sie in einem Slideover, und doppelte Issues zeigen immer auf die Wurzel, die die Untersuchung hält. Autofix-Seiten beginnen jetzt mit dem Ergebnis: dem Pull Request, warum der Run übersprungen wurde (mit einem Run anyway-Button) oder warum er fehlgeschlagen ist (mit Run again).

Außerdem diese Woche:

• Veröffentliche eine öffentliche Karte deiner Architektur: Führe den Map-Prompt in deinem Coding-Agenten aus, und er veröffentlicht eine bewertete, versionierte Karte, die jeder durchstöbern, befragen oder direkt an Polylane zur Untersuchung übergeben kann
• Review-Kommentare beginnen mit View the full analysis: die vollständige Ausarbeitung, interaktive Charts und komplette Log-Auszüge, lesbar für Pull-Request-Betrachter über einen Gastlink; Autofix-Pull-Requests verlinken ihren ganzen Run auf demselben Weg
• Reviews zeigen ihre Belege: Ein Bestanden hängt die Metrikreihe oder den Log-Auszug an, auf dem es beruht, das Briefing listet vergangene Issues, die dieselben Ressourcen getroffen haben, und der Produktionsauswirkungs-Check ist jetzt für jedes Repository standardmäßig an
• Nach einer Untersuchung fragt Polylane, ob fehlendes Signal sie erschwert hat; wenn ja, ergänzt ein Folge-Pull-Request genau dieses Logging oder Tracing, angeführt von der Untersuchung, die es verkürzt hätte
• Zwei neue Verbindungen: Kubernetes-Cluster über einen nur lesenden In-Cluster-Agenten, sodass keine kubeconfig den Cluster verlässt, und Better Stack, dessen Incidents in die Triage fließen und dessen Monitore der Agent abfragen kann
• Externe Services, die dein Code aufruft (Stripe, Datadog und so weiter), kommen aus Umgebungsvariablen-URLs in den Context Graph unter ihrer eigenen Kategorie External services, und ein Graph mit 3.000 Ressourcen öffnet sich jetzt in Sekunden
• In Threads mit mehreren Personen weiß der Agent, wer was gesagt hat, und jedes Memory, das er speichert, wird täglich neu geprüft und bearbeitet oder verworfen, wenn es veraltet
• Admins können einen Workspace als JSON-Archiv exportieren, und das Löschen eines Workspace stellt ihn zuerst unter Quarantäne, mit einem 60-Tage-Fenster vor der endgültigen Löschung
• Das monatliche Token-Kontingent jedes Plans ist fünfmal größer, kein Plan begrenzt mehr die Workspace-Mitglieder, und eine neue Einstellung Privacy & data lässt Admins den Workspace vom Modelltraining ausnehmen
• Und wie immer: Verbesserungen bei Zuverlässigkeit, Performance und Stabilität

Polylane ist ein Teammitglied in Slack

Erwähne Polylane in Slack, und es reagiert sofort, zeigt, dass es nachdenkt, und streamt seine Antwort, während es schreibt. Lange Züge zeigen Live-Fortschritt, und ein fehlgeschlagener Run sagt, was passiert ist und wie es weitergeht, statt zu verstummen. Polylane erscheint in Slacks Agents-Tab mit vorgeschlagenen Prompts, und in Channels, in denen es Mitglied ist, schaltet es sich ungefragt in Gespräche ein, bei denen es helfen kann, außer du stellst einen Channel auf nur bei Erwähnung. Startet ein Autofix aus einem Slack-Thread, hört dieser Thread den Rest: den Pull-Request-Link, CI-Fehler und ihre Fixes, Review-Antworten und eine Reaktion beim Merge.

Issues, gefangen aus dem, was deine Logs sagen

Polylane liest jetzt, was deine Logs sagen, nicht nur, wie sie sich entwickeln. Ein stetiger Strom von Abstürzen, der nie einen Schwellenwert überschritten oder eine Baseline bewegt hat, wird als Issue angelegt, bleibt offen, solange der Fehler weiter auftaucht, und löst sich von selbst, wenn er aufhört. Jedes neue Issue wird gegen die offenen in deinem ganzen Workspace geprüft: Bestätigte Duplikate werden verknüpft und teilen sich eine Untersuchung, statt eine zweite zu starten. Logzeilen werden nach Form geclustert, sodass ein unbekanntes ID-Format kein neues Issue prägt und kein bestehendes flattern lässt.

Außerdem diese Woche:

• Pull-Request-Reviews liefern jetzt Fixes, nicht nur Urteile: Kleine Observability-Lücken in den Zeilen, die du geändert hast, kommen als Ein-Klick-Vorschlagskommentare, größere als gestapelter Verbesserungs-Pull-Request gegen deinen Branch, und keins von beidem ändert das Bestanden oder Nicht-bestanden
• Reviews und Autofix-Pull-Requests prüfen den vollständigen Katalog der Deploy-Gefahren: Umbenennen-und-Löschen-Änderungen, die alte Pods noch lesen, schreibblockierendes CREATE INDEX auf heißen Tabellen, Umgebungsvariablen, die nichts bereitstellt, und Voraussetzungen im System von jemand anderem, jede mit einem Verantwortlichen gelistet, bis sie bestätigt ist
• Menschen und Teams kommen in den Context Graph: CODEOWNERS, Deploy-Autoren und Owner-Tags werden zu Personen- und Team-Knoten mit owns-Kanten, und verschiedene Schreibweisen einer Person werden zu einem Knoten aufgelöst
• Jedes neu verbundene Repository bekommt einen Observability-Autofix-Pull-Request in den eigenen Konventionen des Repos, und Autofix-Pull-Request-Beschreibungen beginnen jetzt mit einer Zusammenfassung in Klartext
• View Thread auf einem Review-Kommentar öffnet die Untersuchung nur lesend für jeden, der den Pull Request sehen kann, ohne Konto, und du bekommst eine Benachrichtigung, wenn sich ein Urteil ändert
• Der Infrastruktur-Graph ist wieder eine Hierarchie von oben nach unten, gruppiert nach Cloud-Konto, und in der Topologie-Ansicht kannst du eine Ressource gedrückt halten, um ihren Blast Radius entlang ihrer Kanten pulsieren zu sehen, oder eine ziehen, um ihre Nachbarn mitzunehmen
• Die Autofixes-Seite hat Suche und Filter, die in der URL leben, und das Bearbeiten einer Zeile zeichnet die Tabelle nicht mehr neu
• Free-Workspaces bekommen 10 Untersuchungen am Tag, statt 1
• Die CLI bekommt polylane setup, das Polylanes MCP-Server und Skill bei jedem Coding-Agenten auf deinem Rechner registriert (--agent wählt einen aus)
• Und wie immer: Verbesserungen bei Zuverlässigkeit, Performance und Stabilität

Jeder Pull Request, geprüft auf Produktionsauswirkungen

Polylane liest jetzt jeden Pull Request und beantwortet eine Frage: Verschlechtert sich die Produktion, wenn das gemergt wird? Es läuft den Context Graph vom Repository zu den Ressourcen ab, auf die der Code ausgeliefert wird, prüft die Änderung gegen Live-Topologie und -Telemetrie und kommentiert sein Urteil auf dem Pull Request: bestanden oder nicht, mit Belegen und den betroffenen Ressourcen dabei. Ein Check „Polylane production impact“ kann in der Branch Protection zur Pflicht gemacht werden, um einen schlechten Merge zu blockieren.

Autofix-Pull-Requests nehmen Feedback an

Hinterlass einen Review-Kommentar auf einem Autofix-PR, und Polylane antwortet oder pusht die gewünschte Änderung. Antworte im Slack-Thread, in dem der PR angekündigt wurde, und es antwortet genau dort. Schlägt die CI auf einem Autofix-Branch fehl, diagnostiziert Polylane die gescheiterten Checks und pusht einen Fix, ohne gefragt zu werden. Und wenn es Code schreibt, hält es sich an deine Hausregeln: AGENTS.md, CLAUDE.md, Cursor-Regeln und die Commit-Message-Konvention, die es aus deiner Git-Historie ableitet.

Außerdem diese Woche:

• Repositories sind in den Context Graph gekommen: Polylane liest Terraform, CloudFormation, Pulumi, CDK und Deploy-Manifeste (wrangler.jsonc, fly.toml, vercel.json, render.yaml), um jedes Repo mit den Ressourcen zu verknüpfen, die es deployt, mit einem Resources-Tab für manuelle Verknüpfungen
• Du kannst Reviews pro Repository mit eigenen Anweisungen steuern, zum Beispiel „Schema-Migrationen nie markieren“, und wenn ein späterer Push ein markiertes Bedenken ausräumt, markiert Polylane es von selbst als gelöst
• Schlüsselrisiken in Berichten werden untersucht, nicht nur aufgelistet: Klick auf eines, oder untersuche alle, und Urteile streamen live ein, bestätigte Risiken steigen nach oben mit einer Zusammenfassung dessen, was gefunden wurde
• Topologie ist jetzt die Eingangstür der Konsole: jede Ressource ein Punkt, nach Kategorie gefärbt und nach Tier skaliert, mit rot pulsierenden Issue-Hotspots und einem gestrichelten Ring um die am häufigsten geänderten Ressourcen
• PlanetScale ist jetzt ein Provider: Verbinde per OAuth, Datenbanken und Branches synchronisieren in den Context Graph, und Query Insights treiben automatische Checks für Query-Fehler, p99-Latenz, Latenz-Spikes und eingebrochenes Query-Volumen
• Neue Cloud-Konten starten nur lesend: Jeder Schreibzugriff über die Provider-API wird abgelehnt, bis ein Admin den Schalter umlegt, pro Konto
• Der Vercel-Sync ist um neun Ressourcentypen gewachsen (Sandboxes, Workflows, Crons, Feature Flags, AI Gateway, Microfrontends, Access Groups, Drains, Container Registry), und Rollbacks werden richtig verfolgt: Polylane folgt dem Deployment, das die Produktion tatsächlich bedient, nicht dem neuesten
• Der Context Graph ist dichter geworden: Cloudflare-Tunnel verknüpfen sich mit den Zonen und Origin-Services, die sie bedienen, Hyperdrive routet durch Tunnel, und URL-förmige Umgebungsvariablen werden zu Kanten über Clouds und Konten hinweg
• Jedes Repository trägt einen Instrumentierungs-Score von 100 (Routen ohne Logging, nackte console-Aufrufe, fehlende Fehlererfassung), und Ressourcen, die Traffic ohne Logging bedienen oder plötzlich verstummen, werden benannt
• Logs haben ein Gedächtnis bekommen: Jede Ressource führt ein Register ihrer wiederkehrenden Muster mit historischen Raten, und Issues zeigen fehlschlagende Requests mit den genauen Logzeilen, die zu ihnen gehören
• Slack-Antworten sind straffer: eine Antwort pro Zug, richtige Formatierung und @-Erwähnungen, und Stille, wenn eine Nachricht nicht für den Agenten ist
• Und wie immer: Verbesserungen bei Zuverlässigkeit, Performance und Stabilität

Dein Coding-Agent kann jetzt alles sehen, was Polylane sieht. Die Tools, die Polylane für seine eigenen Agenten gebaut hat: der Live-Infrastruktur-Graph über alle deine Clouds, Observability-Queries gegen jeden verbundenen Provider, Codesuche über deine Repos, die ganze REST-API, stehen jetzt Claude Code, Cursor, Codex, OpenCode und VS Code über einen einzigen MCP-Server oder die CLI zur Verfügung. Ein Endpunkt, eine Browser-Anmeldung, und dein Agent beantwortet „Was ist in Produktion für den Service fehlgeschlagen, den dieser PR berührt?“, ohne den Editor zu verlassen. Schreiben sitzt hinter einer Default-Deny-Policy, und der Merge bleibt beim Menschen.

Auffälligkeiten und Alerts sind weg. Nicht die Signale, die Trennung: Alles, was Polylane erkennt, und jeder Alert, den deine Provider weiterleiten, landet jetzt an einem Ort, als Issues. Eine Liste, ein Lebenszyklus und richtige Deduplizierung: Dasselbe Problem, das fünfzigmal feuert, ist ein Issue mit Vorkommenszähler, nicht fünfzig Zeilen. Externe Issues verlinken zurück auf den Alarm in der eigenen Konsole des Providers, und Automationen können jetzt auf Triage-Urteile reagieren.

Das Monitoring ist schlauer geworden, was es beobachtet. Für jedes verbundene Konto erzeugt Polylane jetzt Monitoring-Fragen: die Dinge, die ein On-Call-Engineer laufend beantwortet haben wollte. Es liest deine Repos nach den genauen Fehler-Logs, Spans und eigenen Metriken, die du tatsächlich geschrieben hast, macht aus jeder Frage eine Provider-Query, validiert sie auf echten Daten und führt die behaltenen alle paar Minuten als Checks aus. Verwandte Reihen teilen sich jetzt ein Chart: p95 und p99 zusammen, 5xx pro Service auf einer Achse.

Außerdem diese Woche:

• Die Konsole öffnet jetzt auf Home: Feed-Zusammenfassung, Entscheidungen, die auf dich warten, Issue- und Änderungs-Hotspots und ein Best-Practices-Panel mit offen gelassenen Türen in deiner Architektur
• Factory schließt sich Cursor und Devin als Autofix-Executor an, externe PRs verlinken zurück auf die Untersuchung, die sie erzeugt hat, und ein ohne Merge geschlossener PR ist jetzt ein verfolgtes Ergebnis
• Monitoring ist ein Schalter pro Ressource: Schalte es aus, und Polylane hält weiter Änderungen fest, ohne Issues zu öffnen, und eine Abdeckungskarte zeigt genau, was beobachtet wird und wie oft
• Vercel-Metriken und -Logs: Füg einen persönlichen Zugriffstoken ein (validiert beim Tippen) und wähle, welche Telemetrie gesammelt wird
• AWS zu verbinden lässt dich nicht mehr auf einer leeren Seite stehen: Die Konsole wartet auf deinen CloudFormation-Stack, springt zum Konto, sobald es sich meldet, und sagt klar, wenn es das nie tut
• Ein Workspace-weiter wöchentlicher Digest: Ein Schalter schickt jedem Mitglied eine Zusammenfassung von Incidents, Issues, Autofixes, Änderungen und ungenutzten Ressourcen
• Sentry-Issues kommen mit der tatsächlichen Exception an, bevor die Triage startet: Typ, Meldung, oberste Stack-Frames und Tags
• Ruhigere Triage: Der Schweregrad spiegelt die Auswirkung, die gerade passiert, statt den schlimmsten Fall, und Bot-Fluten gegen wp-login.php und .env öffnen keine Incidents mehr
• Und wie immer: Verbesserungen bei Zuverlässigkeit, Performance und Stabilität

Berichte sind diese Woche erwachsen geworden. Was Polylane in einem Konto findet, war früher ein Wegwerf-Ergebnis, das du vorbeiscrollen sahst; jetzt ist es ein Bericht mit eigener URL. Es gibt eine Berichtsseite mit Filtern und Massenaktionen, Live-Fortschritt, während ein Review läuft, Topologie und Einstiegsfragen, wenn er fertig ist, und einen öffentlichen Teilen-Link, wenn du ihn jemandem außerhalb deines Workspace zeigen willst. Das funktioniert auf Cloud-Konten und auf deinen Datadog-, Honeycomb-, Axiom- und Sentry-Integrationen.

Der Feed hat dieselbe Behandlung bekommen. Er beginnt jetzt mit einer 30-Tage-Zusammenfassung dessen, was Polylane tatsächlich für dich getan hat (gefangene Issues, Änderungen, die Issues verursacht haben, Autofix-PRs, gelöste Auffälligkeiten, jeweils mit Sparkline), einem Gesundheitswert und einer „Wartet auf dich“-Tabelle der Entscheidungen, die einen Menschen brauchen. Und unter der Haube sind Incident-Threads auf dauerhafte Workflows umgezogen, sodass Untersuchungen Deploys und Neustarts überleben, und der eingebaute Autofix-Executor läuft jetzt mit dem Open-Source-Coding-Agenten pi, mit dem vollständigen Transkript lesbar hinter jedem PR.

Außerdem diese Woche:

• Sentry-Alert-Regel- und Issue-Webhooks öffnen jetzt Incidents: von einem Agenten triagiert, sobald sie ankommen, mit Status- und Urteils-Badges und einem Ein-Klick-Untersuchen
• Wiederkehrende Auffälligkeiten behalten die Metriken, Logs und Traces, die bei jedem Vorkommen erfasst wurden, neueste zuerst durchsuchbar, statt nur das letzte
• Auffälligkeitsseiten beginnen mit Sparkline-Metrikkarten mit Wert, Baseline und Abweichung, einer Blast-Radius-Ansicht und einer Log-Zusammenfassung
• Änderungshistorie pro Ressource: Änderungssignale im Detailpanel jedes Knotens, und die am häufigsten geänderten Ressourcen im Feed hervorgehoben
• Advisories werden im Backend berechnet, jedes markiert als vor Ort behebbar oder mit Anleitung
• Thread-Zuverlässigkeit: Veraltete Züge werden automatisch aufgeräumt, Kapazitätsprobleme bei Modellen fallen sauber zurück, und außer Kontrolle geratene Züge werden abgebrochen statt weiterzudrehen
• Und wie immer: Verbesserungen bei Zuverlässigkeit, Performance und Stabilität

Niemand will tausend rohe Logzeilen mitten in eine Untersuchung gekippt bekommen. Diese Woche hat jede Telemetrie-Query, die die Agenten ausführen (CloudWatch, Datadog, Honeycomb, Axiom, Sentry, Cloudflare, Vercel, Fly, Render, X-Ray), einen Zusammenfassungsmodus bekommen: Das vollständige, ungekürzte Ergebnis wird zu Schweregrad, Fehlerzahlen, wiederkehrenden Mustern und der Handvoll Zeilen destilliert, die sich wirklich zu lesen lohnen, wörtlich zitiert. Threads bleiben lesbar, und der Agent ertränkt seinen eigenen Kontext nicht mehr in Logs.

Ein Konto zu verbinden ist auch besser geworden. Direkt nach dem Verbinden bekommst du jetzt einen strukturierten Bericht mit gewichteten Risiken, Schlüsselmetriken sowie Log- und Trace-Digests, mit Einstiegsfragen zum Weitergraben. Und für Cloudflare füllt ein neuer Dialog jede Berechtigung vor, die Polylane braucht, und lässt dich zwischen nur lesend (nur untersuchen und erklären; Änderungen landen immer nur als PRs) und Vollzugriff wählen, sodass niemand mehr API-Token-Berechtigungen von Hand zusammensuchen muss.

Außerdem diese Woche:

• Ressourcen-Tiers stufen sich jeden Tag automatisch neu ein, und du kannst das Tier jeder Ressource jetzt von Hand überschreiben (Überschreibungen sind fixiert) oder die Einstufung für ein ganzes Konto neu laufen lassen
• Jede Auffälligkeit bekommt ein Ein-Klick-Untersuchen, das einen Incident-Thread öffnet, mit Deduplizierung, sodass dieselbe Auffälligkeit nie Duplikate erzeugt
• KI-vorgeschlagene Einstiegsfragen erscheinen jetzt bei Änderungen, Check-Run-Auswertungen und einzelnen Ressourcen, nicht nur nach dem Verbinden
• polylane automation create und POST /automations akzeptieren eigene Trigger, Anweisungen und Tools, sodass du Automationen bauen kannst, die kein Template abdeckt
• Ein Check-Run-Slideover, um Metriken, Logs und Traces einer einzelnen Auswertung zu inspizieren, mit Untersuchen- und Fragen-Aktionen direkt darin
• Das Monitoring pro Ressource sammelt jetzt strukturierte Belege: häufigste und neue Log-Templates, Summen pro Schweregrad, Fehler- und Störungsraten sowie p50/p95/p99 pro Operation
• Ein-Klick-Reparatur für kaputte Mermaid-Diagramme in Ressourcen-Wikis
• Und wie immer: Verbesserungen bei Zuverlässigkeit, Performance und Stabilität

Ein Konto zu verbinden hat endlich einen richtigen Moment. Statt dich auf einem Dashboard abzusetzen, landet Polylane dich jetzt auf einer Seite, die erklärt, was es in dem gerade verbundenen Konto sehen kann, sofort anfängt, Issues zu finden, und drei passende Fragen anbietet, die sich an den Agenten zu stellen lohnen. Die ersten fünf Minuten sind von „Und jetzt?“ zu einem echten Gespräch über deine Infrastruktur geworden.

Das andere Thema dieser Woche ist Vertrauen. Will ein Agent eine verändernde Aktion ausführen, zeigt dir der Thread jetzt Methode, Pfad, Body und Grund und wartet auf deine Freigabe, wobei Löschungen als destruktiv markiert sind. Und jeder Incident erklärt jetzt am Ende jedes Agenten-Zugs, wo er steht (braucht menschliches Handeln, braucht eine Entscheidung, wartet auf eine Änderung, fehlgeschlagen oder gelöst), sodass du auf einen Blick siehst, welche Untersuchungen dich wirklich brauchen.

Außerdem diese Woche:

• Jeder Monitoring-Durchlauf wird als Check-Run aufgezeichnet (gesund, verletzt oder stabil), was jeder Ressource eine Zeitleiste der Auswertungen gibt, die du inspizieren kannst, plus einen manuellen Trigger
• Ressourcen werden automatisch nach operativer Kritikalität in die Tiers 1–4 eingestuft, anhand von Topologie, Traffic und jüngsten Änderungen; Tiers steuern jetzt, wie Auffälligkeiten priorisiert werden
• Der AWS-Sync hat Kinesis, KMS, Secrets Manager und Service Discovery dazubekommen
• Du kannst GitHub-Repositories entdecken und mit einem Cloud-Konto verknüpfen, was den Code an die Infrastruktur bindet, auf der er läuft
• Rate Limiting und Request-Bündelung sind in jedem Provider-Client gelandet, sodass Untersuchungen nicht mehr von Provider-APIs gedrosselt werden
• Change Intelligence ordnet Provider-Änderungsereignisse jetzt den konkreten Ressourcen zu, die sie berührt haben, dargestellt im Feed
• Eine rollierende 24-Stunden-Ansicht der Incident-Nutzung gegen deine Workspace-Limits
• Und wie immer: Verbesserungen bei Zuverlässigkeit, Performance und Stabilität

Autofix hat sich diese Woche geöffnet. Du kannst jetzt Cursor verbinden und Autofix-Pull-Requests durch dessen Cloud-Agenten leiten statt durch den eingebauten: Endet eine Untersuchung bei einer Codezeile, übergibt Polylane den Fix, und Cursor öffnet den PR. Wähle einen Standard-Executor pro Workspace unter Settings → Integrations.

Automationen sind auch leichter zu starten. Es gibt jetzt einen Katalog vorgefertigter Templates, mit Trigger, Agenten-Anweisungen und Aktionen bereits verdrahtet, in einem Schritt installierbar aus der Konsole, der CLI (polylane automation from-template) oder der API. Templates lassen sich nach Kategorie und Provider filtern und aktivieren nur Aktionen für Provider, die du tatsächlich verbunden hast. Dazu geben dir neue Triage-Steuerungen einen Hauptschalter plus Schalter pro Alert-Regel auf jedem Cloud-Konto und jeder Integration, sodass du genau entscheidest, welche Alerts Polylane aufnimmt und untersucht.

Außerdem diese Woche:

• Deutlich breitere Cloudflare-Abdeckung im Graph: Zonen, Load Balancing, WAF- und Security-Rulesets, Tunnel, Spectrum, Access, Stream, Images und mehr Workers-Ressourcen
• Cloudübergreifende Kanten: Ein DNS-Eintrag bei einem Provider, der auf eine Ressource bei einem anderen zeigt, erscheint jetzt als echte Kante im Graph
• Ruhigere Auffälligkeitserkennung: Ein deterministischer Filter verwirft einzelne Spikes und Rauschen nahe der Null-Baseline vor der Triage, die Erkennung beachtet pro Metrik, welche Richtung tatsächlich schlecht ist, und Auffälligkeiten aus Änderungseinträgen werden innerhalb von 24 Stunden dedupliziert, statt erneut zu wecken
• Der Changes-Tab zeigt Auswirkungen auf einen Blick: ein Auswirkungs-Badge, Risiken, Verifikation nach der Änderung und betroffene Ressourcen als Chips
• Eigene LLM-Endpunkte listen jetzt die Modelle, die sie tatsächlich anbieten, sodass du aus echten Modellen wählst statt IDs zu tippen
• OAuth-Client-Secrets lassen sich rotieren, ohne den Client neu anzulegen
• Und wie immer: Verbesserungen bei Zuverlässigkeit, Performance und Stabilität