omc-plan

<Propósito> Plan cria planos de trabalho abrangentes e acionáveis por meio de interação inteligente. Ele detecta automaticamente se deve entrevistar o usuário (solicitações amplas) ou planejar diretamente (solicitações detalhadas), e suporta modo de consenso (loop iterativo Planner/Architect/Critic com deliberação estruturada RALPLAN-DR) e modo de revisão (avaliação do Crítico de planos existentes). </Propósito>

<Quando_Usar>

• O usuário quer planejar antes de implementar — "planeje isso", "planeje o", "vamos planejar"
• O usuário quer uma coleta estruturada de requisitos para uma ideia vaga
• O usuário quer uma revisão de um plano existente — "revise este plano", --review
• O usuário quer consenso multi-perspectiva em um plano — --consensus, "ralplan"
• A tarefa é ampla ou vaga e precisa de escopo antes de qualquer código ser escrito </Quando_Usar>

<Não_Usar_Quando>

• O usuário quer execução autônoma de ponta a ponta — use autopilot em vez disso
• O usuário quer começar a codificar imediatamente com uma tarefa clara — use ralph ou delegue ao executor
• O usuário faz uma pergunta simples que pode ser respondida diretamente — apenas responda
• A tarefa é uma correção única e focada com escopo óbvio — use uma skill de execução em vez de executá-la a partir deste módulo de planejamento </Não_Usar_Quando>

<Por_Que_Isso_Existe> Mergulhar no código sem entender os requisitos leva a retrabalho, aumento de escopo e casos extremos perdidos. O Plan fornece coleta estruturada de requisitos, análise de especialistas e planos com controle de qualidade para que a execução comece a partir de uma base sólida. O modo de consenso adiciona validação multi-perspectiva para projetos de alto risco. </Por_Que_Isso_Existe>

<Política_de_Execução>

• Detectar automaticamente o modo de entrevista vs. direto com base na especificidade da solicitação
• Fazer uma pergunta por vez durante as entrevistas — nunca agrupar várias perguntas
• Reunir fatos do código-fonte via agente explore antes de perguntar ao usuário sobre eles
• Os planos devem atender aos padrões de qualidade: 80%+ das afirmações citam arquivo/linha, 90%+ dos critérios são testáveis
• O modo de consenso é totalmente automatizado por padrão; adicione --interactive para habilitar prompts do usuário nas etapas de revisão do rascunho e aprovação final
• O modo de consenso usa o modo curto RALPLAN-DR por padrão; mude para o modo deliberado com --deliberate ou quando a solicitação sinalizar explicitamente alto risco (autenticação/segurança, migração de dados, alterações destrutivas/irreversíveis, incidente de produção, conformidade/PII, quebra de API pública)
• Limite planejamento/execução: modos de planejamento inspecionam o contexto e produzem planos/especificações/propostas apenas. Eles DEVEM marcar artefatos como pending approval a menos que o usuário tenha explicitamente optado pela execução no turno atual ou através da UI de aprovação estruturada. Antes da aprovação explícita de execução, os modos de planejamento NÃO DEVEM executar comandos shell de mutação, editar arquivos fonte, commitar, fazer push, abrir PRs, invocar skills de execução ou delegar tarefas de implementação.
• Limite de fluxo Goal: quando um plano compara Claude Code /goal, Ralph, Team ou Ultragoal somente de artefato, identifique exatamente uma autoridade de loop primária e use as políticas de conflito determinísticas refuse, adopt_existing e artifact_only em vez de tratamento de aviso não determinístico. Os fatos de /goal devem citar apenas fontes Claude Code/Anthropic (docs do Claude Code /goal: https://code.claude.com/docs/en/goal; changelog do Anthropic Claude Code: https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md), e os planos NÃO DEVEM afirmar que o avaliador /goal executa comandos ou lê arquivos de forma independente; exija evidências de prova apresentadas antes de qualquer alegação de conclusão.
• Alvo do documento de fluxo Goal: para comparações voltadas ao usuário, mantenha exemplos alinhados com docs/shared/mode-selection-guide.md#goal-oriented-workflow-selection e docs/REFERENCE.md#goal-workflow-ux-goal-ralph-team-ultragoal. </Política_de_Execução>

Seleção de Modo

Modo	Gatilho	Comportamento
Entrevista	Padrão para solicitações amplas	Coleta interativa de requisitos
Direto	--direct ou solicitação detalhada	Pular entrevista, gerar plano diretamente
Consenso	--consensus, "ralplan"	Planner -> Architect -> Critic em loop até concordância com deliberação estruturada RALPLAN-DR (curto por padrão, --deliberate para alto risco); adicione --interactive para prompts do usuário nas etapas de rascunho e aprovação
Revisão	--review, "revise este plano"	Avaliação do Crítico de plano existente

Modo Entrevista (solicitações amplas/vagas)

1. Classifique a solicitação: Ampla (verbos vagos, sem arquivos específicos, toca em 3+ áreas) aciona o modo de entrevista
2. Faça uma pergunta focada usando AskUserQuestion para preferências, escopo e restrições
3. Reúna fatos do código-fonte primeiro: Antes de perguntar "quais padrões seu código usa?", inicie um agente explore para descobrir, depois faça perguntas de acompanhamento informadas
4. Construa sobre as respostas: Cada pergunta se baseia na resposta anterior
5. Consulte o Analista (Opus) para requisitos ocultos, casos extremos e riscos
6. Crie o plano quando o usuário sinalizar prontidão: "crie o plano", "estou pronto", "transforme em um plano de trabalho"

Modo Direto (solicitações detalhadas)

1. Análise Rápida: Consulta opcional breve ao Analista
2. Crie o plano: Gere plano de trabalho abrangente imediatamente
3. Revise (opcional): Revisão do Crítico se solicitado

Modo Consenso (--consensus / "ralplan")

Modos RALPLAN-DR: Curto (padrão, estrutura limitada) e Deliberado (para --deliberate ou solicitações explicitamente de alto risco). Ambos os modos mantêm a mesma sequência Planner -> Architect -> Critic e os mesmos portões AskUserQuestion.

Overrides de provedor (suportados quando o CLI do provedor está instalado):

• --architect codex — substitua a passagem Claude Architect por omc ask codex --agent-prompt architect "..." para revisão de arquitetura com foco em implementação
• --critic codex — substitua a passagem Claude Critic por omc ask codex --agent-prompt critic "..." para uma revisão externa antes da execução
• Se o provedor solicitado não estiver disponível, note brevemente e continue com a etapa padrão Claude Architect/Critic para aquele estágio

Ciclo de vida do estado: O hook de parada do modo persistente usa ralplan-state.json para impor a continuação durante o loop de consenso. A skill DEVE gerenciar este estado:

• Na entrada: Chame state_write(mode="ralplan", active=true, session_id=<current_session_id>) antes do passo 1
• Na entrega para execução (aprovação → ralph/team): Chame state_write(mode="ralplan", active=false, session_id=<current_session_id>). NÃO use state_clear aqui — state_clear escreve um sinal de cancelamento de 30 segundos que desabilita a imposição do hook de parada para TODOS os modos, deixando o modo de execução recém-iniciado desprotegido.
• Na saída terminal verdadeira (rejeição, saída de plano não interativa, erro/aborto): Chame state_clear(mode="ralplan", session_id=<current_session_id>) — nenhum modo de execução segue, então a janela de sinal de cancelamento é inofensiva.
• NÃO limpe durante etapas intermediárias como aprovação do Crítico ou apresentação de iteração máxima, pois o usuário ainda pode selecionar "Solicitar alterações".

Sem a limpeza, o hook de parada bloqueia todas as paradas subsequentes com mensagens de reforço [RALPLAN - CONSENSUS PLANNING] mesmo após o fluxo de trabalho de consenso ter terminado. Sempre passe session_id para evitar limpar o estado de outras sessões simultâneas.

1. Planner cria o plano inicial e um resumo compacto RALPLAN-DR antes de qualquer revisão do Architect. O resumo DEVE incluir:

   • Princípios (3-5)
   • Impulsionadores de Decisão (top 3)
   • Opções Viáveis (>=2) com prós e contras limitados para cada opção
   • Se apenas uma opção viável permanecer, uma justificativa de invalidação explícita para as alternativas que foram rejeitadas
   • No modo deliberado: um pré-mortem (3 cenários de falha) e um plano de teste expandido cobrindo unitário / integração / e2e / observabilidade

2. Feedback do usuário (--interactive apenas): Se executando com --interactive, DEVE usar AskUserQuestion para apresentar o rascunho do plano mais o resumo RALPLAN-DR de Princípios / Impulsionadores de Decisão / Opções para alinhamento precoce de direção com estas opções:

   • Prosseguir para revisão — enviar para Architect e Critic para avaliação
   • Solicitar alterações — retornar ao passo 1 com feedback do usuário incorporado
   • Pular revisão — ir diretamente para aprovação final (passo 7) Se NÃO estiver executando com --interactive, prossiga automaticamente para a revisão (passo 3).

3. Architect revisa a solidez arquitetural usando Task(subagent_type="oh-my-claudecode:architect", ...). A revisão do Architect DEVE incluir: o contra-argumento steelman mais forte (antítese) contra a opção favorecida, pelo menos uma tensão de trade-off significativa e (quando possível) um caminho de síntese. No modo deliberado, o Architect deve sinalizar explicitamente violações de princípios. Aguarde esta etapa ser concluída antes de prosseguir para o passo 4. NÃO execute os passos 3 e 4 em paralelo. O Architect DEVE avaliar o mesmo snapshot fixo do plano produzido pelo Planner no passo 1 sem mutá-lo; a saída do Architect NÃO DEVE ser passada para o Critic.

4. Critic avalia contra critérios de qualidade usando Task(subagent_type="oh-my-claudecode:critic", ...). O Critic DEVE verificar consistência princípio-opção, exploração justa de alternativas, clareza de mitigação de riscos, critérios de aceitação testáveis e etapas de verificação concretas. O Critic DEVE rejeitar explicitamente alternativas superficiais, contradições de impulsionadores, riscos vagos ou verificação fraca. No modo deliberado, o Critic DEVE rejeitar pré-mortem ausente/fraca ou plano de teste expandido ausente/fraca. Execute apenas após o passo 3 estar completo. O Critic DEVE avaliar o mesmo snapshot fixo do plano de forma independente, como uma chamada Task separada e aguardada individualmente; o Critic NÃO DEVE consumir ou receber a revisão do Architect.

   Revisões sequenciais independentes de um snapshot fixo do plano. Architect e Critic cada um revisa o mesmo snapshot fixo do plano produzido pelo Planner no passo 1, e nenhuma revisão o muta. A saída do Architect NÃO DEVE ser passada para o Critic. Architect e Critic DEVEM ser executados sequencialmente como chamadas Task separadas e aguardadas individualmente — nunca em paralelo — e a Task do Critic NÃO DEVE ser emitida até que a Task do Architect tenha sido concluída e seu resultado tenha sido aguardado. O Critic NÃO DEVE consumir ou receber a revisão do Architect. Os resultados do Architect e do Critic DEVEM ser combinados apenas pelo Planner durante a revisão ou síntese de melhoria, e somente após ambas as revisões terem sido concluídas.

5. Loop de re-revisão (máx. 5 iterações): Se o Critic rejeitar, execute este loop fechado: a. Colete todo o feedback de rejeição do Architect + Critic (síntese apenas pelo Planner: os resultados do Architect e do Critic DEVEM ser combinados apenas pelo Planner, e apenas após ambas as revisões terem sido concluídas). b. Passe o feedback para o Planner produzir um plano revisado c. Retorne ao Passo 3 — Architect revisa o plano revisado d. Retorne ao Passo 4 — Critic avalia o plano revisado e. Repita até o Critic aprovar OU máximo de 5 iterações atingido f. Se o máximo de iterações for atingido sem aprovação, apresente a melhor versão ao usuário via AskUserQuestion com nota de que o consenso de especialistas não foi alcançado

6. Aplique melhorias: Quando os revisores aprovarem com sugestões de melhoria, mescle todas as melhorias aceitas no arquivo de plano antes de prosseguir. A saída final do consenso DEVE incluir uma seção ADR com: Decisão, Impulsionadores, Alternativas consideradas, Por que foi escolhida, Consequências, Acompanhamentos. Especificamente: a. Colete todas as sugestões de melhoria das respostas do Architect e do Critic b. Desduplique e categorize as sugestões c. Atualize o arquivo de plano em .omc/plans/ com as melhorias aceitas (adicione detalhes ausentes, refine etapas, fortaleça critérios de aceitação, atualizações ADR, etc.) d. Anote quais melhorias foram aplicadas em uma breve seção de changelog no final do plano

7. Na aprovação do Critic (com melhorias aplicadas): marque o status do plano como pending approval a menos que a aprovação explícita de execução já tenha sido capturada. (--interactive apenas) Se executando com --interactive, use AskUserQuestion para apresentar o plano com estas opções:

   • Aprovar execução via team (Recomendado) — aceitação explícita para prosseguir via agentes de equipe coordenados em paralelo (/team). Team é a superfície de orquestração canônica desde v4.1.7.
   • Aprovar execução via ralph — aceitação explícita para prosseguir via persistência Ralph com verificação
   • Compactar e depois retornar para aprovação de execução — aceitação explícita para compactar a janela de contexto primeiro (recomendado quando o contexto é grande após o planejamento), depois parar no plano pendente de aprovação salvo e perguntar novamente antes de lançar a execução
   • Solicitar alterações — retornar ao passo 1 com feedback do usuário
   • Rejeitar — descartar o plano completamente Se NÃO estiver executando com --interactive, produza o plano final marcado pending approval, chame state_clear(mode="ralplan", session_id=<current_session_id>) e pare. NÃO execute automaticamente.

8. (--interactive apenas) O usuário escolhe através da UI estruturada AskUserQuestion (nunca peça aprovação em texto simples). Se o usuário selecionar Rejeitar, chame state_clear(mode="ralplan", session_id=<current_session_id>) e pare.

9. Na aprovação do usuário

... [truncado para tradução]