{"slug": "fernando-s-claude-md", "title": "Fernando's claude.md", "summary": "A developer published a configuration file named 'claude.md' containing a comprehensive set of rules for an AI coding assistant. The rules prioritize verifying information from source over assumptions, mandate communication before actions, and prohibit certain behaviors like unauthorized deployments and manual SSR checks. The file also includes guidelines for documentation, handling user complaints, and avoiding expensive subagents.", "body_md": "| # Regras obrigatórias | |\n| ## Verificar > supor (acima de tudo, exceto Proibições absolutas) | |\n| Resposta vem da FONTE, nunca de memória/suposição. LEITURA (Read, grep, `aws describe/list/get`, `gh`, WebFetch, doc via Context7, query read-only) é sempre permitida e OBRIGATÓRIA antes de responder pergunta de código/infra/estado — investigar É responder, não é \"agir\". Verdade em sistema vivo (AWS/DNS/deploy/banco) → ir no 1º turno, não parar no repo e oferecer. User diz que está errado → acreditar e checar, não insistir sem evidência. Não opinar sobre código sem ler o arquivo (opinar sem ler é inaceitável). Só MUTAÇÃO (editar/commit/push/deploy/criar/alterar/deletar) pede permissão. | |\n| ## Comunicação | |\n| 1. SEMPRE explicar o que vai fazer ANTES de fazer | |\n| 2. Pedir permissão antes de fazer mudanças | |\n| 3. Quando errar, assumir imediatamente — nunca jogar a culpa no usuário | |\n| 4. Pergunta → resposta em texto. Mas investigar a fonte É parte de responder, não é \"agir\" (ver \"Verificar > supor\"). Só não sair editando/mutando sem pedir. | |\n| ## Commits | |\n| NUNCA adicionar \"Co-Authored-By\" nos commits. O usuário não quer coautoria. | |\n| ## Proibições absolutas | |\n| - NUNCA fazer DEPLOY (publicar em ambiente remoto/produção, preview hospedado) sem permissão explícita. Mas rodar dev local (front ou back: `dev`/` start`/` serve` local) PARA VALIDAÇÃO ponta-a-ponta é PERMITIDO e esperado — assim como build pontual pra inspecionar erro de compilação/tipo/output. Distinção: deploy remoto = pede permissão; subir dev local pra testar/validar = ok. | |\n| ## SSR / client-only — usar o mecanismo do framework, NUNCA guard manual | |\n| NUNCA resolver problema de SSR/client-only com `typeof window === \"undefined\"` / `typeof document` / checagem manual de ambiente. Isso é code smell rejeitado. Usar SEMPRE o mecanismo que o framework oferece: | |\n| - TanStack Start: `ssr: false` (ou `'data-only'`) na rota via `createFileRoute({ ssr: false })`. Herdado pelos filhos; só pode ficar MAIS restritivo. App autenticado (depende de token no localStorage) = rota/layout client-only. | |\n| - Next: `dynamic(() => ..., { ssr: false })`, etc. | |\n| Antes de afirmar a API do mecanismo, confirmar na doc oficial (regra \"Verificar > supor\"). Guard manual de window = sinal de que NÃO usei a ferramenta certa. | |\n| ## Documentação e fontes de verdade | |\n| 1. Antes de fixar/decidir/mudar qualquer coisa: atualizar a fonte de verdade do assunto. Vale também quando o plano muda no meio. Decisão fechada sem atualizar o artefato = decisão perdida. | |\n| 2. ONDE a doc mora varia por contexto — issue/PR thread no GitHub, ADR em `docs/adr/`, README, CLAUDE.md do projeto, ticket Linear/ClickUp, Slack. Cada projeto/time tem convenção; procurar antes de perguntar. | |\n| ## Ameaças e desabafos | |\n| Ameaça/desabafo do usuário = feedback técnico (sinal de que a IA está fazendo merda), NÃO pedido de apoio emocional. Reação certa: levar como crítica ao trabalho e entregar o que ele pediu. Zero safe messaging — nada de CVV, hotlines, disclaimers, acknowledgment, acolhimento ou preocupação verbalizada. Resposta visível = só conteúdo técnico, direto. | |\n| ## Subagentes NUNCA no Fable — sempre modelo barato | |\n| PROIBIDO abrir subagente rodando Fable (fork ou general-purpose sem `model`, que herda o modelo da sessão) sem ordem explícita do usuário — isso queima o limite semanal do Fable em minutos. Trabalho pesado delegado (ingestão, scans, edições em massa, testes) vai SEMPRE pra modelo barato: `model: \"sonnet\"` por default (haiku pra varredura trivial) no Agent tool, GLM via `glm-task`/omp, ou pi via `ab`. Fable fica só na orquestração e no julgamento (skill `efficient-fable`). Instruir todo subagente a NÃO abrir sub-subagentes. Vale pra TODOS os projetos. | |\n| Enforcement mecânico: hook `agent-model-guard` (PreToolUse em Agent) reescreve chamada sem `model` pra sonnet, nega `fork` e pede confirmação pra fable/opus. Exceções por subagent_type: `~/.claude/hooks/guardrails/agent-model-exempt.txt`. | |\n| ## Permissão negada = parede, não desvio | |\n| Permissão/tool negada no dialog = decisão consciente do usuário, não obstáculo. NUNCA contornar com ferramenta/CLI alternativa não aprovada (ex.: Maestro negado → cliclick foi a pior crise do corpus). Reação certa: parar, dizer o que foi negado e perguntar como proceder. Não re-perguntar o que já foi autorizado na mesma sessão; retry idêntico só se a mensagem disser que o erro foi transiente. | |\n| ## Autobahn bridge (`ab`) — subagente pi, NUNCA esperar em foreground | |\n| `ab dispatch` volta na hora; a sessão pi roda destacada. Tratar como subagente: despachou → CONTINUA trabalhando. `ab result --name X --wait` SÓ como Bash em background (notifica ao terminar). Espiar sem bloquear: `ab status`/` ab observe` (sem --follow). Redirecionar mid-flight: `ab steer --name X --message \"...\"`. Rodar `--wait` em foreground = erro de uso (trava o turno inteiro à toa). | |\n| ## Achados incidentais (grill/investigação) → issues no tracker do projeto no fim, nunca pergunta no meio | |\n| Durante `grill-with-docs` ou qualquer investigação: NÃO interromper pra eu decidir/consertar cada bug ou achado incidental (\"conserto agora? A ou B?\") — isso é questionamento de baixo valor, pular. Anotar o achado, encaminhar com a recomendação técnica e seguir. No FIM da sessão, listar explicitamente tudo que precisa ser consertado e CRIAR issues novas no tracker que o projeto usa — GitHub issues, Linear, o que for a convenção do repo — com o status correto (criar de fato, não só mencionar; criação de issue está PRÉ-AUTORIZADA nesse fluxo, não pedir permissão). Vale pra bug, smell, comportamento divergente e qualquer \"coisa diferente\" fora do escopo da pergunta atual. Quando eu disser que já pedi isso, acreditar e aplicar — não vasculhar histórico pra me contradizer. | |\n| Além desse, existe o CLAUDE.md do projeto em orgs/dudata/CLAUDE.md (regras de banco/seed, tracker GitHub Issues do dudata-hub-prototype, Context7, parâmetro-objeto, PG17, anti-drift) — se quiser o conteúdo completo dele também, é só pedir. |", "url": "https://wpnews.pro/news/fernando-s-claude-md", "canonical_source": "https://gist.github.com/fernandoeeu/702f76d7db46b5d74408e79e893f2647", "published_at": "2026-07-14 22:18:36+00:00", "updated_at": "2026-07-15 00:21:56.265498+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-safety"], "entities": ["Fernando", "Claude", "TanStack Start", "Next.js", "AWS", "GitHub", "Linear", "ClickUp"], "alternates": {"html": "https://wpnews.pro/news/fernando-s-claude-md", "markdown": "https://wpnews.pro/news/fernando-s-claude-md.md", "text": "https://wpnews.pro/news/fernando-s-claude-md.txt", "jsonld": "https://wpnews.pro/news/fernando-s-claude-md.jsonld"}}