Aprovações no Claude Code sem hesitar: como montar um log de decisão para ler/editar/executar/publicar

Numa sexta-feira à noite, pedi ao Claude Code: “conserta só os links desta página”. O que voltou foi uma tela inteira de confirmações. Ele perguntou “posso executar este comando?” e eu, cansado, apertei Enter sem ler direito o que estava ali.

Na manhã seguinte, o preço exibido no site de produção estava diferente. De quebra, junto com os links, a IA tinha “aproveitado” para mexer em outro arquivo onde o preço estava escrito. Quem apertou o botão de permitir, sem sombra de dúvida, fui eu.

O problema não é a IA ser esperta demais. É que a linha que separa o que aprovei ontem do que eu deveria barrar hoje ficava só na minha cabeça, e mudava a cada vez. Se o “ah, deixa pra lá” depende do meu humor do dia, o acidente é só questão de tempo. Hoje vou mostrar como tirar essa linha de dentro da cabeça e transformá-la num “log de aprovações”.

Pontos principais

• As aprovações do Claude Code param de gerar hesitação quando você as divide em quatro frentes: ler, editar, executar e publicar.
• Classifique cada operação em “liberado, perguntar ou proibido”, e registre o motivo e o comando de verificação num único arquivo por dia.
• Delegue à IA o levantamento e o rascunho; o humano fica com quatro coisas: preço, publicação em produção, exclusão e qualquer ação sem volta.
• Deixei pronto um modelo de log para copiar e colar, mais um prompt para a IA rascunhar a classificação.
• Na dúvida, não marque como “liberado”. Só isso já fez o “acidente de quebra” praticamente desaparecer.

Divida a aprovação em quatro: ler, editar, executar, publicar

Usando o Claude Code, chegam confirmações de todo tipo. Como você junta tudo num único “sim ou não”, cada decisão pesa. Quando separa as tarefas em quatro categorias, julgar fica bem mais leve.

• Ler: só olhar o conteúdo de arquivos ou logs. Em geral, liberar não causa problema.
• Editar: reescrever um arquivo. Um erro de digitação no artigo pode ser tranquilo. A tabela de preços é outra história.
• Executar: rodar um comando. Conferir o funcionamento é leve, mas o que tem efeito externo pede cautela.
• Publicar: refletir no site de produção. Aqui eu trato sempre como a última linha de defesa.

Mesmo dentro de “editar”, corrigir um erro no corpo do blog e mexer no arquivo de configuração de pagamento têm pesos completamente diferentes. Por isso passei a definir não só o tipo de operação, mas também qual arquivo está em jogo, como um conjunto.

Classifique a decisão em três níveis

Depois de dividir em quatro, distribua cada uma em três níveis. Não precisa de palavras difíceis.

Nível	Significado	Exemplo
Liberado	Pode seguir sem perguntar	Ler a pasta de artigos, corrigir erro de digitação no corpo
Perguntar	Consultar uma vez antes	Editar arquivo de preço, publicar em produção
Proibido	Não fazer desta vez	Exclusão em lote de arquivos, sobrescrita forçada

O truque é um só. Se houver a menor dúvida, não coloque em “liberado”. Deixe em “perguntar” por enquanto. Depois, quando você entender que “isto é sempre seguro”, promova para “liberado”. Comece segurando todas as rédeas e só afrouxe as que comprovou serem seguras. Só de manter essa ordem, casos como o acidente de preço do começo deixam de acontecer.

Registre num arquivo por dia: o modelo de log

Tentar guardar tudo de cabeça é receita de colapso. Um arquivo por dia, anotando apenas a classificação daquele dia. O formato pode ser qualquer um, mas eu acabei chegando neste. Dá para copiar e usar direto.

{
  "data": "2026-06-07",
  "escopo": "apenas trocar corpo de artigo e roteamento de CTA",
  "ler":      { "liberado": ["site/src/content/**", "site/src/lib/gumroadProducts.ts"] },
  "editar":   { "liberado": ["novos arquivos de artigo"], "perguntar": ["preço", "config de pagamento", "secrets de produção"] },
  "executar": { "liberado": ["npm run build", "checar exibição da URL pública"], "perguntar": ["publicar", "git push"] },
  "publicar": { "perguntarAte": ["o build passa", "o h1 da URL pública está correto", "exibição de cada idioma conferida a olho"] },
  "proximaVez": "Preço continua em perguntar. Trocar roteamento de CTA pode virar liberado após verificação."
}

Escrever leva 2 ou 3 minutos. Mas esses 2 ou 3 minutos apagam os 10 minutos do dia seguinte gastos pensando “espera, o que eu fiz com isso ontem?”. A linha de escopo faz uma diferença discreta porém real. Quando você anota antes até onde vai o trabalho de hoje, percebe na hora em que a IA sai daquele limite.

O que delegar à IA e o que o humano decide

Misturar isto causa acidente. Vamos deixar a linha bem clara.

O que pode delegar à IA

• Procurar quais arquivos parecem estar relacionados
• Montar o rascunho da mudança
• Mostrar o diff de antes e depois
• Rodar o comando que confirma “se o build passa”

O que o humano precisa segurar sempre

• Mudanças que tocam em preço, pagamento ou formulário de inscrição
• A publicação no site de produção (o botão de publicar você aperta com a própria mão)
• A exclusão de arquivos ou dados
• Qualquer trabalho cuja forma de desfazer você não saiba explicar

Minha regra é simples: quando entra em jogo “dinheiro”, “produção”, “apagar” ou “sem volta”, a decisão final é sempre minha, com a própria mão. Por outro lado, todo o levantamento e o rascunho fora disso eu jogo para a IA sem cerimônia. Essa forma de traçar a linha eu também comento no guia do Claude Code para quem não é engenheiro, e mesmo sem conhecimento técnico basta decidir “só dinheiro e produção são comigo” para se proteger bem.

Prompt para a IA rascunhar a classificação

Dá para pedir à própria IA que ajude na classificação. Mas não engula o resultado de olhos fechados; no fim, você confere. É só colar o texto abaixo.

Sobre o trabalho de hoje no Claude Code, classifique as operações em "liberado, perguntar ou proibido".
Os alvos são quatro tipos: ler / editar / executar / publicar.

Para cada item, retorne:
1. A lista de operações que pode liberar
2. A lista de operações que devem passar por uma confirmação
3. A lista de operações proibidas desta vez
4. O comando de verificação para confirmar a segurança (ex.: npm run build)
5. Um memo para a próxima vez (a condição para subir de perguntar para liberado)

Operações ligadas a preço, pagamento, publicação em produção ou exclusão: na dúvida, coloque em "perguntar".

O ponto é a última linha. Com ela ali, você evita que a IA afrouxe o julgamento por conta própria, dizendo “isto pode liberar, né”. Quem quiser afinar mais a escrita de prompts pode olhar também design de prompts no Claude Code.

Onde isto funciona na prática (três casos)

1. Troca de conteúdo de um post do blog Você quer trocar só um link de inscrição que fica embaixo de um artigo popular. Nessas horas, pedir “conserta o que parecer relacionado” abre um escopo amplo demais. Anote antes no log os “arquivos que pode tocar”, os “arquivos que não pode tocar” e a “URL pública a conferir”. Aí a verificação depois do trabalho muda de “parece estar tudo bem” para “com esta prova, pode publicar”.

2. Triagem de mensagens recebidas Você deixa a IA ler as mensagens que chegaram e indicar só as que parecem promissoras. Ler pode ficar em “liberado”. Mas o cadastro na lista de clientes fica em “perguntar”. Mesmo que a IA classifique errado, ela para antes de escrever sozinha nos dados de produção.

3. Checagem antes de publicar artigos multilíngues Mesmo com a configuração de idioma correta no frontmatter, às vezes o corpo continua em inglês. Confira, em cada idioma, o título, o começo e a região do CTA, verificando se o leitor daquele idioma entende qual é o próximo passo. Fixe essa conferência a olho como “item a verificar antes de publicar” dentro do log.

Copie e rode: script de checagem do log de aprovações

Não adianta escrever o log e pular justamente a “conferência antes de publicar”. Por isso, transforme num único script a checagem que deve passar sempre antes de publicar. É um exemplo que deixa a máquina confirmar se o build passa e se o título da URL de produção está correto. Funciona se você tiver Node.js.

node check-before-deploy.mjs https://claudecode-lab.com/blog/claude-code-permission-decision-log/

O conteúdo é só isto.

import { execSync } from "node:child_process";

// confere a URL pública passada como argumento
const url = process.argv[2];
if (!url) {
  console.error("Passe a URL pública que você quer verificar");
  process.exit(1);
}

// 1. confirma se o build passa (se cair aqui, não publica)
try {
  console.log("Verificando o build...");
  execSync("npm run build", { stdio: "inherit" });
} catch {
  console.error("O build falhou. Cancelando a publicação.");
  process.exit(1);
}

// 2. confirma se a URL pública tem exatamente um título h1
const res = await fetch(url);
const html = await res.text();
const h1Count = (html.match(/<h1[\s>]/g) || []).length;

if (res.status !== 200) {
  console.error(`A URL não abre (código de status: ${res.status}). Revise a publicação.`);
  process.exit(1);
}
if (h1Count !== 1) {
  console.error(`Há ${h1Count} títulos h1. Ajuste para ficar com 1 antes de publicar.`);
  process.exit(1);
}

console.log("Build, URL e título conferidos. Pode publicar com segurança.");

Só quando este script fica verde é que eu libero a “publicação”. Dito de outra forma: o que não fica verde não é publicado, custe o que custar. O segredo é entregar a decisão ao certo/errado da máquina, e não ao humor da pessoa.

Erros comuns e como corrigir

Sendo honesto, cometi todos eles.

Mudar só a configuração sem anotar o motivo. Se você atualiza só o arquivo de configuração e não registra “por que fez assim”, o você de amanhã repete a mesma hesitação. A correção é simples: escreva uma linha de motivo no “memo para a próxima vez” do log. Algo como “preço continua em perguntar porque está ligado diretamente à confiança”.

Liberar a publicação no embalo. No embalo de o build ter passado, você acaba liberando até a publicação. Mas a conferência antes de publicar é outra coisa. Fixe em “perguntar até” os itens a olhar (título da URL de produção, quebras de exibição, exibição no celular) e não publique até a checagem da máquina passar.

Tratar tarefa leve e tarefa pesada do mesmo jeito. Se você roda no mesmo “liberado” a correção de erro no corpo e a mudança de link de inscrição ou de preço, uma hora acontece o acidente do começo. Trabalhos que tocam em links do gumroad, preço ou formulário ficam numa prateleira diferente da correção de digitação. Deixe essa linha escrita como regra em como escrever o CLAUDE.md, e você não precisa pensar nela toda vez.

Perguntas frequentes

P. Qual a diferença entre o log de aprovações e as configurações de segurança? R. As configurações de segurança fixam “o que é permitido”; o log de aprovações registra “por que aquela decisão foi tomada hoje”. A configuração é a regra, o log é mais próximo de um diário. Com os dois, o você de amanhã ou a equipe conseguem reproduzir a mesma decisão.

P. Escrever todo dia é trabalhoso. Como manter o hábito? R. Não mirar a perfeição. No começo, só as duas colunas “editar” e “publicar” já fazem efeito de sobra. Deixe num formato que você escreve em 2 ou 3 minutos e crie o hábito de colá-lo como primeira entrada antes de começar o trabalho.

P. Posso confiar na classificação que a IA propõe? R. Como rascunho é útil, mas a decisão final é do humano. Em especial nas linhas ligadas a preço, produção e exclusão, mesmo que a IA diga “pode liberar”, rebaixe para perguntar você mesmo. O objetivo é reduzir o esforço de decidir, não terceirizar a decisão em si.

P. Quais cuidados ao usar em equipe? R. Centralize o log num só lugar e, para as operações que entram em “liberado”, escreva o motivo que leva qualquer pessoa à mesma decisão. Liberação sem motivo gera interpretações diferentes entre as pessoas, e isso vira fonte de acidente. A forma de ampliar a aprovação aos poucos também aparece em como subir a autonomia com segurança.

P. Preciso de tudo isso mesmo num blog pequeno? R. Quanto menor a operação, mais direto um acidente de preço ou de link bate no faturamento. Aliás, é justamente o indivíduo ou a equipe pequena que ganha mais começando com uma única regra: “só dinheiro e produção ficam em perguntar”.

Links de referência

• Guia de permissões do Claude Code
• Guia de como começar com o Claude Code
• Oficial da Anthropic: documentação de settings do Claude Code

O que aconteceu quando testei de verdade

Mantendo este log de aprovações por umas duas semanas, o que mais surtiu efeito foi, surpreendentemente, o “trabalho leve”. A correção de digitação no artigo eu deixo tranquilo em liberado; preço, links, formulário de inscrição e configuração de publicação ficam em perguntar. Só de anotar essa distinção antes, sumiu o esforço de, depois de ler a resposta da IA, ficar repensando toda vez “isto era um trabalho que eu podia liberar?”.

A hesitação aparecia mesmo era em “executar” e “publicar”. O build pode liberar, mas publicar sem conferir a URL de produção ainda é cedo. Depois que confiro a olho o título, as quebras de exibição e a exibição no celular, consigo subir o mesmo tipo de publicação para liberado nas próximas vezes. Como os níveis vão ficando registrados, hoje minha sensação é que o log de aprovações funciona menos como um documento de segurança rígido e mais como um bilhete que torna leve a decisão de cada dia.

Se você quer organizar a linha de permissões para a sua equipe, ou acertar junto as regras de publicação em produção, dá para baixar isso a uma operação concreta em treinamentos e consultoria.