CCA-F Cenário 2 na prática: um CLAUDE.md que decide o plan mode por você

Segundo artigo da série de 6 partes sobre os cenários do CCA-F — código-fonte completo de cada cenário: aicert-labs.

O cenário, como está no exam guide

Um time usa Claude Code para geração de código, refactoring, debugging e documentação, com slash commands customizados e um CLAUDE.md, decidindo entre plan mode e execução direta.

Domínio	Peso	Onde aparece neste cenário
Claude Code Configuration & Workflows	20%	Convenções de time no CLAUDE.md e três slash commands customizados, cada um com um nível de risco diferente
Context Management & Reliability	15%	Um CLAUDE.md deliberadamente curto — um arquivo longo e desatualizado já é, em si, uma falha de context management

"Use plan mode pra mudanças arriscadas" não é uma decisão

Essa instrução só reformula o problema. O que é arriscado? Sem definição, isso vira responsabilidade de quem estiver rodando a sessão naquele dia, usando o julgamento que tiver à mão. Dois engenheiros no mesmo time vão traçar a linha em lugares diferentes, e nenhum dos dois está errado — nunca existiu uma definição compartilhada pra estar errado sobre ela.

O CLAUDE.md de referência no aicert-labs troca a instrução vaga por uma tabela explícita: o raio de impacto de um arquivo — único, módulo compartilhado, legado, schema — mapeia para um modo. Não é dificuldade, não é como o engenheiro se sente em relação à mudança. É raio de impacto.

A mudança toca...	Modo
Um único arquivo, não importado em nenhum outro lugar	Execução direta
Um arquivo importado por 3+ módulos, ou src/shared/	Plan mode obrigatório
src/legacy/	Plan mode obrigatório, o plano precisa dizer o que não foi verificado
Schema de banco de dados	Plan mode obrigatório, sempre

Os comandos são a fiscalização, não a tabela

Uma tabela num arquivo markdown ainda é só uma tabela que alguém precisa lembrar de consultar. O projeto de exemplo transforma isso em três slash commands que carregam seu próprio nível de risco:

• /fix-bug é execução direta, mas o próprio corpo do comando instrui a recusar e redirecionar pra /refactor-safely se o fix não estiver mesmo confinado a um único arquivo.
• /refactor-safely recebe a instrução explícita: se não foi invocado em plan mode, pare e diga ao usuário pra rodar de novo em plan mode. Ele não prossegue "com cuidado" — ele não prossegue.
• /document é execução direta, mas proibido de tocar em lógica, pra um comando de documentação não virar um refactor silenciosamente.

Pra tornar a regra de raio de impacto concreta em vez de hipotética, o exemplo tem src/shared/format-currency.ts genuinamente importado por três arquivos de rota. Peça pro /refactor-safely mudar esse arquivo, e a primeira coisa que ele precisa fazer — segundo suas próprias instruções — é enumerar os três importadores antes de propor qualquer coisa.

Duas camadas independentes, não uma só

CLAUDE.md e os comandos atuam no nível do prompt — moldam o que o Claude decide fazer. .claude/settings.json adiciona uma camada que não depende do modelo ler nada corretamente: um hook PostToolUse que roda o linter depois de cada edição, e uma lista de negação de permissões que bloqueia git push --force e rm -rf de forma incondicional, independente do que qualquer prompt diga. É o mesmo princípio do process_refund do Cenário 1: colocar a restrição onde ela não pode ser contornada por argumento, não só onde é provável que seja seguida.

Rode você mesmo

git clone https://github.com/AICERT-STUDY/aicert-labs
cd aicert-labs/cca-f/scenario-2-claude-code-workflows/example-project
npm install && npm test && npm run lint

Depois abra a pasta no Claude Code e teste /document src/shared/format-currency.ts, /fix-bug e /refactor-safely — o README tem comandos exatos pra testar, incluindo um que deve fazer o Claude enumerar os três importadores antes de tocar em qualquer coisa.

Teste seus conhecimentos

1. Por que a tabela de raio de impacto do projeto de exemplo se baseia em quais arquivos um módulo toca, em vez do tamanho ou complexidade da mudança?

Resposta: porque complexidade é subjetiva e inconsistente entre engenheiros, enquanto "importado por 3+ módulos" é um fato que dá pra checar com um grep.

Uma regra que depende de julgamento reintroduz exatamente a ambiguidade que a tabela existe pra eliminar. Uma regra baseada num fato verificável produz a mesma resposta independente de quem — ou o quê — está avaliando.

2. Qual a diferença funcional entre colocar uma regra no CLAUDE.md e aplicá-la via hooks e permissions do .claude/settings.json?

Resposta: o CLAUDE.md molda o que o modelo decide fazer; hooks/permissions do settings.json rodam independente da decisão do modelo.

Uma regra no CLAUDE.md só vale se o modelo ler e seguir corretamente em cada turno relevante. Um hook ou uma lista de negação de permissões executa de qualquer forma — é o mesmo padrão de "a tool garante, não o prompt" do resultado tipado needs_escalation do Cenário 1.

3. As instruções do /fix-bug dizem pra redirecionar pro /refactor-safely em certas condições. Por que colocar essa lógica dentro do comando em vez de simplesmente confiar que o engenheiro vai escolher o comando certo?

Resposta: porque o engenheiro que invoca o comando é exatamente quem pode errar o julgamento do raio de impacto — o comando é uma segunda checagem, não uma redundante.

Se escolher o comando certo fosse confiável por si só, a tabela de raio de impacto nem seria necessária de início. O redirecionamento é uma rede de segurança pro caso que a tabela existe pra proteger.

4. Por que o CLAUDE.md diz explicitamente pra mantê-lo curto, chamando um arquivo longo de "falha de Context Management"?

Resposta: um CLAUDE.md longo compete por orçamento de contexto com a tarefa em si, e conteúdo raramente relevante pra uma dada tarefa empurra pra fora conteúdo que é relevante.

Isso mapeia diretamente pro domínio Context Management & Reliability: o que entra em contexto persistente, sempre carregado, precisa justificar seu espaço a cada sessão, não só uma vez quando foi escrito.

5. O comentário em src/legacy/reconcile.ts diz que três outros serviços dependem do comportamento de arredondamento não documentado dele. Que risco relevante pro CCA-F documentar isso no próprio arquivo endereça?

Resposta: evita que o conhecimento tribal se perca quando a pessoa que sabia disso sair — e coloca a informação exatamente onde um agente (ou uma pessoa nova) que mexer nesse arquivo vai realmente ler.

Restrições não documentadas que vivem só na cabeça de uma pessoa são um risco de confiabilidade no momento em que essa pessoa não está disponível. Escrever a restrição no ponto de contato é o que a torna duradoura.

Simulado gratuito do CCA-F, cobrindo os 5 domínios: aicert.study/certifications/ccaf.