Em desenvolvimentoPlataformas / Web
LexContract
O LexContract centraliza o ciclo de vida de contratos de advogados autônomos e pequenos escritórios — clientes, modelos, contratos, documentos, pagamentos e histórico de auditoria — em um único sistema, no lugar de planilhas, e-mail e papel. Cada escritório é um tenant com dados isolados. É o projeto com a maior amplitude técnica do portfólio: frontend, backend próprio, banco relacional, testes e automação de deploy.
O problema
Pequenos escritórios de advocacia acompanham contratos, cobranças e documentos espalhados entre e-mail, WhatsApp, planilhas e pastas físicas, sem rastreabilidade e com dificuldade de continuidade quando mais de uma pessoa acompanha o mesmo caso.
A solução
Um domínio central — o contrato — ligado a cliente, modelo, versões do texto, documentos, pagamentos e auditoria, tudo isolado por escritório (officeId). O contrato percorre estados controlados (rascunho → envio → assinatura → vigência → encerramento), com permissões por papel (ADMIN, LAWYER, ASSISTANT) aplicadas no backend.
Arquitetura
- 1
React + TypeScript (Vite) — interface, sessão do usuário e cliente HTTP central
- 2
API Fastify — rotas e controllers por módulo, com autenticação e papéis nos preHandlers
- 3
Services — regras de negócio, sempre filtrando pelo escritório do usuário autenticado
- 4
Prisma ORM — acesso tipado ao banco, com índices e restrições de unicidade por escritório
- 5
PostgreSQL — dados relacionais: clientes, contratos, versões, documentos, pagamentos e auditoria
- 6
GitHub Actions — CI (frontend, backend, Docker, E2E) e deploy encadeado para Render (API) e Cloudflare Pages (frontend)
O que o projeto faz
- Autenticação por e-mail e senha com JWT, sessão validada em /auth/me e hash de senha com bcryptjs
- Permissões por papel (ADMIN, LAWYER, ASSISTANT) verificadas no backend, e não apenas escondidas na interface
- Isolamento multi-tenant: os serviços filtram por escritório em toda leitura e escrita
- Modelos de contrato com variáveis substituídas automaticamente e criação de contratos em etapas, com versionamento do conteúdo
- Transições de status controladas, término e renovação com alerta automático de vencimento
- Aceite eletrônico por link público de uso único (assinatura eletrônica simples, não ICP-Brasil), com token em hash, expiração e vínculo com a versão exata do contrato
- Documentos, parcelas de pagamento com indicadores financeiros, notificações e Web Push
- Dashboard, busca global, filtros avançados e histórico de auditoria das ações
Desafios técnicos
- Problema
- Em um sistema multi-escritório, um erro de filtro em uma única consulta pode expor contratos de um escritório a outro.
- Investigação
- Mapeamento de todo recurso de negócio que precisa guardar o escritório de origem e de quais pontos o identificador poderia chegar à consulta.
- Solução
- Todo recurso guarda officeId e cada service filtra por request.user.officeId vindo do token, nunca por um id enviado livremente pelo cliente. Restrições de unicidade (como CPF/CNPJ) valem por escritório, não globalmente.
- Problema
- Ocultar botões para quem não tem permissão não impede uma chamada direta à API.
- Investigação
- Separação entre autenticação, autorização e validação como etapas sequenciais de cada rota.
- Solução
- Autorização por papel aplicada no servidor (authenticate → requireRole → validação com Zod); quem força a chamada recebe 403. Há testes de integração dedicados às regras de papel.
Decisões técnicas
Qualidade e entrega
O repositório tem testes unitários e de integração no backend (Vitest, com PostgreSQL real no CI), 4 fluxos E2E em Playwright (login, criar contrato, enviar contrato, registrar pagamento) e um pipeline que só publica depois que typecheck, build, testes, E2E e build das imagens Docker passam.
Limitações declaradas
A assinatura é um aceite eletrônico simples, sem validade ICP-Brasil. O projeto não alega conformidade com a LGPD nem certificação de segurança: os mecanismos listados são os que existem no código. É um projeto em evolução, sem usuários reais comprovados.
O que este projeto me ensinou
O LexContract foi onde passei a pensar o sistema de ponta a ponta: modelagem relacional, API própria, autorização no servidor, isolamento de dados entre clientes, testes automatizados e um pipeline que impede deploy com falha.
Telas do projeto
