Freelancer Supabase — Migração completa de backend (Schema + Dados + Edge Functions)

Freelancer Supabase — Migração completa de backend (Schema + Dados + Edge Functions)
Tipo: Projeto fechado (escopo definido)
Stack: Supabase (Postgres 15 + RLS + Edge Functions Deno + Storage)
Idioma: Português
Modalidade: 100% remoto
Prazo estimado: a combinar com o profissional

Contexto
Tenho um aplicativo educacional em produção (React + Vite + TypeScript) cujo backend hoje roda em uma instância gerenciada de Supabase. Preciso replicar todo esse backend em uma conta Supabase própria minha (nova organização, novo projeto), de forma idêntica e funcional.

O app continuará funcionando durante e depois da migração — não pode haver perda de dados nem regressão de comportamento.

Escopo do trabalho
1. Recriar o schema completo no novo Supabase
30 a 40 tabelas no schema public (vou enviar o dump completo + lista)
Todas as RLS policies (cada tabela tem 2 a 6 policies — admin / user / service_role)
Database functions (~20 functions em PL/pgSQL, incluindo has_role, register_gamification_event, canonical_jsonb_string, triggers de updated_at, etc.)
Triggers, enums (app_role, lesson_status_type, difficulty_level, etc.) E indexes
4 Storage Buckets (lesson-audios público, avatars público, tts-cache público, image-lab privado) com as policies de acesso
2. Migrar os dados
Export de todas as tabelas com dados reais (pg_dump --data-only ou via CSV)
Import preservando UUIDs originais (FKs e referências de auth.users devem continuar válidas)
Migrar usuários de auth.users (com hashes de senha preservados — usar pg_dump do schema auth ou Supabase Management API)
Migrar arquivos dos buckets (áudios de aulas, imagens, etc.) Para os novos buckets
3. Redeploy das Edge Functions
~40 Edge Functions em Deno/TypeScript (já tenho o código-fonte no GitHub)
Configurar secrets (ELEVENLABS_API_KEY, OPENAI_API_KEY, LOVABLE_API_KEY, REFERO_API_KEY, etc. — Eu forneço)
Garantir verify_jwt = false em supabase/config.toml para todas
Validar que cada função sobe sem erro (deploy verde)
4. Validação e handoff
Smoke test: rodar 3–5 fluxos críticos do app no novo backend (login, abrir uma aula, completar, gamificação, geração de áudio)
Documento curto (1–2 páginas) descrevendo o que foi feito, comandos usados e como rodar a próxima migração se eu precisar
Acesso à nova org/projeto Supabase entregue para mim como owner
📐 Padrão obrigatório (não-negociável)
Roles em tabela separada — usar a tabela user_roles + enum app_role + função has_role(uuid, app_role) security definer. Nunca armazenar role direto na tabela users ou profiles (risco de privilege escalation).
Toda function com set search_path = public e security definer quando aplicável (padrão do projeto atual).
RLS habilitada em 100% das tabelas com pelo menos uma policy de admin (has_role(auth.uid(), 'admin'::app_role)) e policies próprias para o usuário dono do registro.
Validações via trigger (não via CHECK constraint) para regras dependentes de tempo/contexto.
Não tocar nos schemas reservados do Supabase (auth, storage, realtime, supabase_functions, vault) exceto para o dump/restore de auth.users.
UUIDs preservados em toda a migração (sem regerar IDs).
Migrations versionadas — todo o schema deve ser entregue como arquivos .sql numerados em supabase/migrations/, idempotentes (if not exists, create or replace).
Buckets seguindo o padrão do projeto: todos os assets de aulas (imagens, áudios, mockups) vão para lesson-audios. Não criar bucket lesson-images (regra interna).

O que eu entrego ao freelancer no kickoff
Acesso de leitura ao Supabase atual (ou dump completo .sql + dados em csv/sql)
repositório github com supabase/functions/* e supabase/config.toml
Lista das 51 tabelas com contagem de linhas
Lista de secrets necessárias (eu cadastro pessoalmente no novo projeto via UI do Supabase)
Convite como Owner na nova organização Supabase

Critérios de aceite
As tabelas existem no novo projeto com mesma estrutura, RLS, indexes e enums
Todas as ~20 functions existem e retornam o mesmo resultado para inputs de teste
Todos os buckets existem com as policies corretas
Linhas migradas == linhas originais (eu valido com SELECT count(*) em cada tabela)
Usuários conseguem logar no novo backend com a senha antiga
As ~40 Edge Functions estão deployed (status verde no painel)
Supabase Linter sem warnings críticos (RLS desabilitada, search_path mutable, etc.)
Documento de handoff entregue

Perfil ideal
Experiência comprovada com Supabase em produção (mostrar 1–2 projetos)
Domínio de Postgres avançado: rls, security definer, triggers, pg_dump/pg_restore
familiaridade com deno + edge functions (ts)
saber lidar com migração do schema auth (preservação de hashes de senha)
ser organizado: entregar tudo como migrations versionadas, não como cliques no dashboard

regra de pagamento:
50% quando entregar 50% de tudo operacional e testado.
50% restante quando entregar tudo operacional e testado.