O AI-DLC 2.11.0 pode parar um fluxo do Codex CLI antes da geração de código para que um desenvolvedor leia e aprove o plano proposto. Este guia segue o lançamento v2.11.0 de 8 de outubro de 2026 e suas instruções versionadas de Codex CLI, perfis de fluxo de trabalho e Plan Approval. A BIG CHANGE examinou esses documentos e a referência de comandos da tag. Não instalamos nem executamos o AI-DLC; todas as etapas abaixo se baseiam apenas na documentação.

O leitor previsto é um desenvolvedor com um projeto Git que quer examinar um plano de código antes que um assistente de programação com IA gere arquivos. O resultado esperado é uma pergunta de Plan Approval que identifica o plano, permite solicitar mudanças e deixa a construção aguardando até o desenvolvedor responder. O AI-DLC ainda tem verificações posteriores; essa etapa de aprovação trata especificamente do plano de código.

Antes de começar

O guia do Codex na tag exige Codex CLI 0.145.0 ou mais recente, um repositório Git para os hooks do projeto e um provedor de modelos configurado. A versão nativa do AI-DLC não requer Bun nem Node.js. Use um projeto cujo código e plano você tenha autorização para enviar ao provedor configurado. Confira separadamente as condições de tratamento de dados e cobrança do provedor; o repositório do AI-DLC não informa um preço único de uso do provedor para esse fluxo.

Prepare uma tarefa concreta de desenvolvimento como entrada. Este passo a passo escolhe o perfil Feature porque a documentação da v2.11.0 informa que Plan Approval está ativado para Feature. Express e Proof of concept começam com Plan Approval desativado, embora uma pessoa possa pedir a revisão de um plano específico. O perfil importa mais que uma expectativa genérica de que toda execução do AI-DLC vai pausar.

1. Instale e verifique a versão fixa

No macOS, Linux ou WSL, o lançamento v2.11.0 fornece este comando de instalação específico da versão:

Terminal
curl -fsSL https://github.com/awslabs/aidlc-workflows/releases/download/v2.11.0/install.sh | sh -s -- --version 2.11.0

O lançamento também oferece um instalador do Windows específico da versão para PowerShell. Examine o instalador e escolha o caminho adequado para sua máquina antes de executá-lo. Depois confira a versão instalada e o ambiente a partir do projeto:

Terminal
aidlc --version
aidlc doctor
codex --version

Espere que aidlc --version informe 2.11.0. aidlc doctor relata problemas de configuração e execução, enquanto codex --version permite conferir a versão mínima do Codex CLI. Se a versão instalada for diferente, pare aqui e use as instruções de instalação ou atualização da v2.11.0; as etapas abaixo estão fixadas nessa versão.

2. Configure o Codex e confie nos hooks do projeto

Na raiz do projeto Git, use o caminho de configuração do Codex na tag:

Terminal
aidlc config --harness codex
aidlc doctor
codex

O Codex pergunta se você confia nos hooks do projeto. Examine o projeto e os hooks gerados antes de escolher Trust all and continue (Confiar em todos e continuar). O guia da tag diz que uma caixa de diálogo já fechada pode ser reaberta com /hooks, depois t e Esc. Execute $aidlc --doctor no Codex após conceder confiança. Se os hooks não estiverem funcionando, siga a recuperação de confiança do guia do ambiente de integração; um instalador bem-sucedido, por si só, não comprova que os hooks do projeto estão ativos. O provedor de modelos e suas credenciais são configurados nas definições de usuário do Codex, e não fornecidos pelo AI-DLC.

3. Inicie um fluxo Feature e confira as configurações

Primeiro execute $aidlc --status no Codex e confirme que não há fluxo ativo. A referência de comandos da tag diz que um comando de escopo sem outras opções continua o trabalho existente quando há um fluxo ativo. Use um projeto sem fluxo ativo neste passo a passo.

Nesse projeto do Codex configurado, digite $aidlc feature e responda à solicitação sobre a tarefa que quer construir. A entrada deve descrever a funcionalidade e suas restrições; o plano final é gerado desse trabalho. Antes de criar o plano de código, examine os controles efetivos usando a referência de comandos da v2.11.0:

Text
$aidlc --status
$aidlc config get plan-approval
$aidlc config get guard-policy

Procure Plan Approval on (ativado) e a origem indicada da configuração. Se estiver desativado para essa intenção, $aidlc --plan-approval on ativa a pergunta para o próximo plano. Um controle no nível da máquina pode forçar sua desativação, e uma regra de memória da equipe pode exigir que fique ativado; a linha de status identifica o valor efetivo. Neste passo a passo, configure Guard Policy como estrita com $aidlc --guard-policy strict se também quiser exigir nova aprovação quando um plano já aprovado ou suas instruções de teste forem editados. Plan Approval ativado controla a primeira pergunta; Guard Policy controla o que acontece depois de uma mudança no plano aprovado.

4. Revise o plano de código na etapa de aprovação

Continue o fluxo até Code Generation ter um plano pronto. Com Plan Approval ativado, o mecanismo v2.11.0 mostra o resumo e o caminho do plano, incluindo as opções Approve Plan (Aprovar plano), Request Changes (Solicitar mudanças) ou I'll edit the files (Vou editar os arquivos). Abra o arquivo code-generation-plan.md indicado e leia os arquivos propostos, a sequência e as instruções de teste. Confira comandos, acesso aos dados do projeto e ações que possam alterar o repositório antes de aprovar.

Escolha Request Changes (Solicitar mudanças) se o plano precisar de outra implementação ou teste. Se editar os arquivos por conta própria, use o caminho do mecanismo I'll edit the files (Vou editar os arquivos) em vez de considerar uma edição como aprovação. Só sua resposta autoriza o plano; um modelo não pode aprová-lo por você. Com essa etapa ativada, a geração de código aguarda essa resposta. As notas de lançamento dizem que uma revisão, configuração, commit ou outra solicitação permitida pode prosseguir enquanto a construção aguarda.

5. Aprove, confira o registro e trate um plano alterado

Quando o plano estiver aceitável, responda Approve Plan (Aprovar plano) na pergunta aberta. O mecanismo registra a aprovação para aquele plano e retoma a construção pelo fluxo normal next. Segundo as notas de lançamento, um plano aprovado sem alterações é lembrado mesmo após a conversa ser compactada ou estacionada. A referência de comandos da tag documenta o comando somente de leitura aidlc engine audit history para examinar a linha do tempo registrada, e $aidlc --status mostra a posição do fluxo. Esses registros são a verificação de sucesso, junto com a aparição visível da etapa de aprovação antes do código gerado.

Se o plano ou suas instruções de teste mudarem antes da construção, Guard Policy estrita pede aprovação novamente. Com uma política relaxada ou desativada, a mudança é relatada e registrada, mas o fluxo pode continuar sem nova aprovação obrigatória. A documentação da tag também distingue alterações de arquivos-fonte não relacionados depois da aprovação: elas são relatadas, enquanto a aprovação continua tratando do plano e das instruções de teste. A pessoa pode dizer “volte ao plano aprovado” para restaurar o plano anterior antes da construção. Um plano sem mudanças não deve perguntar de novo só porque a conversa foi compactada.

Se a pausa não aparecer

Primeiro leia $aidlc --status e $aidlc config get plan-approval. Confira o escopo escolhido, a configuração efetiva e sua origem. Express e Proof of concept ficam desativados por padrão; ative Plan Approval para essa intenção ou inicie um fluxo Feature se seu ciclo completo servir à tarefa. Se a configuração ou os hooks parecerem quebrados, execute aidlc doctor e siga a recuperação do ambiente de integração do Codex. Verifique incompatibilidades de versão antes de alterar o ambiente de execução de um projeto ativo. Não presuma que a ausência da pergunta comprova uma aprovação registrada: com a opção desativada, o AI-DLC grava uma linha PLAN_APPROVAL_SKIPPED, que a documentação da tag diferencia expressamente da aprovação de uma pessoa.

A grande mudança

  • O AI-DLC 2.11.0 coloca a pergunta do plano em seu mecanismo, que registra a decisão e preserva um plano aprovado sem mudanças durante sessões estacionadas ou compactadas.
  • Em uma execução Feature no Codex CLI, o desenvolvedor pode conferir a configuração efetiva de Plan Approval, ler o plano antes de gerar código e solicitar mudanças na etapa de aprovação.
  • A reaprovação depois de editar um plano depende de Guard Policy. O desenvolvedor pode escolher a política estrita para parar de novo quando o plano ou as instruções de teste mudarem.

Fontes e leituras adicionais