NÃO APTO PARA PRODUÇÃO
O fornecedor entregou um backend bem arquitetado com apenas ~20% do frontend implementado,
múltiplas vulnerabilidades críticas (incluindo dados reais de pacientes no repositório) e sem configuração
adequada de deploy. 6 brechas críticas · Violação direta da LGPD.
Estágio Atual do Projeto
Backend API
75%
Rails 6.1 · 32 tabelas · 60+ endpoints
Frontend UI
20%
Nuxt 3 · apenas módulos básicos
Segurança
40%
6 críticas · 4 altas · 3 médias
Deploy / Infra
40%
Docker incompleto · sem SSL
Stack Tecnológica
Backend (Rails API)
Linguagem
Ruby ~> 3.0 [EOL mar/2024]
Framework
Rails 6.1.7 [EOL]
Autenticação
Devise 4.2 + JWT
Serialização
ActiveModel::Serializers
Storage
Active Storage local
Admin Panel
rails_admin 3.1
Testes
RSpec — cobertura baixa
Frontend (Nuxt 3)
Framework
Nuxt 3.13 (Vue 3.4)
Estado
Pinia + persistedstate
Calendário
FullCalendar 6.1
API URL
Hardcoded — pedrost.com
Banco de Dados — 32 Tabelas Implementadas
customers
Pacientes completos com plano de saúde, preferências, relacionamentos
appointments
Consultas com sinais vitais (pressão, FC, saturação O2)
odontograms / teeth
Odontograma completo — 32 dentes por paciente com status
anamneses / alerts
Histórico médico, alergias, medicamentos e alertas automáticos
clinical_sheets
Fichas de atendimento clínico por sessão e profissional
treatment_plans
Planos de tratamento com itens e % de conclusão
dental_xrays
Radiografias com upload de imagem via Active Storage
budgets / procedures
Orçamentos com procedimentos mapeados por dente
payment_plans
Parcelamentos com parcelas individuais e controle de status
accounting_entries
Lançamentos contábeis (receitas e despesas da clínica)
leads / interactions
CRM com pipeline de vendas e histórico de contatos
smart_boards
Kanban para gestão visual de pacientes e leads
goals
Metas da clínica com métricas e período mensal/anual
products / stock
Estoque de materiais e movimentações de entrada/saída
lab_cases
Casos enviados ao laboratório com acompanhamento
tags / taggings
Tags polimórficas para categorizar qualquer entidade
message_templates
Templates de mensagens WhatsApp e e-mail
clinics / users / jwt
Multi-tenancy, usuários e blacklist de tokens JWT
Status das Funcionalidades — Frontend vs Backend
Login / Logout
Autenticação JWT funcional
Cadastro de Pacientes
Lista, busca, cadastro e edição
Agenda (Calendário)
FullCalendar com criação de consultas
Orçamentos
Com seleção de dentes e procedimentos
Retornos
Apenas listagem, sem ações
Dashboard
Componente com dados mockados
Odontograma
Core da clínica — sem interface
Anamnese
Prontuário médico — obrigatório por lei
Fichas Clínicas
Histórico de atendimentos do paciente
Planos de Tratamento
Planejamento e acompanhamento
Financeiro Completo
Planos de pagamento, parcelas, contabilidade
CRM / Leads
Pipeline comercial e WhatsApp
Kanban / Smart Boards
Gestão visual de pacientes
Estoque / Laboratório
Controle de materiais e casos de lab
Auditoria de Segurança
⚠ RESULTADO: 6 CRÍTICAS · 4 ALTAS · 3 MÉDIAS — Não pode processar dados de pacientes assim.
Vulnerabilidades Críticas
Senha armazenada em cookie em texto plano
A senha digitada pelo usuário é salva diretamente em um cookie persistido no navegador. Qualquer script XSS, extensão maliciosa ou acesso físico ao computador consegue ler as senhas de todos os usuários.
stores/useAuthStore/index.ts:11 · handlers/login.ts:16
master.key (chave mestra de criptografia) commitada no repositório
O arquivo config/master.key está no repositório com a linha de exclusão comentada no .gitignore. Esta chave decripta credentials.yml.enc, expondo JWT secret e todos os secrets da aplicação. Qualquer pessoa com acesso ao código pode forjar tokens de autenticação.
config/master.key → eaeb1c2ef74ddef8cdd776a8568a70c6
CORS completamente aberto — aceita qualquer origem (origins *)
origins '*' com todos os métodos HTTP e header Authorization exposto permite que qualquer site malicioso faça requisições autenticadas ao backend em nome do usuário logado.
config/initializers/cors.rb
Backup do banco com dados reais de pacientes no repositório — LGPD
O arquivo db/backup.sql contém dados reais de pacientes (CPFs, nomes, histórico médico) e é montado como volume de inicialização do PostgreSQL. Violação direta da LGPD — dados sensíveis de saúde com proteção reforçada (Art. 11, Lei 13.709/2018).
db/backup.sql → docker-compose.yaml:13
Autenticação desabilitada com RAILS_ENV=development (Dockerfile usa development)
O Dockerfile define RAILS_ENV=development como padrão. Em modo development a autenticação é substituída por usuário automático criado na hora. Um docker run direto sem env vars expõe toda a API sem autenticação.
Dockerfile:6 · base_controller.rb:13-14
Registro público permite escolher qualquer clinic_id
O endpoint POST /users/sign_up aceita clinic_id como parâmetro sem validação. Qualquer pessoa pode criar conta e se vincular a qualquer clínica, acessando todos os dados dos pacientes.
users/registrations_controller.rb:33
Vulnerabilidades Altas e Médias
| ID | Severidade | Problema | Arquivo |
|---|
| ALTO-01 | ALTO | JWT decodificado sem especificar algoritmo (algorithm confusion) | base_controller.rb:55 |
| ALTO-02 | ALTO | JWT com validade de 15 dias — excessivo para dados de saúde | devise.rb:28 |
| ALTO-03 | ALTO | URL da API hardcoded para domínio pessoal do dev (pedrost.com) | nuxt.config.ts:5 |
| ALTO-04 | ALTO | Stack trace completo exposto na resposta HTTP de erro 500 | base_controller.rb:35 |
| MEDIO-01 | MÉDIO | console.log com tokens de autenticação nos server routes | server/api/users/[...].ts:16 |
| MEDIO-02 | MÉDIO | Sem lockout de conta após tentativas de login falhas | devise.rb:207-224 |
| MEDIO-03 | MÉDIO | SECRET_KEY_BASE não configurado como env var para produção | — |
Status de Deploy
| Backend |
|---|
| Dockerfile | ⚠ Parcial — RAILS_ENV errado |
| docker-compose | ✓ PostgreSQL 16 configurado |
| SSL / HTTPS | ✗ force_ssl comentado |
| SECRET_KEY_BASE | ✗ não configurado |
| Active Storage | ⚠ Local — arquivos perdidos |
| Ruby version | ⚠ 3.0 EOL desde mar/2024 |
| Rails version | ⚠ 6.1 EOL — sem atualizações |
| CI/CD Pipeline | ✗ Ausente |
| Frontend |
|---|
| Dockerfile | ✗ Ausente — não existe |
| .env.example | ✗ Ausente — não existe |
| API URL | ✗ Hardcoded pedrost.com |
| Build script | ✓ nuxt build presente |
| Modo SSR | ✓ Nuxt 3 SSR configurado |
| Lock file | ⚠ Duplo: yarn + pkg-lock |
| CI/CD Pipeline | ✗ Ausente |
| Testes | ✗ Zero testes |
Plano de Ação
🚨 Bloqueantes — Obrigatório Antes de Qualquer Deploy
| # | Ação | Prioridade | Esforço |
|---|
| 1 | Remover armazenamento de senha em cookie (CRITICO-01) | BLOQUEANTE | 2h |
| 2 | Remover master.key do git + rotacionar todos os secrets (CRITICO-02) | BLOQUEANTE | 4h |
| 3 | Remover db/backup.sql + limpar histórico git (CRITICO-04) | BLOQUEANTE | 4h |
| 4 | Restringir CORS para domínios específicos (CRITICO-03) | BLOQUEANTE | 1h |
| 5 | Remover clinic_id dos parâmetros de cadastro público (CRITICO-06) | BLOQUEANTE | 2h |
| 6 | Corrigir Dockerfile: RAILS_ENV=production como padrão (CRITICO-05) | BLOQUEANTE | 30min |
🔴 Alta Prioridade — Para Deploy Seguro
| # | Ação | Esforço |
|---|
| 7 | Criar Dockerfile para o frontend + configurar URL via env var | 2h |
| 8 | Habilitar force_ssl = true em production.rb | 15min |
| 9 | Configurar Active Storage para S3 ou volume persistente | 4h |
| 10 | Configurar SECRET_KEY_BASE via variável de ambiente | 1h |
| 11 | Adicionar algoritmo na decodificação JWT (algorithms: [HS256]) | 1h |
| 12 | Reduzir validade JWT para 1–4h + implementar refresh token | 1 dia |
🟡 Funcionalidades Faltando no Frontend
| Módulo | Impacto | Esforço Estimado |
|---|
| Odontograma (interface) | ALTO | 5–8 dias |
| Anamnese (interface) | ALTO | 2–3 dias |
| Fichas Clínicas | ALTO | 3–4 dias |
| Planos de Tratamento | ALTO | 3–4 dias |
| Módulo Financeiro Completo | ALTO | 8–12 dias |
| CRM / Leads | MÉDIO | 5–8 dias |
| Smart Boards / Kanban | MÉDIO | 3–5 dias |
| Estoque + Laboratório | MÉDIO | 4–6 dias |
Estimativa total: ~2 dias para bloqueantes · ~1 semana para deploy seguro · ~3–4 meses para plataforma completa
Conclusão e Recomendação
✓ O que foi entregue de valor
Modelagem de banco rica e bem pensada. Arquitetura multi-tenant correta. Swagger presente. Admin panel funcional. Base técnica sólida — o backend está bem arquitetado.
✗ O que não foi entregue
~80% da interface de usuário. Segurança mínima para dados de saúde. Configuração de deploy para produção. Testes adequados. Documentação de setup.
A entrega do fornecedor representa uma plataforma incompleta com riscos críticos de segurança.
A situação mais grave é a presença de dados reais de pacientes no repositório (db/backup.sql),
que constitui violação direta da LGPD — especialmente sensível por tratar-se de dados de saúde,
com proteção reforçada na legislação brasileira (Art. 11 da Lei 13.709/2018).
O sistema NÃO deve ser implantado em produção sem antes corrigir os 6 itens bloqueantes.
A Digital AI recomenda um contrato de continuidade de desenvolvimento para completar as
funcionalidades faltantes e garantir conformidade com LGPD e padrões de segurança para dados de saúde.