openclaw-landable-bug-sweep

Varredura de Correções de Bugs do OpenClaw Prontas para Integração

Fluxo de trabalho autônomo de mantenedor para produzir um lote solicitado de URLs de PRs de correção de bugs do OpenClaw prontos para integração. Use para varreduras amplas de issues/PRs onde o padrão é alto e a saída são PRs, não anotações. NÃO use para trabalho nos limites do SDK/API de plugins; isso requer uma revisão de arquitetura separada.

Alvo

Use batch_size da solicitação, com valor padrão 5 e máximo 20. Retorne até esse número de URLs de PRs qualificados, cada um com:

• resumo do bug
• por que a correção é de baixo risco
• prova: comandos locais/Testbox/ao vivo no head rebasado ou IDs de execução
• autorevisão: resultado limpo exatamente no head que está sendo mostrado
• CI verde exatamente no head do PR enviado
• limpeza de issue/duplicata feita ou ainda pendente

As URLs podem ser PRs existentes que foram revisados/corrigidos, ou novos PRs criados a partir de issues/clusters. NÃO apresente uma URL de PR ao mantenedor até que ele tenha sido atualizado no main atual, testado à esquerda, autorevisado e considerado limpo, enviado e verificado verde no CI ao vivo do GitHub. Se código, testes, changelog, corpo do PR ou branch base mudar após a autorevisão, reexecute a autorevisão antes de mostrar a URL. NÃO complete um lote quando a busca limitada resultar em menos PRs qualificados.

Entradas

• batch_size: número solicitado de PRs prontos para integração; padrão 5, máximo 20.
• source_mode: discovery ou provided-prs; padrão discovery.
• provided_prs: referências explícitas a PRs quando source_mode=provided-prs.

No modo provided-prs, inspecione apenas os PRs fornecidos mais referências duplicadas/canônicas diretamente vinculadas, a menos que uma descoberta mais ampla seja necessária para provar a melhor correção.

Skills Complementares

Use $gitcrawl para descoberta/agrupamento, $openclaw-pr-maintainer para regras de mutação ao vivo no GitHub, $github-author-context quando a confiança do contribuidor for relevante, $openclaw-testing para escolha de prova, $autoreview antes de publicar/integrar e $crabbox para provas amplas/E2E/ao vivo.

Critério do Candidato

Aceite apenas quando TODOS os itens a seguir forem verdadeiros:

• bug ou pequeno incômodo, não funcionalidade, produto, suporte ou apenas documentação
• causa raiz comprovada no código atual
• comportamento de dependência verificado por meio de documentação/fonte/tipos upstream quando relevante
• diff de produção/tempo de execução pequeno, idealmente muito menor que 500 LOC e sempre abaixo de 500 LOC
• testes podem ser maiores, mas focados
• nenhuma nova dependência
• nenhuma nova opção de configuração
• nenhum comportamento de quebra de compatibilidade
• nenhuma decisão de segurança/produto/limite de propriedade necessária
• nenhuma alteração no SDK de plugins, API pública de plugins ou limite src/plugin-sdk/**
• nenhum indício de refatoração ampla
• prova focada é viável
• o branch pode ser rebasado/atualizado e enviado, ou um PR substituto pode ser criado

Bons exemplos:

• incompatibilidade de parâmetro de provedor comprovada contra contrato de dependência/API
• comando CLI que diverge do comportamento de comandos adjacentes
• bug estreito de estado/serialização em tempo de execução com teste com falha
• issue já corrigida no main atual, com prova e duplicatas fecháveis

Rejeite:

• solicitações de funcionalidades, novos controles, migrações, trabalho de release, política de fluxo de trabalho, suporte
• alterações nos limites do SDK/API de plugins, incluindo shims de compatibilidade, novos métodos do SDK, exportações do SDK ou seams de canal/provedor voltados para plugins
• alterações nos limites de autenticação/segurança, a menos que explicitamente atribuídas
• bugs que precisam de credenciais ao vivo indisponíveis
• PRs com CI vermelho, a menos que você corrija, rebaseie, envie e os verifique verdes novamente
• PRs que você revisou apenas localmente, mas não atualizou/enviou/verificou ao vivo
• PRs cujo head final não passou por $autoreview
• correções cuja forma limpa é um movimento arquitetural maior
• relatos especulativos sem causa reproduzível/comprovável
• alterações de UI/UX que exigem julgamento de produto

Ciclo de Varredura

1. Começar limpo:
   • git status -sb
   • git pull --ff-only
   • verificar se o branch é o esperado, geralmente main
2. Construir clusters candidatos:
   • gitcrawl para issues/PRs abertos, vizinhos e pesquisa
   • gh issue/pr view ao vivo
   • incluir PRs vinculados de issues e duplicatas
3. Para cada cluster:
   • ler corpo da issue/PR, comentários, labels, referências vinculadas, código-fonte atual, testes adjacentes
   • excluir PRs de mantenedores com amplo acesso até que created_at tenha pelo menos 14 dias; apenas um PR nomeado ou solicitação explícita de trabalho de mantenedor substitui
   • identificar autor/abridor e preservar crédito
   • decidir: repair-existing-pr, create-new-pr, close-fixed-on-main, close-duplicate ou reject
4. Provar antes de corrigir:
   • teste com falha, reprodução focada, prova de log/fonte ou prova de contrato de dependência
   • se já corrigido no main, provar com fonte/teste/commit atuais e fechar gentilmente
5. Corrigir:
   • preferir PR existente quando for bom e gravável
   • se não for gravável ou tiver formato errado, criar próprio PR e preservar crédito útil do contribuidor
   • se não houver PR, criar um
   • adicionar teste de regressão quando couber
   • contexto de release-note para correções voltadas ao usuário no corpo do PR ou mensagem de commit; creditar relator/contribuidor humano quando conhecido
6. Revisar, atualizar e publicar:
   • rebasar ou atualizar o branch do PR no origin/main atual
   • resolver divergências, incluindo falhas de CI recém-expostas, em vez de considerar o PR como pronto
   • NÃO adicionar CHANGELOG.md durante PRs de varredura normal; a automação de release o gera a partir de PRs e commits
   • testar à esquerda o head rebasado com o menor comando local/Testbox/ao vivo significativo que prove o bug
   • executar $autoreview até que não haja mais achados aceitos/acrionáveis antes de criar, atualizar ou apresentar a URL do PR
   • criar/atualizar PR com corpo real e campos de prova
   • enviar o head exato revisado
   • verificar se o CI ao vivo do GitHub está verde para aquele head enviado; NÃO contar PRs pendentes, vermelhos, sujos, conflitantes ou bloqueados externamente no lote
7. Higiene:
   • fechar issues/PRs duplicados e corrigidos no main com prova assim que notá-los durante a varredura
   • nunca alterar mais de cinco itens associados em um cluster sem confirmação explícita
   • comentários devem ser gentis, concretos e incluir links para prova/PR/commit
8. Repetir até que batch_size URLs de PRs prontos para integração estejam prontos ou a fila qualificada limitada esteja esgotada.

Prova no Corpo do PR

Use o template de PR do repositório. Inclua seções autorais ## What Problem This Solves (## Que Problema Isso Resolve) e ## Evidence (## Evidências). Mantenha o corpo focado na intenção e na evidência de validação mais útil; inspecione o código, os testes e o CI antes de julgar a correção.

Regras para PRs Existentes

• Revise o caminho do código além do diff antes de confiar nele.
• Se o PR for bom: rebaseie/atualize no main atual, corrija pequenos problemas, teste à esquerda, autorevisão limpa, envie e obtenha CI verde antes de mostrar ou contar.
• Se o PR não for bom, mas tiver uma ideia útil: recrie localmente, co-autor quando justificado, feche o original com agradecimentos e explicação.
• Se o PR for duplicado ou corrigido no main: comente com prova, feche.
• Se o mantenedor não puder enviar para o branch do contribuidor: crie seu próprio branch/PR, preserve commits ou crédito úteis.
• Se o CI ficar vermelho após a prova local, trate como trabalho normal: inspecione o job com falha, corrija ou rejeite, reexecute e só conte o PR quando estiver verde.

Registro de Saída

Mantenha um registro contínuo:

aceitos:
- URL do PR:
  refs de origem:
  bug:
  causa raiz:
  correção:
  risco:
  rebase/head:
  teste à esquerda:
  autorevisão:
  CI:
  crédito/agradecimentos:
  limpeza:

rejeitados:
- ref:
  motivo:

fechados:
- ref:
  motivo:
  prova/comentário:

Resposta final:

• o número solicitado de URLs de PRs aceitos, ou a contagem menor de qualificados com o motivo da busca esgotada
• explicador de 2 a 4 frases por PR
• estado da prova/CI por PR
• refs de duplicatas fechadas/corrigidas no main
• branch/status atual