Execução autônoma
Este é o modo para "aqui está o plano, vá": implemente-o de ponta a ponta sem ninguém no teclado, e seja revisável quando o humano voltar. Não está vinculado a um horário do dia. Aplica-se a qualquer período em que ninguém esteja olhando para responder a uma pergunta.
Pressupõe um plano aprovado
Este modo não dispensa o "propor antes de construir" (veja coding-process). É
o que acontece após a aprovação. Dentro do plano aprovado, decida
detalhes de implementação reversíveis você mesmo e registre cada suposição. Uma
suposição documentada supera uma sessão que passou a noite esperando. Isso é
tudo o que a dispensa faz.
Quatro pontos de verificação que você nunca passa sozinho
Estes permanecem pontos de verificação mesmo quando a etapa é reversível. Nenhum deles é uma questão de julgamento.
- Escopo. Qualquer coisa que o plano aprovado já não cubra: uma nova funcionalidade, uma refatoração que ninguém pediu, ou pular uma etapa porque ela se tornou difícil. Configurar uma estrutura de teste ausente conta como escopo.
- Qualquer coisa que saia da máquina: mensagens externas, publicações, ou chamadas a um serviço de terceiros. Trabalho no repositório (branches, commits, pushes, PRs) está dentro do plano; conversar com o mundo exterior não está.
- Qualquer coisa que gaste dinheiro: APIs pagas, infraestrutura provisionada, qualquer coisa medida.
- Qualquer coisa destrutiva ou irreversível: perda de dados, force-pushes para branches compartilhados, produção.
Mantenha o trabalho durável
- Isole primeiro. Use uma worktree, a menos que a estrutura já tenha lhe dado uma. Uma execução autônoma é exatamente quando outra pessoa pode tocar no checkout principal.
- Faça commit e push após cada unidade lógica, não apenas no final. Trabalho não enviado é perdido se a sessão terminar abruptamente. Neste modo, isso substitui o usual "perguntar antes de commitar".
- Nunca entre em uma pausa com trabalho não commitado. Se seu agente expõe limites de uso, pause perto do limite, aguarde a reinicialização e depois retome.
- Execute as validações completas nos pontos de verificação, não após cada edição. Durante a edição, execute a verificação mais estreita que capturaria o que você acabou de alterar: a verificação de tipo de um pacote, ou um arquivo de teste. Execute o build, o lint, a suíte de testes completa e a validação equivalente ao CI assim que uma unidade de trabalho estiver concluída e antes de enviá-la para revisão. Reexecutar uma suíte que passou há dez minutos, em código que você não tocou, gasta computação para aprender nada.
Delegação (se seu agente puder gerar subagentes)
- Delegate trabalho mecânico para modelos mais baratos: clonar uma estrutura existente, código boilerplate, sincronizar documentação, edições repetitivas. Mantenha o modelo principal para lógica crítica de correção (esquema, limites de segurança, serviços principais) e para decisões de julgamento.
- Limite a concorrência a cerca de cinco. Acima disso, a auditoria deixa de ser real e agentes paralelos colidem nos mesmos arquivos.
- Audite tudo que for delegado. Nunca integre a saída de um subagente não lida. Verifique se faz sentido, segue as convenções e se build e testes estão verdes. Quando estiver errado, avalie a lacuna: corrija uma pequena você mesmo e envie uma grande de volta com a correção.
Bloqueadores
- Traga-os à tona; não adivinhe. Quando uma etapa do plano tem um ponto de verificação explícito, ou encontra um bloqueador genuíno (infraestrutura faltante, uma suposição falha), sinalize-o claramente em vez de inventar uma solução alternativa que mude o design.
- Faça primeiro tudo que não depende da resposta, para que o humano retorne a uma pergunta mais trabalho concluído, não apenas a uma pergunta.
- Uma revisão de PR parada também é um bloqueador. Sinalize-a e continue construindo as etapas acima dela localmente, onde não dependem da resposta.
A verificação de UI não é opcional quando ninguém está olhando
Conduzir a interface do usuário em um navegador é a etapa mais fácil de pular
quando ninguém está olhando, e aquela cuja ausência um revisor não vê no diff.
Siga verify-ui. Se o ambiente realmente não puder executar a funcionalidade
(credenciais ausentes, infraestrutura que você não possui), diga isso na seção
"Testes" do PR: nomeie o que bloqueou e o que foi verificado em seu lugar.
Silêncio é lido como "verificado".
Quando você terminar
Relate o estado do trabalho: o que foi entregue (PRs e branches), o que está
aguardando revisão, cada suposição feita e cada bloqueador sinalizado. Escreva
em uma passagem de mão em docs/plans/ se a sessão estiver terminando.