Mudou o requisito no meio da implementação: atualizar a spec ou seguir com o Claude Code?

Fala aí, beleza? O Claude Code tá no meio da execução, arquivos mudando na tua frente, e aí chega a mensagem: o cliente quer outra regra

Ou pior, tu mesmo olha a tela e percebe um caso que ninguém previu quando o plano foi aprovado 😅

O impulso é digitar a correção no chat e torcer

Mas a pergunta real é outra: a especificação precisa mudar ANTES do Claude continuar? Porque se ela não mudar, o modelo segue executando o plano velho, que agora descreve um software que ninguém mais quer

A resposta depende de duas coisas: o tamanho da mudança e quantos passos do plano ela invalida

Parar e replanejar x ajustar na mesma sessão: qual caminho serve

Olha o plano aprovado na tela e avalia critério por critério, é bem mais rápido que ficar no achismo

Regra prática: se você não consegue apontar UM passo do plano que a mudança substitui, ela não é pontual

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

O que você precisa ter antes de decidir

Decidir sem perder trabalho depende de três coisas estarem no lugar

Um plano aprovado, não um chute. O plan mode é modo somente leitura: o Claude Code lê arquivos, roda comandos de exploração e propõe um plano, e nenhuma edição chega ao disco antes da aprovação

Se existe plano aprovado, existe documento pra comparar com o requisito novo

Checkpoints. O checkpointing captura automaticamente o estado dos arquivos antes de cada prompt do usuário, então dá pra voltar

E aqui vem a ressalva dura, presta atenção nessa: só edições feitas pelas ferramentas de edição de arquivo do Claude são rastreadas

Arquivo modificado por comando bash NÃO entra no checkpoint

Ou seja: aquele script que o Claude rodou e que reescreveu um arquivo gerado não volta com o rewind. Tome cuidado!

Os atalhos na ponta dos dedos. Esc interrompe o turno em andamento, inclusive durante execução de comandos

Esc duas vezes (ou o comando /rewind) abre o menu de rewind

E os modos de permissão são quatro: default, acceptEdits, bypassPermissions e plan, com Shift+Tab ciclando entre eles na sessão interativa

Se você tava em acceptEdits ou bypassPermissions quando o requisito mudou, provavelmente já tem coisa no disco, então decidir rápido importa mais ainda

Caminho A: parar, atualizar a spec e replanejar a execução

Esse é o caminho pra mudança que invalida o plano, não que ajusta o plano

1. Interrompa o turno com Esc. Esc interrompe o turno em andamento, inclusive durante execução de comandos

O erro comum deste passo: ficar assistindo o Claude terminar "só esse arquivinho" antes de parar. Cada arquivo a mais escrito sob a regra velha é um arquivo a mais pra revisar depois

2. Decida o que fica no disco. Esc duas vezes ou /rewind abre o menu, e ali dá pra escolher: restaurar a conversa mantendo o código atual, restaurar o código mantendo a conversa, resumir a partir daqui, resumir até aqui, ou sair sem alterar

/rewind

Pensa no que você quer preservar. Muitas vezes o código feito até ali continua bom e o que ficou ruim foi a conversa, que agora aponta pro requisito errado

O erro comum deste passo: dar rewind no código achando que tudo volta, esquecendo que arquivos tocados por comandos bash ficam de fora do checkpoint

3. Escreva o requisito novo no documento de especificação do projeto. E escreva também o que ele SUBSTITUI, não só o que ele adiciona

"Agora o cadastro aceita CNPJ" é metade da informação. "Agora o cadastro aceita CNPJ, substituindo a validação de CPF obrigatório definida antes" é a informação inteira

O erro comum deste passo: registrar a regra nova sem marcar a antiga como morta, aí o plano seguinte tenta atender as duas e nasce contraditório

4. Volte pro plan mode. Shift+Tab até a barra de status mostrar ⏸ plan mode on, ou use o /plan já com a descrição do requisito

/plan fix the auth bug

O /plan aceita esse argumento opcional de descrição: ele entra em plan mode e já começa o planejamento com aquilo

Dá também pra abrir a sessão direto no modo, se você já sabe que vai replanejar:

claude --permission-mode plan

O erro comum deste passo: achar que apertou Shift+Tab e não conferir a barra de status. Se o indicador não aparece, você não tá em plan mode e o Claude vai editar arquivo

5. Revise o plano ANTES de aprovar. Ctrl+G abre o plano no editor de texto configurado pra edição direta antes da execução

Na extensão do VS Code o plano abre como documento Markdown, e dá pra deixar comentários inline como feedback antes do Claude começar

O erro comum deste passo: aprovar o plano novo no automático porque "já falei o que mudou". O plano é justamente o lugar onde você descobre que o requisito novo derrubou um passo que você nem tinha notado

Se o problema é o inverso, o plano tá certo mas a execução saiu do trilho, o caso é outro: vale ver quando a IA foge da spec sem jogar fora o que já foi construído

Caminho B: tratar como ajuste pontual dentro da mesma sessão

Agora o caso leve: a mudança cabe dentro de um passo e não mexe na arquitetura

1. Interrompa com Esc no momento certo, de preferência antes de o passo afetado ser escrito

O erro comum deste passo: interromper depois. Aí você não tá mais ajustando, tá corrigindo, e corrigir custa mais que ajustar

2. Enuncie a correção amarrada ao passo que ela substitui. Não escreva "na verdade tem que validar CNPJ também"

Escreva algo do tipo: "no passo 3 do plano, a validação de documento passa a aceitar CNPJ além de CPF, o resto do passo segue igual"

Amarrar no número do passo é o que impede o modelo de tratar aquilo como requisito solto

O erro comum deste passo: descrever o comportamento novo sem dizer onde ele entra, e o Claude aplicar em três lugares diferentes

3. Peça a confirmação do impacto antes de retomar. Pergunta quais passos do plano mudam com isso, e lê a resposta com calma

Se a resposta citar mais de um passo, para tudo: você tá no Caminho A e ainda não percebeu

O erro comum deste passo: pular a confirmação porque a mudança "é boba". Mudança boba que toca dois passos deixa de ser boba

4. Libere a execução e acompanha o passo afetado até o fim antes de sair pra outra coisa

O erro comum do caminho inteiro: empilhar ajuste em cima de ajuste

Cada um parece pequeno, mas em cinco deles o plano na tela não descreve mais o que tá sendo construído

E aí você tem o pior dos mundos: um documento aprovado que mente, e um monte de regra viva só no histórico do chat

Como registrar a mudança para ela não se perder na próxima sessão

Mudança que só existiu no chat morre com o chat. Então o destino do registro depende do TIPO de mudança

Decisão permanente de projeto vai pro CLAUDE.md. Ele é markdown puro com instruções persistentes (de projeto, pessoais ou de organização) e o Claude lê no começo de cada sessão

O detalhe que faz diferença em sessão longa: depois do /compact, o Claude relê o CLAUDE.md da raiz do projeto no disco e reinjeta o conteúdo na sessão

Ou seja, o que tá escrito ali sobrevive à compactação. O que tá só na conversa, não

Organização com imports não é economia. Dá pra quebrar o CLAUDE.md em pedaços com @caminho, e isso arruma a casa

Mas os arquivos importados por @path são carregados na inicialização da sessão, então dividir organiza e NÃO economiza contexto

Se você achou que ia enxugar a sessão fatiando o arquivo: não vai 😀

O que ficou salvo entre sessões você audita com /memory. O comando abre a pasta de memória automática, e o conteúdo é markdown puro que dá pra ler, editar ou apagar

/memory

O toggle da memória automática grava autoMemoryEnabled em ~/.claude/settings.json

Vale a visita justamente depois de uma mudança de requisito: se ficou salva por lá alguma nota descrevendo a regra ANTIGA, ela vai voltar te assombrar na próxima sessão

E o caso da sessão que já esticou demais. O /clear reseta o contexto pra vazio, e a conversa anterior permanece salva em disco, retomável pelo ID de sessão

Isso é ótimo pra auditoria e péssimo como estratégia de memória: ninguém vai caçar ID de sessão pra lembrar qual regra vale hoje

O registro escrito é o que sobrevive, o histórico é só o arquivo morto

Conclusão

A pergunta que resolve isso não é "quanto já foi feito"

É: o plano aprovado ainda descreve o que eu estou construindo?

Se sim, ajuste pontual amarrado ao passo, e toca o barco

Se não, para, atualiza a spec com o que entrou e com o que morreu, e replaneja em plan mode

Próximo passo prático pra próxima vez que o requisito virar no meio: antes de digitar a correção no chat, reabre o plano e marca quais passos ela invalida

Um passo? Caminho B

Mais de um? Caminho A, sem dó

E se replanejar virou rotina no teu fluxo, dá uma olhada na opção do /model que usa Opus somente em plan mode e Sonnet fora dele: quem passa bastante tempo na etapa de planejar tende a gostar disso

até o próximo post! 🙂