Visão geral
O TermoQuality é o sistema de gestão de procedimentos da qualidade da Termotubos. Nele os administradores elaboram procedimentos por área, revisores e aprovadores sugerem alterações, a Qualidade publica a versão final e os riscos e oportunidades levantados viram planos de ação acompanhados por prazo.
O sistema tem duas metades, no padrão de projeto da Termotubos:
| Parte | Endereço em dev | O que faz |
|---|---|---|
| Frontend (SvelteKit) | http://localhost:51070 | O painel dos colaboradores (/painel) |
| Backend (Rust + Axum) | http://localhost:51071 | A API, o fluxo de movimentação dos procedimentos, os e-mails (Mailgun) e a rotina de avisos dos planos de ação |
| PostgreSQL (local) | localhost:5432 | Banco do app, no schema termoquality |
O que existe no painel
| Área | Rota | O que faz |
|---|---|---|
| Início | /painel/inicio | Política da Qualidade |
| Procedimentos | /painel/procedimentos | Áreas com os procedimentos publicados; lista mestra; novo, editar, revisar, aprovar e visualizar; solicitações pendentes |
| Pipeline | /painel/pipeline | Quadro com cada procedimento na etapa em que está (Criação, Revisão, Ajustes, Aprovação, Publicação) |
| Riscos e oportunidades | /painel/riscos | Planos de ação por departamento e ciclo, meus planos, ficha do plano com 5W2H, evidências e aceite |
| Colaboradores | /painel/colaboradores | Lista dos colaboradores vindos do TermoAuth (só leitura); aqui só se configuram as permissões |
| Configurações | /painel/configuracoes | Perfis de acesso, departamentos, frequências, operadores, etapas do pipeline, logs e meu perfil |
Fluxo de um procedimento
- O administrador cria o procedimento (
ProcedimentoCriar) e envia para revisão. O backend gera o código (PR QUA 001), grava o evento, cria a solicitação e envia o e-mail ao revisor. - O revisor abre em
/painel/procedimentos/revisar/:id, sugere alterações campo a campo (lápis) ou solicita adição/exclusão de passos, riscos e indicadores, e conclui: sem sugestões vai para aprovação; com sugestões volta para ajustes. - O administrador aplica ou rejeita cada sugestão na "Análise de Alterações" (
ProcedimentoAtualizarPeloId) e reenvia. - O aprovador repete o ciclo em
/painel/procedimentos/aprovar/:id. - A Qualidade publica. A versão anterior vira obsoleta e os riscos e oportunidades acima do corte (risco ≥ 12, oportunidade ≥ 16) viram planos de ação.
Toda mudança de situação passa por POST /procedimento/:id/movimentar (backend/controller/procedimento/movimentar.rs), que centraliza eventos, solicitações, notificações e e-mails.
Integrações
| Integração | Pasta | Para que serve |
|---|---|---|
| TermoAuth | backend/integrations/termoauth/ | Valida o JWT pelo JWKS e lista os usuários do login central |
| Mailgun | backend/integrations/mailgun/ | E-mails de revisão, aprovação, publicação e escalonamento dos planos de ação |
Acesso
O login é do TermoAuth (app termo-quality): o frontend manda a pessoa para o TermoAuth, recebe o JWT e o envia em Authorization: Bearer a toda chamada. O backend valida o token e libera só quem tem cadastro ativo na tabela auth. As permissões por área (procedimentos, riscos, pipeline, colaboradores, configuracoes) ficam em auth_permissao; o papel no fluxo (Administrador, Revisor, Aprovador, Leitor) vem do perfil_acesso do colaborador.
Rodando localmente
| Serviço | Porta | Como subir |
|---|---|---|
| Frontend | 51070 | Configuração frontend do .claude/launch.json |
| Backend | 51071 | Configuração backend do .claude/launch.json |
| Documentação | 51072 | Configuração docs-projeto do .claude/launch.json |
| Diagrama do banco (ERD) | 51073 | Configuração database-erd do .claude/launch.json |
| Drizzle Studio | 51074 | Configuração database-studio do .claude/launch.json |
| PostgreSQL | 5432 | Serviço local do PostgreSQL; .claude/preparar-banco.sh cria o banco e aplica as migrations |