ASP — Plataforma de Inspeção e Execução
Sistema interno da ASP (Advanced Services Provider / ASP Serviços Industriais)
para gestão de inspeção robótica e execução de serviços em tanques e
tubulações. Um Projeto (um pedido de compra) reúne várias Inspeções (tanques/
pontos), e cada inspeção percorre um fluxo de fases simétrico — Inspeção e
Execução — com coleta de dados de campo, relatórios versionados, aprovação
da gerência, agendamento com notificações e histórico auditável.
Stack: Next.js 14 (App Router · TypeScript · React 18) · Supabase (Postgres +
Auth + Storage, com RLS) · Vercel · Resend (e-mail, opcional) · medidor de
sedimento embutido (HTML/JS standalone).
Produção: asp-plataform.vercel.app · Repo: github.com/douglaskengit-dev/ASP-PLATAFORM
1. Funcionalidades
Projetos & Inspeções
- Abertura de projeto (1 = 1 pedido de compra) com cliente, código, pedido,
endereço da obra e responsável. Edição e exclusão em lixeira (soft-delete).
- Inspeções (tanques/pontos) dentro do projeto, cada uma com barra de progresso
das fases e status (Em andamento / Aguardando aprovação / Em execução /
Encerrado).
Fluxo de fases (por inspeção)
- Abertura do Projeto (Comercial · nível projeto)
- Agendamento de Visita/Inspeção (Comercial)
- Coleta de Dados (Operações)
- Relatório de Inspeção (Operações)
- Aprovação do Relatório de Inspeção (Gerência)
- Agendamento de Execução (Comercial)
- Execução (Operações)
- Relatório de Execução (Operações)
- Aprovação do Relatório de Execução (Gerência)
- Encerramento
Avançar registra data de autenticação e autor. Aprovação (fases 5/9) avança;
reprovação volta uma fase com a tag "Ajustar", exigindo motivo e preservando
o histórico de versões.
Coleta — Medidor de Sedimento
- Ferramenta de campo embutida (cálculo local, exporta PDF). A medição é salva
como Relatório Técnico interno (JSONB) — reabrível e editável — via
ponte
postMessage com o app. Anexo de PDF também suportado. Outras
ferramentas (ultrassom, drone, MFL) marcadas como "em desenvolvimento".
Relatórios
- Upload versionado (PDF/DOCX); ciclo rascunho → em aprovação → aprovado /
ajustar / assinado; fila de aprovação da Gerência; download por versão.
Agendamento
- Data + hora da visita e data prevista de execução; equipe por seleção
de usuários; equipamentos como chips; checklist extensível (NR-33, NR-10,
EPIs, PT…). Editar/excluir. Ao agendar, os envolvidos recebem notificação
in-app e e-mail com convite de calendário (.ics) para a agenda do
celular (e-mail via Resend, opcional).
Dashboard
- KPIs (projetos, inspeções, em andamento, aguardando aprovação, em execução,
encerradas, progresso médio) com tooltips; gráficos (inspeções por fase,
projetos por cliente); calendário mensal com datas de inspeção e execução;
filtros por cliente, período e status.
Clientes (reutiliza gp_orgaos) — cadastro/edição, busca e filtros, e
lixeira. Histórico — projetos em aberto. Arquivos — coletas e relatórios
agrupados por projeto/inspeção, com busca e filtros.
Notificações — sino no header com avisos persistidos (ex.: inspeção
agendada) e as inspeções paradas numa fase sob responsabilidade do perfil do
usuário.
Administração de usuários — criar usuários; Área/Acesso (Comercial,
Operações, Gerência, Admin), Função (Coordenador, Engenheiro, Técnico),
editar nome, redefinir senha e ativar/inativar.
Identidade visual — paleta ASP (azul #0f5cad / amarelo #e8c51f), fonte
Montserrat, badge + wordmark no header, mascote nos títulos.
2. Perfis e permissões
| Área (perfil) | Atua nas fases | Observações |
|---|
| Comercial | 1, 2, 6 | abre projetos e agenda |
| Operações | 3, 4, 7, 8 | coleta e relatórios |
| Gerência | 5, 9 (+ todas) | aprova/reprova |
| Admin | tudo | + administração de usuários |
- Excluir projeto/inspeção/cliente: Comercial, Gerência, Admin ou quem
tem a Função Coordenador.
- Permissões finas ficam nas API routes; o RLS garante o mínimo por perfil.
Perfis legados (
editor/visualizador) ainda são aceitos durante a migração.
3. Modelo de dados (tabelas novas do fluxo ASP)
gp_projetos 1 projeto = 1 pedido de compra (cliente → gp_orgaos)
└── gp_inspecoes N por projeto; carregam as fases 2..10
├── gp_coletas medição (jsonb) + PDF do medidor
├── gp_relatorios inspeção/execução, versionados
├── gp_agendamentos data/hora, execução, equipe, checklist (jsonb)
└── gp_fase_historico auditoria de fases (ação, autor, data)
gp_notificacoes avisos in-app por usuário
gp_profiles perfil (área) + funcao
Soft-delete (excluido_em / excluido_por) em gp_projetos, gp_inspecoes e
gp_orgaos — a exclusão vira lixeira, recuperável por 30 dias, com
limpeza automática (preguiçosa) depois disso. Storage no bucket privado
gp-arquivos (coletas e relatórios).
O fluxo antigo (Processos/TR/Proposta/Ofício, tabelas gp_processos etc.)
permanece no repositório para reaproveitamento, mas fora da navegação.
4. Setup
Pré-requisitos: Node 18+, um projeto Supabase.
npm install
cp .env.example .env.local # preencha os valores
npm run dev # http://localhost:3000
Variáveis de ambiente (.env.local e Vercel):
| Variável | Uso |
|---|
NEXT_PUBLIC_SUPABASE_URL | URL do projeto Supabase |
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY | chave publicável (client) |
SUPABASE_SECRET_KEY | chave secreta / service_role (só servidor) |
NEXT_PUBLIC_APP_URL | URL pública do app (links de e-mail) — opcional |
SMTP_HOST | servidor SMTP, ex.: smtp.gmail.com — definido, o e-mail sai por SMTP |
SMTP_PORT | 465 (TLS direto, padrão) ou 587 (STARTTLS) |
SMTP_USER | conta que envia, ex.: [email protected] |
SMTP_PASS | senha de app do Google (16 letras; espaços são ignorados) |
RESEND_API_KEY | envio pelo Resend (usado quando não há SMTP_HOST) |
EMAIL_PROVEDOR | smtp ou resend para forçar um provedor (opcional) |
EMAIL_REMETENTE | remetente, ex.: ASP <[email protected]> (opcional) |
EMAIL_RESPONDER_PARA | endereço de resposta (Reply-To) (opcional) |
Sem nenhum provedor configurado o e-mail é no-op (as notificações in-app
seguem funcionando).
Migrations: aplique os arquivos de supabase/migrations/ no banco (SQL
Editor do Supabase ou supabase db push). Os relevantes ao fluxo ASP:
20260725120000_asp_novo_fluxo_v1.sql schema + RLS + perfis
20260727100000_asp_usuario_funcao.sql coluna funcao
20260728100000_asp_agendamento_notificacoes.sql hora + gp_notificacoes
20260729100000_asp_agendamento_data_execucao.sql data de execução
20260730100000_asp_projeto_soft_delete.sql lixeira de projeto
20260731100000_asp_soft_delete_inspecao_cliente.sql lixeira de inspeção/cliente
E-mail via Gmail
Envia convites, redefinição de senha e agendamentos (com o .ics) por uma
conta Gmail, sem precisar de domínio próprio:
- Na conta Google que vai enviar, ative a Verificação em duas etapas
(Conta do Google → Segurança).
- Crie uma senha de app: Conta do Google → Segurança → Senhas de app
(myaccount.google.com/apppasswords), nome Plataforma ASP. Copie os 16
caracteres (o Google mostra em blocos de 4 — espaços podem ficar).
- Na Vercel (Settings → Environment Variables, ambiente Production e, se
quiser, Preview) defina:
SMTP_HOST=smtp.gmail.com
SMTP_PORT=465
SMTP_USER=<conta>@gmail.com
SMTP_PASS=<senha de app, 16 caracteres>
EMAIL_REMETENTE="ASP <[email protected]>"
EMAIL_RESPONDER_PARA=<opcional: endereço para respostas>
- Redeploy (Deployments → ⋯ → Redeploy) — variáveis novas só valem
após um novo deploy.
- Logado como admin, abra
/api/diag (deve mostrar "provedor": "smtp",
SMTP_PASS_presente: true) e depois /api/[email protected] para
enviar um teste; o erro, se houver, vem em português.
Observações:
- O Gmail só envia como a própria conta: se o endereço de
EMAIL_REMETENTE
for outro, o sistema usa o SMTP_USER e mantém o nome (o /api/diag avisa).
- Limites do Gmail: ~500 e-mails/dia (conta pessoal) e ~2.000/dia (Google
Workspace). Acima disso aparece "Limite diário de envio do Gmail atingido".
RESEND_API_KEY pode continuar definida: com SMTP_HOST o SMTP tem
precedência. EMAIL_PROVEDOR=resend volta para o Resend sem apagar nada.
E-mail (Resend, alternativa): crie a conta, verifique um domínio em
Domains (registros SPF/DKIM) e defina RESEND_API_KEY/EMAIL_REMETENTE.
5. Estrutura
app/
page.tsx landing pública
login/ autenticação (Supabase)
dashboard/ KPIs, gráficos e calendário
projetos/ lista, detalhe, edição e lixeira
inspecoes/[id]/ fases, coleta, agendamento, relatórios, histórico
arquivos/ documentos por projeto/inspeção
orgaos/ clientes (cadastro, edição, lixeira)
admin/usuarios/ administração de usuários
api/ route handlers (projetos, inspecoes, coletas,
relatorios, agendamentos, notificacoes, usuarios…)
components/ BarraUsuario, Modal, TituloPagina, CalendarioAgenda,
NotificacoesBotao, FormularioOrgao, DashboardCharts…
lib/
asp/fases.ts modelo de fases e ações
asp/permissoes.ts regras de exclusão
supabase/ clients (browser, route, admin/server)
email.ts, ics.ts, email-templates.ts
public/ferramentas/ medidor de sedimento (HTML standalone)
supabase/migrations/ migrations SQL
6. Convenções
- Construir e validar fase a fase, com deploy incremental na Vercel.
- Nunca commitar segredos; chaves só via variáveis de ambiente.
- Rodar
npx tsc --noEmit (type-check) e, quando possível, npm run build
antes do push.
- Storage e operações que ignoram RLS usam o cliente admin (
SUPABASE_SECRET_KEY),
nunca no navegador.
