Fernando's claude.md

| # Regras obrigatórias | | | ## Verificar > supor (acima de tudo, exceto Proibições absolutas) | | | 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. | | | ## Comunicação | | | 1. SEMPRE explicar o que vai fazer ANTES de fazer | | | 2. Pedir permissão antes de fazer mudanças | | | 3. Quando errar, assumir imediatamente — nunca jogar a culpa no usuário | | | 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. | | | ## Commits | | | NUNCA adicionar "Co-Authored-By" nos commits. O usuário não quer coautoria. | | | ## Proibições absolutas | | | - 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. | | | ## SSR / client-only — usar o mecanismo do framework, NUNCA guard manual | | | 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: | | | - 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. | | | - Next: dynamic(() => ..., { ssr: false }), etc. | | | 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. | | | ## Documentação e fontes de verdade | | | 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. | | | 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. | | | ## Ameaças e desabafos | | | 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. | | | ## Subagentes NUNCA no Fable — sempre modelo barato | | | 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. | | | 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. | | | ## Permissão negada = parede, não desvio | | | 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. | | | ## Autobahn bridge (ab) — subagente pi, NUNCA esperar em foreground | | | 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). | | | ## Achados incidentais (grill/investigação) → issues no tracker do projeto no fim, nunca pergunta no meio | | | 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. | | | 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. |