NexoGov
Onde o processo está, quem está com ele, e há quanto tempo.
GovTech · Tramitação processual
- Beta
- Status
- Tramitação interna
- Domínio
- Restrita
- Consulta externa
Visão geral
O que este sistema resolve
NexoGov é um sistema de tramitação processual para prefeituras, inspirado na lógica dos sistemas eletrônicos do Judiciário brasileiro e adaptado à realidade administrativa municipal. Registra protocolos, encaminha entre secretarias, órgãos e setores, e mantém a linha do tempo do que aconteceu com cada processo.
É um sistema interno. A consulta externa existe, mas é restrita: quem tem o número do protocolo acompanha o andamento, e o acesso aos documentos exige a senha do protocolo. O escopo é a tramitação interna: o cidadão acompanha o andamento externamente, mas a abertura do protocolo ocorre pela administração.
O desafio
O que tornava o problema difícil
Estes são os pontos que mais influenciaram a arquitetura.
Tramitação não linear entre órgãos e setores
Um processo não anda em linha reta. Ele é encaminhado a uma secretaria com cópia para outras duas, volta, é redistribuído a um setor. O modelo precisa representar isso sem perder a ordem nem a responsabilidade em cada ponto.
A numeração é a identidade pública do processo
O número segue o formato ano e sequencial, e circula em ofício, e-mail e conversa. Duas criações simultâneas não podem receber o mesmo número — e ler o último e somar um é exatamente a corrida clássica.
Documentos restritos por padrão
O anexo pode conter dado pessoal, e o número do protocolo circula com facilidade. O padrão de visibilidade decide quanto uma distração custa.
Interface voltada a rotinas rápidas de atendimento
A adoção falha por curva de aprendizado antes de falhar por funcionalidade. A interface precisa de tours de primeiro acesso por papel e um caminho principal muito curto.
Arquitetura
Como o sistema é montado
- Aplicação
Next.js · App Router · TypeScript estrito
Área autenticada, área de login e consulta pública separadas por grupo de rotas.
- Serviços
Camada própria
O acesso ao banco vive nos serviços; as rotas validam, autorizam e delegam.
- Dados
PostgreSQL · Prisma
Conexão por adaptador, com a credencial fora do schema.
- Autenticação
Auth.js
Configuração dividida entre o que roda no edge e o que precisa de Node.
- Validação
Zod
Schema por entrada, no servidor.
- Arquivos
Armazenamento externo
Documento com hash de conteúdo e registro de cada acesso concedido.
Decisões de engenharia
Decisões e trade-offs
Cada decisão registra a justificativa e o trade-off aceito.
Escopo declarado: tramitação interna, não protocolo aberto
Abrir a criação de protocolo ao cidadão muda o modelo de ameaça, o volume, a triagem e a responsabilidade legal do município. Manter o escopo fechado permitiu resolver bem o problema que a prefeitura tem hoje — saber onde o processo está — em vez de resolver mal dois problemas.
Custo aceito · O cidadão depende de um servidor para abrir processo. Em troca, a consulta externa por protocolo entrega o que ele realmente quer: acompanhar.
Visibilidade restrita como padrão do documento
O padrão importa mais que a opção disponível. Com o documento nascendo restrito, expor é sempre um ato deliberado; se nascesse público, bastaria um esquecimento.
Custo aceito · Mais passos para publicar o que realmente deveria ser público. O custo adicional de publicação é aceito para manter o padrão restritivo.
Movimentação e auditoria na mesma transação
Auditoria gravada depois da ação é auditoria que some justamente quando algo dá errado no meio. Escrevendo as duas na mesma transação, ou existem as duas ou não existe nenhuma.
Custo aceito · A transação fica maior e a escrita de auditoria não pode ser adiada para uma fila. Para o volume de uma prefeitura, é troca barata.
Por dentro da engenharia
Os problemas em detalhe
Cada bloco abre com o problema, mostra a solução e explica por que ela foi escolhida. Expanda o que interessar.
Numeração sequencial sem furo e sem colisão
Problema
O número do protocolo é a identidade pública do processo. Duas criações simultâneas não podem receber o mesmo número. E a implementação natural — ler o maior número do ano e somar um — falha exatamente sob concorrência, porque duas transações leem o mesmo valor antes de qualquer uma gravar.
Solução
O contador de cada ano é uma linha própria numa tabela dedicada, incrementada atomicamente dentro da mesma transação que cria o protocolo. O incremento e a criação vivem ou morrem juntos.
Por que foi feito assim
Concentrar o contador numa linha faz o banco serializar as transações concorrentes naquele ponto — e apenas naquele ponto, sem travar o resto do sistema. Estar na mesma transação resolve o segundo defeito, menos óbvio: consumir o número e falhar depois deixaria furo na sequência, e sequência com furo em processo administrativo é uma pergunta que alguém vai fazer.
Documento restrito por padrão, com acesso registrado
Problema
O anexo de um processo administrativo pode conter dado pessoal, e a consulta externa é feita pelo número do protocolo — que circula em ofício, em e-mail e em conversa. Tratar o documento como público por estar vinculado a um processo consultável é confundir duas coisas diferentes.
Solução
A visibilidade padrão do documento é restrita ao protocolo, e o acesso externo exige a senha do protocolo, verificada contra um hash. Cada acesso concedido gera um registro próprio, separado da trilha geral de auditoria.
Por que foi feito assim
Separar "quem consultou o andamento" de "quem baixou o documento" é o que permite responder à pergunta que realmente importa depois de um incidente. E o registro de acesso ser uma entidade própria, e não uma linha genérica de log, é o que torna essa consulta possível sem varrer a auditoria inteira.
Onboarding específico por papel e tela
Problema
O sistema tem perfis com rotinas muito diferentes — quem cria protocolo, quem despacha, quem acompanha indicador. Um tour único mostra a maior parte das telas para quem nunca vai usá-las, e a adoção morre no treinamento.
Solução
Tours de primeiro acesso definidos por combinação de papel e tela, com a marcação de "já visto" separada por essa combinação.
Por que foi feito assim
A chave composta é o detalhe que faz funcionar: com a marcação por papel apenas, o tour reaparecia a cada navegação; com a marcação por tela apenas, um usuário que muda de papel nunca veria o conteúdo novo.
Stack
Stack do projeto
O sistema em números
- 16
- Modelos de dados
- 31
- Rotas de API
- 18
- Páginas
- 10
- Enums de domínio
conferido no repositório em 27/08/2026
Status
Beta
Aplicação
Dados
Autenticação
Validação
Visualização
Infraestrutura