Initial project import
This commit is contained in:
Tiago
@@ -0,0 +1,82 @@
|
||||
# Prompt 02 — Migrations do `db_master`
|
||||
|
||||
## Contexto
|
||||
O Prompt 01 já entregou: projeto Java rodando em Docker, `HttpServer` no ar, `MigrationRunner` pronto pra rodar arquivos `.sql`, `DataSourceProvider` com conexão ao `db_master`. **Leia o tracker (`10-tracker-progresso.md`) antes de começar** para confirmar que o Prompt 01 está marcado como concluído.
|
||||
|
||||
Este prompt cria todo o schema do banco de catálogo (`db_master`): empresas, funcionários, planos, funcionalidades, financeiro (assinaturas/pagamentos), logs.
|
||||
|
||||
## Objetivo
|
||||
Criar os arquivos de migration SQL em `src/main/resources/migrations/master/`, rodá-los automaticamente na subida da aplicação (se `db_master` ainda não tiver as tabelas), e criar as classes Java de acesso a dados (DAO) básicas para essas tabelas — sem endpoints HTTP ainda (isso vem no Prompt 05).
|
||||
|
||||
## Especificação
|
||||
|
||||
### 1. Migrations (uma tabela por arquivo, numeração sequencial)
|
||||
Criar em `src/main/resources/migrations/master/`:
|
||||
- `001_empresas.sql`
|
||||
- `002_funcionarios.sql`
|
||||
- `003_api_keys.sql`
|
||||
- `004_funcionalidades.sql`
|
||||
- `005_empresa_funcionalidades.sql`
|
||||
- `006_evolution_instancias.sql`
|
||||
- `007_configuracoes_plataforma.sql`
|
||||
- `008_planos.sql`
|
||||
- `009_plano_funcionalidades.sql`
|
||||
- `010_assinaturas.sql`
|
||||
- `011_periodos_uso.sql`
|
||||
- `012_pagamentos.sql`
|
||||
- `013_logs_envio_avisos.sql`
|
||||
- `014_lembretes_cobranca.sql`
|
||||
- `015_seed_funcionalidades.sql` (INSERT do catálogo — ver abaixo)
|
||||
|
||||
Usar exatamente o DDL do documento de arquitetura v3.0 (seção 1), tabela por tabela — não inventar colunas novas. Reproduzo aqui as tabelas que essa fase cria (copie fielmente, incluindo tipos e defaults):
|
||||
|
||||
- `empresas(id, nome, cnpj, slug, database_name, status, criado_em)`
|
||||
- `funcionarios(id, empresa_id, nome, email, senha_hash, cargo, status, criado_em)`
|
||||
- `api_keys(id, empresa_id, key_hash, descricao, ativa, criado_em, revogada_em)`
|
||||
- `funcionalidades(id, chave, nome, descricao)`
|
||||
- `empresa_funcionalidades(empresa_id, funcionalidade_id, ativa, liberado_em, liberado_por)` — PK composta
|
||||
- `evolution_instancias(id, empresa_id, instance_url, instance_token_enc, numero_whatsapp, status, solicitado_em, aprovado_em, aprovado_por)`
|
||||
- `configuracoes_plataforma(chave, valor, atualizado_em)` — PK = chave
|
||||
- `planos(id, nome, valor_mensal_centavos, descricao, ativo, criado_em)`
|
||||
- `plano_funcionalidades(plano_id, funcionalidade_id)` — PK composta
|
||||
- `assinaturas(id, empresa_id, plano_id, valor_mensal_centavos, dia_vencimento, status, criado_em)`
|
||||
- `periodos_uso(id, empresa_id, mes_referencia, status, data_liberacao, data_bloqueio)` — UNIQUE(empresa_id, mes_referencia)
|
||||
- `pagamentos(id, empresa_id, periodo_uso_id, valor_centavos, abacatepay_charge_id, qr_code_payload, qr_code_base64, status, criado_em, pago_em)`
|
||||
- `logs_envio_avisos(id, empresa_id, condominio_id, aviso_id, contato_id, contato_nome, canal, status, erro_detalhe, criado_em)`
|
||||
- `lembretes_cobranca(id, empresa_id, periodo_uso_id, canal, enviado_por, criado_em)`
|
||||
|
||||
Seed (`015_seed_funcionalidades.sql`): usar o catálogo completo (MVP + Fase 2) da seção 6 do documento de arquitetura v3.0 — 24 chaves MVP + 6 chaves Fase 2. Copiar os `INSERT INTO funcionalidades` literalmente.
|
||||
|
||||
### 2. Índices recomendados
|
||||
Adicionar (na própria migration de cada tabela, ou em um `016_indices.sql`):
|
||||
```sql
|
||||
CREATE INDEX idx_funcionarios_empresa ON funcionarios(empresa_id);
|
||||
CREATE INDEX idx_api_keys_empresa ON api_keys(empresa_id);
|
||||
CREATE INDEX idx_evolution_empresa ON evolution_instancias(empresa_id);
|
||||
CREATE INDEX idx_assinaturas_empresa ON assinaturas(empresa_id);
|
||||
CREATE INDEX idx_periodos_uso_empresa ON periodos_uso(empresa_id);
|
||||
CREATE INDEX idx_pagamentos_empresa ON pagamentos(empresa_id);
|
||||
CREATE INDEX idx_pagamentos_periodo ON pagamentos(periodo_uso_id);
|
||||
CREATE INDEX idx_logs_envio_empresa ON logs_envio_avisos(empresa_id, status);
|
||||
```
|
||||
|
||||
### 3. Rodar migrations na subida
|
||||
No `Main.java`, após confirmar conexão com `db_master`, chamar `MigrationRunner.runMigrations(masterConnection, "migrations/master")`.
|
||||
|
||||
### 4. DAOs básicos (sem endpoints ainda)
|
||||
Criar em `com.seconectai.condocontab.master.dao`:
|
||||
- `EmpresaDao` (métodos: `inserir`, `buscarPorId`, `listarTodas`, `atualizarStatus`)
|
||||
- `FuncionarioDao` (`inserir`, `buscarPorEmail`, `listarPorEmpresa`)
|
||||
- `FuncionalidadeDao` (`listarTodas`, `buscarPorChave`)
|
||||
|
||||
Usar JDBC puro (`PreparedStatement`), sem ORM. Todo valor monetário como `long` (centavos) no Java.
|
||||
|
||||
## Critérios de aceite
|
||||
- [ ] `docker compose up` roda as 15 migrations em ordem, sem erro, na primeira subida.
|
||||
- [ ] Subir o container uma segunda vez NÃO tenta re-executar migrations já aplicadas (tabela `schema_migrations` funcionando).
|
||||
- [ ] `SELECT * FROM funcionalidades` retorna as 30 linhas do seed (24 MVP + 6 Fase 2).
|
||||
- [ ] `EmpresaDao.inserir` + `EmpresaDao.buscarPorId` funcionam via um teste manual (pode ser um `main` temporário ou teste JUnit simples).
|
||||
- [ ] Nenhuma tabela usa `DELETE` como estratégia de remoção — todas têm campo de `status` para inativação lógica onde fizer sentido (já está no DDL).
|
||||
|
||||
## Ao concluir
|
||||
Atualizar `10-tracker-progresso.md`: Prompt 02 concluído, data, resumo. Confirmar que Prompt 01 segue marcado como concluído antes de finalizar.
|
||||
Reference in New Issue
Block a user