Seed de Dados
O mecanismo de seed popula o banco de dados (D1 no backend e SQLite WASM no frontend) com dados de demonstração assim que a aplicação é acessada pela primeira vez em ambientes de desenvolvimento. Em produção, o seed é completamente desabilitado — todos os dados são reais, cadastrados pelos próprios usuários.
v0.54.0: Guard
ENVIRONMENT— o seed só roda seENVIRONMENT != 'production'(backend) eDEPLOY_ENV != 'prod'(frontend). Um deploy comNODE_ENV=productionautomaticamente desabilita o seed.
O seed cria 5 usuários com papéis distintos e senha compartilhada senha123: admin@neemias.local (ADMIN), chamador@neemias.local (CHAMADOR), relatorios@neemias.local (RELATORIOS), cadastro@neemias.local (CADASTRO), e um usuário multi-role com CHAMADOR + RESPONSAVEL simultâneos (v0.56.0+). Cada um possui o conjunto de permissões definido pelo sistema de RBAC (packages/permissions), permitindo testar os diferentes níveis de acesso logo após a inicialização.
Além dos usuários, o seed insere 500 estudantes com nomes realistas (combinação de ~100 nomes e ~50 sobrenomes brasileiros), avatares via DiceBear (estilo micah, conservador, determinístico), dados de responsável, telefones, endereços completos, alergias, necessidades especiais e campos sociodemográficos completos (estrutura familiar, vulnerabilidade econômica, violência doméstica, situação escolar, etc.). São criadas 7 turmas (Berçário, Maternal, Jardim de Infância, Infantil, Juniores 1, Juniores 2, Pré-Adolescentes) com distribuição em curva sino (mais alunos nas turmas intermediárias) e 20 núcleos (14 na região Azul Celeste com crianças, 1 em cada uma das outras 6 regiões). O seed gera eventos de presença baseados em personas (consistente 60%, esporádico 25%, em risco 10%, crônico 5%) com efeito sazonal (queda de 15% na 4ª semana de cada ciclo), distribuídos em 4 slots de turma (Terça-feira 20h, Sexta-feira 19h30, Domingo 9h, Domingo 19h) com sessões pré-calculadas para as últimas 8 semanas (56 dias).
A geração de dados é feita pelo pacote compartilhado @neemias/seed-data (packages/seed-data/), garantindo que frontend (SQLite WASM) e backend (D1) produzam dados idênticos a partir das mesmas funções puras.
O controle de ambiente é feito pela variável DEPLOY_ENV (ou VITE_DEPLOY_ENV no frontend). O frontend (app/src/modules/_dev/seed.ts) verifica se __DEPLOY_ENV__ === "prod" e aborta o seed nesse caso; caso contrário, popula o IndexedDB local via Dexie. O backend expõe o endpoint POST /api/v1/_seed (disponível apenas em desenvolvimento), que insere os mesmos dados diretamente no D1 da Cloudflare. Esse endpoint possui uma guarda de idempotência: se a tabela users já contiver registros, retorna HTTP 409 (ALREADY_SEEDED), evitando duplicação acidental.
O disparo é automático no primeiro acesso (frontend) ou sob demanda via chamada HTTP (backend). Para acionar o seed do backend manualmente, basta enviar um POST para /api/v1/_seed com o Worker rodando localmente (wrangler dev). A senha padrão pode ser alterada pela variável de ambiente SEED_PASSWORD no wrangler.toml ou .dev.vars.
⚠️ Seção em expansão.
Fonte: workers/src/routes/seed.ts e app/src/modules/_dev/seed.ts