Estado do projeto e handoff

Atualizado em: 15 de outubro de 2026 Fase: Fases 1 a 6 concluídas; Fase 7 em curso (identidade, saúde, recuperação e ligação de leitura ao Snipe-IT de produção concluídas) Último agente: Devin

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.
Preflight remoto obrigatório antes de checkout; ativos já atribuídos são recusados sem qualquer pedido de escrita.
Check-in condicionado a checkout confirmado pelo portal para o mesmo requisitante e a atribuição remota atual ao respetivo utilizador Snipe-IT.
Snipe-IT de produção formalmente limitado a leitura, checkout e check-in: criar, editar ou eliminar inventário é proibido no código, diagnóstico e procedimentos de agentes.
Á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.
Gestão administrativa de utilizadores com pesquisa, perfis múltiplos, estado ativo, departamento, ID Snipe-IT e reposição de palavra-passe.
Proteção contra desativação da própria conta administrativa e contra remoção do último administrador ativo.
Políticas de reserva editáveis para antecedência, duração, margem operacional, prazo de aprovação e limite de equipamentos.
Margens temporais persistidas por item e garantidas pela restrição de exclusão PostgreSQL, sem reescrever reservas existentes quando a política muda.
Calendário institucional global para aprovadores, operadores, administradores e auditores.
Relatórios por período com totais, horas de utilização, incidentes, atrasos, estados, categorias, departamentos e equipamentos mais requisitados.
Exportação CSV protegida contra formula injection e limitada a períodos de 366 dias.
Consulta paginada e filtrável de audit_logs, apenas para administradores e auditores.
Modelos editáveis de assunto/mensagem para os seis eventos de notificação, com variáveis validadas e auditoria das alterações.
Autenticação Microsoft Entra/OIDC de tenant único com descoberta .well-known, Authorization Code Flow, PKCE, state, nonce e validação criptográfica RS256.
Associação Microsoft explícita após login local e confirmação recente da palavra-passe; nenhuma conta é associada automaticamente por email.
Login Microsoft para identidades previamente associadas, bloqueio de contas inativas e eventos de associação/login/remoção em auditoria.
Endpoints /health/live e /health/ready, sendo readiness dependente de PostgreSQL e cache sem divulgar detalhes internos.
Health check Docker do Nginx sobre readiness.
Scripts operacionais de backup PostgreSQL custom com checksum e restauro de teste numa base temporária isolada.
Checklist versionado de produção, incluindo Entra, Snipe-IT, SMTP/TLS, segredos, monitorização, recuperação, segurança e piloto.
Melhoria na validação do formulário de requisição: erros de validação são agora acumulados e mostrados simultaneamente em vez de parar no primeiro erro.
Validação limpa erros de campos já corrigidos ao clicar em submeter, mantendo apenas os erros dos campos ainda incorretos.
Endpoint /requisicoes/verificar-disponibilidade-semanal para verificar disponibilidade de equipamentos baseado em slots semanais.
Botão "Verificar equipamentos livres" visível quando a repetição semanal está ativa, permitindo filtrar o catálogo pela próxima ocorrência semanal.

Limites conhecidos

A URL e os dois tokens distintos estão configurados localmente e responderam com sucesso a pedidos GET em 5 de agosto de 2026. A sincronização integral de leitura importou 2367 ativos para o cache local, dos quais 716 estavam atribuídos e 144 marcados como requisitáveis. Não foi executada qualquer escrita real. Falta confirmar institucionalmente a versão, o menor privilégio efetivo dos tokens e as categorias/estados autorizados.
Microsoft Entra ID está implementado e testado com tokens assinados simulados; falta registar/configurar a aplicação no tenant institucional e validar Conditional Access/MFA real.
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.
As exportações administrativas estão disponíveis em CSV; XLSX poderá ser acrescentado se o processo institucional o exigir.

Próxima tarefa recomendada

Continuar com a Fase 7 — hardening e entrada em produção:

configurar e validar Microsoft Entra no tenant institucional, incluindo Conditional Access/MFA;
confirmar com o responsável Snipe-IT a versão, o âmbito de menor privilégio dos tokens e as categorias/estados requisitáveis; validar checkout/check-in apenas no primeiro movimento institucional legítimo;
configurar SMTP institucional, domínio, HTTPS e gestão externa de segredos;
ligar os health checks a monitorização/alertas e agendar backups cifrados externos;
executar testes de segurança, concorrência, desempenho e end-to-end com equipamentos reais;
preparar formação, dados iniciais e piloto com um grupo reduzido;
corrigir resultados do piloto e preparar a disponibilização geral.

Testes da última sessão

Validação concluída em 15 de outubro de 2026:

TypeScript: passou
ESLint: passou
Vite build: passou
Validação de formulário corrigida: removido listener global de erros do Inertia e adicionado preserveState/preserveScroll para garantir que erros aparecem inline por baixo de cada campo

Validação concluída em 14 de outubro de 2026:

docker compose exec -T app composer test: passou;
Laravel Pint: 147 ficheiros sem desvios;
PHPStan/Larastan nível 7: 109 ficheiros, zero erros;
Pest: 113 testes passaram, 638 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;
Modal de detalhes do dia nos calendários pessoal e global implementado, mostrando todas as requisições de um dia com estado, horário, equipamentos e requisitante;
Fuso horário da aplicação alterado de UTC para Europe/Lisbon para garantir consistência com o PHP e evitar discrepâncias de horário entre frontend e backend;
Correção da conversão de data no frontend para usar fuso horário local em vez de UTC, evitando desvios de horário na data de repetição.

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.

Próximo ficheiro a abrir

Começar em docs/PRODUCTION_CHECKLIST.md. Para Snipe-IT, confirmar versão, categorias/estados e permissões efetivas com o responsável institucional; não executar testes de escrita. A próxima alteração de código pode preparar testes de concorrência/desempenho e observabilidade local. Entra, SMTP e o primeiro movimento Snipe-IT só ficam concluídos com validação institucional, sem guardar segredos no repositório.

11 KiB Raw Blame History