Registro de risco de permissões no Claude Code: decida antes do agente agir

Por que criar um artefato próprio

Este artigo cria um registro de risco de permissões para times que saem do uso individual de Claude Code para regras compartilhadas de aprovação. A falha comum é simples: o time discute permissões só depois que o agente já editou, fez deploy ou pediu comando arriscado. Um workflow com Claude Code não deve terminar em uma resposta confiante. Ele precisa deixar um artefato que outra pessoa consiga revisar. Aqui, o artefato é um registro pequeno com ação, decisão padrão, prova e owner.

Trate o artefato como contrato entre prompt, linha de comando e página pública. Ele mostra o que Claude Code leu, o que mudou, qual comando provou o resultado e qual rota de receita o leitor deve ver depois. Por isso o tema se conecta a harness engineering, getting started e permissions.

O loop operacional

Rode o loop em cinco passos: definir a ação, escolher a prova, deixar Claude Code fazer o menor trabalho útil, verificar a saída e registrar a próxima ação de receita. Aqui, prova útil não é só “o código rodou”. Observe contagem de aprovações, comandos negados, rollback notes, prova de deploy e intenção de consultoria. Com esses campos visíveis, a melhoria deixa de ser chute.

1. Mapeamento read-only do repo pode ser permitido se a nota final listar o que foi lido.

2. Edições de conteúdo podem ser permitidas quando diff review, build e URL pública são obrigatórios.

3. Secrets, billing, dados de clientes e force push continuam com aprovação do owner mesmo se o agente acertar.

Starter para copiar

permission_risk_register:
  - action: "read repository files"
    default: "allow"
    proof: "list files read in the final note"
  - action: "edit content files"
    default: "allow after diff review"
    proof: "build passes and URL matches the slug"
  - action: "deploy production"
    default: "ask first"
    proof: "build log, deploy URL, rollback note"
  - action: "touch secrets or billing"
    default: "never without owner approval"
    proof: "human approval id"

Três exemplos práticos

Exemplo 1. Mapeamento read-only do repo pode ser permitido se a nota final listar o que foi lido.

Exemplo 2. Edições de conteúdo podem ser permitidas quando diff review, build e URL pública são obrigatórios.

Exemplo 3. Secrets, billing, dados de clientes e force push continuam com aprovação do owner mesmo se o agente acertar.

Checklist de auto-revisão

Antes de transformar este workflow em hábito, revise o artigo como uma nota de release. O primeiro controle é escopo: o leitor precisa saber quando usar um registro de risco de permissões e quando um checklist menor basta. O segundo controle é prova: cada recomendação deve apontar para comando, URL, diff ou métrica. O terceiro controle é routing: PDF grátis, guia Gumroad e consultoria não devem competir, mas responder a urgências diferentes.

Use uma regra pequena de ownership. Uma pessoa cuida do artefato, outra da verificação e outra do próximo experimento de CTA. Em operação solo pode ser a mesma pessoa, mas os papéis ainda devem aparecer na nota. Isso impede Claude Code de misturar publicação, medição e venda em uma tarefa vaga. A próxima execução também sabe de onde continuar.

A pergunta prática é: o que tornaria este artigo mais fácil de verificar amanhã cedo? Se for screenshot, salve. Se for um prompt melhor, coloque no prompt pack. Se for uma fronteira mais clara, registre nas notas de setup. um registro pequeno com ação, decisão padrão, prova e owner só é útil quando sobrevive à próxima sessão.

Falhas comuns

A primeira falha é usar pageviews como único score. A segunda é aprovar mudança sem comando de prova. A terceira é mandar todo leitor para o mesmo produto pago quando PDF grátis ou consultoria seria melhor. Escreva a regra de routing antes de mexer no CTA.

Rota de receita

Direcione pelo gargalo. Se falta fluência em comandos, envie para o PDF gratuito ou cheatsheet grátis no Gumroad. Se o trabalho se repete toda semana, use 50 Prompt Templates ou Setup Guide. Se o problema é rollout, risco ou receita, use consultoria. Neste artigo, Setup Guide dá a base de policy, e consultoria ajuda quando produção ou receita dependem de aprovação.

Métricas de verificação

Depois de publicar, HTTP 200 não basta. Confirme h1, canonical, hero image, abertura do texto, links CTA, mobile layout e idioma. Depois acompanhe contagem de aprovações, comandos negados, rollback notes, prova de deploy e intenção de consultoria. Se a métrica não mexer, ajuste o CTA perto do primeiro exemplo concreto.