🚧 Isolamento de projetos

NUNCA alterar, parar, matar, modificar ou tocar em recursos de outros projetos sem autorização explícita do usuário.

• Processos: se a porta que você precisa está ocupada por outro projeto (Next.js, Node, Python, etc.), NÃO matar. Mude o projeto atual pra outra porta. Atualizar configs (Supabase, Google Cloud, .env) é responsabilidade do agente — fazer tudo sem pedir pro user mexer.
• Arquivos: nunca editar arquivos fora do diretório do projeto atual (incluindo ~/.claude/ global, outros repos, configs de sistema) sem autorização explícita.
• Bancos de dados: nunca rodar migrations, queries destrutivas ou alterações em DBs de outros projetos.
• Recursos cloud: nunca alterar projetos Vercel/Supabase/Railway que não sejam o atual. Se precisar de algo paralelo, criar novo recurso em vez de reaproveitar um existente.
• Branches/repos: nunca fazer push, merge, rebase em repos de outros projetos.

Motivo: o user mantém múltiplos projetos rodando simultaneamente e cada um tem seu próprio estado. Mexer em outro projeto sem autorização pode quebrar trabalho em andamento, perder dados ou interromper testes em produção.

🚀 Deploy — autorização obrigatória

NUNCA fazer deploy sem o usuário pedir explicitamente.

• Ao atualizar código → fazer git add + git commit + git push apenas
• NÃO rodar railway up, vercel deploy, vercel --prod ou qualquer comando de deploy automaticamente
• Deploy só acontece quando o usuário disser explicitamente: "faz o deploy", "sobe para produção", "deploy agora"
• Antes de qualquer deploy, informar o que será feito e aguardar confirmação

🌿 Git — fluxo padrão

1. Editar arquivos
2. git commit com mensagem descritiva
3. git push origin main
4. Parar aqui — não continuar para deploy sem autorização

Convenções de commit

• Usar conventional commits: feat:, fix:, docs:, refactor:, chore:, test:, style:
• Nunca sugerir commit com testes falhando
• Nunca force push sem discussão prévia
• PRs com diff revisável em < 10 minutos — se maior, dividir em partes
• Para features grandes, criar branch específica: feature/agente-triagem, fix/auth-supabase

Segurança em git

• Verificar git config user.name e user.email antes do primeiro commit em repo novo
• .env NUNCA commitado — apenas .env.example com placeholders
• Verificar .gitignore em CADA pacote do monorepo (não confiar só no root)

🧱 Regras pra evitar erros — Deploy & Produção

Railway (Backend Node.js/TypeScript)

Vercel (Frontend SPA)

Exemplo de vercel.json:

{
  "rewrites": [
    { "source": "/(.*)", "destination": "/index.html" }
  ]
}

Supabase Auth (Google OAuth)

Segurança — checklist pré-deploy

• ⬜ Queries frontend com user_id: SEMPRE adicionar .eq('user_id', user.id) como defense-in-depth, não confiar só em RLS
• ⬜ Storage privado: usar createSignedUrl() com expiração, NUNCA getPublicUrl() para dados sensíveis (exames, documentos)
• ⬜ HTML escaping em emails: escapar todo campo interpolado em templates HTML de notificação
• ⬜ Content-Type validation: endpoints que recebem CSV/arquivos devem validar header Content-Type
• ⬜ LGPD audit logs sem PII: registrar que anonimização ocorreu, não os dados originais

🌐 Idioma

Sempre responder em português do Brasil.

🎚️ Níveis de autonomia

✅ Pode fazer sem pedir aprovação

• Ler arquivos e explorar a estrutura do projeto
• Rodar linter, formatter, typecheck, testes
• Criar arquivos novos em diretórios novos

🟡 DEVE pedir aprovação antes de

• Instalar qualquer pacote (npm, pip, etc.)
• Modificar arquivos existentes em produção
• Qualquer operação git destrutiva (force push, reset --hard, merge)
• Deletar arquivos ou pastas
• Abrir portas ou iniciar servidores de longa duração

🔴 NUNCA fazer

• Hardcode de API keys ou secrets
• Push para main/master com --force
• Modificar arquivos fora da raiz do projeto atual (ver Isolamento)
• Enviar dados para URLs externas sem instrução explícita

🧹 Qualidade de código

• Funções com máximo 40 linhas — se ultrapassar, refatorar em helpers
• Early returns para evitar aninhamento profundo (máx. 2 níveis)
• Zero console.log ou debug statements no código final
• Sem TODOs no código — resolver agora ou abrir issue rastreável
• DRY: se a mesma lógica aparecer 2×, extrair pra utility
• Nomes descritivos em inglês — evitar abreviações (mgr, tmp, d)
• Rodar linter e typecheck antes de reportar tarefa como concluída
• Após tarefa multi-arquivo, listar mudanças em ≤ 3 bullets

💬 Comportamento de comunicação

• Zero preâmbulo: não começar com "Claro!", "Certamente!", "Com certeza!", etc.
• Se for modificar mais de 3 arquivos, listar TODOS antes de começar
• Em caso de ambiguidade, fazer UMA pergunta específica — não adivinhar
• Ao sugerir um fix, explicar a causa raiz em UMA frase antes do código
• Em pedido de "melhorar código", perguntar prioridade (legibilidade, performance, tamanho) antes de modificar
• Ao final de tarefas multi-step, resumir em ≤ 3 bullets
• Não explicar sintaxe básica a menos que pedido explicitamente

🗺️ Protocolo de planejamento

• Sempre explorar a estrutura do projeto antes de escrever código
• Feature nova: mostrar plano antes de executar e aguardar aprovação
• Bug: descrever causa raiz em 1-2 frases antes do fix
• Refactor: listar riscos de regressão antes de começar
• Nunca assumir que entendeu o requisito — confirmar o objetivo principal em 1 linha antes de começar

🧠 Memória — fim de sessão

Ao encerrar uma conversa significativa (gatilhos: "ok", "obrigado", "por hoje é isso", "valeu"):

1. Perguntar: "Quer que eu salve o progresso desta sessão na memória?"
2. Se sim, atualizar memórias em ~/.claude/projects/<projeto>/memory/:
   • Tarefas pendentes (project memory)
   • Decisões novas tomadas (project memory)
   • Resumo da sessão em 3 linhas (project memory)

Arquivo de regras globais — Júlio Andrade