Gestor de relatórios de campo

1. 01

   Substituí um fluxo de três etapas (formulário pelo WhatsApp, digitação manual por outra pessoa e comprovações enviadas à parte) por um formulário único em que o técnico registra o relatório e anexa as fotos, com os dados já conhecidos preenchidos.

2. 02

   Implementei autenticação com Supabase Auth e acesso por perfil: cada técnico vê apenas os próprios relatórios, e cada supervisor vê os dos técnicos atribuídos a ele. O supervisor revisa, corrige e aprova; o sistema gera o PDF e exporta o histórico para Excel.

3. 03

   Inventário de ONTs: o administrador importa os equipamentos do Excel com uma prévia dos novos, existentes e repetidos; o supervisor os atribui a cada técnico, e um relatório só aceita uma ONT atribuída a quem o preenche.

4. 04

   Feito para o trabalho de campo com sinal fraco: as fotos são comprimidas no celular antes do envio, as requisições são repetidas quando a rede falha e o formulário avisa antes de fechar se houver fotos não salvas.

Cada relatório de instalação passava por três etapas: o técnico preenchia um formulário pelo WhatsApp, outra pessoa digitava esses dados à mão e as fotos de comprovação eram enviadas à parte. A mesma informação era escrita duas vezes, e as fotos ficavam separadas do relatório a que pertenciam.

O técnico preenche o relatório pelo celular em quatro seções (informações gerais, cliente, instalação e georreferência) e envia as oito fotos de comprovação que cada instalação exige. O servidor define o técnico, o supervisor e a equipe a partir da sessão, e o campo da ONT só mostra os equipamentos atribuídos a esse técnico. Depois de enviado, o relatório vai para revisão: o supervisor o confere, corrige o que for preciso e o aprova, e nesse momento o sistema gera o PDF com os dados e as fotos. O histórico pode ser exportado para Excel por período. Um administrador gerencia usuários, equipes e o inventário de ONTs, que é importado do Excel.

• Servi a API em /api no mesmo domínio do frontend, com uma regra de rewrite no Render. Com o frontend e a API em dois subdomínios de onrender.com, o cookie de sessão era de terceiros e o Safari o bloqueava: o login falhava no iPhone e funcionava no Chrome do computador. Agora o backend se recusa a iniciar se as duas origens não forem do mesmo site.
• O PDF é gerado com um limite de 250 KB: primeiro são reduzidas as fotos gerais, e as da ONT e do formulário R20 continuam nítidas, porque servem para a verificação técnica. Quando o relatório é aprovado, as fotos são apagadas do armazenamento e o PDF fica como registro; uma tarefa semanal remove os relatórios aprovados com mais de um ano, conforme a regra de retenção do negócio.
• O cliente nunca define o status, o técnico, a equipe nem a data de liquidação: quem define é o servidor. Cada endpoint sensível aplica o filtro por perfil e por recurso na leitura e novamente na escrita, e as operações que podem entrar em conflito (instalar ou reatribuir uma ONT, aprovar ou excluir um relatório) rodam em funções transacionais do Postgres.
• Cada vulnerabilidade corrigida tem um teste de regressão no pytest. A integração contínua os executa junto com pip-audit, npm audit e gitleaks.

• Se a rede falhar, cada requisição é repetida duas vezes antes de mostrar o erro, e se a sessão tiver expirado ela é renovada uma vez e a requisição é refeita.
• Os botões de salvar e enviar ficam bloqueados enquanto a requisição está em andamento, para que um toque duplo com sinal lento não crie um relatório duplicado. Se o rascunho foi salvo mas o envio para revisão falhou, a nova tentativa atualiza esse mesmo rascunho.
• Antes de ir para revisão ou de ser aprovado, o servidor valida os campos obrigatórios, as oito fotos, as coordenadas e se a ONT pertence ao técnico, e responde com a lista exata do que falta.
• A geração do PDF e o envio de fotos têm limite de concorrência e de frequência; se o servidor estiver ocupado, ele responde com uma mensagem clara para tentar de novo, em vez de travar.

Desenvolvi sozinho, de ponta a ponta: a API em FastAPI, o frontend em React e TypeScript, o modelo de dados e as migrações no Supabase, a autenticação com Supabase Auth e o acesso por perfil, a geração do PDF, a exportação para Excel e o deploy no Render, com integração contínua no GitHub Actions. Hoje faço a manutenção.

• Usado por cinco técnicos e um supervisor, com manutenção contínua.
• O técnico registra os dados e as fotos em um só lugar; ninguém mais redigita o relatório à mão.
• Cada relatório aprovado fica salvo como um PDF com os dados e as oito fotos, pronto para baixar no painel do supervisor.