SamuelChien/mega-skills-collection

Acceptance Orchestrator

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 central: não otimize para "código alterado"; otimize para "DoD comprovado".

Quando Usar

• A tarefa já possui uma issue ou critérios de aceitação claros e deve ser executada de ponta a ponta com mínima reintervenção humana.
• Você precisa de uma transferência estruturada 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-Skills Obrigatórias

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

Sub-skills opcionais de suporte:

• deploy-dev
• pr-watch
• pr-review-autopilot
• git-ship

Entradas

Exigir estas entradas:

• id da issue ou corpo da issue
• status da issue
• critérios de aceitação (DoD)
• ambiente alvo (dev como padrão)

Padrões fixos:

• número máximo de iterações = 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. Intake

   • Ler a issue e extrair o objetivo da tarefa + DoD.

2. Gate da issue

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

3. Executar

   • Transferir 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:
     • aguardar 3m
     • depois 6m
     • depois 10m
   • Após a rodada de 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, implantar apenas em dev por padrão.
   • Verificar com logs/API/comportamento Lambda reais, não suposições.

6. Gate 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 uma evidência correspondente.

Mover para escalated quando qualquer uma destas situações ocorrer:

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

Gates Humanos

Sempre parar para confirmação humana em:

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

Contrato de Saída

Ao relatar status, sempre incluir:

• Status: intake / executing / accepted / escalated
• Critérios de Aceitação: checklist de passou/falhou
• Evidências: comandos, logs, resultados de API ou prova em tempo de execução
• Riscos em Aberto: qualquer coisa ainda incerta
• Necessita de Entrada Humana: menor próxima decisão, se bloqueado

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

Limitações

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