Codex AutoLoop - Ciclo Autônomo para Desenvolvimento

Codex AutoLoop

Transforme tarefas de desenvolvimento longas em um fluxo de trabalho retomável, auditável, com barreiras de segurança e que para quando deve.

Quando usar

Ative este skill para solicitações como:

• "Desenvolvimento contínuo / loop automático / rodar em segundo plano"
• "Não pare, me avise quando terminar"
• "Vou dormir, você continua"
• "Avance seguindo a lista de tarefas do CSV"
• "Siga o plan.md até o fim"
• "Deixe o Codex / Claude Code iterar sozinho por um longo período"
• "Modo burro de carga"

Se a tarefa for muito pequena e puder ser concluída em minutos, não force o AutoLoop. Apenas faça diretamente.

Princípios centrais

O loop principal é simples:

1. Leia o contexto atual
2. Escolha uma pequena tarefa com limites claros / uma única hipótese
3. Faça uma alteração atômica e explicável
4. Verifique o resultado mecanicamente
5. Se passar: mantenha a alteração; se falhar: reverta
6. Registre o estado e o resultado
7. Continue até que uma condição de parada seja acionada

Use o git e o arquivo de estado como memória, e a verificação como barreira de segurança. Não trate a verificação como "a verdade absoluta".

Dois modos de trabalho

Modo A: Loop de objetivo único

Ideal para tarefas com um objetivo claro e métricas definidas, por exemplo:

• Reduzir o uso de any em um diretório específico
• Fazer todos os testes de um conjunto ficarem verdes
• Otimizar um benchmark continuamente
• Aumentar a cobertura de uma funcionalidade

Modo B: Execução orientada por CSV / plano

Ideal para uma sequência de tarefas de backlog que já possuem:

• Prioridades
• Dependências
• Critérios de aceitação
• Comandos de verificação (verify)
• Escopo de modificação

Quando necessário, leia:

• references/csv-template.md: como escrever a tabela de tarefas
• references/plan-template.md: como escrever o plano como um contrato executável por máquina

Verificações antes de iniciar

Não inicie um loop longo sem atender a todas estas condições:

• O repositório já está no git
• O comando de verificação (verify) de linha de base já foi executado manualmente com sucesso
• Os caminhos permitidos para modificação estão claros
• Os caminhos que nunca devem ser tocados estão claros
• Os arquivos de estado / resultados não serão enviados acidentalmente para o repositório
• O usuário explicitamente solicitou "execução autônoma / em segundo plano / de longa duração"

Condições de parada

Continue por padrão, mas pare imediatamente e relate quando:

1. Falha no gateway: o gateway completo ou o gateway de revisão falhou
2. Ambiguidade de requisitos: existem múltiplas opções de produto razoáveis, mas o plano/tarefa não especifica a regra de decisão
3. Ação perigosa: exclusão de banco de dados, migração, manipulação de credenciais, efeitos colaterais em produção, operações de escrita externas
4. Desvio de verificação: a verificação não representa mais realisticamente a "conclusão da tarefa"
5. Falhas consecutivas: após várias rodadas de descarte/crash, nenhuma nova hipótese surgiu
6. Modificação fora do escopo: a alteração necessária excede o escopo definido
7. Ponto de verificação humano: o usuário solicitou explicitamente que você mostre o resultado antes de continuar

Não acredite no "nunca interrompa". O princípio correto é:

Avance autonomamente por padrão, mas escale imediatamente em caso de risco, ambiguidade ou violação de escopo.

Protocolo de execução de cada rodada

A cada rodada, faça:

1. Releia os arquivos relevantes no escopo, os resultados recentes e o histórico recente do git
2. Selecione apenas uma tarefa ou uma hipótese atômica
3. Faça a menor alteração verificável
4. Execute o comando de verificação correspondente à tarefa
5. Se passar: mantenha a alteração e registre o resultado
6. Se falhar: reverta limpo e registre a causa da falha
7. Verifique se alguma condição de parada foi acionada
8. Avance para a próxima rodada

Tarefas que exigem muita experimentação e tentativa e erro devem ser feitas preferencialmente em branches temporárias / áreas de trabalho independentes, não transforme o branch principal em um depósito de experimentos.

Requisitos de design para scripts de verificação (verify)

Um bom comando de verificação deve atender a:

• Mecânico: depender o mínimo possível de julgamento subjetivo
• Rápido: adequado para execução repetida
• Difícil de trapacear: não deve ser fácil enganar com "métricas infladas"
• Próximo da aceitação: o mais próximo possível do padrão real de conclusão
• Executável sem supervisão: seguro rodar de forma autônoma

Quando precisar projetar ou corrigir um script de verificação, leia:

• references/verify-scripts.md

Princípios de git / reversão

Git é memória, não um fusível universal de segurança.

Prefira as seguintes abordagens em vez de reescrever o histórico de forma agressiva:

• Branch temporário (scratch branch)
• Worktree
• Sequências de commits reversíveis
• Reversão com escopo (scoped revert)

Não paralelize tarefas apenas porque seus glob parecem não se sobrepor. Quando compartilham tipos, configurações, processos de build ou snapshots de teste, elas podem interferir entre si.

Dicas práticas para OpenClaw / Codex

Em ambientes que suportam sessões / subagentes / harness ACP:

• Tarefas pequenas: faça diretamente na sessão atual
• Tarefas longas: envie para uma sessão isolada e deixe executar
• Quando houver solicitação explícita para usar o estilo Codex / Claude Code / Gemini: use o harness / thread persistente correspondente
• Não faça polling frequente de progresso; confie nos checkpoints e na notificação de conclusão
• Prefira recuperar o estado salvo a replanejar após cada interrupção

Quando necessário, leia:

• references/openclaw-execution.md: postura recomendada para OpenClaw / sessão gerenciada
• references/python-launcher.md: referência para um launcher DIY local

Ordem de leitura recomendada

Quer apenas começar a usar

1. Este arquivo
2. references/openclaw-execution.md
3. references/verify-scripts.md

Quer avançar em lote usando uma lista de tarefas

1. Este arquivo
2. references/csv-template.md
3. references/plan-template.md
4. references/openclaw-execution.md

Quer modificar o launcher

1. Este arquivo
2. references/python-launcher.md
3. references/verify-scripts.md

Lembre-se

O objetivo não é "rodar para sempre".

O objetivo é:

• Exigir o mínimo possível de supervisão (babysitting)
• Processo rastreável
• Capacidade de recuperação em caso de problemas
• Parar quando necessário
• Resultado final realmente entregável

Autônomo por padrão. Interruptível por design.