Manual de Uso - ifpebj-ti/controle-acesso-veiculos GitHub Wiki

Manual de Uso

Projeto: Controle de Acesso de Veículos
Instituição: Instituto Federal de Pernambuco — Campus Belo Jardim
Versão: 2.6 Status: Fluxos geral e institucional, catálogos, autorizações de eventos, resumo operacional, administração de contas, primeiro acesso obrigatório e consulta da auditoria integrados no frontend para desenvolvimento e QA; produto ainda não liberado para operação real Data de referência: 13 de outubro de 2026

1. Finalidade deste documento

Este manual será a referência de uso do sistema para porteiros, vigilantes, Setor de Transporte e demais perfis que forem validados. Ele existe desde o início para que instruções operacionais acompanhem a implementação e sejam verificadas com usuários reais.

O documento não representa uma aplicação pronta. O frontend já integra com a API o login, o fluxo geral de entrada, consulta de acessos abertos, saída manual, histórico, os catálogos ativos de veículos e motoristas institucionais, as autorizações de eventos, as utilizações de veículos institucionais, o resumo operacional diário, a administração de contas e a consulta administrativa da trilha de auditoria. As regras e a experiência de uso ainda precisam de validação com os perfis envolvidos.

Para instalação, configuração, migrations, containers e diagnóstico técnico, consulte o Guia de Execução, Configuração, Deploy e Operação.

2. Quem utilizará o sistema

Os perfis abaixo são preliminares e dependem de validação institucional:

Perfil	Uso esperado
Porteiro	Registrar e consultar entradas e saídas durante o atendimento
Vigilante	Assumir integralmente a operação da portaria durante a ausência do Porteiro
Setor de Transporte	Supervisionar a portaria, consultar históricos, corrigir campos descritivos com justificativa e gerenciar frota e motoristas
Administrador autorizado	Gerenciar usuários, autorizações de eventos e configurações permitidas

Permissões definitivas não devem ser inferidas deste manual. Elas serão documentadas após a validação dos papéis e da política de acesso.

3. O que já pode ser verificado

3.1. Interface web e fluxo geral integrado

O frontend React oferece, para desenvolvimento e QA, os seguintes caminhos integrados à API:

/login: autenticação com usuário e senha; o access token permanece somente em memória, enquanto uma sessão válida pode ser restaurada com segurança por cookie protegido gerenciado pelo servidor;
/acessos/novo: registro de placa, condutor, categoria, objetivo e dados complementares opcionais; o horário oficial é definido pelo servidor;
/acessos/abertos: consulta e busca local dos acessos ainda abertos, atualização manual da lista e registro de saída após confirmação;
/acessos/historico: consulta paginada por período, placa, condutor, categoria e situação.

Em /acessos/novo, “Registrar e continuar” é o caminho principal para uma sequência de atendimento: depois de uma resposta bem-sucedida, os dados concluídos são limpos, o sucesso é anunciado de forma acessível e o foco retorna ao campo Placa. “Registrar e ver acessos” conclui a mesma entrada e abre /acessos/abertos para conferência. As duas ações ficam bloqueadas enquanto a requisição está pendente. Se a validação ou a API falhar, os valores permanecem disponíveis para correção e uma confirmação anterior não continua visível.

O caminho consecutivo foi incorporado pela Issue #167 e pelo PR #168. Sua utilidade, nomenclatura e prioridade visual ainda dependem da homologação com os perfis operacionais na Issue #162.

Porteiro, Vigilante e Administrador acessam o registro e o encerramento do fluxo geral conforme a política atual da API. Setor de Transporte consulta o histórico e pode corrigir objetivo, categoria e observação mediante justificativa, mas não recebe operação de entrada, saída ou encerramento excepcional. A restrição visual orienta a navegação; a autorização efetiva continua sendo aplicada pelo servidor.

Carregamento, resposta vazia, indisponibilidade e acesso negado possuem estados distintos. Se uma consulta falhar, resultados anteriores são removidos, a quantidade não é apresentada como zero e a interface oferece “Tentar novamente”. Uma mensagem de lista vazia aparece apenas quando a API responde com sucesso sem itens.

Essas telas não devem ser usadas na operação real da portaria antes da homologação institucional, definição do ambiente e conclusão dos controles operacionais pendentes. A visão administrativa utiliza agregados reais da API e não fabrica números de demonstração quando não há registros.

3.2. Catálogo ativo de veículos institucionais

O caminho /frota consulta GET /institutional-vehicles e apresenta somente os veículos ativos devolvidos pela API. Os quatro perfis autenticados podem consultar e pesquisar o catálogo. Porteiro e Vigilante utilizam a tela para conferência e não recebem ações de manutenção. Setor de Transporte e Administrador podem criar, editar e desativar veículos conforme a autorização aplicada pelo servidor.

A criação e a edição validam placa, identificação institucional, tipo, marca, modelo, cor e ano de acordo com o contrato atual. A desativação exige confirmação explícita, é lógica e retira o item da lista ativa sem apagar o histórico mantido no servidor. Operações duplicadas e a troca de formulário permanecem bloqueadas enquanto uma requisição está em andamento.

Carregamento, resposta vazia, falha e acesso negado possuem apresentações distintas. Erros de campo locais e devolvidos pela API são associados aos controles do formulário também para tecnologias assistivas. A interface não oferece reativação porque a API ainda não possui um contrato para consultar os veículos inativos; ela não mantém uma lista paralela no navegador.

Este incremento foi incorporado pela Issue #138 e pelo PR #139. Motoristas e utilizações institucionais possuem telas próprias, descritas nas seções seguintes.

3.3. Catálogo ativo de motoristas institucionais

O caminho /motoristas-institucionais consulta GET /institutional-drivers e apresenta somente as autorizações ativas devolvidas pela API. Os quatro perfis autenticados podem consultar e pesquisar o catálogo. Porteiro e Vigilante utilizam a tela para conferência. Setor de Transporte e Administrador podem autorizar e desativar motoristas conforme a autorização aplicada pelo servidor.

Uma autorização informa nome e, opcionalmente, tipo e número de documento em conjunto. O documento é enviado à API para identificar a pessoa, mas o contrato de resposta não o devolve e a interface não o exibe nem mantém uma cópia paralela. A desativação exige confirmação explícita, é lógica e impede novas saídas institucionais sem bloquear o retorno de uma utilização já aberta.

Carregamento, resposta vazia, falha e acesso negado possuem apresentações distintas. Operações duplicadas e a troca de formulário permanecem bloqueadas durante uma requisição. Erros locais e devolvidos pela API são associados aos campos para tecnologias assistivas. A interface não oferece edição nem consulta de inativos porque esses contratos ainda não existem na API; uma nova autorização com os mesmos dados pode reativar a pessoa conforme a regra atual do servidor.

Este incremento foi incorporado pela Issue #141 e pelo PR #142. Saídas, retornos e histórico possuem uma tela própria, descrita na seção 3.5.

3.4. Autorizações de eventos

O caminho /eventos consulta GET /event-authorizations com filtros por período, nome e situação e apresenta resultados paginados. Os quatro perfis autenticados podem consultar as autorizações. Porteiro, Vigilante e Setor de Transporte permanecem em modo de consulta; somente Administrador pode criar, editar e cancelar conforme a autorização aplicada pelo servidor. Para o Setor de Transporte, a tela aparece em Supervisão e não apresenta ações de manutenção.

A interface distingue a vigência do evento, a quantidade prevista, as entradas já registradas e a quantidade restante. Cada regra representa uma placa específica, que corresponde a exatamente um veículo, ou uma cota por tipo com a quantidade permitida pelo contrato atual. O cancelamento é lógico, exige confirmação e preserva o histórico. A tela não registra uma entrada diretamente nem trata a autorização antecipada como abertura automática do portão.

Carregamento, resposta vazia, falha e acesso negado possuem apresentações distintas. Um período inválido é informado junto aos dois campos, não consulta a API e não remove o último resultado válido. Se uma criação, alteração ou cancelamento for persistido e somente a atualização da lista falhar, a mensagem diferencia os dois resultados; “Tentar novamente” repete apenas a consulta, sem repetir a mutação. Erros gerais de uma regra e erros específicos são associados semanticamente aos controles para tecnologias assistivas.

Este incremento foi incorporado pela Issue #148 e pelo PR #149. A matriz de manutenção foi restringida posteriormente pela Issue #270 e pelo PR #280. Reativação de eventos cancelados não é oferecida porque esse contrato não existe na API. A validação institucional e a liberação para uso real continuam separadas da integração técnica.

3.5. Utilizações de veículos institucionais

O caminho /utilizacoes-institucionais integra os contratos de saída, utilizações abertas, retorno e histórico. Porteiro e Vigilante selecionam um veículo e um motorista ativos, registram saída com quilometragem e itinerário, consultam utilizações abertas e confirmam o retorno. Setor de Transporte consulta somente o histórico. Administrador possui as duas áreas conforme a política atual da API. A autorização efetiva permanece no servidor.

O retorno exige confirmação e quilometragem igual ou superior à informada na saída. A interface bloqueia submissões duplicadas e não repete a mutação quando apenas a recarga posterior falha. Nesse caso, informa que a alteração foi persistida e oferece nova tentativa somente para consultar a lista.

O histórico oferece filtros por período, placa, identificação da frota, veículo e motorista, além de paginação. Erros locais não executam requisição nem removem o último resultado válido. Erros de validação devolvidos pela API são associados aos campos correspondentes; falhas de rede, acesso negado e respostas vazias permanecem estados distintos e acessíveis.

Este incremento foi incorporado pela Issue #152 e pelo PR #153. Correções posteriores de dados, homologação em navegador e com tecnologias assistivas e validação institucional continuam fora desta entrega.

3.6. Resumo operacional diário

O caminho /visao-geral consulta GET /operations/daily-summary. Os quatro perfis autenticados podem selecionar uma data local e consultar três grupos de totais: entradas, saídas e registros gerais abertos; saídas, retornos e utilizações institucionais abertas; entradas vinculadas a eventos e quantidade de eventos com entradas.

Para o Administrador, o mesmo contrato também apresenta o fluxo horário de entradas e saídas, a distribuição por categoria de acesso e tipo de veículo e uma série limitada aos 14 dias encerrados na data escolhida. Os gráficos possuem alternativas textuais e estados vazios; nenhum total é inventado quando a API retorna zero registros. Esses agregados não incluem nomes, placas, documentos ou identificadores dos registros.

“No início” representa registros recebidos do dia anterior. “No fim” representa os registros que permanecem abertos ao final do período consultado. Esses números não classificam atraso, irregularidade, ocorrência nem fechamento formal de turno. A resposta é agregada e não contém nomes, documentos, placas, itinerários ou observações.

A interface distingue carregamento, dia sem movimentações, falha de consulta e acesso negado. Uma falha remove totais antigos e não apresenta zero como quantidade conhecida. “Tentar novamente” repete somente a consulta da data aplicada. A data e o fuso exibidos vêm da resposta validada da API.

Este incremento foi incorporado pela Issue #155 e pelo PR #156. Validação em navegador real, responsividade, tecnologias assistivas e homologação institucional permanecem pendentes.

3.7. Administração de contas

O caminho /administracao é destinado ao Administrador e consulta o catálogo real de contas. A interface permite pesquisar por nome ou e-mail, filtrar contas ativas ou inativas, navegar entre páginas, criar uma conta, redefinir a credencial temporária de outra conta ativa e confirmar sua desativação ou reativação. Os rótulos “Nome da pessoa”, “E-mail de acesso” e “Usuário” evitam presumir vínculo empregatício ou obrigatoriedade de endereço institucional.

O Administrador não escolhe a senha permanente. Ao criar uma conta, o servidor gera uma credencial temporária aleatória, expirável e de uso único. Ela aparece somente depois da resposta bem-sucedida, em um diálogo acessível de exibição única, e permanece apenas na memória da interface. Fechar o diálogo, encerrar ou perder a sessão remove o valor; a interface não o grava em URL, armazenamento do navegador, log ou telemetria.

No primeiro uso da credencial temporária, a conta entra em uma sessão restrita: pode apenas criar a senha permanente ou sair. Menus e operações do sistema permanecem indisponíveis até a troca. Depois do sucesso, a sessão é encerrada e a pessoa deve entrar novamente com a senha permanente. Credencial expirada, consumida ou substituída não pode ser reutilizada.

O Administrador pode gerar uma nova credencial temporária para outra conta ativa, informando um motivo categorizado. A redefinição invalida a credencial anterior, incrementa a versão de segurança, revoga sessões existentes e produz auditoria transacional sem guardar o segredo. A API ainda não permite alterar nome, e-mail ou perfil de uma conta existente. A criação inicial foi incorporada pela Issue #158 e pelo PR #159; o ciclo seguro atual foi integrado pelas Issues #258, #260 e #261 e pelo PR #259.

A decisão institucional registrada na Issue #220 atribui o provisionamento e a recuperação a dois Administradores funcionais. A credencial temporária deve ser entregue diretamente ao titular e não pode ser copiada para planilhas, issues, capturas ou mensageria não aprovada. A observação desse procedimento no ambiente real permanece na Issue #162, e o identificador principal da conta continua separado nas Issues #266 e #267.

3.8. Trilha de auditoria

Na área “Trilha de auditoria” de /administracao, o Administrador consulta GET /audits em modo somente leitura. A tela inicia com os últimos 30 dias e permite filtrar por período de até 90 dias, ação, entidade, identificador do registro, identificador do usuário e origem humana ou do sistema. Os resultados são paginados e exibem data e hora, ação, entidade, registro, origem, detalhes e os estados anterior e novo disponíveis.

Detalhes e estados JSON são apresentados como texto, sem interpretar seu conteúdo como HTML. Campos nulos são identificados como não informados; a interface não inventa nomes para atores que a API identifica apenas por número nem oferece um catálogo de entidades inexistente no contrato.

Erros locais e devolvidos pela API são associados aos filtros correspondentes. Um erro de preenchimento preserva o último resultado válido e não cria nova requisição. Uma falha real de consulta remove resultados antigos, não apresenta zero como quantidade conhecida e oferece “Tentar novamente”. Ao alternar entre contas e auditoria, os filtros e resultados das contas permanecem coerentes.

O frontend oculta essa área dos demais perfis, e o backend continua responsável pela autorização efetiva. A exclusividade do Administrador e a experiência de uso ainda dependem da homologação da Issue #162. A integração foi incorporada pela Issue #161 e pelo PR #164.

3.9. Disponibilidade da API

Desenvolvedores e responsáveis por QA podem verificar a disponibilidade técnica da API pelos endpoints:

GET /health
GET /health/live
GET /health/ready

/health e /health/live verificam o processo HTTP. /health/ready também verifica o PostgreSQL. O antigo endpoint demonstrativo /weatherforecast foi removido; testes e diagnóstico devem usar health checks e endpoints reais do produto.

3.10. API funcional para desenvolvimento e QA

Após autenticar uma conta autorizada em POST /auth/login, é possível testar:

POST /access-records/entries
GET  /access-records/open
GET  /access-records/history
POST /access-records/{id}/exit
PUT  /access-records/{id}/correction

O servidor define os horários, associa o usuário autenticado e impede dois acessos abertos para o mesmo veículo. Porteiro, Vigilante, Setor de Transporte e Administrador podem pesquisar o histórico geral por período, placa, trecho do nome do condutor, categoria ou status. Os quatro perfis podem corrigir objetivo, categoria e observação mediante justificativa, sem alterar placa, condutor, veículo, horários, status ou autoria original. Cada correção é autorizada no servidor e registrada na auditoria. O Setor de Transporte continua sem permissão para registrar entrada, saída ou encerramento excepcional. A interface desse perfil foi integrada pela Issue #274 e pelo PR #396. Os exemplos executáveis estão no arquivo ControleAcessoVeiculos.API.http do repositório.

Os dois Porteiros se revezam em jornadas informadas de 12 horas. Quando não há Porteiro, o Vigilante utiliza sua própria conta e executa integralmente o fluxo da portaria. O fechamento por volta das 23h não é bloqueado automaticamente, pois residentes e acessos previamente autorizados podem constituir exceções.

Depois da homologação, o sistema deve ser a fonte principal. Papel fica disponível somente para contingência e deve ser reconciliado posteriormente; dupla digitação permanente não faz parte do processo recomendado.

3.11. Documentação interativa da API

Ao executar a API localmente com o ambiente Development, desenvolvedores e QA podem consultar o contrato em http://localhost:5118/openapi/v1.json e abrir a Swagger UI em http://localhost:5118/swagger. Para uma verificação manual de endpoint protegido, use exclusivamente uma conta fictícia local, execute POST /auth/login, copie apenas o accessToken retornado e informe-o em Authorize. Não publique nem compartilhe senha, token ou cookie.

A interface não persiste a autorização e não é publicada fora de Development. Ela auxilia o estudo do contrato e o diagnóstico manual, mas não substitui testes automatizados, o frontend, a autorização aplicada pelo servidor ou a homologação com os perfis institucionais. Os fluxos de renovação e logout dependem também de cookie protegido e CSRF e devem ser exercitados pelo frontend ou pelos testes de integração. Cada operação publicada possui identificador único, resumo em português e agrupamento funcional verificados automaticamente. A interface foi implementada pela Issue #368 e pelo PR #369; os metadados autodescritivos foram concluídos pela Issue #375 e pelo PR #376.

Administrador pode consultar GET /audits para revisar a trilha por período, ação, entidade, registro e ator. Sem período, são usados os últimos 30 dias; o intervalo máximo é de 90 dias. systemOnly=true mostra somente eventos de sistema.

Também é possível verificar o fluxo institucional:

POST   /institutional-vehicles
GET    /institutional-vehicles
PUT    /institutional-vehicles/{id}
DELETE /institutional-vehicles/{id}
POST   /institutional-vehicles/{id}/reactivation
POST   /institutional-drivers
GET    /institutional-drivers
DELETE /institutional-drivers/{id}
POST   /institutional-vehicle-usages/departures
GET    /institutional-vehicle-usages/open
POST   /institutional-vehicle-usages/{id}/returns
GET    /institutional-vehicle-usages/history

Somente SetorTransporte e Administrador gerenciam os catálogos. Perfis operacionais podem consultá-los. A atualização preserva o identificador do veículo; a desativação é lógica e pode ser revertida, sem apagar o histórico. Veículo inativo não inicia nova saída, mas ainda pode retornar de uma viagem aberta. Uma nova saída exige veículo institucional ativo e pessoa com autorização ativa como motorista; revogar a autorização bloqueia novas saídas, sem impedir o retorno de uma viagem já aberta. Na saída, driverId corresponde ao personId retornado pelo catálogo de motoristas. Transporte e Administrador também podem pesquisar o histórico por período, veículo, placa, identificação da frota ou motorista em GET /institutional-vehicle-usages/history.

O catálogo inicial de eventos também pode ser verificado:

GET    /event-authorizations
POST   /event-authorizations
PUT    /event-authorizations/{id}
DELETE /event-authorizations/{id}

Porteiro e Vigilante consultam autorizações vigentes; Setor de Transporte e Administrador criam, atualizam e cancelam. Cada evento informa período, responsável, área, pernoite e regras por cota de tipo ou placa específica. O cancelamento é lógico. Ao registrar uma entrada, eventAuthorizationId pode ser informado. Nesse caso, a API exige evento ativo e vigente, prioriza uma placa específica e, na ausência dela, consome a cota do tipo de veículo. O PostgreSQL serializa o consumo para impedir que entradas simultâneas ultrapassem a última vaga. A saída não devolve a cota, pois ela representa o total admitido no evento. O sistema apoia a conferência da portaria; não abre portão nem autoriza automaticamente um veículo.

O resumo para troca de turno e conferência pode ser verificado por todos os quatro perfis do MVP:

GET /operations/daily-summary?date=2026-08-30

Sem date, a API utiliza a data atual no fuso institucional, configurado por padrão como America/Recife. openAtStart representa registros recebidos do dia anterior e openAtEnd representa os que continuam abertos na virada do dia. A resposta contém somente totais agregados: não inclui nome, documento, placa, itinerário ou observação e não classifica automaticamente atrasos ou irregularidades.

3.11. Persistência

O esquema PostgreSQL é criado por migrations do Entity Framework Core. Dezesseis migrations estão versionadas, incluindo ciclo de sessão, versão de credencial, troca autenticada, credenciais temporárias e encerramento excepcional. O resumo diário consulta as tabelas existentes e não exige migration ou tabela de fechamento. API e frontend já integram os fluxos gerais, institucionais, eventos, resumo, contas e auditoria; a operação real ainda depende de homologação, infraestrutura e decisões institucionais.

3.12. Dados fictícios para demonstração

Desenvolvimento e QA podem preparar uma demonstração local representativa sem usar dados pessoais reais nem escrever diretamente no PostgreSQL. Com a API local saudável e o Administrador provisionado, execute a partir da raiz:

./infrastructure/demo/Initialize-DemoData.ps1

O script aceita somente uma API em localhost ou outro endereço de loopback, solicita credenciais por prompts protegidos e cria, pelos endpoints normais, contas fictícias, acessos gerais aberto e encerrado, frota e motorista institucionais, usos aberto e concluído, evento vigente e resumo diário. O servidor gera uma credencial temporária para cada conta, e o script conclui o primeiro acesso pela API usando três senhas permanentes locais distintas.

A execução pode ser repetida com as mesmas senhas e o mesmo banco sem duplicar o conjunto. O procedimento não representa carga de produção nem homologação já realizada. Durante a apresentação, prompts, senhas e tokens não devem ser projetados. O guia completo e a limpeza segura estão no infrastructure/demo/README.md.

4. Fluxos que o manual deverá cobrir

Os itens 1, 3, 4, 5, 11, 12, 13 e 14 já possuem fluxo integrado para desenvolvimento e QA. À medida que as demais funcionalidades forem implementadas e validadas, este manual deverá explicá-las com capturas de tela sem dados reais:

Entrar e sair do sistema com segurança.
Localizar ou cadastrar pessoa e veículo.
Registrar entrada de veículo.
Registrar saída de veículo.
Consultar acessos abertos e histórico.
Registrar saída e retorno de veículo institucional.
Informar motorista, quilometragem e itinerário.
Corrigir um registro com justificativa e rastreabilidade.
Conferir registros conforme a permissão do perfil.
Encerrar a sessão e agir em caso de indisponibilidade.
Consultar e, conforme o perfil, manter autorizações de eventos.
Pesquisar, criar, desativar e reativar contas como Administrador.
Entregar uma credencial temporária por canal aprovado e orientar a troca obrigatória no primeiro acesso.
Redefinir a credencial temporária de outra conta ativa com motivo e auditoria.

O conteúdo deverá seguir o MVP e Fluxo Digital, os Requisitos e Backlog e as Regras de Negócio. Divergências devem gerar uma issue antes de alterar o comportamento do produto.

5. Segurança, privacidade e uso responsável

Não utilizar dados reais em ambientes de desenvolvimento, demonstração ou documentação.
Não compartilhar senha, sessão ou conta entre usuários.
Não registrar, capturar ou guardar credencial temporária após sua exibição única.
Não registrar documento pessoal sem finalidade e autorização confirmadas.
Não inserir segredos em capturas de tela, issues, logs ou exemplos.
Não corrigir ou excluir registros de forma a apagar o histórico operacional.
Comunicar incidentes e indisponibilidades pelo processo institucional que vier a ser definido.

Consulte também Segurança e Privacidade, Modelagem de Ameaças e o Guia de Boas Práticas de Desenvolvimento Seguro.

6. Critérios para evoluir este manual

Cada fluxo somente deverá ser marcado como disponível quando:

existir uma issue e uma implementação revisada;
os critérios de aceite estiverem validados;
houver teste proporcional ao risco;
o perfil autorizado estiver definido;
a instrução tiver sido conferida contra a versão executável;
imagens e exemplos não contiverem dados pessoais ou credenciais;
a equipe ou o responsável pelo processo tiver revisado a orientação de uso.

7. Pendências

Validar os perfis e permissões com os responsáveis.
Validar com os usuários a experiência da correção supervisionada já integrada.
Definir o procedimento de contingência da portaria.
Realizar teste de usabilidade com representantes dos perfis operacionais.
Substituir esta estrutura por instruções verificadas e imagens seguras à medida que cada fluxo for entregue.

8. Histórico

Versão	Data	Alteração
0.1	26/08/2026	Estrutura inicial criada, com distinção explícita entre base técnica e funcionalidades disponíveis
0.2	28/08/2026	Registrado o primeiro fluxo operacional da API
0.3	29/08/2026	Registrados o fluxo institucional e os catálogos de frota e motoristas
0.4	29/08/2026	Registradas a consulta histórica institucional e a manutenção controlada da frota
0.5	29/08/2026	Registrada a consulta histórica paginada do fluxo geral
0.6	29/08/2026	Registrada a correção descritiva rastreável dos acessos gerais
1.2	31/08/2026	Documentada a preparação repetível e segura de dados fictícios para demonstração local
1.3	03/09/2026	Documentado o fluxo geral do frontend integrado à API pela Issue #118 e pelo PR #136
1.4	04/09/2026	Documentado o catálogo ativo da frota integrado pela Issue #138 e pelo PR #139
1.5	07/09/2026	Documentado o catálogo ativo de motoristas integrado pela Issue #141 e pelo PR #142
1.6	07/09/2026	Documentadas as autorizações de eventos integradas pela Issue #148 e pelo PR #149
1.7	07/09/2026	Documentadas as utilizações institucionais integradas pela Issue #152 e pelo PR #153
1.8	08/09/2026	Documentado o resumo operacional integrado pela Issue #155 e pelo PR #156
1.9	08/09/2026	Documentada a administração de contas integrada pela Issue #158 e pelo PR #159
2.0	08/09/2026	Documentada a consulta administrativa da auditoria integrada pela Issue #161 e pelo PR #164
2.1	09/09/2026	Documentado o fluxo consecutivo de entradas gerais incorporado pela Issue #167 e pelo PR #168
2.2	23/09/2026	Documentados credencial temporária, primeiro acesso obrigatório e redefinição administrativa integrados pelo PR #259
2.3	24/09/2026	Registrada a manutenção de autorizações de eventos exclusiva do Administrador após a Issue #270 e o PR #280
2.4	29/09/2026	Registrados dois Administradores funcionais e entrega direta da credencial temporária conforme a Issue #220 e o PR #304
2.5	05/10/2026	Sincronizada a correção descritiva supervisionada pelo Setor de Transporte incorporada pelo PR #396
2.6	13/10/2026	Sincronizadas a modernização visual dos PRs #419, #420 e #426 e as métricas operacionais reais do PR #425