Começamos com um conjunto de 23 requisitos de classificação e temporalidade arquivística. O sistema já era um GED capaz de receber e visualizar PDFs. O desafio era acrescentar planos de classificação, tabelas de temporalidade e processos arquivísticos sem perder o funcionamento existente.

A implementação exigiu decisões de domínio antes das telas. A principal foi definir o processo como objeto classificado. Seus PDFs são componentes digitais, organizados em representações como volumes, partes ou anexos.

Processo arquivístico
├── Metadados, classe, tipologia, eventos e prazos
├── Representação: Volume 1
│ └── Componente: volume-1.pdf
└── Representação: Volume 2
└── Componente: volume-2.pdf

Essa separação determina onde cada informação é gravada, como o visualizador a apresenta e o que precisa ser preservado quando uma regra muda.
A estrutura técnica
O backend usa PHP 7.4, Laravel 8 e PostgreSQL. A interface usa Vue 3 e Inertia. Organizamos as regras principalmente em serviços, deixando os controllers responsáveis por receber, validar e autorizar as requisições.

Há dois conjuntos de serviços:

  • Classificação: cadastro de planos, classes, tipologias, códigos, importação institucional, movimentações e versões da TTD.
  • Processos SIGAD: captura, representações digitais, eventos arquivísticos, projeção de prazos, reconciliação de novas regras e destinação. Migrations criam os vínculos entre esses objetos. O application_id delimita os dados de cada aplicação, enquanto permissões específicas controlam ações como criar, classificar, publicar, consultar e baixar. Uma classe possui identificador interno estável; seu código arquivístico e sua posição na hierarquia podem mudar sem perder os vínculos históricos. Importar um plano é interpretar uma fonte Testamos o modelo com planos institucionais de estruturas diferentes. Uma fonte pode usar códigos de largura variável, reservar códigos ou trazer definições e observações junto ao nome da classe. Fixar uma única árvore e uma única fórmula de numeração não atenderia esses casos.

Criamos um modelo XLSX para importar hierarquia, tipologias, prazos, eventos iniciais, destinação e observações. O processamento conserva a referência à linha original. Dados ambíguos geram apontamentos de conferência; a importação entra em rascunho antes da publicação.

Essa decisão evita um erro perigoso: transformar texto incerto da fonte em uma regra estruturada aparentemente definitiva.
Mudanças estruturais têm efeitos em cadeia
Deslocar, desmembrar ou fundir classes pode alterar códigos de descendentes e afetar processos classificados. Por isso, a operação começa com uma prévia dos efeitos e exige justificativa. A solicitação de movimentação é aprovada por outro usuário.

As alterações registram revisão, autor, instante, fuso, motivo e valores anteriores e posteriores. Também usamos revisão esperada nas atualizações: se outra pessoa alterou o plano enquanto a tela estava aberta, a gravação é recusada para evitar sobrescrever uma mudança recente.

Inativação e exclusão lógica seguem regras próprias. Uma classe retirada do uso continua necessária para explicar classificações feitas no passado.
A temporalidade depende de eventos
A data de captura no sistema não é automaticamente a data de abertura do processo. Um processo histórico pode ser capturado hoje e ter sido aberto anos antes.

A TTD publicada indica qual evento inicia cada prazo. A aplicação registra o evento com data efetiva e fonte, depois calcula a projeção da idade corrente ou intermediária. Desarquivamento e inclusão de conteúdo sigiloso só alteram um prazo quando a regra os menciona expressamente.

Quando a classificação ou a TTD muda, o serviço recalcula as projeções aplicáveis. Se não há correspondência inequívoca entre a regra antiga e a nova, o processo fica pendente de conferência. Isso é particularmente relevante antes de uma decisão de destinação.
A convivência com o GED existente
O GED tinha duas APIs de upload: uma geral e outra usada pela tela de arquivos. Para aplicações com SIGAD habilitado, ambas passam por uma verificação no backend que bloqueia novos envios avulsos. A interface também direciona o usuário para a abertura de processos.

O fluxo SIGAD usa outra rota: incluir um PDF como representação de um processo. Nela, o arquivo físico continua registrado, mas também são criados os vínculos arquivísticos e o hash SHA-256 do componente.

Recentemente acrescentamos seleção múltipla na abertura. A interface cria o processo em rascunho e envia os PDFs em sequência pela rota de representações já existente. Cada envio cria uma representação e incrementa a revisão do processo. Se um arquivo falhar, os anteriores continuam vinculados ao rascunho, e a tela mantém os pendentes para nova tentativa. Classificação e captura são passos posteriores.
Como verificamos o trabalho
A implementação combina testes de serviços, APIs e fluxos completos com PostgreSQL. Os cenários cobrem, entre outros pontos, permissões, versões, movimentações, importação, eventos, prazos e processos com vários volumes. A compilação do Vue verifica a integração da interface.

Ainda há uma etapa que testes automatizados não substituem: homologar a interpretação arquivística dos planos e tabelas reais. O roteiro de testes separa o comportamento técnico implementado do aceite das fontes, dos perfis de acesso e das decisões institucionais.

A principal lição dessa worktree foi que classificação e temporalidade formam um conjunto de regras sobre objetos que continuam vivendo depois do cadastro. Modelar identidade, história, eventos e impacto das mudanças desde o início tornou essas regras verificáveis.