feat: dispositivos e ajustes de csat e relatórios

docs/OPERACAO-PRODUCAO.md

@@ -13,11 +13,11 @@ Nota: este documento foi substituído por `docs/operations.md` e permanece aqui
 - Seeds prontos (Better Auth e dados demo Convex).
  - Seeds Better Auth automáticos: o container do web executa `pnpm auth:seed` após `prisma migrate deploy`, garantindo usuários padrão em toda inicialização (sem resetar senha existente por padrão).
 
-### Sessão de máquina (Desktop/Tauri)
+### Sessão de dispositivo (Desktop/Tauri)
 - A rota `GET /machines/handshake?token=...&redirect=/portal|/dashboard` é pública no middleware para permitir a criação da sessão "machine" a partir do agente desktop, mesmo sem login prévio.
 - Após o handshake, o servidor grava cookies de sessão (Better Auth) e um cookie `machine_ctx` com o vínculo (persona, assignedUser*, etc.). Em seguida, o App carrega `/api/machines/session` para preencher o contexto no cliente (`machineContext`).
 - Com esse contexto, o Portal exibe corretamente o nome/e‑mail do colaborador/gestor no cabeçalho e permite abrir chamados em nome do usuário vinculado.
-- Em sessões de máquina, o botão "Encerrar sessão" no menu do usuário é ocultado por padrão na UI interna.
+- Em sessões de dispositivo, o botão "Encerrar sessão" no menu do usuário é ocultado por padrão na UI interna.
 
 #### Detalhes importantes (aprendidos em produção)
 - CORS com credenciais: as rotas `POST /api/machines/sessions` e `GET /machines/handshake` precisam enviar `Access-Control-Allow-Credentials: true` para que os cookies do Better Auth sejam aceitos na WebView.
@@ -72,7 +72,7 @@ SMTP_ENABLE_STARTTLS_AUTO=false
 SMTP_TLS=true
 MAILER_SENDER_EMAIL="Nome <no-reply@seu-dominio.com>"
 
-# Máquina/inventário
+# Dispositivo/inventário
 MACHINE_PROVISIONING_SECRET=<hex forte>
 MACHINE_TOKEN_TTL_MS=2592000000
 FLEET_SYNC_SECRET=<hex forte ou igual ao de provisionamento>
@@ -239,7 +239,7 @@ docker run --rm -it \
 
 ### Smoke test pós‑deploy (CI)
 O pipeline executa um teste rápido após o deploy do Web:
-- Registra uma máquina fake usando `MACHINE_PROVISIONING_SECRET` do `/srv/apps/sistema/.env`
+- Registra uma dispositivo fake usando `MACHINE_PROVISIONING_SECRET` do `/srv/apps/sistema/.env`
 - Espera `HTTP 201` e extrai `machineToken`
 - Envia `heartbeat` e espera `HTTP 200`
 - Se falhar, o job é marcado como erro (evita regressões silenciosas)

docs/OPERATIONS.md

@@ -59,28 +59,28 @@ Este documento consolida as mudanças recentes, o racional por trás delas e o p
       - “Bring convex.json from live app if present” (usa o arquivo de link do projeto em `/srv/apps/sistema`).
       - “convex env list” e “convex deploy” com `CONVEX_SELF_HOSTED_URL` + `CONVEX_SELF_HOSTED_ADMIN_KEY`.
 
-## 4) Troca de colaborador / reaproveitamento de máquina
+## 4) Troca de colaborador / reaproveitamento de dispositivo
 
-Quando um computador muda de dono (ex.: João entrega o equipamento antigo para Maria e recebe uma máquina nova), siga este checklist para manter o inventário consistente:
+Quando um computador muda de dono (ex.: João entrega o equipamento antigo para Maria e recebe uma dispositivo nova), siga este checklist para manter o inventário consistente:
 
-1. **No painel (Admin → Máquinas)**
-   - Abra os detalhes da máquina que será reaproveitada (ex.: a “amarela” que passará da TI/João para a Maria).
+1. **No painel (Admin → Dispositivos)**
+   - Abra os detalhes da dispositivo que será reaproveitada (ex.: a “amarela” que passará da TI/João para a Maria).
    - Clique em **Resetar agente**. Isso revoga todos os tokens gerados para aquele equipamento; ele precisará ser reprovisionado antes de voltar a reportar dados.
    - Abra **Ajustar acesso** e altere o e-mail para o do novo usuário (Maria). Assim, quando o agente se registrar novamente, o painel já mostrará a responsável correta.
 
-2. **Na máquina física que ficará com o novo colaborador**
+2. **Na dispositivo física que ficará com o novo colaborador**
    - Desinstale o desktop agent (Painel de Controle → remover programas).
-   - Instale novamente o desktop agent. Use o mesmo **código da empresa/tenant** e informe o **e-mail do novo usuário** (Maria). O backend emite um token novo e reaproveita o registro da máquina, mantendo o histórico.
+   - Instale novamente o desktop agent. Use o mesmo **código da empresa/tenant** e informe o **e-mail do novo usuário** (Maria). O backend emite um token novo e reaproveita o registro da dispositivo, mantendo o histórico.
 
-3. **Máquina nova para o colaborador antigo**
-   - Instale o desktop agent do zero na máquina que o João vai usar (ex.: a “azul”). Utilize o mesmo código da empresa e o e-mail do João.
-   - A máquina azul aparecerá como um **novo registro** no painel (inventário/tickets começarão do zero). Renomeie/associe conforme necessário.
+3. **Dispositivo nova para o colaborador antigo**
+   - Instale o desktop agent do zero na dispositivo que o João vai usar (ex.: a “azul”). Utilize o mesmo código da empresa e o e-mail do João.
+   - A dispositivo azul aparecerá como um **novo registro** no painel (inventário/tickets começarão do zero). Renomeie/associe conforme necessário.
 
 4. **Verificação final**
-   - A máquina antiga (amarela) continua listada, agora vinculada à Maria, com seus tickets históricos.
-   - A máquina nova (azul) aparece como um segundo registro para o João. Ajuste hostname/descrição para facilitar a identificação.
+   - A dispositivo antiga (amarela) continua listada, agora vinculada à Maria, com seus tickets históricos.
+   - A dispositivo nova (azul) aparece como um segundo registro para o João. Ajuste hostname/descrição para facilitar a identificação.
 
-> Não é necessário excluir registros. Cada máquina mantém seu histórico; o reset garante apenas que o token antigo não volte a sobrescrever dados quando o hardware mudar de mãos.
+> Não é necessário excluir registros. Cada dispositivo mantém seu histórico; o reset garante apenas que o token antigo não volte a sobrescrever dados quando o hardware mudar de mãos.
     - Importante: não usar `CONVEX_DEPLOYMENT` em conjunto com URL + ADMIN_KEY.
 
 - Como forçar o deploy do Convex
@@ -161,7 +161,7 @@ Depois disso, o job “Deploy Convex functions” funciona em modo não interati
   - Front envia `assigneeId` e o backend Convex deve aceitar esse parâmetro (função `tickets.list`).
   - Se necessário, forçar redeploy das funções (`convex/**`).
 
-- Admin ▸ Máquinas travado em skeleton infinito
+- Admin ▸ Dispositivos travado em skeleton infinito
   - Abra o DevTools (console) e filtre por `admin-machine-details`. Se o log mostrar `machineId: undefined`, o componente não recebeu o parâmetro da rota.
   - Verifique se o `page.tsx` está passando `params.id` corretamente ou se o componente client-side usa `useParams()` / `machineId` opcional.
   - Deploys antigos antes de `fix(machines): derive machine id from router params` precisam desse patch; sem ele o fallback nunca dispara e o skeleton permanece.
@@ -170,30 +170,30 @@ Depois disso, o job “Deploy Convex functions” funciona em modo não interati
 
 Última atualização: sincronizado após o deploy bem‑sucedido do Convex e do Front (20/10/2025).
 
-## 9) Admin ▸ Usuários e Máquinas — Unificação e UX
+## 9) Admin ▸ Usuários e Dispositivos — Unificação e UX
 
-Resumo das mudanças aplicadas no painel administrativo para simplificar “Usuários” e “Agentes de máquina” e melhorar o filtro em Máquinas:
+Resumo das mudanças aplicadas no painel administrativo para simplificar “Usuários” e “Agentes de dispositivo” e melhorar o filtro em Dispositivos:
 
-- Unificação de “Usuários” e “Agentes de máquina”
-  - Antes: abas separadas “Usuários” (pessoas) e “Agentes de máquina”.
-  - Agora: uma só aba “Usuários” com filtro de tipo (Todos | Pessoas | Máquinas).
+- Unificação de “Usuários” e “Agentes de dispositivo”
+  - Antes: abas separadas “Usuários” (pessoas) e “Agentes de dispositivo”.
+  - Agora: uma só aba “Usuários” com filtro de tipo (Todos | Pessoas | Dispositivos).
   - Onde: `src/components/admin/admin-users-manager.tsx:923`, aba `value="users"` em `:1147`.
   - Motivo: evitar confusão entre “usuário” e “agente”; agentes são um tipo especial de usuário (role=machine). A unificação torna “Convites e Acessos” mais direta.
 
-- Máquinas ▸ Filtro por Empresa com busca e remoção do filtro de SO
+- Dispositivos ▸ Filtro por Empresa com busca e remoção do filtro de SO
   - Adicionado dropdown de “Empresa” com busca (Popover + Input) e removido o filtro por Sistema Operacional.
-  - Onde: `src/components/admin/machines/admin-machines-overview.tsx:1038` e `:1084`.
+  - Onde: `src/components/admin/devices/admin-devices-overview.tsx:1038` e `:1084`.
   - Motivo: fluxo real usa empresas com mais frequência; filtro por SO era menos útil agora.
 
 - Windows ▸ Rótulo do sistema sem duplicidade do “major”
   - Exemplo: “Windows 11 Pro (26100)” em vez de “Windows 11 Pro 11 (26100)”.
-  - Onde: `src/components/admin/machines/admin-machines-overview.tsx` (função `formatOsVersionDisplay`).
+  - Onde: `src/components/admin/devices/admin-devices-overview.tsx` (função `formatOsVersionDisplay`).
   - Motivo: legibilidade e padronização em chips/cartões.
 
-- Vínculos visuais entre máquinas e pessoas
-  - Cards de máquinas mostram “Usuário vinculado” quando disponível (assignment/metadata): `src/components/admin/machines/admin-machines-overview.tsx:3198`.
-  - Editor de usuário exibe “Máquinas vinculadas” (derivado de assign/metadata): `src/components/admin/admin-users-manager.tsx` (seção “Máquinas vinculadas” no sheet de edição).
-  - Observação: por ora é leitura; ajustes detalhados de vínculo permanecem em Admin ▸ Máquinas.
+- Vínculos visuais entre dispositivos e pessoas
+  - Cards de dispositivos mostram “Usuário vinculado” quando disponível (assignment/metadata): `src/components/admin/devices/admin-devices-overview.tsx:3198`.
+  - Editor de usuário exibe “Dispositivos vinculadas” (derivado de assign/metadata): `src/components/admin/admin-users-manager.tsx` (seção “Dispositivos vinculadas” no sheet de edição).
+  - Observação: por ora é leitura; ajustes detalhados de vínculo permanecem em Admin ▸ Dispositivos.
 
 ### Identidade, e‑mail e histórico (reinstalação)
 
@@ -202,20 +202,20 @@ Resumo das mudanças aplicadas no painel administrativo para simplificar “Usu
 - Novo e‑mail como nova conta: se criar um usuário novo (novo `userId`), será considerado um colaborador distinto e não herdará o histórico.
 - Caso precise migrar histórico entre contas diferentes (merge), recomendamos endpoint/rotina de “fusão de contas” (remapear `userId` antigo → novo). Não é necessário para a troca de e‑mail da mesma conta.
 
-### Vínculos múltiplos de usuários por máquina (Fase 2)
+### Vínculos múltiplos de usuários por dispositivo (Fase 2)
 
 - Estrutura (Convex):
   - `machines.linkedUserIds: Id<"users">[]` — lista de vínculos adicionais além do `assignedUserId` (principal).
   - Mutations: `machines.linkUser(machineId, email)`, `machines.unlinkUser(machineId, userId)`.
-  - APIs admin: `POST /api/admin/machines/links` (body: `{ machineId, email }`), `DELETE /api/admin/machines/links?machineId=..&userId=..`.
+  - APIs admin: `POST /api/admin/devices/links` (body: `{ machineId, email }`), `DELETE /api/admin/devices/links?machineId=..&userId=..`.
 - UI:
-  - Detalhes da máquina mostram “Usuários vinculados” com remoção por item e campo para adicionar por e‑mail.
-  - Editor de usuário mostra “Máquinas vinculadas” consolidando assignment, metadata e `linkedUserIds`.
-- Racional: permitir que uma máquina tenha mais de um colaborador/gestor associado, mantendo um “principal” (persona) para políticas e contexto.
+  - Detalhes da dispositivo mostram “Usuários vinculados” com remoção por item e campo para adicionar por e‑mail.
+  - Editor de usuário mostra “Dispositivos vinculadas” consolidando assignment, metadata e `linkedUserIds`.
+- Racional: permitir que uma dispositivo tenha mais de um colaborador/gestor associado, mantendo um “principal” (persona) para políticas e contexto.
 
 ### Onde editar
 
 - Usuários (pessoas): editar nome, e‑mail, papel, tenant e empresa; redefinir senha pelo painel. Arquivo: `src/components/admin/admin-users-manager.tsx`.
-- Agentes (máquinas): provisionamento automático; edição detalhada/vínculo principal em Admin ▸ Máquinas. Arquivo: `src/components/admin/machines/admin-machines-overview.tsx`.
+- Agentes (dispositivos): provisionamento automático; edição detalhada/vínculo principal em Admin ▸ Dispositivos. Arquivo: `src/components/admin/devices/admin-devices-overview.tsx`.
 
-> Observação operacional: mantivemos o provisionamento de máquinas inalterado (token/e‑mail técnico), e o acesso web segue apenas para pessoas. A unificação é de UX/gestão.
+> Observação operacional: mantivemos o provisionamento de dispositivos inalterado (token/e‑mail técnico), e o acesso web segue apenas para pessoas. A unificação é de UX/gestão.

docs/admin/admin-inventory-ui.md

@@ -1,6 +1,6 @@
-# Admin UI — Inventário por máquina
+# Admin UI — Inventário por dispositivo
 
-A página Admin > Máquinas agora exibe um inventário detalhado e pesquisável do parque, com filtros e exportação.
+A página Admin > Dispositivos agora exibe um inventário detalhado e pesquisável do parque, com filtros e exportação.
 
 ## Filtros e busca
 - Busca livre por hostname, e-mail, MAC e número de série.
@@ -19,15 +19,15 @@ A página Admin > Máquinas agora exibe um inventário detalhado e pesquisável
   - Windows: informações de SO (edição, versão, build, data de instalação, experiência, ativação), resumo de hardware (CPU/Memória/GPU/Discos físicos com suporte a payloads únicos), serviços, lista completa de softwares com ação “Ver todos”, Defender.
   - macOS: pacotes (`pkgutil`), serviços (`launchctl`).
 - Postura/Alertas: CPU alta, serviço parado, SMART em falha com severidade e última avaliação.
-- Zona perigosa: ação para excluir a máquina (revoga tokens e remove inventário).
-- Ação administrativa extra: botão “Ajustar acesso” permite trocar colaborador/gestor e e-mail vinculados sem re-provisionar a máquina.
+- Zona perigosa: ação para excluir a dispositivo (revoga tokens e remove inventário).
+- Ação administrativa extra: botão “Ajustar acesso” permite trocar colaborador/gestor e e-mail vinculados sem re-provisionar a dispositivo.
 
 ## Exportação
 - Exportar CSV de softwares ou serviços diretamente da seção detalhada (quando disponíveis).
-- Exportar planilha XLSX completa (`/admin/machines/:id/inventory.xlsx`). A partir de 31/10/2025 a planilha contém:
+- Exportar planilha XLSX completa (`/admin/devices/:id/inventory.xlsx`). A partir de 31/10/2025 a planilha contém:
   - **Resumo**: data de geração, filtros aplicados, contagem por status e total de acessos remotos/alertas.
   - **Inventário**: colunas principais exibidas na UI (status, persona, hardware, token, build/licença do SO, domínio, colaborador, Fleet, etc.).
-  - **Vínculos**: usuários associados à máquina.
+  - **Vínculos**: usuários associados à dispositivo.
   - **Softwares**: lista deduplicada (nome + versão + origem/publisher). A coluna “Softwares instalados” no inventário bate com o total desta aba.
   - **Partições**: nome/mount/FS/capacidade/livre, convertendo unidades (ex.: 447 GB → bytes).
   - **Discos físicos**: modelo, tamanho, interface, tipo e serial de cada drive.
@@ -36,7 +36,7 @@ A página Admin > Máquinas agora exibe um inventário detalhado e pesquisável
   - **Serviços**: serviços coletados (Windows/Linux) com nome, display name e status.
   - **Alertas**: postura recente (tipo, mensagem, severidade, criado em).
   - **Métricas**: CPU/Memória/Disco/GPU com timestamp coletado.
-  - **Labels**: tags aplicadas à máquina.
+  - **Labels**: tags aplicadas à dispositivo.
   - **Sistema**: visão categorizada (Sistema, Dispositivo, Hardware, Acesso, Token, Fleet) contendo build, licença, domínio, fabricante, serial, colaborador, contagem de acessos, etc.
 
 ## Notas

docs/admin/companies-expanded-profile.md

@@ -24,7 +24,7 @@ Este documento resume a ampliação do cadastro de empresas (dados fiscais, cont
 - **Nova UI de Empresas** (`AdminCompaniesManager`): substituir pelo layout com listagem filtrável (lista + quadro) e formulário seccional ligado a `companyFormSchema` / `sanitizeCompanyInput`.
 - **Form dinâmico**: montar o formulário com React Hook Form + zod resolver usando os schemas/validações já prontos no backend.
 - **Área de Clientes → Usuários**: renomear a seção, carregar os novos campos (contatos, localizações, contratos) e reaproveitar as transformações do serviço.
-- **Máquinas**: expor o novo identificador de acesso remoto previsto no schema Convex/Prisma.
+- **Dispositivos**: expor o novo identificador de acesso remoto previsto no schema Convex/Prisma.
 - **Qualidade**: ajustar lint/testes após a nova UI e cobrir o fluxo de criação/edição com testes de integração.
 
 > Até que a nova interface seja publicada, a API já aceita todos os campos e qualquer cliente (front, automação, seed) deve usar `company-service.ts` para converter dados de/para Prisma, evitando divergências.

docs/alteracoes-2025-11-03.md

@@ -0,0 +1,27 @@
+# Alterações — 03/11/2025
+
+## Concluído
+- [x] Estruturado backend para `Dispositivos`: novos campos no Convex (`deviceType`, `deviceProfile`, custom fields), mutations (`saveDeviceProfile`, `saveDeviceCustomFields`) e tabelas auxiliares (`deviceFields`, `deviceExportTemplates`).
+- [x] Refatorado gerador de inventário XLSX para suportar seleção dinâmica de colunas, campos personalizados e nomenclatura de dispositivos.
+- [x] Renomeado "Máquinas" → "Dispositivos" em toda a navegação, rotas, botões (incluindo destaque superior) e mensagens de erro.
+- [x] UI do painel ajustada com criação manual de dispositivos, gerenciamento de campos personalizados, templates de exportação e inclusão de dispositivos móveis.
+- [x] Fluxo de CSAT revisado: mutation dedicada, timeline enriquecida, formulário de estrelas apenas para solicitante e dashboards com novos filtros/combobox.
+- [x] Diálogo de encerramento de ticket com vínculo opcional a outro ticket, prazo configurável de reabertura (7 ou 14 dias) e mensagem pré-visualizada.
+- [x] Botão de reabrir disponível para solicitante/equipe até o fim do prazo; timeline registra `TICKET_REOPENED`.
+- [x] Chat em tempo real incorporado ao detalhe do ticket (listagem live, envio, leitura automática, bloqueio pós-prazo).
+- [x] Formulários dinâmicos para admissão/desligamento com escopo e permissões por empresa/usuário; `create` envia `formTemplate` e `customFields`.
+- [x] Corrigidos mocks/tipagens das rotinas de resolução e reabertura (`resolveTicketHandler`, `reopenTicketHandler`) garantindo `pnpm lint`, `pnpm test` e `pnpm build` verdes.
+- [x] Atualizado schema/tipagens (`TicketWithDetails`, `ChartTooltipContent`) e dashboards CSAT para suportar reabertura com prazos e tooltips formatados.
+- [x] Reatribuição de chamado sem motivo obrigatório; comentário interno só é criado quando o motivo é preenchido.
+- [x] Botão “Novo dispositivo” reutiliza o mesmo primário padrão do shadcn usado em “Nova empresa”, mantendo a identidade visual.
+- [x] Cartão de CSAT respeita a role normalizada (inclusive em sessões de dispositivos), só aparece para a equipe após o início do atendimento e mostra aviso quando ainda não há avaliações.
+- [x] Dashboard de abertos x resolvidos usa buscas indexadas por data, evitando timeouts no Convex.
+
+## Riscos
+- Necessário validar migração dos dados existentes (máquinas → dispositivos) antes de entrar em produção.
+- Testes de SMTP/entregabilidade precisam ser executados para garantir que notificações sigam as novas regras de pausa/comentário.
+
+## Pendências
+- [ ] Validar comportamento de notificações (pausa/comentário) com infraestrutura de e-mail real.
+- [ ] Executar migração de dados existente antes do deploy (mapear máquinas → dispositivos e revisar templates legados).
+- [ ] Cobertura de testes automatizados para chat e formulários dinâmicos (resolve/reopen já cobertos).

docs/archive/plano-app-desktop-dispositivos.md

@@ -1,11 +1,11 @@
-# Plano Integrado – App Desktop & Inventário por Máquina (Arquivo)
+# Plano Integrado – App Desktop & Inventário por Dispositivo (Arquivo)
 
 > Documento vivo. Atualize após cada marco relevante.
 
 ## Contexto
 - **Objetivo:** Expandir o Sistema de Chamados (Next.js + Convex + Better Auth) para suportar:
   - Cliente desktop nativo (Tauri) mantendo UI web e realtime.
-  - Autenticação máquina-a-máquina usando tokens derivados do inventário.
+  - Autenticação dispositivo-a-dispositivo usando tokens derivados do inventário.
   - Integração com agente de inventário (osquery/FleetDM) para registrar hardware, software e heartbeats.
   - Pipeline de distribuição para Windows/macOS/Linux.
 - **Escopo inicial:** Focar no fluxo mínimo viável com inventário básico (hostname, OS, identificadores, carga resumida). Métricas avançadas e distribuição automatizada ficam para iteração seguinte.
@@ -21,12 +21,12 @@
 | --- | --- | --- |
 | Documento de arquitetura e roadmap | 🔄 Em andamento | Estrutura criada, aguardando detalhamento incremental a cada etapa. |
 | Projeto Tauri inicial apontando para UI Next | 🔄 Em andamento | Estrutura `apps/desktop` criada; pendente testar build após instalar toolchain Rust. |
-| Schema Convex + tokens de máquina | ✅ Concluído | Tabelas `machines` / `machineTokens` criadas com TTL e fingerprint. |
+| Schema Convex + tokens de dispositivo | ✅ Concluído | Tabelas `machines` / `machineTokens` criadas com TTL e fingerprint. |
 | API de registro/heartbeat e exchange Better Auth | 🔄 Em andamento | Endpoints `/api/machines/*` disponíveis; falta testar fluxo end-to-end com app desktop. |
 | Endpoint upsert de inventário dedicado | ✅ Concluído | `POST /api/machines/inventory` (modo por token ou provisioningSecret). |
 | Integração FleetDM → Convex (inventário básico) | 🔄 Em andamento | Endpoint `/api/integrations/fleet/hosts` criado; falta validar payload real e ajustes de métricas/empresa. |
-| Admin > Máquinas (listagem, detalhes, métricas) | ✅ Concluído | Página `/admin/machines` exibe parque completo com status ao vivo, inventário e métricas. |
-| Ajustes na UI/Next para sessão por máquina | ⏳ A fazer | Detectar token e exibir info da máquina em tickets. |
+| Admin > Dispositivos (listagem, detalhes, métricas) | ✅ Concluído | Página `/admin/devices` exibe parque completo com status ao vivo, inventário e métricas. |
+| Ajustes na UI/Next para sessão por dispositivo | ⏳ A fazer | Detectar token e exibir info da dispositivo em tickets. |
 | Pipeline de build/distribuição Tauri | ⏳ A fazer | Definir estratégia CI/CD + auto-update. |
 | Guia operacional (instalação, uso, suporte) | ⏳ A fazer | Gerar instruções finais com casos de uso. |
 
@@ -48,23 +48,23 @@ Legenda: ✅ concluído · 🔄 em andamento · ⏳ a fazer.
 
 ## Notas de Implementação (Atual)
 - Criada pasta `apps/desktop` via `create-tauri-app` com template `vanilla-ts`.
-- O agente desktop agora possui fluxo próprio: coleta inventário local via comandos Rust, solicita o código de provisionamento, registra a máquina e inicia heartbeats periódicos (`src-tauri/src/agent.rs` + `src/main.ts`).
+- O agente desktop agora possui fluxo próprio: coleta inventário local via comandos Rust, solicita o código de provisionamento, registra a dispositivo e inicia heartbeats periódicos (`src-tauri/src/agent.rs` + `src/main.ts`).
 - Formulário inicial exibe resumo de hardware/OS e salva o token em `~/.config/Sistema de Chamados Desktop/machine-agent.json` (ou equivalente por SO) para reaproveitamento em relançamentos.
 - URLs configuráveis via `.env` do app desktop:
   - `VITE_APP_URL` → aponta para a interface Next (padrao produção: `https://tickets.esdrasrenan.com.br`).
   - `VITE_API_BASE_URL` → base usada nas chamadas REST (`/api/machines/*`), normalmente igual ao `APP_URL`.
-- Após provisionar ou encontrar token válido, o agente dispara `/machines/handshake?token=...` que autentica a máquina no Better Auth, devolve cookies e redireciona para a UI. Em produção, mantemos a navegação top‑level pelo handshake para garantir a aceitação de cookies na WebView (mesmo quando `POST /api/machines/sessions` é tentado antes).
+- Após provisionar ou encontrar token válido, o agente dispara `/machines/handshake?token=...` que autentica a dispositivo no Better Auth, devolve cookies e redireciona para a UI. Em produção, mantemos a navegação top‑level pelo handshake para garantir a aceitação de cookies na WebView (mesmo quando `POST /api/machines/sessions` é tentado antes).
 - `apps/desktop/src-tauri/tauri.conf.json` ajustado para rodar `pnpm run dev/build`, servir `dist/` e abrir janela 1100x720.
 - Novas tabelas Convex: `machines` (fingerprint, heartbeat, vínculo com AuthUser) e `machineTokens` (hash + TTL).
 - Novos endpoints Next:
-  - `POST /api/machines/register` — provisiona máquina, gera token e usuário Better Auth (role `machine`).
+  - `POST /api/machines/register` — provisiona dispositivo, gera token e usuário Better Auth (role `machine`).
   - `POST /api/machines/heartbeat` — atualiza estado, métricas e renova TTL.
   - `POST /api/machines/sessions` — troca `machineToken` por sessão Better Auth e devolve cookies.
 - As rotas `/api/machines/*` respondem a preflight `OPTIONS` com CORS liberado para o agente (`https://tickets.esdrasrenan.com.br`, `tauri://localhost`, `http://localhost:1420`).
-- Rota `GET /machines/handshake` realiza o login automático da máquina (seta cookies e redireciona).
+- Rota `GET /machines/handshake` realiza o login automático da dispositivo (seta cookies e redireciona).
   - As rotas `sessions/handshake` foram ajustadas para usar `NextResponse.cookies.set(...)`, aplicando cada cookie da Better Auth (sessão e assinatura) individualmente.
   - CORS: as respostas incluem `Access-Control-Allow-Credentials: true` para origens permitidas (Tauri WebView e app).
-- Página de diagnóstico: `/portal/debug` exibe `get-session` e `machines/session` com os mesmos cookies da aba — útil para validar se o desktop está autenticado como máquina.
+- Página de diagnóstico: `/portal/debug` exibe `get-session` e `machines/session` com os mesmos cookies da aba — útil para validar se o desktop está autenticado como dispositivo.
   - O desktop pode redirecionar automaticamente para essa página durante os testes.
 - Webhook FleetDM: `POST /api/integrations/fleet/hosts` (header `x-fleet-secret`) sincroniza inventário/métricas utilizando `machines.upsertInventory`.
 - Script `ensureMachineAccount` garante usuário `AuthUser` e senha sincronizada com o token atual.
@@ -73,7 +73,7 @@ Legenda: ✅ concluído · 🔄 em andamento · ⏳ a fazer.
 - O agente coleta `extended.windows.osInfo` via PowerShell/WMI. Caso o script falhe (política ou permissão), aplicamos um fallback com `sysinfo` para preencher ao menos `ProductName`, `Version` e `BuildNumber` — evitando bloco vazio no inventário exibido.
 
 ### Portal do Cliente (UX)
-- Quando autenticado como máquina (colaborador/gestor):
+- Quando autenticado como dispositivo (colaborador/gestor):
   - O portal deriva o papel a partir do `machineContext` (mesmo se `/api/auth/get-session` vier `null`).
   - A listagem exibe apenas os tickets onde o colaborador é o solicitante.
   - Informações internas (Fila, Prioridade) são ocultadas; o responsável aparece quando definido.
@@ -81,7 +81,7 @@ Legenda: ✅ concluído · 🔄 em andamento · ⏳ a fazer.
 - O botão “Sair” é ocultado no desktop (faz sentido apenas fechar o app).
 - Variáveis `.env` novas: `MACHINE_PROVISIONING_SECRET` (obrigatória) e `MACHINE_TOKEN_TTL_MS` (opcional, padrão 30 dias).
 - Variável adicional `FLEET_SYNC_SECRET` (opcional) para autenticar webhook do Fleet; se ausente, reutiliza `MACHINE_PROVISIONING_SECRET`.
-- Dashboard administrativo: `/admin/machines` usa `AdminMachinesOverview` com dados em tempo real (status, heartbeat, token, inventário enviado pelo agente/Fleet).
+- Dashboard administrativo: `/admin/devices` usa `AdminMachinesOverview` com dados em tempo real (status, heartbeat, token, inventário enviado pelo agente/Fleet).
 
 ### Checklist de dependências Tauri (Linux)
 ```bash

docs/archive/status-2025-10-16.md

@@ -13,8 +13,8 @@ Documento de referência sobre o estado atual do sistema (web + desktop), melhor
 
 | Item | Descrição | Impacto |
 | --- | --- | --- |
-| **Centralização Convex** | Helpers `createConvexClient` e normalização do cookie da máquina (`src/server/convex-client.ts`, `src/server/machines/context.ts`). | Código das rotas `/api/machines/*` ficou mais enxuto e resiliente a erros de configuração. |
-| **Auth/Login redirect** | Redirecionamento baseado em role/persona sem uso de `any`, com dependências explícitas (`src/app/login/login-page-client.tsx`). | Evita warnings de hooks e garante rota correta para máquinas/colaboradores. |
+| **Centralização Convex** | Helpers `createConvexClient` e normalização do cookie da dispositivo (`src/server/convex-client.ts`, `src/server/machines/context.ts`). | Código das rotas `/api/machines/*` ficou mais enxuto e resiliente a erros de configuração. |
+| **Auth/Login redirect** | Redirecionamento baseado em role/persona sem uso de `any`, com dependências explícitas (`src/app/login/login-page-client.tsx`). | Evita warnings de hooks e garante rota correta para dispositivos/colaboradores. |
 | **Ticket header** | Sincronização do responsável com dependências completas (`ticket-summary-header.tsx`). | Removeu warning do lint e previne estados inconsistentes. |
 | **Upgrade para Next.js 16 beta** | Dependências atualizadas (`next@16.0.0-beta.0`, `eslint-config-next@16.0.0-beta.0`), cache de filesystem do Turbopack habilitado, scripts de lint/test/build ajustados ao novo fluxo. | Projeto pronto para validar as novidades do Next 16 (React Compiler opcional, prefetch incremental, etc.); builds e testes já rodando com sucesso. |
 | **Posture / inventário** | Type guards e normalização de métricas SMART/serviços (`convex/machines.ts`). | Reduziu `any`, melhorou detecção de alertas e consistência do metadata. |
@@ -39,7 +39,7 @@ Documento de referência sobre o estado atual do sistema (web + desktop), melhor
 
 | Cenário | Sintoma | Como resolver |
 | --- | --- | --- |
-| Token de máquina revogado | POST `/api/machines/sessions` retorna 401 e desktop volta ao onboarding | Reprovisionar pela UI do agente; garantir que `machineToken` foi atualizado. |
+| Token de dispositivo revogado | POST `/api/machines/sessions` retorna 401 e desktop volta ao onboarding | Reprovisionar pela UI do agente; garantir que `machineToken` foi atualizado. |
 | Falha de heartbeat | Logs com `Falha ao registrar heartbeat` + status 500 | Verificar `NEXT_PUBLIC_CONVEX_URL` e conectividade. Roda `pnpm convext:dev` em DEV para confirmar schema. |
 | Updater sem atualização | Desktop fica em “Procurando atualização” indefinidamente | Confirmar release publicado com `latest.json` apontando para URLs públicas do bundle e assinaturas válidas. |
 
@@ -47,6 +47,6 @@ Documento de referência sobre o estado atual do sistema (web + desktop), melhor
 
 - Monitorar execução do novo workflow de qualidade em PRs.
 - Garantir que a equipe esteja ciente do procedimento atualizado de deploy (symlink + service update).
-- Revisar backlog acima e priorizar smoke tests para o fluxo da máquina.
+- Revisar backlog acima e priorizar smoke tests para o fluxo da dispositivo.
 
 _Última atualização: 16/10/2025 (UTC-3)._ 

docs/desktop/handshake-troubleshooting.md

@@ -1,9 +1,9 @@
-# Desktop (Tauri) — Handshake, Sessão de Máquina e Antivírus
+# Desktop (Tauri) — Handshake, Sessão de Dispositivo e Antivírus
 
 Este documento consolida as orientações e diagnósticos sobre o fluxo do agente desktop, handshake na web e possíveis interferências de antivírus.
 
 ## Sintomas observados
-- Ao clicar em “Registrar máquina”, o antivírus aciona (ex.: ATC.SuspiciousBehavior) e o processo é interrompido.
+- Ao clicar em “Registrar dispositivo”, o antivírus aciona (ex.: ATC.SuspiciousBehavior) e o processo é interrompido.
 - Após o registro, ao abrir a UI web: cabeçalho mostra “Cliente / Sem e‑mail definido” e o Portal não permite abrir chamados.
 - No passado, mesmo quando o app “entrava direto”, o Portal não refletia o colaborador/gestor vinculado (sem assignedUser); receio de repetir o problema.
 
@@ -19,11 +19,11 @@ Este documento consolida as orientações e diagnósticos sobre o fluxo do agent
 ## O que já foi aplicado no projeto
 - Middleware permite `GET /machines/handshake` sem exigir login (rota pública).
 - Frontend preenche `machineContext` chamando `GET /api/machines/session` (assignedUserId/email/nome/persona) e usa esse ID ao abrir chamados.
-- UI oculta “Sair” quando a sessão é de máquina (portal e shell interno).
+- UI oculta “Sair” quando a sessão é de dispositivo (portal e shell interno).
 - DevTools habilitado no desktop (F12, Ctrl+Shift+I ou botão direito com Ctrl/Shift).
 - Desktop salva dados em `C:\\Raven\\data\\machine-agent.json` (ou equivalente ao lado do executável), com fallback para AppData se a pasta do app não permitir escrita.
 
-## Validação rápida (após “Registrar máquina”)
+## Validação rápida (após “Registrar dispositivo”)
 1) No executável, com DevTools:
    ```js
    fetch('/api/machines/session').then(r => r.status).then(console.log)
@@ -33,7 +33,7 @@ Este documento consolida as orientações e diagnósticos sobre o fluxo do agent
    ```
 2) Na UI (Portal/Topo):
    - Mostrar nome/e‑mail do colaborador/gestor (não “Cliente / Sem e‑mail definido”).
-   - Sem botão “Sair” (sessão de máquina).
+   - Sem botão “Sair” (sessão de dispositivo).
 3) No Portal, o formulário “Abrir chamado” deve habilitar normalmente (usa `machineContext.assignedUserId`).
 
 Se `GET /api/machines/session` retornar 403:
@@ -68,4 +68,4 @@ Se `GET /api/machines/session` retornar 403:
 
 ---
 
-Última atualização: automatização do handshake no middleware, ocultação de “Sair” em sessão de máquina, dados persistidos junto ao executável e DevTools habilitado.
+Última atualização: automatização do handshake no middleware, ocultação de “Sair” em sessão de dispositivo, dados persistidos junto ao executável e DevTools habilitado.

docs/desktop/updater.md

@@ -12,7 +12,7 @@ Este guia consolida tudo o que precisa ser feito para que o auto-update do Tauri
    ```
    - Privada: `~/.tauri/raven.key` (nunca compartilhar)  
    - Pública: `~/.tauri/raven.key.pub` (cole em `tauri.conf.json > plugins.updater.pubkey`)
-   - Se for buildar em outra máquina (ex.: Windows), copie os dois arquivos para `C:\Users\<usuario>\.tauri\raven.key(.pub)`.
+   - Se for buildar em outra dispositivo (ex.: Windows), copie os dois arquivos para `C:\Users\<usuario>\.tauri\raven.key(.pub)`.
 
 2. **Verificar o `tauri.conf.json`**
    ```json

docs/historico-agente-desktop-2025-10-10.md

@@ -61,8 +61,8 @@ Referências úteis:
     - Abrir no navegador padrão com `openUrl` (`apps/desktop/src/main.ts:694`).
     - Se necessário, limpar Store via botão "Reprovisionar" (Configurações) ou removendo o arquivo `machine-agent.json` no diretório de dados do app.
 - Mensagem de erro genérica no desktop:
-  - Antes: "Erro desconhecido ao registrar a máquina".
-  - Agora: exibe `Falha ao registrar máquina (STATUS): mensagem — detalhes` (quando disponíveis), facilitando diagnóstico.
+  - Antes: "Erro desconhecido ao registrar a dispositivo".
+  - Agora: exibe `Falha ao registrar dispositivo (STATUS): mensagem — detalhes` (quando disponíveis), facilitando diagnóstico.
 
 ## Provisionamento — segredo e boas práticas
 - Variável: `MACHINE_PROVISIONING_SECRET` (VPS/Convex backend).
@@ -74,7 +74,7 @@ Referências úteis:
      docker service update --force sistema_convex_backend
      ```
   3. Validar com `POST /api/machines/register` (esperado 201).
-- Máquinas já registradas não são afetadas (token delas continua válido).
+- Dispositivos já registradas não são afetadas (token delas continua válido).
 
 ## Pendências e próximos passos
 - Mapear erros "esperados" para HTTP adequado no web (Next):
@@ -90,9 +90,9 @@ Referências úteis:
 
 ## Checklist rápido de verificação (QA)
 - `.env` do desktop contém apenas `VITE_APP_URL` e `VITE_API_BASE_URL` apontando para produção.
-- Primeiro registro sem empresa retorna 201 e aparece "Máquina provisionada" nas abas.
+- Primeiro registro sem empresa retorna 201 e aparece "Dispositivo provisionada" nas abas.
 - "Ambiente" e "API" em Configurações exibem `https://tickets.esdrasrenan.com.br`.
-- "Abrir sistema" abre o navegador com `/machines/handshake?token=...` e loga a máquina.
+- "Abrir sistema" abre o navegador com `/machines/handshake?token=...` e loga a dispositivo.
 - Reprovisionar limpa a Store e volta ao formulário inicial.
 
 ---