O ticket vira uma pull request. O Polylane faz a escavação no meio do caminho.
Entrar na lista de esperaEle confere primeiro o que mudou. Metade dos tickets leva a uma mudança que alguém fez.
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 Teorias são testadas, não confiadas. Confirmadas só com evidência dos seus sistemas reais.
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
A correção chega pronta para revisar. Causa raiz, validação e o diff incluídos.
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.
Como o Polylane funciona. Ele aprende seu sistema, observa, investiga e age.
-
Ele aprende seu sistema primeiro
O grafo de contexto mapeia cada recurso e dependência entre suas nuvens, repositórios e provedores de observabilidade. Os agentes raciocinam sobre a topologia real, não sobre palpites.
-
Detecção sem limiares
Verificações integradas para cada provedor, mais verificações geradas a partir das suas próprias queries salvas e dashboards. Uma passagem estatística e um agente decidem juntos, e uma melhoria nunca abre uma issue.
-
Investigações que mostram evidências
Cada afirmação aponta de volta para a query, a linha de log ou o registro de mudança por trás dela. Um veredito sem evidência recua para inconclusivo.
-
Escritas se conquistam, nunca se presumem
As contas se conectam em modo somente leitura. Rollbacks ficam desativados por padrão, com limite de taxa e registrados. Mudanças de código passam pela sua revisão normal.
-
Ele fica mais afiado a cada semana
Memórias, notas diárias e queries de monitoramento reconfirmadas contra dados reais: a investigação de julho aprende com a de junho.
Ele se conecta ao que você já roda. Conecte em modo somente leitura e comece.
Perguntas.
Como entrego um ticket ao Polylane?
Inicie uma thread no console, pela CLI ou do seu editor pelo servidor MCP, e descreva o bug. Os agentes assumem dali com o contexto completo do workspace: o grafo, a telemetria, os registros de mudança e o código.
E se ele não encontrar a causa?
Ele diz isso. As investigações terminam resolvidas, diagnosticadas ou inconclusivas: uma investigação que não conseguiu chegar aos dados nunca confirma, e tudo o que precisa de uma decisão humana vira um único escalonamento, não um loop insistente.
Ele aprende com tickets anteriores?
Sim. Achados confirmados são armazenados como memórias e recuperados por significado em threads posteriores, e notas diárias mantêm um registro contínuo do que aconteceu. A investigação de julho aprende com a de junho.
Quem escreve a correção?
O autofix do Polylane por padrão: investigada primeiro, escrita e validada, com o raciocínio anexado. Ou entregue a implementação ao Devin, ao Cursor ou à Factory. De qualquer forma, você revisa.
Com quais repositórios ele funciona?
Repositórios do GitHub, conectados pelo app do GitHub. A correção chega em uma branch no repositório por trás do serviço afetado, com a investigação ligada a partir da mudança.