Seeders e bootstrap da plataforma
Dados de referência que se reconciliam a cada deploy e o primeiro operador de plataforma, criado uma vez só.
Os seeders padrão rodam em ordem, numa única transação, depois de conferir que o baseline está aplicado:
| Seeder | O que faz | Repetir |
|---|---|---|
CatalogSeeder | Catálogo de produtos de referência: IFs, grupos de produto, produtos, tipos de operação e ofertas, a partir de um JSON validado | Faz merge pela chave natural: rodar de novo só atualiza |
PermissionsSeeder | Projeta o registry de permissões (permissions.json, gerado dos @Requires) em permissions e permission_use_cases | Upsert por code, atualizando description e scope |
PlatformBootstrapSeeder | Cria o primeiro operador de plataforma | One-shot: não faz nada se já existe qualquer grant de plataforma |
bun run db:seed # os três seeders padrão
bun run db:seed --class DevSeeder # dados locais; recusado com NODE_ENV=productionNa imagem do migrator, o registry de permissões vem do mesmo build (MONALISA_PERMISSIONS_REGISTRY); fora dela,
rode bun run permissions:emit antes. Como o seeder de permissões atualiza permissions.scope a cada deploy, a
mudança de escopo de uma permissão passa pelo teto de escopo e é recusada se deixar
algum perfil acima do teto.
Marcar permissões removidas do código (deprecated_at), tratar renomeações (replaces_code) e registrar
permission_changes ainda não são feitos pelo seeder; ficam para a sincronização de permissões no deploy (NOVA-37).
O bootstrap da plataforma
O PlatformBootstrapSeeder cria, na mesma transação:
- a party e o usuário do operador;
- um login de plataforma do tipo username, sem tenant (
platform_logins); - uma credencial de senha, com o hash calculado a partir da variável de ambiente;
- o perfil de administração da plataforma, com as permissões de escopo
platform; - um convite de plataforma já aceito, que é a origem obrigatória do grant;
- o grant de plataforma (concedido por ele mesmo, porque não existe operador antes dele).
O bootstrap não cria tenant.
É one-shot. Se existe qualquer linha em platform_grants, ativa ou revogada, ele não faz nada e nem lê as
variáveis. Revogar o operador, trocar o username ou a senha nas variáveis, ou editar o perfil nunca recria nem
ressuscita nada; operadores seguintes vêm de convites. Um username que já foi login de plataforma é recusado em vez de
ser tomado. Nada secreto é registrado em log.
| Variável | Significa |
|---|---|
PLATFORM_BOOTSTRAP_USERNAME | Login de plataforma do primeiro operador: 1 a 64 caracteres [a-zA-Z0-9_.-] |
PLATFORM_BOOTSTRAP_PASSWORD | A senha, 1 a 1024 bytes UTF-8, de um segredo de deploy; nunca registrada em log |
PLATFORM_BOOTSTRAP_EMAIL | E-mail do convite de plataforma aceito de onde o grant nasce |
PLATFORM_BOOTSTRAP_NAME | Nome de exibição; o padrão é o username |
As três primeiras só são exigidas no primeiro deploy, num banco sem operador de plataforma: ele falha, nomeando a variável que falta, até que sejam definidas. Depois disso o bootstrap não as lê mais, então as versões seguintes podem rodar sem o segredo da senha.
Enquanto a autenticação é reconstruída, o operador existe no banco, mas não há rota de login para ele (ver Autenticação).
DevSeeder
Só para desenvolvimento: cria um tenant de exemplo, uma conta, um corretor, perfis e alguns membros com CPFs
sintaticamente válidos que não pertencem a ninguém. É opcional (--class DevSeeder) e recusado com
NODE_ENV=production.
Os seeders que procuram uma linha antes de inseri-la não são seguros contra dois db:seed simultâneos; isso é aceitável
enquanto o deploy roda um migrator por vez.