Protocolo de migração

Se você tem arquivos do trabalho da empresa na sua máquina (código, docs, scripts, etc.), eles precisam migrar pro repo com cuidado. Seguir esse protocolo evita 4 problemas clássicos:

1. PR de 5000 linhas que ninguém revisa
2. Credenciais vazadas no histórico
3. Pasta com 2GB de lixo junto
4. Apagar local antes de ter certeza que subiu

Regra de ouro

1 sub-projeto = 1 PR.

Cada pasta top-level que você migra vira um Pull Request separado. Fred revisa, aprova, merge. Aí passa pro próximo.

Protocolo — 5 passos

Passo 1 — Inventário

Antes de subir nada, faz uma lista do que tem localmente:

• Pastas e arquivos relacionados à empresa
• Separar: código vs docs vs scripts vs dados
• O que é rascunho vs oficial
• O que é teu (pessoal) vs da empresa

Manda essa lista pro Fred. Juntos decidem:

• ✅ O que entra no repo (time da empresa)
• 📦 O que vai pro teu espaço pessoal
• 🗑️ O que vai pro lixo

Passo 2 — Validar credenciais antes do Git

Dentro da pasta que você vai migrar, roda:

grep -rE "(api[_-]?key|secret|password|token|bearer)" . 2>/dev/null

Se achar qualquer coisa que pareça credencial:

1. Move pra arquivo .env:

   API_KEY=valor_real_aqui

2. Adiciona .env em .gitignore:

   echo ".env" >> .gitignore

3. Valida:

   git check-ignore .env  # deve retornar ".env"

⚠️ Credencial vazada no Git = rotação imediata. Mesmo se apagar, fica no histórico.

Passo 3 — Estrutura antes de conteúdo

Antes de popular, define com Fred a estrutura de pastas do repo.

1. Chama Fred no Gather/Telegram
2. Diz quais sub-projetos você acha que precisa
3. Alinham nomes + estrutura + README inicial
4. Você cria as pastas vazias com README.md e CLAUDE.md em cada
5. Abre PR só com estrutura (sem conteúdo ainda)
6. Fred aprova
7. Agora pode migrar sub-projeto por sub-projeto

Passo 4 — Migrar um sub-projeto por vez

Ordem recomendada:

• Começa pelo sub-projeto que você conhece melhor
• Evita o que tá “meio quebrado” — arruma depois de migrado
• Evita o que depende de outros — migra dependências primeiro

Pra cada sub-projeto:

migrate/1bmg-claimradar

cd ~/ventures/emotion-studios/<empresa>
git checkout -b migrate/<empresa>-<subprojeto>
# Copia os arquivos locais pra dentro da pasta do sub-projeto
cp -r ~/onde-estava/claimradar/* ./claimradar/

git status                  # confere o que vai entrar
git add .
git diff --cached           # última conferida antes do commit
git commit -m "migra claimradar do local pro repo. YouTube claims scanner operacional"
git push origin migrate/<empresa>-<subprojeto>
gh pr create --title "Migra claimradar" --body "..."

Template de PR de migração

## O que é
<1-2 linhas>

## O que está migrado
- Pasta X com N arquivos
- Script Y que faz Z

## Dependências externas
- API X (key em .env)
- Serviço Y

## Status atual
- ✅ Operacional / ⏸️ Pausado / 🔴 Quebrado

## Próximos passos (depois do merge)
- <o que você vai fazer depois>

Depois de abrir PR, chama Fred no Gather/Telegram avisando.

Passo 5 — Só após merge, delete o local

Nunca delete arquivo da máquina antes de confirmar que subiu:

1. Espera PR ser mergeado
2. Faz git pull no main
3. Confirma que tá tudo no repo
4. Só aí pode deletar cópia local

Ainda mais seguro: mantenha backup em Drive pessoal por 30 dias. Zero risco.

Não começa sozinho

Antes de migrar qualquer coisa, chama Fred. O processo é conversacional:

1. Inventário você faz sozinho
2. Manda pro Fred
3. Alinham estrutura
4. Você executa passo a passo, PR por PR

Estrutura ruim no começo custa caro depois. Alinhe uma vez, flua sozinho.

Próximo

→ Organização por sub-projeto.