Andrade Systems
EntregueFiveMCliente: SIDE RP

side_legaldepartment

Sistema jurídico · Lua e React

A emissão do documento é o único ponto do sistema onde o mundo do jogo muda de verdade.

Tipos de processo
5
Capacidades de permissão
16
Endpoints no servidor
20
TypeScript e React
5.539 linhas
Lua
2.499 linhas

Fonte verificada no repositório interno em 08/09/2026

O que faz

Em uso

O sistema atende cinco tipos de processo, cada um com o seu fluxo: análise, pagamento, aprovação, emissão — ou indeferimento e cancelamento a partir dos estados intermediários. Cada movimento gera uma linha de histórico no processo e uma linha de auditoria no sistema.

Os oito cargos da hierarquia do jogo são mapeados para quatro perfis de painel, e o topo recebe todas as capacidades independentemente do perfil. A capacidade que aprova depende do tipo do processo: o que é judicial não é aprovado por quem responde pelo administrativo.

Evidência

Como o sistema aparece

Capturas da interface real, renderizada com payload de demonstração derivado dos contratos do resource — organizações, cargos, pessoas e identificadores são sintéticos. Onde não existe interface, entra visualização técnica, rotulada como tal.

  • Interface do sistema

    Painel: processos por estado e o que mudou desde a última abertura.

  • Interface do sistema

    Solicitações: cada linha carrega o estado atual do processo, e cada ação exige o estado certo.

  • Interface do sistema

    Empresas: alvará vigente é consequência da emissão, não um campo que se edita à mão.

  • Interface do sistema

    Auditoria: autor, cargo, valor anterior e novo. Ato sigiloso é marcado como tal na própria linha.

Por dentro da engenharia

Decisões de implementação

Um bloco por decisão de implementação. Abra o que interessa.

Máquina de estados explícita

Problema

Um processo cujo status é apenas um texto pode saltar de qualquer estado para qualquer outro. Basta um botão novo, feito com pressa, para um documento ser emitido sem ter sido aprovado — e o histórico registra o salto como se fosse normal.

Solução

Cada ação declara três coisas: o estado que exige, a capacidade que exige e o estado que produz. Transição inválida falha na porta, com a mensagem dizendo qual era o estado esperado.

Por que foi feito assim

O fluxo deixa de ser convenção entre quem escreveu as telas e passa a ser propriedade do sistema. Quem lê o código vê o processo inteiro num arquivo.

Efeitos externos concentrados na etapa de emissão

Problema

Se cada tela aplicasse o seu efeito, um processo aprovado e não emitido já teria alterado a realidade — e desfazer exigiria saber quais telas foram abertas e em que ordem.

Solução

Mudança de nome, limpeza de ficha e concessão de alvará acontecem exclusivamente na emissão, cada uma exigindo a sua própria capacidade e gravando auditoria marcada como ato sigiloso, com valor anterior e valor novo.

Por que foi feito assim

Um lugar para auditar, um lugar para falhar, um lugar para corrigir. Efeito espalhado por telas é a forma mais cara de descobrir o que aconteceu.

Cobrança validada antes da emissão

Problema

Emitir primeiro e cobrar depois cria documento sem pagamento quando a cobrança falha. Cobrar primeiro e falhar na emissão cria pagamento sem documento.

Solução

A cobrança acontece antes de o documento existir e é condição para ele existir. Se o cidadão não tem o valor, a operação retorna erro e nada é criado.

Por que foi feito assim

Entre as duas falhas possíveis, a única aceitável é a que não deixa rastro. Documento emitido sem lastro é um problema que só aparece meses depois.

Decisões

Decisões e trade-offs

Cada decisão registra a justificativa e o trade-off aceito.

  1. A capacidade de aprovar depende do tipo do processo.

    Separar o que é decisão judicial do que é ato administrativo reproduz a separação que o próprio roleplay pressupõe, e evita que um cargo acumule os dois por descuido de configuração.

    Custo aceito · Um tipo novo de processo precisa declarar qual capacidade o aprova, senão cai no padrão mais restritivo — o que é chato de descobrir e barato de corrigir.

  2. Os nomes dos cargos vivem na configuração do jogo, não no sistema.

    Renomear um cargo passa a ser uma edição só, no lugar onde a hierarquia já existe. O painel lê em tempo real e mostra o rótulo atual.

    Custo aceito · O sistema depende de a configuração externa estar correta; um cargo removido lá aparece aqui pelo identificador do grupo.

Stack

O que foi usado

  • Servidor

    • Lua
    • FiveM
    • vRP
  • Dados

    • MySQL
    • 8 tabelas
    • Migrations na subida do sistema
  • Interface

    • React
    • TypeScript
    • Vite
  • Controle

    • 16 capacidades
    • Histórico por processo
    • Auditoria com marcação de ato sigiloso