Files
reservas/docs/PROJECT_STATUS.md

7.9 KiB

Estado do projeto e handoff

Atualizado em: 4 de agosto de 2026
Fase: Fases 1 a 5 concluídas; próxima entrega: Fase 6 Último agente: Codex

Resultado disponível

  • Projeto oficial Laravel 13 React Starter Kit criado.
  • Autenticação local via Fortify, recuperação de palavra-passe, verificação de email, 2FA e passkeys.
  • Registo público desativado conforme o plano.
  • Estrutura relacional de utilizadores, identidades externas, perfis e permissões.
  • Cache local de ativos Snipe-IT.
  • Modelo completo inicial para reservas, itens, aprovações, bloqueios, entrega/devolução, sincronizações e auditoria.
  • Proteção PostgreSQL contra períodos sobrepostos para o mesmo equipamento através de EXCLUDE USING gist e intervalos [início, fim).
  • Serviço de disponibilidade que considera estado local, atribuição, reservas e bloqueios.
  • Criação transacional de uma requisição pendente com vários equipamentos e registo de auditoria.
  • Dashboard pessoal, catálogo com pesquisa/filtros, formulário de nova requisição e histórico.
  • Docker Compose com Nginx, PHP-FPM, PostgreSQL, Redis, Node/Vite, filas, scheduler e Mailpit.
  • Dados fictícios e duas contas locais para desenvolvimento.
  • Cliente Snipe-IT autenticado com paginação, timeout, retry seletivo e validação de respostas.
  • Sincronização convergente de ativos com histórico, hash de conteúdo, lock, job único e desativação apenas após execução completa.
  • Comando snipe:sync-assets, execução horária e painel de diagnóstico exclusivo para administradores.
  • Pesquisa do catálogo por início/fim que exclui atribuições atuais, reservas bloqueantes e bloqueios administrativos.
  • Propagação do período consultado do catálogo para o formulário e consulta atualizável de equipamentos livres.
  • Cancelamento pelo próprio requisitante, com validação de estado, libertação transacional dos itens e auditoria.
  • Expiração de pré-reservas vencidas através do comando reservations:expire e job único agendado a cada cinco minutos.
  • Calendário mensal pessoal, isolado por utilizador e com navegação entre meses.
  • Área de aprovação protegida por perfil, com pesquisa por referência/requisitante.
  • Aprovação, rejeição e pedido de esclarecimentos transacionais, registados em approval_actions e audit_logs.
  • Aprovação revalida disponibilidade e estado operacional do ativo antes de promover itens held para reserved.
  • Notificações assíncronas por email e base de dados para submissões, decisões, esclarecimentos e substituições.
  • Caixa interna de notificações, contador de não lidas, marcação individual/coletiva e isolamento por utilizador.
  • Resposta auditada do requisitante a esclarecimentos, com regresso a pending_approval e novo prazo de 48 horas.
  • Substituição de equipamento apenas por ativo livre da mesma categoria, mantendo a pré-reserva e todo o histórico.
  • Fila de aprovação com filtros por referência, requisitante, categoria e período, incluindo histórico de ações.
  • Cliente Snipe-IT operacional com token separado, checkout para utilizador, check-in para a localização habitual e validação de erros transportados em HTTP 200.
  • Área diária do operador protegida pelo perfil inventory_operator/administrator, com leitura por scanner-teclado ou pesquisa de referência, requisitante, etiqueta e ID Snipe-IT.
  • Preparação, entrega, devolução e conclusão com máquina de estados, condição física, observações, operador, destinatário e resposta externa em handover_records.
  • Associação persistente entre o utilizador do portal e o respetivo ID no Snipe-IT, confirmada durante uma entrega bem-sucedida.
  • Tratamento explícito de falhas parciais: movimentos já aceites são preservados, a requisição passa a incident e a falha fica em audit_logs para reconciliação.
  • Registo de falta, atraso e incidente; um incidente pode criar um bloqueio temporal do equipamento que entra imediatamente no motor de disponibilidade.

Limites conhecidos

  • A integração está implementada e testada contra respostas simuladas; falta configurar e validar URL, versão e token da instância institucional. Até lá, o catálogo utiliza dados fictícios do seeder.
  • Microsoft Entra ID ainda não está implementado; as variáveis de ambiente já estão definidas.
  • As notificações estão implementadas com Mailpit em desenvolvimento; falta validar SMTP institucional antes do piloto.
  • O calendário atual é a vista mensal pessoal do MVP; vistas diária, semanal, global e por equipamento/categoria/localização ficam para as áreas operacional e administrativa.
  • O leitor operacional aceita scanners QR/código de barras que funcionem como teclado. A leitura direta pela câmara do navegador ainda não foi adicionada.
  • Uma falha depois de o Snipe-IT confirmar um movimento e antes do commit local é uma transação distribuída ambígua; não existe retry automático de escritas. O operador deve reconciliar pelos registos Snipe-IT e audit_logs conforme o runbook.

Próxima tarefa recomendada

Implementar a Fase 6 — administração e relatórios:

  1. criar a área administrativa de utilizadores, perfis e associação ao ID Snipe-IT;
  2. tornar configuráveis as políticas de antecedência, duração, margens, estados e categorias;
  3. criar calendário global e relatórios de utilização, atrasos, incidentes e ativos mais requisitados;
  4. adicionar exportação CSV/XLSX e filtros por período, categoria, departamento e estado;
  5. criar consulta de auditoria apenas de leitura para o perfil auditor;
  6. adicionar métricas operacionais e gestão de modelos de email;
  7. cobrir autorização, exportações e agregações com testes e atualizar toda a documentação.

Testes da última sessão

Validação concluída em 4 de agosto de 2026:

  • docker compose exec -T app composer test: passou;
  • Laravel Pint: 117 ficheiros sem desvios;
  • PHPStan/Larastan nível 7: 89 ficheiros, zero erros;
  • Pest: 79 testes passaram, 412 asserções e 2 testes de registo ignorados por a funcionalidade estar deliberadamente desativada;
  • TypeScript (tsc --noEmit): passou;
  • ESLint: passou;
  • Prettier: passou;
  • Vite: builds cliente e SSR concluídos, 2309 módulos cliente e 98 módulos SSR transformados;
  • PostgreSQL 17: migrate:fresh --seed concluído, incluindo extensão btree_gist e restrição de exclusão temporal;
  • PostgreSQL 17: migration incremental do marcador last_seen_sync_run_id aplicada com sucesso;
  • PostgreSQL 17: nenhuma migration pendente; comando de expiração executado e agendamentos horário/a cada cinco minutos confirmados;
  • PostgreSQL 17: migration notifications aplicada com sucesso;
  • PostgreSQL 17: migration snipe_user_id aplicada e fluxo operacional exercitado contra API simulada;
  • smoke test HTTP: /login respondeu com estado 200 através do Nginx;
  • Vite em Docker: URL pública, HMR e CORS verificados em localhost:5173; corrigida a página em branco causada pela publicação anterior de 0.0.0.0:5173;
  • Inertia SSR: renderização do login validada através do serviço node; corrigido o componente de mensagens flash que usava usePage() fora do contexto Inertia;
  • verificação visual no browser integrado: a inspeção controlada de localhost continua impedida por uma política administrativa temporariamente indisponível; aprovações, esclarecimentos e notificações foram validados por testes Inertia, TypeScript e builds cliente/SSR.

Decisões pendentes do contexto institucional

Estas decisões não bloqueiam o desenvolvimento com defaults seguros, mas devem ser confirmadas antes do piloto:

  • versão e URL da instância Snipe-IT;
  • categorias e estados requisitáveis;
  • tenant, client ID e redirect URI do Entra ID;
  • matriz final de aprovadores por categoria/departamento;
  • duração máxima, antecedência e margens por categoria;
  • domínio institucional e método de emissão TLS;
  • SMTP institucional.