Orchestrador de Aceitação

Visão Geral

Orquestra o trabalho de codificação como uma máquina de estados que só termina quando os critérios de aceitação são verificados com evidências ou a tarefa é explicitamente escalada.

Regra principal: não otimize para "código alterado"; otimize para "DoD comprovado".

Quando Usar

• A tarefa já possui um problema ou critérios de aceitação claros e deve ser executada de ponta a ponta com mínima reintervenção humana.
• Você precisa de um repasse estruturado entre implementação, revisão, implantação e verificação final.
• Você deseja condições de parada explícitas e escalonamento em vez de conclusão parcial silenciosa.

Sub-habilidades Necessárias

• create-issue-gate
• closed-loop-delivery
• verification-before-completion

Monitoramento de implantação e PR são capacidades específicas do projeto, não sub-habilidades agrupadas. Use os procedimentos reais de implantação e revisão do repositório; os nomes legados deploy-dev, pr-watch, pr-review-autopilot e git-ship não estão disponíveis no AAS.

Entradas

Requer estas entradas:

• id do problema ou corpo do problema
• status do problema
• critérios de aceitação (DoD)
• ambiente de destino (dev padrão)

Padrões fixos:

• rodadas máximas de iteração = 2
• polling de revisão de PR = 3m -> 6m -> 10m

Máquina de Estados

• intake
• issue-gated
• executing
• review-loop
• deploy-verify
• accepted
• escalated

Fluxo de Trabalho

1. Entrada

   • Ler o problema e extrair o objetivo da tarefa + DoD.

2. Portão do Problema

   • Usar lógica create-issue-gate.
   • Se o problema não estiver ready ou o portão de execução não estiver allowed, parar imediatamente.
   • Não implementar nada enquanto o problema permanecer draft.

3. Executar

   • Repassar para closed-loop-delivery para implementação e verificação local.

4. Loop de Revisão

   • Se o feedback do PR for relevante, agrupar janelas de polling como:
     • esperar 3m
     • então 6m
     • então 10m
   • Após a rodada 10m, parar de esperar e processar todos os comentários visíveis juntos.

5. Implantação e Verificação em Tempo de Execução

   • Se o DoD depender do comportamento em tempo de execução, verificar o ambiente explicitamente autorizado.
   • Um rótulo dev não concede permissão de implantação; inspecionar efeitos e usar o portão de implantação do projeto antes de alterar qualquer ambiente compartilhado.
   • Verificar com logs reais/API/comportamento do Lambda, não com suposições.

6. Portão de Conclusão

   • Antes de qualquer alegação de conclusão, exigir verification-before-completion.
   • Nenhuma alegação de sucesso sem evidências recentes.

Condições de Parada

Mover para accepted somente quando cada critério de aceitação tiver evidências correspondentes.

Mover para escalated quando qualquer um destes ocorrer:

• DoD ainda falha após 2 rodadas completas
• segredos/permissões/dependências externas ausentes bloqueiam o progresso
• a tarefa necessita de ação de produção ou aprovação de operação destrutiva
• instruções de revisão entram em conflito e não podem ser satisfeitas ambas

Portões Humanos

Sempre parar para confirmação humana em:

• implantações em produção/staging além do escopo acordado
• operações destrutivas de git/dados
• alterações de faturamento ou postura de segurança
• critérios de aceitação fornecidos pelo usuário ausentes

Contrato de Saída

Ao relatar o status, sempre incluir:

• Status: entrada / executando / aceito / escalado
• Acceptance Criteria: lista de verificação de aprovação/reprovação
• Evidence: comandos, logs, resultados de API ou prova em tempo de execução
• Open Risks: qualquer coisa ainda incerta
• Need Human Input: menor decisão seguinte, se bloqueado

Não relatar "concluído" a menos que o status seja accepted.

Exemplo

Solicitação do usuário:

Pegue este problema e seus critérios de aceitação através da implementação, validação, revisão e um veredito final baseado em evidências.

Limitações

• Use esta habilidade apenas quando a tarefa corresponder claramente ao escopo descrito acima.
• Não trate a saída como um substituto para validação, teste ou revisão de especialista específica do ambiente.
• Pare e peça esclarecimentos se as entradas necessárias, permissões, limites de segurança ou critérios de sucesso estiverem ausentes.