feat: complete approval workflow

docs/ARCHITECTURE.md

@@ -32,7 +32,6 @@ Nginx ──► Laravel + Inertia/React
 - `app/Domain/Identity`: perfis, permissões e identidades externas.
 - `app/Domain/Inventory`: cache local de ativos e consultas do catálogo.
 - `app/Domain/Reservations`: disponibilidade, estados, regras e requisições.
-- `app/Domain/Approvals`: decisões e concorrência de aprovação (a criar).
 - `app/Domain/Approvals`: decisões, histórico e concorrência de aprovação.
 - `app/Domain/Handovers`: entrega, devolução e incidentes (a criar).
 - `app/Domain/Audit`: logs imutáveis pela interface.
@@ -53,6 +52,10 @@ Uma criação ou aprovação deve bloquear as linhas dos ativos, voltar a valida
 
 Pré-reservas ficam bloqueantes em `held` enquanto aguardam decisão. `ReservationService` centraliza criação, cancelamento e expiração: todas as transições bloqueiam a requisição, atualizam os itens bloqueantes e criam um `AuditLog`. Um job único procura prazos vencidos a cada cinco minutos. A restrição GiST continua a proteger contra corridas entre estes ciclos de vida.
 
+`ApprovalService` bloqueia a requisição e os ativos antes de aprovar ou substituir, revalida a disponibilidade e regista cada passo em `approval_actions` e `audit_logs`. Uma substituição cancela o item original e cria um novo `held`, apenas na mesma categoria. Pedidos e respostas de esclarecimento conservam o histórico e renovam explicitamente o prazo.
+
+Notificações implementam `ShouldQueue`, usam `afterCommit` e seguem dois canais: email e tabela `notifications`. A caixa interna consulta exclusivamente a relação polimórfica do utilizador autenticado, evitando acesso horizontal a notificações de terceiros.
+
 ## Fluxo de dados Snipe-IT
 
 1. Um job consulta a API paginada com token de leitura.