Entrega em Ciclo Fechado

Visão Geral

Trate cada tarefa como incompleta até que os critérios de aceitação sejam verificados em evidências, não apenas até que o código seja alterado.

Regra principal: entregue de acordo com o DoD (Definição de Pronto), não de acordo com o tamanho da diferença de código.

Quando Usar

Use esta habilidade quando:

• o usuário fornecer uma tarefa de codificação/correção e esperar a conclusão de ponta a ponta
• a tarefa abranger código + testes + comentários de PR + deploy de desenvolvimento + verificações em tempo de execução
• prompts manuais repetidos como "agora teste", "agora implante", "agora verifique novamente o PR" devem ser evitados

Não use esta habilidade para:

• perguntas e respostas/explicações puras
• solicitações de deploy em produção sem aprovação humana explícita
• tarefas bloqueadas por segredos ausentes/acesso à conta que não podem ser inferidos

Entradas Necessárias

Antes da execução, defina isto uma vez:

• objetivo da tarefa
• critérios de aceitação (DoD)
• ambiente de destino (dev por padrão)
• cadência/orçamento de revisão quando solicitado; uma cadência de revisão padrão não é um limite de conclusão de tarefa

Se os critérios de aceitação estiverem ausentes, solicite-os uma vez. Se o usuário não fornecer, proponha um padrão concreto e prossiga.

Dependência de Gate de Issue

Se o projeto já usa create-issue-gate, respeite seu contrato atual; caso contrário, derive os critérios de aceitação da tarefa autorizada sem inventar uma issue obrigatória.

• Se o status da issue for ready e o gate de execução for allowed, continue.
• Um gate de rascunho real exigido pelo projeto pode bloquear ações dependentes; ele não proíbe descobertas independentes ou trabalho já autorizado sob um fluxo de trabalho aplicável diferente.
• Use o contexto de tarefa disponível para formular critérios testáveis; esclareça apenas quando uma decisão ausente alterar materialmente o resultado.

Fluxo de Trabalho Padrão

1. Definir DoD

   • Converta a solicitação em critérios testáveis.
   • Exemplo: DoD da tarefa de checkout = "endpoint de checkout retorna um URL de pagamento de terceiros válido e abridor em dev".

2. Implementar mudança mínima

   • Mantenha o escopo restrito ao objetivo da tarefa.

3. Verificar localmente

   • Execute testes focados primeiro, depois verificações mais amplas, se necessário.

4. Loop de revisão

   • Busque comentários/revisões de PR.
   • Classifique como válidos vs. não acionáveis.
   • Corrija itens válidos, reexecute a verificação.

5. Deploy de desenvolvimento + verificação em tempo de execução

   • Implante apenas em um destino de desenvolvimento já autorizado quando o comportamento em tempo de execução for importante; caso contrário, prepare e verifique o candidato concreto localmente.
   • Verifique por meio de evidências reais de API/Lambda/log contra o DoD.

6. Decisão de conclusão

   • Relate "pronto" apenas quando todas as verificações do DoD forem aprovadas.
   • Caso contrário, continue o loop até a aprovação ou condição de parada.

Política de Sondagem de Comentários de PR

Evite sondagens curtas e barulhentas por padrão. Use janelas em lote:

• Rodada 1: espere 3m, colete comentários/revisões delta
• Rodada 2: espere 6m, colete delta novamente
• Rodada final: espere 10m, colete todos os comentários/revisões visíveis restantes

Em cada rodada:

• processe todos os novos comentários em um lote
• evite repolling imediato após cada comentário único
• após a rodada 10m, pare de esperar e prossiga com todos os comentários visíveis naquele momento

Se o CI ainda estiver em execução, alinhe a sondagem para verificar os limites de conclusão em vez de sondagens rápidas fixas.

Regras de Gate Humano (Deve Perguntar)

Exija autorização consequente ausente para o seguinte; não a solicite novamente quando o usuário já concedeu o escopo exato:

• deploy em produção/staging além do escopo acordado
• operações destrutivas (reescrita de histórico, push forçado, operações destrutivas de dados)
• ações com alterações de faturamento/postura de segurança
• valores secretos não disponíveis no repositório/tempo de execução
• DoD ambíguo que altera materialmente o resultado

Condições de Iteração/Parada

Pare e escale com um relatório conciso de bloqueio quando:

• O mesmo bloqueador externo verificado não deixar nenhum próximo passo autorizado significativo; duas iterações falhas sozinhas não são motivo para parar quando resta trabalho de reparo útil
• dependência externa bloqueia o progresso (interrupção do provedor, credenciais ausentes, permissão de conta)
• instruções de revisão conflitantes não podem ser ambas satisfeitas

O relatório de escalonamento deve incluir:

• o que passou
• o que falhou
• evidências (comandos/logs/resultado da API)
• a menor decisão necessária do usuário

Contrato de Saída

Ao reivindicar a conclusão, sempre inclua:

• checklist de critérios de aceitação com aprovação/falha
• comandos/testes executados
• evidências em tempo de execução (endpoint/Lambda/linhas chave de log)
• status do PR (contagem de novos comentários acionáveis)

Não reivindique sucesso sem evidências.

Exemplo

Solicitação do usuário:

Pegue este bug desde a reprodução até a prova da causa raiz, implementação, testes, revisão e validação final.

Limitações

…