Um assistente de programação pode continuar a trabalhar numa validação falhada, mas a própria validação e o código final continuam a exigir revisão. Este guia destina-se a quem mantém um repositório com um comando de teste, compilação ou análise de estilo que já falha. Usa um Goal delimitado no Claude Code ou, como opção separada, a CLI interativa do Codex. Escolha uma. O trabalho termina quando o comando original passa numa alteração revista que preserva o comportamento definido previamente. Se não for demonstrável, guarde a falha e o impedimento exato. É um procedimento documental: a BIG CHANGE não executou um Goal nem reparou um repositório para este artigo.

A grande mudança

  • O que mudou: Os comandos documentados /goal mantêm um objetivo ativo entre turnos, permitindo ao assistente investigar uma falha, fazer uma alteração limitada e verificar de novo sem novas instruções após cada turno.
  • Porque importa: Pode definir o comando original, os ficheiros permitidos e o comportamento protegido antes do ciclo. Assim, as tentativas sucessivas têm o mesmo critério de aceitação.
  • O que observar: Um estado Goal ou veredito do modelo não demonstra a reparação. Leia a saída real e o diff final e decida pessoalmente se aceita a alteração.

Antes de começar: registe a falha e os limites

Use um repositório que tenha autorização para alterar. Leia as instruções locais, incluindo AGENTS.md ou CLAUDE.md quando existirem, e verifique o ramo, as edições existentes e os ficheiros não seguidos. Num repositório Git, estes comandos fornecem o inventário inicial:

Terminal
git status --short
git diff --stat
git diff

Guarde o inventário para distinguir as alterações do assistente do trabalho anterior. Execute a validação real que falha uma vez ou conserve uma execução recente fiável com o comando exato, o erro completo e o estado de saída. Não a substitua por um exemplo deste artigo. Registe previamente dependências de serviços, segredos ou plataformas inacessíveis. Uma alteração única conhecida poderá ser mais simples com um pedido normal; um Goal ajuda quando cada resultado determina o diagnóstico seguinte.

Escreva fora do Goal uma nota breve de aceitação: comando original exato, resultado atual, caminhos e ferramentas permitidos, comportamentos ou outras validações a preservar e decisões que exigem parar e rever. Proteja expressamente edições anteriores sem relação. Não deixe apagar ou enfraquecer a validação para fabricar um sucesso. Reveja a nota antes de autorizar ferramentas. Pedir uma paragem após alguns turnos pode orientar o modelo, mas não garante um limite de despesa.

1. Escolha uma interface Goal

No Claude Code, abra a sessão do repositório pretendido e verifique se /goal está disponível. O manual de Goal, verificado a 20 de outubro de 2026, indica que depende da confiança no espaço de trabalho e das definições de hooks. Só pode haver um Goal ativo por sessão. Uma nova condição substitui a anterior e começa imediatamente. O Goal não altera o modo de permissões: o modo manual pode continuar a pedir autorização antes das ferramentas; o automático é uma definição separada. Mantenha os controlos habituais de ficheiros, comandos e rede.

Para a alternativa da CLI interativa do Codex, verifique a versão instalada e a lista de comandos com barra. O guia prático de Goals da OpenAI indica que começam no Codex 0.128.0. O guia de utilização documenta a opção features.goals caso o comando não exista. São verificações para a sua instalação; não foram executadas para o artigo:

Terminal
codex --version
codex features enable goals

Ative a função apenas se a instalação precisar e a organização permitir. Estas instruções referem-se à CLI interativa. Não pressuponha o mesmo suporte em codex exec ou em todas as versões de ambiente de trabalho. Se o comando continuar ausente, pare e verifique a versão, a definição e o acesso da conta ou espaço de trabalho antes de escolher outro método.

2. Defina a condição delimitada

Use /goal seguido da condição revista. Indique o comando real e os caminhos permitidos, não um teste inventado. Por exemplo: «Faça a minha validação, que já falha, passar usando apenas os caminhos e ferramentas da nota de aceitação. Após cada tentativa, mostre o comando, o resultado completo e os ficheiros alterados. Preserve o comportamento protegido e as edições sem relação. Se não puder executar a validação ou não restar alteração segura no âmbito, pare com o erro exato, as alterações tentadas e a informação necessária da minha parte.» Substitua «a minha validação» pelo comando exato e anexe ou indique a nota revista antes de começar.

Os dois comandos documentados /goal aceitam uma condição não vazia com até 4.000 carateres. Mantenha as restrições detalhadas na nota. No Claude Code, /goal <condition> inicia logo um turno. Na CLI interativa do Codex, /goal <objective> associa um objetivo persistente à conversa atual. Nenhuma via concede novas autorizações sobre ficheiros, comandos ou contas. Se a reparação exigir mais caminhos, um serviço externo, um segredo, uma integração ou uma implementação, pare para decisão do responsável.

3. Acompanhe as provas durante o trabalho

Peça a saída exata após cada tentativa relevante e a lista de ficheiros alterados. Execute /goal sem argumento para consultar o estado. O Claude Code mostra tempo decorrido, turnos avaliados, consumo de tokens e o motivo mais recente do avaliador após a avaliação. O avaliador lê o que Claude apresentou na conversa; não executa a validação nem inspeciona ficheiros de forma independente. Assim, um veredito «met» pede confirmação, não prova a reparação. O estado Goal do Codex também precisa da saída real e do diff para estabelecer um resultado.

Mantenha o ciclo no âmbito original. Leia comandos propostos antes de autorizar, sobretudo os que apagam ficheiros, reescrevem o histórico, enviam dados para fora ou alteram permissões. Pare se a validação original for enfraquecida, um ficheiro alheio mudar sem explicação ou dados privados forem expostos. Se não puder autorizar com segurança a ação seguinte, registe o estado Goal e peça um plano mais restrito.

4. Verifique o fim pessoalmente

Quando o assistente declarar sucesso, examine o diff final completo face ao inventário inicial. Verifique cada ficheiro alterado ou novo nos caminhos permitidos. Execute o mesmo comando original de validação novamente quando viável e guarde a saída completa e o estado de saída. Execute os testes pertinentes não alterados da nota e reveja o comportamento a preservar. Uma validação substituta passar não cumpre o acordo.

Aceite a alteração apenas se as provas corresponderem à condição revista e aprovar o diff. Commit, integração e implementação são decisões autorizadas separadamente. Se a verificação falhar, guarde comando e saída exatos, ficheiros alterados, estado Goal e a permissão, dependência ou decisão em falta. Um Goal pausado, interrompido, impossível, bloqueado ou limitado por orçamento não é uma reparação concluída.

Se o Goal parar ou ficar preso

No Claude Code, /goal mostra a condição e o motivo mais recente; /goal clear remove o Goal ativo. O manual indica que uma condição ativa pode voltar ao retomar a sessão, mas as bases de tempo, turnos e tokens reiniciam. A recuperação pelo seletor de sessões foi corrigida em v2.1.239. Falhas de autenticação gerida pelo Claude Code, crédito esgotado, excesso irrecuperável de contexto e modelo indisponível podem apagar o Goal. A autenticação gerida pelo anfitrião pode deixá-lo ativo. Outros erros podem mantê-lo e repetir ou pausar; os avisos interativos estão documentados desde v2.1.269. Leia o aviso, estado, saída guardada e diff antes de definir ou retomar. Uma condição nova substitui a anterior.

Na CLI interativa do Codex, /goal mostra o objetivo, enquanto /goal edit, /goal pause, /goal resume e /goal clear são controlos documentados na referência de comandos CLI. O guia prático distingue conclusão de pausa, interrupção, limite de orçamento ou impedimento. Inspecione o estado e as provas reais antes de retomar ou alterar o objetivo. Se orçamento ou acesso pararam o trabalho, um impedimento exato pode ser mais útil do que outra tentativa.

Os turnos usam quota ou créditos; o avaliador separado do Claude Code também usa tokens. Verifique os controlos e limites atuais da sua conta. Uma condição de tempo ou turnos em prosa não garante um teto em dólares. Use apenas material autorizado, exclua segredos e ficheiros privados alheios e inspecione as instruções do repositório antes de o assistente as seguir.

Para uma configuração separada, o nosso guia do ambiente Codex Cloud explica a ligação e preparação de um repositório remoto. O nosso guia de Team Tasks partilhadas trata de trabalho recorrente no ChatGPT. Nenhuma configuração é necessária para o procedimento local anterior.

Fontes e leituras complementares