autopilot

<Propósito> O Autopilot recebe uma ideia de produto breve e gerencia de forma autônoma todo o ciclo de vida: análise de requisitos, design técnico, planejamento, implementação paralela, ciclos de QA e validação multi-perspectiva. Ele produz código funcional e verificado a partir de uma descrição de 2 a 3 linhas. </Propósito>

<Quando_Usar>

• O usuário deseja execução autônoma de ponta a ponta, de uma ideia ao código funcional
• O usuário diz "autopilot", "auto pilot", "autonomous", "build me", "create me", "make me", "full auto", "handle it all" ou "I want a/an..."
• A tarefa requer múltiplas fases: planejamento, codificação, teste e validação
• O usuário deseja execução sem intervenção e está disposto a deixar o sistema rodar até a conclusão </Quando_Usar>

<Não_Usar_Quando>

• O usuário deseja explorar opções ou fazer um brainstorming -- use o skill plan
• O usuário diz "just explain", "draft only" ou "what would you suggest" -- responda de forma conversacional
• O usuário deseja uma única alteração de código focada -- use ralph ou delegue a um agente executor
• O usuário deseja revisar ou criticar um plano existente -- use plan --review
• A tarefa é uma correção rápida ou um pequeno bug -- use delegação direta ao executor </Não_Usar_Quando>

<Por_Que_Isso_Existe> A maioria das tarefas de software não triviais exige fases coordenadas: entender os requisitos, projetar uma solução, implementar em paralelo, testar e validar a qualidade. O Autopilot orquestra todas essas fases automaticamente, para que o usuário descreva o que deseja e receba código funcional sem gerenciar cada etapa. </Por_Que_Isso_Existe>

<Política_de_Execução>

• Cada fase deve ser concluída antes que a próxima comece
• A execução paralela é usada dentro das fases, quando possível (Fase 2 e Fase 4)
• Os ciclos de QA se repetem até 5 vezes; se o mesmo erro persistir 3 vezes, pare e relate o problema fundamental
• A validação requer aprovação de todos os revisores; itens rejeitados são corrigidos e revalidados
• Cancele com /oh-my-claudecode:cancel a qualquer momento; o progresso é preservado para retomada </Política_de_Execução>

<Perfis_de_Fluxo_de_Trabalho>

Perfis de estágios nomeados (v1)

Selecione um perfil configurado apenas com /autopilot --workflow <nome> <tarefa>. Um perfil é uma programação de estágios de propriedade do autopilot, não um comando, modo, plugin, nome de arquivo ou identidade de estado separada. Sem --workflow, o autopilot mantém seu ciclo de vida e comportamento legados.

Os perfis de fluxo de trabalho nomeados exigem Linux com o utilitário flock na v1 porque seu limite de evidência de transcrição usa travessia de descritor de arquivo sem follow do Linux e seu bloqueio de mutação recuperável usa bloqueio consultivo do kernel. Ambientes não suportados rejeitam a ativação explícita de --workflow antes da mutação de estado; use o autopilot legado.

Os perfis são configurados em JSONC de projeto ou usuário como autopilot.workflows.<slug>. Cada perfil v1 tem exatamente version: 1 e stages; nenhuma outra chave de perfil é aceita. As únicas sequências de estágios admitidas são:

{
  "autopilot": {
    "workflows": {
      "plan-build-qa": {
        "version": 1,
        "stages": ["ralplan", "execution", "qa"]
      }
    }
  }
}

[ralplan, execution]
[ralplan, execution, ralph]
[ralplan, execution, qa]
[ralplan, execution, ralph, qa]

ralplan cria o plano consumido por execution; execution cria o espaço de trabalho implementado exigido por ralph e qa. Portanto, pré-requisitos omitidos ou reordenados, estágios duplicados e estágios não embutidos são inválidos. Os nomes dos perfis usam ^[a-z][a-z0-9-]{0,62}$, são metadados validados apenas e não podem colidir com estágios embutidos, nomes de autopilot/mode ou aliases obsoletos.

As fontes de configuração do usuário e do projeto são validadas separadamente antes da composição. Nomes diferentes coexistem; um perfil de projeto com o mesmo nome substitui o perfil de usuário completo, em vez de fazer merge profundo. A configuração de ambiente não pode definir ou substituir perfis.

Após a seleção bem-sucedida, o autopilot cria atomicamente seu estado existente com escopo de sessão com um descritor normalizado imutável e rastreamento de pipeline apenas selecionado. O descritor contém o nome do fluxo de trabalho, versão do perfil, estágios canônicos e um hash SHA-256 de perfil determinístico; exclui texto da tarefa e progresso mutável. Retomar e Parar verificam esse hash e recusam uma incompatibilidade sem recarregar a configuração ou emitir um prompt de estágio. Cancelar, retomar, limpeza, inspeção de estado, HUD e continuação de Parar permanecem de propriedade do autopilot.

Os hooks de Parar do plugin instalado e da instalação autônoma avançam somente após um registro de conclusão de assistente autorizado para o estágio ativo aparecer após o limite de transcrição de evidência ativado desse estágio. Eles vinculam evidência à sessão proprietária e à transcrição limitada e não simbólica; rejeitam saída de comando de usuário/ferramenta/local e evidência desatualizada ou de estágio errado; e usam atualizações de rastreamento de comparação antes da gravação para que eventos de Parar duplicados ou simultâneos avancem exatamente uma vez. O estado público, HUD e saída de Parar mostram apenas metadados de fluxo de trabalho seguros e progresso, nunca a tarefa, detalhes internos do descritor, referências de transcrição, deslocamentos ou hashes de registro.

Adiamentos da v1

A v1 não suporta stageModels, roteamento de modelo, seleção de provedor ou função; execução inline/sem spawn; comandos dinâmicos, modos ou arquivos de estado; estágios arbitrários, prompts, plugins, branches, loops, DAGs ou callbacks; ou definições de perfil definidas pelo ambiente. A incompatibilidade do analisador de frontmatter de array inline de skill personalizado separado também é adiada. </Perfis_de_Fluxo_de_Trabalho>

2. Fase 1 - Planejamento: Crie um plano de implementação a partir da especificação

   • Se existir um plano de consenso ralplan: Pule — já foi feito no pipeline de 3 estágios
   • Arquiteto (Opus): Crie o plano (modo direto, sem entrevista)
   • Crítico (Opus): Valide o plano
   • Saída: .omc/plans/autopilot-impl.md

3. Fase 2 - Execução: Implemente o plano usando agentes executores com persistência Ralph quando necessário

   • Executor (Haiku): Tarefas simples
   • Executor (Sonnet): Tarefas padrão
   • Executor (Opus): Tarefas complexas
   • Execute tarefas independentes em paralelo

4. Fase 3 - QA: Ciclo até que todos os testes passem

   • Compilar, lint, testar, corrigir falhas
   • Repita até 5 ciclos
   • Pare cedo se o mesmo erro se repetir 3 vezes (indica um problema fundamental)

5. Fase 4 - Validação: Revisão multi-perspectiva em paralelo

   • Arquiteto: Completude funcional
   • Revisor de segurança: Verificação de vulnerabilidade
   • Revisor de código: Revisão de qualidade
   • Todos devem aprovar; corrija e revalide em caso de rejeição

6. Fase 5 - Limpeza: Exclua todos os arquivos de estado na conclusão bem-sucedida

   • Remova .omc/state/autopilot-state.json, ralph-state.json (mais cópias legadas obsoletas ultraqa-state.json/ultrawork-state.json se existirem)
   • Execute /oh-my-claudecode:cancel para saída limpa

<Uso_de_Ferramentas>

• Use Task(subagent_type="oh-my-claudecode:architect", ...) para validação de arquitetura da Fase 4
• Use Task(subagent_type="oh-my-claudecode:security-reviewer", ...) para revisão de segurança da Fase 4
• Use Task(subagent_type="oh-my-claudecode:code-reviewer", ...) para revisão de qualidade da Fase 4
• Os agentes formam sua própria análise e a retornam; o LÍDER então gera quaisquer agentes de validação cruzada por conta própria. Não dependa que um subagente gere mais subagentes sem verificar a configuração de profundidade do Claude Code: Claude Code 2.1.217–2.1.218 definiu CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH como 1, enquanto 2.1.219+ usa 3 como padrão. Mantenha a validação cruzada no nível do LÍDER, a menos que a delegação aninhada seja deliberada e suportada pelo runtime ativo.
• Nunca bloqueie em ferramentas externas; prossiga com os agentes disponíveis se a delegação falhar </Uso_de_Ferramentas>

<Condições_de_Escalonamento_e_Parada>

• Pare e relate quando o mesmo erro de QA persistir por 3 ciclos (problema fundamental que requer entrada humana)
• Pare e relate quando a validação continuar falhando após 3 rodadas de revalidação
• Pare quando o usuário disser "stop", "cancel" ou "abort"
• Se os requisitos eram muito vagos e a expansão produzir uma especificação pouco clara, ofereça redirecionamento para /deep-interview para esclarecimento socrático, ou pause e peça esclarecimento ao usuário antes de prosseguir </Condições_de_Escalonamento_e_Parada>

<Lista_de_Verificação_Final>

• Todas as 5 fases concluídas (Expansão, Planejamento, Execução, QA, Validação)
• Todos os validadores aprovaram na Fase 4
• Testes passam (verificado com saída de execução de teste recente)
• Build bem-sucedido (verificado com saída de build recente)
• Arquivos de estado limpos
• Usuário informado da conclusão com resumo do que foi construído </Lista_de_Verificação_Final>

Riscos de sessão paralela

• Âncora de espaço de trabalho multi-repositório: coloque um marcador .omc-workspace no diretório pai para que várias sessões em sub-repositórios compartilhem um .omc/. Ordem de resolução: OMC_STATE_DIR > .omc-workspace > git > cwd. Consulte docs/REFERENCE.md.
• Fonte do ID da sessão: a variável de ambiente OMC_SESSION_ID vence em contextos de CLI; data.session_id do hook vence em contextos de hook.
• ID do plano (quando aplicável): o estado do autopilot tem escopo de sessão. Dois autopilots no mesmo espaço de trabalho exigem IDs de sessão distintos.
• Veredito paralelo: suportado (estado com escopo de sessão)

<Avançado>

Configuração

Configurações opcionais em .claude/omc.jsonc (projeto) ou ~/.config/claude-omc/config.jsonc (usuário):

{
  "autopilot": {
    "maxIterations": 10,
    "maxQaCycles": 5,
    "maxValidationRounds": 3,
    "pauseAfterExpansion": false,
    "pauseAfterPlanning": false,
    "skipQa": false,
    "skipValidation": false,
    "execution": "solo"
  }
}

Para executar a implementação do autopilot através do runtime de equipe tmux CLI e preferir trabalhadores executores Cursor:

{
  "autopilot": {
    "execution": "team",
    "team": { "agentTypes": ["cursor"] }
  }
}

Com essa configuração, o estágio de execução deve lançar trabalho do tipo executor através de:

omc team 1:cursor "<tarefa de implementação>"

ou da superfície de compatibilidade de barra do Claude Code:

/omc-teams 1:cursor "<tarefa de implementação>"

Limitações:

• Trabalhadores Cursor suportam funções de equipe do tipo implementação e revisor. Trabalhadores critic, code-reviewer, security-reviewer e test-engineer devem emitir o arquivo de veredito estruturado consumido pelo líder da equipe; a aprovação final permanece uma responsabilidade da sessão líder.
• O Cursor exige que o CLI cursor-agent esteja instalado e autenticado. Se cursor-agent estiver indisponível, relate esse requisito de configuração em vez de recorrer silenciosamente à execução apenas com Claude.

Retomada

Se o autopilot foi cancelado ou falhou, execute /oh-my-claudecode:autopilot novamente para retomar de onde parou.

Melhores Práticas para Entrada

1. Seja específico sobre o domínio -- "bookstore" não "store"
2. Mencione funcionalidades principais -- "with CRUD", "with authentication"
3. Especifique restrições -- "using TypeScript", "with PostgreSQL"
4. Deixe-o executar -- evite interromper a menos que seja realmente necessário

Solução de Problemas

Preso em uma fase? Verifique a lista TODO para tarefas bloqueadas, revise .omc/autopilot-state.json ou cancele e retome.

Ciclos de QA esgotados? O mesmo erro 3 vezes indica um problema fundamental. Revise o padrão de erro; pode ser necessária intervenção manual.

Validação continua falhando? Revise os problemas específicos. Os requisitos podem ter sido muito vagos — cancele e forneça mais detalhes.

Integração com Deep Interview

Quando o autopilot é invocado com uma entrada vaga, a Fase 0 pode redirecionar para /deep-interview para esclarecimento socrático:

Usuário: "autopilot build me something cool"
Autopilot: "Sua solicitação é aberta. Gostaria de executar uma deep interview primeiro?"
  [Sim, entrevista primeiro (Recomendado)] [Não, expandir diretamente]

Se uma especificação de deep-interview já existir em .omc/specs/deep-interview-*.md, o autopilot a usa diretamente como saída da Fase 0 (a especificação já foi matematicamente validada quanto à clareza).

Pipeline de 3 Estágios: deep-interview → ralplan → autopilot

O pipeline completo recomendado encadeia três portões de qualidade:

/deep-interview "ideia vaga"
  → Q&A socrático → especificação (ambiguidade ≤ 20%)

(...truncado para tradução)

</Avançado>