Autorreparo: o que ele faz

Como os runners do Latchkey detectam e corrigem falhas transitórias de CI durante a execução, o que eles nunca vão tocar e como as propostas de reparo viram pull requests revisáveis.

Todo runner do Latchkey vem com autorreparo integrado, habilitado por padrão. Quando um passo de workflow falha, o runner diagnostica a falha localmente e, quando é uma classe transitória conhecida, a corrige e repete o passo no lugar. Seu build fica verde sem uma reexecução humana, e toda intervenção é registrada para você inspecionar.

A cascata de diagnóstico em três estágios#

O diagnóstico roda do mais rápido primeiro, então os casos comuns custam quase nada:

O que ele detecta, por categoria#

npm ERR! code ETIMEDOUT
npm ERR! network request to https://registry.npmjs.org/react failed
npm ERR! network This is a problem related to network connectivity.

# self-heal: network/registry timeout -> retry with backoff -> passed on retry 2

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

# self-heal: memory/node heap -> set NODE_OPTIONS=--max-old-space-size=4096 -> retried

Error: ENOSPC: no space left on device, write

# self-heal: disk/full -> pruned docker + package caches (14.2 GB freed) -> retried

/usr/bin/bash: line 1: ffmpeg: command not found

# self-heal: tool_missing -> apt-get install ffmpeg (allowlisted) -> retried

npm ERR! `npm ci` can only install packages when your package.json and
package-lock.json are in sync.

# self-heal: config/lockfile drift -> command rewrite: npm ci -> npm install -> retried

A caixa de ferramentas de correção#

Toda correção é aplicada apenas dentro do runner efêmero, e o runner é destruído após o job:

Como um reparo aparece nos seus logs#

A saída do seu passo transmite inalterada, em tempo real. Quando um reparo acontece, as linhas de diagnóstico do runner aparecem ao lado dela, então a intervenção nunca é invisível:

$ npm ci
npm ERR! code ETIMEDOUT
npm ERR! network request to https://registry.npmjs.org/lodash failed
# [latchkey-bash-wrapper] step failed (exit 1), diagnosing...
# [latchkey-bash-wrapper] verdict: network/registry-timeout (stage 2 pattern match)
# [latchkey-bash-wrapper] action: retry with backoff (attempt 1 of 3, waiting 5s)
$ npm ci
added 1291 packages in 42s
# [latchkey-bash-wrapper] heal successful, continuing job

Pull requests de reparo#

Algumas causas raiz merecem uma correção duradoura no seu repositório, não apenas um resgate na execução: um passo de setup ausente do workflow, um pin engines ausente em package.json, um timeout de job baixo demais. Quando um reparo bem-sucedido remonta a uma causa estrutural como essas, o autorreparo produz uma proposta estruturada e abre um PR de reparo com uma edição tipada e determinística.

• Cada PR é intitulado "Latchkey heal: <error summary>"; o corpo explica o Error, a Root cause e o Fix, e liga de volta à execução do workflow, então a revisão leva minutos.
• PRs de reparo nunca sofrem auto-merge, e pull requests de forks nunca são tocados.
• A criação de PR usa as permissões do GitHub App; se você nunca fizer merge de um PR de reparo, nada no seu repositório muda.

O que ele fará e nunca fará#

Passe a bola para seu agente de código#

O autorreparo conserta o ambiente, nunca seu código-fonte. Quando o problema real é um bug no seu próprio código, o build falha de forma verdadeira, e a falha chega como um pacote completo e estruturado servido pelo servidor MCP do Latchkey, pronto para o seu próprio agente de código consertar a partir dele. O pacote entrega ao seu agente o que ele, de outra forma, reconstruiria à mão:

• A causa raiz, em linguagem simples.
• O código de saída do passo que falhou e o arquivo-fonte exato onde o erro surgiu.
• Os logs completos e não truncados do passo que falhou, incluindo saída que o GitHub esconde no seu visualizador de logs, com segredos removidos antes de saírem do Latchkey.
• O que o autorreparo já investigou e por que recuou, mais a definição do workflow.

No Claude Code, o comando embutido /mcp__latchkey__fix faz toda a ida e volta em um passo: ele pega a falha não corrigida mais recente e mãos à obra. Qualquer agente com capacidade MCP (Cursor, Codex e outros) pode ler os mesmos pacotes através das ferramentas do servidor. Setup, chaves de API e o comando de conexão pronto estão em Conecte seu agente de IA.

Observabilidade: todo reparo fica registrado#

• Recent Heals (na página de Runners) lista toda intervenção com sua categoria, veredito e uma descrição em linguagem simples da ação tomada; reparos diagnosticados por IA incluem as iterações de raciocínio do agente.
• Execuções reparadas são sinalizadas na tabela de execuções do Desempenho de pipeline e têm link direto para seu relatório de reparo.
• KPIs e tendências de reparo na página de Runners mostram com que frequência o reparo salva uma execução e quais categorias dominam, o que é em si um sinal sobre sua infraestrutura.

Controles#

• Modo em nível de workspace em Settings, Self-Healing (owners e admins); as mudanças entram em vigor em cerca de um minuto.
• Alternador por configuração na página de Runners, para excluir um tipo de runner específico.
• Não há alternador por repositório hoje; o modo do workspace se aplica a todos os repositórios monitorados.

Perguntas comuns#

Para ver quais falhas do mundo real o reparo cobre, navegue pela biblioteca de padrões de autorreparo no Learn - cada entrada mostra a correção manual ao lado do que o runner faz automaticamente. Para qualquer coisa que esteja falhando seus builds atualmente, comece pela biblioteca completa de erros de CI/CD.